Managing Requirements in a Structured Manner

Why Do We Need to Manage Requirements in a Structured Manner?

We do not need structured management of software project requirements in all circumstances. If it is a transaction management requirement on the recording and status tracking during implementation, which does not need continuous tracking and requirement association maintenance afterwards, structured requirement management is not required. In this case, both the Scrum and Kanban project templates of CodeArts can be used to manage requirements and software projects. Structured requirement management is required only when there are a large number of interrelated requirements and implemented requirements need to be managed and maintained. In this case, we need to use the Scrum project template in CodeArts, whose "Epic-Feature-Story" structure and requirement planning function are helpful for structured management.

What Is Structured Requirement Management Based on?

Software R&D is either project-based or product-based. In general, the former is temporary or short-term, while the latter is long-term or requires continuous maintenance and update of functions and features. We can achieve project objectives and deliver the required functions and features by continuously improving the software product or system. This means that our structured requirement management needs to be based on product or system functions and features. Information such as versions, customers, and modules that software project management focuses on can be implemented through different attributes or even tags of requirements.

Using CodeArts for Structured Requirement Management

The recommended procedure is as follows:

• Step 1: Create a CodeArts project.

  Create a CodeArts project for a product or system. All requirements of the product or system are managed in the CodeArts project.

• Step 2: Establish an "Epic-Feature-Story" requirement structure.
  1. Epic needs to carry business value, that is, an epic needs to be meaningful to the enterprise itself.

     Service modules of a product or system, such as the user center, shopping cart, and delivery management, can be an epic. For example, it is suitable for a cloud-based freight company to take the fuel card service as an epic so that functions related to the fuel card can be used as features.

  2. Feature needs to bring benefits to users. That is, users can understand and recognize the value of a feature. Generally, a feature can be directly perceived and operated by users.

     Features are what service modules are broken down into. Simply speaking, a feature is a service or user process. If the user center is taken as an epic, user information, order management, or address management can be a feature. If the fuel card service is taken as an epic, purchasing a fuel card or managing fuel cards can be a feature.

  3. A feature is usually large and complex. Therefore, it needs to be broken down to small-granularity stories to carry a specific user operation.

     For example, viewing all orders, filtering orders, changing user aliases, and customize profile pictures are stories.

  4. Tasks, at one level lower than stories, are mainly used for work division and collaboration. That is, stories that can be assigned to specific people do not need to be broken down.

     Tasks are specific work that engineers need to do, which are irrelevant to the business value, user value, and single operations of users. Generally, stories are broken down into tasks based on specific components and modules (such as front end, background, and database) or work processes (such as UCD, development, test, and deployment).

  The following figure is an example:

  • Epic: user center
  • Feature: address management
  • Story: address creation
  • Task: [Web client] page entry and address editing form or [Database] user address data table design and implementation
    Figure 1 Requirement planning
    
• Step 3: Manage different modules and versions based on work item attributes.
  Figure 2 shows the attributes on the work item details page.

  • Module: web client.
  • Release Version: 1.0.1.2.
    Figure 2 Attribute example
    

  To maintain a module list, click next to the Module field on the editing page of the work item. In the displayed window, you can add, modify, or delete a module.

  Figure 3 Editing a module
  

  In the backlog view of work item management, after adding the Module field in the Select Field window, you can easily view the modules related to the work item and filter the modules.