This is the 14th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

The preface

In requirements management, we always encounter various problems. For example: β‘  the implicit error of requirements; (2) Customers continue to increase demand, change demand; (3)… . Often these requirements are the root cause of our project failure. ‘

Then, we first use a picture to analyze the reasons for the failure of the project. The details are as follows:

Based on the above analysis, it is natural for us to know the unshakable status of software requirements in software project management.

In the following articles, we will look at all aspects of software requirements.

Ding, start learning ~πŸ‘

I. Definition and hierarchy of software requirements

1, define,

Refers to the user’s requirements for software functions and performance. (What users want the software to do, what functions it performs, and what performance it achieves)

2, level

The hierarchy of software requirements consists of the following three aspects:

Business requirements β†’ user requirements β†’ functional requirements

Second, software requirements management process

1. Management process

The process of software requirement management includes two aspects, namely requirement development and requirement management.

The path of requirement development is: requirement acquisition β†’ requirement analysis β†’ requirement specification writing β†’ requirement verification; Requirements management refers to: requirements change.

We will analyze these concepts one by one.

2. Demand acquisition

First of all, we have to analyze the user’s requirements, after the analysis is completed, then we have to get the user’s requirements, and let the software to achieve it. Then the software gets the software requirements. As shown below:

3. Demand analysis

Requirements analysis is to establish a conceptual model of the system as seen by the end user. It is an abstract description of the requirements. As shown below:

4. Preparation of requirements and specifications

A basic sign of the completion of requirements analysis is the formation of a complete, standardized requirements specification.

5. Requirements verification

After identifying the requirements, we need to verify the following:

  • Are the requirements right?
  • Are the requirements consistent?
  • Is the demand complete?
  • Are the requirements realistic?
  • Is demand necessary?
  • Are requirements verifiable?
  • Are requirements traceable?
  • Final signature

6. Requirements change

At some point in the software cycle, we will encounter requirements that change. For requirements change, the following are the main things to know.

(1) Main work of demand change management

The main tasks of requirement change management include:

  • Establish a requirement baseline
  • Determine the requirements change control process
  • Establish change controlThe committee (SCCB)
  • Conduct requirement change impact analysis
  • Track all work products affected by requirements changes
  • Establish requirements baseline version and requirements control version documentation
  • Maintain a history of requirement changes
  • Track the status of each requirement
  • Measure demand stability

(2) Demand change control process

The control process of demand change is shown in the figure below:

Three, software requirements analysis method

1. Prototype analysis method

The prototype analysis method needs to go through three steps, namely demand analysis β†’ prototype method β†’ prototype evaluation. As shown below:

2. Structured analysis (based on data flow modeling)

(1) Definition

  • A data flow oriented approach developed in the 1970s
  • Is a top – down refinement of the analysis method
  • According to the software internal data transfer, transformation of the relationship for analysis

(2) Techniques of structured analysis methods

  • Data flow diagram(DFD)
  • The data dictionary(DD)
  • E-R ε›Ύ
  • System flow chart

3. Object-oriented Use Case analysis (based on UML Modeling)

(1) Definition

  • Scenario analysis method based on object – oriented
  • Functional requirements considered from the user’s perspective
  • A use case is a function of the system that provides a valuable result to the user

(2) UML requirements view

  • Use Case Diagram
  • Sequence Diagram
  • State Diagram
  • Activity Diagram

4. Feature list

(1) Legend

The legend of the function list method is as follows:

(2) An instance based on a feature list

Now, let’s look at an example based on a feature list. As shown below:

5. Agile analysis

Agile analysis consists of the following three parts:

  • User Story template

    As a<type of user>,
I want<some goal>,
So that<some reason>.
Copy the code

    User stories are often written on cards and then deployed on the wall for easy discussion.

  • Evaluating user stories

  • User story iteration priority

    β‘  Must have; (2) should have; β‘’ Could/could/couldCopy the code

4. Task decomposition

1. Definition of task decomposition

(1) Definition

  • Task breakdown refers to the breaking down of a project into more work items or sub-items to make the project smaller, more manageable, and easier to operate.

(2) WBS and work packages

  • WBS, i.e.,Work Breakdown StructureRepresents the task decomposition structure.WBSIt’s the result of task breakdown.
  • Work package, yesWBS Lowest levelDeliverable, yesWBSThe smallest element of.

(3) The difference between WBS and work packages

The differences between WBS and workpacks are as follows:

  • WBSIs the projectFrom coarse to fineDecomposition process;
  • WBS 是Interactive results-oriented;
  • At the same time,WBSThe organization defines the overall project scope;
  • whileThe work packageisWBS δΈ­Lowest levelDeliverables (as shown below);
  • And the work package should be the responsibility of a single agent.

2. Form of task decomposition

There are two main forms of task decomposition, namely:

  • Chart form (Organizational structure diagram)
  • The skeleton type

(1) WBS in chart form (Organizational Structure Diagram)

As shown below:

(2) Outline formula

Something like this:

1 Change counter 1.1 Compare the two versions of the program 1.1.1 1.1.2 1.1.3 1.2 Find the lines of code added and deleted in the modified program 1.2.1 1.2.2 1.3 Count the lines of code added and deleted in the modified program 1.3.1 1.3.2Copy the code

3. Task decomposition process

(1) Five steps

The process of task decomposition should go through three processes: input β†’ decomposition β†’ WBS. There are the following steps:

  • Identify and break down the major components of the project

  • Confirmation of decomposition criteria

  • Verify that the decomposition is detailed

  • Identify project deliverables (WBS dictionary can be written)

  • Verify the correctness of decomposition

(2) Decomposition criteria

There are two standards for the process of task decomposition:

  • Decomposition criteria should be unified;
  • You can’t use both criteria for decomposition.

(3) Illustration of decomposition standards

The first: decomposition standards should be unified

The second kind: cannot use two kinds of standard to carry on decomposition simultaneously

(4) WBS dictionary

The WBS dictionary is shown below:

4. Task decomposition method

There are four methods of task decomposition, which are:

  • The template reference
  • analogy
  • The top-down
  • From the bottom up

(1) Template reference

As shown below:

(2) Analogy

  • Some projects are similar in some way;
  • You can do something similarWBSFor reference.

(3) Top down

As shown below:

(4) Bottom-up

As shown below:

5. Result of task decomposition

(1) Test the decomposition result standard

  • Whether the lowest element is a necessary and sufficient condition to achieve the goal;
  • Whether there is duplication of the lowest level elements;
  • Whether each element is clearly and completely defined;
  • Whether there is a clearly defined person responsible for the lowest level element;
  • Are cost estimates and schedules available?

(2) WBS task decomposition suggestions

  • The lowest level is manageable and manageable, but not necessarily too detailed;
  • eachWork packageThere has to be onesubmission;
  • Define criteria for task completion;
  • Conducive to responsibility distribution;
  • It is recommended to break tasks down to less than 40 hours.

V. Concluding remarks

In the above article, we explained requirements management and task decomposition in software project scope planning, and analyzed software requirements analysis from many aspects.

This is the end of this article! Hope to help you ~

πŸ›΅ column through train

Software Project Management πŸ‘‰juejin.cn/column/7024…