Requirement Management Process

Updated on 2024-10-31 GMT+08:00

View PDF

Scrum is an incremental, iterative, and agile software development method. It enables continuous delivery through sprints, which are cycles of closed-loop software development from user requirements management to user feedback implementation.

In Scrum projects, requirements can be managed in the four-layer hierarchy: Epic > Feature > Story > Task, as shown in Figure 1.

Figure 1 Scrum project requirement breakdown model

Table 1 describes the work item types used by Scrum projects.

**Table 1** Scrum project work items
Work Item Type	Description	Example
Epic	An epic is a key strategy of an enterprise, such as the major business direction or technical evolution. By discovering, defining, investing in, managing, and implementing epics, enterprises can realize their strategies and gain market shares and returns. Since an epic is a high-level description of requirements, it needs to be broken down into features, which are further divided into stories for development and delivery. It usually takes several months, or multiple sprints to deliver an epic. Epics should be visible to all developers so that they can understand the strategic meaning and values of the to-be-delivered stories in a bigger picture.	An epic is defined based on an enterprise's operations, competitiveness, and market environment. Examples are as follows: Market differentiation: Deliver better user experience than competitors. Better solution: Develop a solution for the industrial Internet. Revenue growth: Increase paid users by 1 million in the next fiscal quarter. Major technical direction: Deploy all products on containers.
Feature	A feature is a product function that delivers benefits to customers. Features come from epics and are broken down into stories. Features are more specific and intuitive than epics, and are often included in the release notes distributed to customers during product release. It usually takes several weeks, or several sprints to deliver a feature.	The description of a feature should specify its values for customers, product form, and delivery mode. Recommended template: As a <user role> I want <results> So that <purposes> User A wants to import and export data, so that they can efficiently organize data in batches. User B wants to receive notifications of due tasks, so that they can handle the tasks in time. User C wants to have a better drag-and-drop experience, so that they can perform operations more quickly. User D wants to create an alias, so that they can be more easily identified and remembered.
Story	"Story" is short for user story. Stories are created from features to describe more detailed product requirements from the perspective of users. Stories are listed by priority in a dynamic backlog where the order is continuously adjusted to suit actual requirements. The higher the stories are located in the backlog, the sooner they will be developed and delivered to customers. A story must comply with the INVEST principle: Independent: Each story should be independent and can be delivered to customers independently. Negotiable: A story does not need to describe specific functions. The details should be negotiated and determined by developers and customers during development. Valuable: A story must deliver values to customers. Estimable: The workload of a story can be estimated. Small: A story should be small enough so that it can be completed in a sprint. Testable: A story should be testable. A story should be delivered in days within a sprint. You can estimate the workload of stories by person-hours, person-days, or story points. Story point estimation is used for agile development. This method estimates the costs for story delivery, including the efforts, complexities, and risks. The Fibonacci series (1, 1, 2, 3, 5, 8...) is commonly used to size a story in a relative manner. For example, the workload of a story with 3 story points is three times as large as that of a story with 1 story point. Story points are measured by the Fibonacci series by default.	Examples of stories in compliance with INVEST: Recommended template: As a <user role> I want <results> So that <purposes> As a project manager, I want to filter requirements by handler, so that I can quickly locate a specific requirement. As a developer, I want to collapse some unnecessary information, so that visual distraction can be reduced. As a tester, I want to associate test cases with requirements, so that I can track the verification progress of requirements.
Task	In a sprint planning meeting, stories scheduled in a sprint are assigned to members and broken down into one or more tasks with estimated workloads.	Tasks focus on series of actions that lead to a goal. Examples are as follows: Developer A needs to prepare a production-like environment today. Developer B needs to complete the permission settings for the project team this week. Developer C needs to review the code.
Bug	Bugs are created to track problems of software functions found during testing and verification. Bugs can be prioritized. Bugs can be created and tracked separately. You can also create bugs when verifying a story. The bugs are child work items of the story, helping you identify the number of issues. The bug description should be as detailed as possible, including but not limited to: Symptoms: You are advised to describe symptoms from the perspective of users. Error code: The error code can be used to locate and analyze code problems. Environment: Including the development, test, or live network environments. Software stack: Including the operating system and database and their versions. Whether the bug can be reproduced and how this can be done.	An example template for bug description: [Symptom] [Error Code (Obtained by Pressing F12)] [Environment] [Fault Reproduction Procedure] [Onsite Fault Locating R&D Engineer] [Preliminary Fault Locating] [Packets Captured Using Google Chrome]