Demand and business model innovation - demand 3- demand engineering process

Book3- Requirements engineering process

1. Requirements engineering process

1. A process is an integration of a set of related activities , Through the implementation of these activities , Can complete a task or achieve a goal .
2. Requirements engineering process is the integration of requirements development activities in system development , He takes the business problems faced by users as the starting point for analysis and various transformations , Finally, a system solution that can solve users' business problems in the user environment is generated , And document it into clear requirements

3. Above right , Requirements engineering activities are intertwined , The whole development activity is also iterative and increasing .
4. Different projects have different requirements engineering processes
   1. Large scale military systems will have strict requirements engineering process
   2. Requirements engineering for small, innovative software companies may be just some brainstorming sessions .
5. From the perspective of hierarchy of requirements, requirements development

6. Common documents ：
   1. Project prospect and scope document ： Define the business requirements of the system , Define the direction and scope of the system .
   2. User requirements document ： Define user requirements , It expresses the expectation of the system behavior from the user's standpoint , For example, use case documents .
   3. Requirements specification document ： The system level requirements of the system are defined , It points out the tasks that developers should complete .
      1. System specifications ： Including the requirements of the whole system
      2. Software specifications ： The software requirements

2. Activities of requirements engineering process

2.1. Demand acquisition

1. Requirements are obtained from people 、 Information or environment The process of obtaining requirements
2. Requirements engineers must take advantage of Various methods and techniques Come on " Find out " demand
3. Requirements acquisition and analysis are Interweave Of ： The target model used in establishing the project prospect and scope in the first half of requirements acquisition can also be regarded as a typical model-based requirements analysis

2.1.1. Collect background information

In depth understanding of the need to build a knowledge framework , It is the knowledge base for communicating with users .

2.1.2. Get problems and goals , Define the prospect and scope of the project

1. Generate business requirements , Define what the system needs to achieve .
2. When requirements conflict between users , The project prospect can be used to guide the negotiation and resolution of requirements conflicts .
3. Demand acquisition faces a wide range of information ：
   1. Don't spend too much on irrelevant content .
   2. Do not omit the important contents that should be obtained .
4. Business requirements of the project 、 The foreground and scope will be recorded in the foreground and scope document of the project .
5. The content of the document helps strengthen investor confidence ( Project clarification )

2.1.3. Identify stakeholders , Choose the source of information

1. Stakeholder analysis ： Select a few users to represent all users , So we need to classify users , Find the user representative
2. Hard data sampling ： Forms 、 report form 、 Hard data such as memos is another important source of information that needs to be obtained ： They use more clearly 、 Regulations and accurate way to describe the actual business , But we need to use appropriate methods for sampling .
3. Related products 、 Documents, domain experts, etc. may also be the source of requirements .

2.1.4. Choose the acquisition method , Execute get

Interview ( questionnaire )、 Observe 、 Prototype ( It needs to go deep into )

2.1.5. Record the results ( Raw information not finished )

1. The main results of the requirements acquisition phase are business requirements 、 Project prospects and scope 、 User requirements and problem domain characteristics .
   1. Prospect and scope documentation Business needs
   2. Get notes User requirements and problem domain characteristics
2. The obtained records may be messy 、 Ambiguity and so on .

2.2. Demand analysis

1. The main work of requirement analysis is modeling to integrate all kinds of information , So that people can better understand the problem ： Refinement of information 、 Provide support for creative activities , Complete the conversion of content
   1. Define a for the problem Demand set , This set can define an effective solution to the problem
   2. Check what exists in the requirements error 、 missing 、 atypism And other defects , And amend it ： Make use of the syntax and semantics of the model itself
2. At the end of requirement analysis, a requirement will be generated Baseline set . It specifies the tasks that need to be completed for system development .
   1. Under the condition of limited resources, the baseline set is often a subset of the functions required by users .
   2. The requirements in the baseline set require the characteristics of excellent requirements , In particular, inconsistencies and conflicts should be resolved .

2.2.1. Background analysis

1. Because the system must interact with the deployed environment to solve the user's problems , So in system development , Especially requirements development , It is important to study the environment in which the system will be deployed .
2. Analysis and understanding of the environment , Help requirements engineers form a knowledge framework about user business , It is conducive to effective communication with users in the detailed requirements acquisition activities .
3. Background the analyst studies part of the system environment . Complex environments require specialized analysis methods , Such as domain analysis and enterprise modeling .

2.2.2. Business analysis ( Problem analysis 、 Goal analysis 、 Stakeholder analysis ), Determine system boundary ( Business needs )

1. The definition of system boundary should ensure that the system and the surrounding environment form an effective interaction , And solve the problems of users in the interaction , Meet business needs .
2. System use case diagrams and context diagrams are often used to define system boundaries .

2.2.3. Software requirements modeling

1. Modeling is an abstract description activity for presenting and interpreting information .
2. Modeling helps requirements engineers have a deeper understanding , More convenient for information transmission .
3. Requirements modeling techniques include data flow diagrams 、 Entity relation diagram 、 State transition diagram 、 Class diagram and other semi formal modeling techniques , as well as Z Models and other more rigorous formal techniques .

2.2.4. Refine requirements

1. User requirements are often vague 、 Ambiguity and so on .
2. Get the system level requirements according to the model

2.2.5. prioritizing

1. Regular evaluation and adjustment
2. In the case of limited and insufficient development resources, the priority should be dynamically adjusted .

2.2.6. Demand negotiation

1. Sometimes, in the analysis, the requirements conflict between users does not occur , In this case, the respective needs of users are reasonable , But it is impossible to be involved in the system at the same time .
   1. Different user needs are hostile
   2. Insufficient system resources
2. The requirements engineer should find out the conflict in time through analysis , And provide technical reference information for dealing with conflicts , Organize and guide the negotiation between users

2.3. Requirements specification

1. The acquired requirements need to be documented , The main purpose is to Exchange requirements information among system stakeholders
   1. The business requirements are written into the project prospect and scope document
   2. User requirements are written into the user requirements document ( Or use case documents )
   3. The system requirements are written into the requirements specification
2. The most important quality requirement is concise 、 accurate 、 Consistent and easy to understand .

2.3.1. Custom document templates

1. Development talks about maintaining some document templates internally for documents that need to be written .
2. Reference resources IEEE1998 Recommended specification documents .
3. The requirements engineer needs to further customize the reference template of the organization according to the characteristics of the project .

2.3.2. Document

1. Choose the most accurate expression
2. Ensure good structure and legibility of documents .
3. The way
   1. Model language ( graphics 、 Expression etc. )： Ensure the accuracy of information transmission .
   2. Natural language ( Text )： Ensure that the document is readable .

2.4. Requirements validation

1. Ensure that the requirements specification document can correct 、 accuracy Reflect the user's intention
2. Ensure high quality standards for documentation
   1. In the document Each requirement All right 、 It accurately reflects the user's intention
   2. The documented set of requirements is in whole Have on Integrity and consistency
   3. The organization of documents and the writing of requirements have Readability and modifiability

2.4.1. Execution verification

1. Peer review ： The most commonly used
2. Prototype ： The cost is high
3. simulation ： The cost is high

2.4.2. Problem correction

Follow up after correction to ensure implementation

2.5. demand management

1. Ensure that the requirements act on the whole software Product life cycle Medium continued 、 Stable and effective play
2. Demand management will perform change control , Incorporate and implement reasonable change requests , Reject unreasonable change requests , Control the cost and impact scope of the change .
3. In business time , Requirements change is considered to be one of the two main causes of project failure .
4. CMMI(Capability Maturity Model Integration, Software capability maturity model integration ) Take it as the key process area that all level 2 maturity enterprises should have .

2.5.1. Establish and maintain requirements baseline set

1. Establish good configuration management , Versioning baselines , It is the premise and foundation for effective demand management .
2. Implement baseline version control , First, identify each requirement , Record its related attributes , Such as ID、 source 、 Generation date 、 Reason for 、 Priority and pre implementation cost, etc , Then create a unique version number identification for each requirement document .
3. After version control is established , All changes 、 The date and reason of the change shall be recorded , And communicate it to everyone affected .

2.5.2. Establish requirements tracking information

1. Starting from system level requirements .
2. Backward tracking ： Track the design of various system level requirements 、 Which artifacts are implemented , And go back to each design 、 What requirements does the implementation artifact exist for .
3. Forward tracking ： Trace back to which user and business requirements are supported by each system level requirement , And track each business requirement 、 How user requirements are translated into system level requirements .

2.5.3. Change control

1. The variability of the real world , After establishing the baseline, the project should still respond to external demand change requests in a timely manner , But it must be under control ,
2. To realize change control, we first need to establish a change control process and related strategies , We also need to select experienced users and developers to form a change control team , Analyze the gains and losses of interests 、 Accept or not .
3. Strive to achieve semi automation

3. Concurrency and iteration of requirements engineering process

Requirements development is iterative , Its important activities demand acquisition and demand analysis are intertwined .

3.1. Analysis model complexity in requirements development

1. Theoretically, as time goes on , Get more content , The overall complexity should always increase linearly .
2. The decline is due to the possible knowledge reconstruction process of knowledge accumulation to a certain extent .
3. obtain 、 analysis $\to$ restructure $\to$ Get more 、 analysis $\to$ Reconstruction

3.2. Iterative requirements development process model

Iterativeness of requirements development

3.3. Concurrency of requirements development activities

1. Requirements development is more than iterative , The activities are concurrent .
2. among , Classification belongs to the requirements analysis activities of this book .

4. Application of practical methods

1. Personal intelligence $\to$ Practice method $\to$ Knowledge system
2. The engineering field has been explored for quite a long time , From a large number of individual behaviors of producers, effective working methods are summarized , There is still a long way from the requirements of knowledge system , But they can help people to complete engineering practice , So it is called practical method ( principle )
3. The requirements engineer needs to select... For the organization or project 、 Customize and apply some effective practices

4.1. Practice method

4.2. Management practice

5. Requirements engineering process example

5.1. Requirements development process model suitable for spiral model of software development

1. Spiral model is used for requirement development of risk driven projects
2. Negotiation and modeling are requirements analysis activities .

5.2. A requirements development process that relies on a prototype approach

1. Domain analysis and prototype development are requirements acquisition activities .
2. The development of basic and high-order models is a requirement analysis activity .
3. Peer review 、 Scenario walk through and stakeholder feedback are requirements verification activities .
4. characteristic ： With the help of the prototype and the validation of the analytical model , Add stakeholder comments 、 feedback , Requirements verification can be completed without relying on software specification documents , Then, the verified high-quality requirements are documented .

5.3. HP The demand process of the company

1. Divide requirements development into two parts
   1. System requirements development of system engineering
   2. Requirements analysis of software engineering
2. It is applicable to the development of innovative products or large-scale projects .
3. After the system requirements development is completed and the feasibility analysis is passed , Before the software product development stage .

5.4. Practices-Based

1. Requirements development process based on requirements practice method , The requirements practice method is divided into many types to evaluate and improve the process
   1. Basic practice ： Complete the most basic requirements development tasks , necessary .
   2. Advanced practice ： Make some parts of requirements engineering better .
   3. Optimization Practice ： Not necessary , It can further improve the effect of requirements engineering .
   4. Context dependent practices apply only to time in a particular context .

5.5. Agile RE The seven practices of

1. Face to face communication is better than writing specifications (User Story)
2. Iterative requirements engineering ;
3. Prioritize requirements to the limit ;
4. Manage demand changes through continuous planning ;
5. Prototype method ;
6. Test-driven development ;
7. User review meeting and acceptance test .

5.6. RUP

1. Emphasize best practices while giving a customizable process framework .
2. Different workflows work together to complete requirements development .

6. Requirements engineering process and software engineering

6.1. Waterfall

1. The problem domain of the software is mature and easy to define , And the demand is relatively stable
2. It is not conducive to the effective participation of users
3. Waterfall

6.2. Incremental

1. The problem domain of software is complex , But the business is very mature and the demand is relatively stable
2. It is not conducive to the effective participation of users
3. Incremental

6.3. Spiral/Evolutional

1. The problem domain is extremely complex or the requirements are unstable
2. Better respond to changing needs
3. Improve the effective participation of users
4. It makes the coordination and management of development work difficult
5. Spiral/Evolutional

6.4. Agile

1. The problem domain is not mature , Business activities are still evolving and changing
2. It can solve all kinds of uncertainties
3. Increases the cost of the requirements engineering phase , And prone to various prototype risks
4. Agile

6.5. summary

1. The requirements engineering process should be a part of the software engineering process , Rather than stand alone as a separate part
2. < Requirements Engineering and Software Project Success- An Industrial Survey in Australia and the US >
   1. Find out whether the method is good or bad compared to the requirements method itself , The adaptability of requirements method and software development method will affect the success or failure of the project . That means , Whether the requirements development method and software development method are suitable , It can affect the success or failure of the project more than the result demand
   2. Compared with proficiency in the application field , The ability of a project manager to effectively manage requirements is more important ;
   3. There is no need to establish complete requirements at the beginning of the project , A better way is to gradually improve the requirements in the subsequent stages of the project ;

6.6. Software Process Model in Practices

1. < Requirements Engineering-The State of the Practice >, 2003 – Traditional software engineering process pays more attention to requirements engineering process

7. The interaction between requirements development process and software engineering process .

1. " Demand engineering " It's positive sexual activity :
   1. Prospect and scope definition
   2. Stakeholder description
   3. The analysis model
   4. Description of requirements characteristics

1. Whether the requirements development method and software development method are suitable , It can affect the success or failure of the project more than the result demand .
2. The impact of demand on follow-up ：Requirements Engineering and Downstream Software Development: Findings from a Case Study, 2005
   1. Improve understanding of the details , Improve understanding of dependencies and complexities between features
   2. Save energy and waste
   3. Invisible benefits ： Improve communication
   4. Invisible benefits ： Help make decisions
   5. Estimate
   6. Change management
3. How to Manually Trace during Process [Watkins & Neal, IEEE Software1994]

8. Summary

1. Requirements engineering has its own lifecycle model , There is a requirements engineering process for requirements development
2. The requirements engineering process has some common requirements engineering activities ： Demand acquisition 、 Demand analysis 、 Requirements specification 、 Requirements validation and requirements management
3. Requirements development activities are intertwined 、 Concurrent 、 Iterations and increments Of
4. The successful implementation of the requirements engineering process requires the application of many effective practical methods
5. In practice , The process of requirements engineering is very different
6. Because it's in the front , The impact of requirements engineering on subsequent software development activities is very deep