System architecture design professional skills·Software engineering

Table of Contents of Series Articles

Advanced skills in system architecture design · Software architecture concepts, architectural styles, ABSD, architecture reuse, DSSA (1) [System Architect] Advanced
skills in system architecture design · System quality attributes and architecture evaluation (2) [System Architect]
Advanced skills in system architecture design · Software reliability analysis and design (3) [System Architecture Designer]

1. Software Engineering Concept★

Software development life cycle:

Software definition period : includes feasibility study and detailed requirements analysis process . The task is to determine the overall goal that the software development project must complete. It can be divided into problem definition, feasibility study, requirements analysis, etc.
Software development period : It is the design and implementation of software, which can be divided into outline design, detailed design, coding, testing , etc.
Software operation and maintenance : It means handing over software products to users .

Software system documentation:

Software system documentation can be divided into two categories: user documentation and system documentation . User documentation mainly describes system functions and usage , and does not matter how these functions are implemented; system documentation describes various aspects of system design, implementation, and testing .

The software engineering process refers to the following four aspects of activities (PDCA) to obtain software products :

P (Plan) - software specification : specifies the functions of the software and its runtime limitations.
D(Do) - Software Development : Develop software that meets specifications.
C (Check) - Software confirmation : Confirm that the developed software can meet the needs of users.
A (Action) - Software evolution : The software is continuously improved during operation to meet new customer needs.

Software system tools can usually be divided into software tools according to software process activities :

Software development tools : requirements analysis tools, design tools, coding and debugging tools, testing tools, etc.
Software maintenance tools : version control tools, document analysis tools, development information base tools, reverse engineering tools, and re-engineering tools.
Software management and software support tools : evaluation and selection of project management tools, configuration management tools, software evaluation tools, and software development tools.

There are four activities in software design :
data design, architecture (system structure) design, human-computer interface (interface) design, and process design .

1.1 Software Crisis

2. Software Capability Maturity Model

Capability Maturity Model for Software (CMM)

Ability level	Features	key process areas
initial level	The software process is characterized by being disorganized and sometimes chaotic, with few clearly defined steps, and the success of the project relying entirely on the efforts of individuals and the role of heroic core figures .
repeatable level	Basic project management processes and practices are established to track project costs, schedules, and features, and the necessary process disciplines are in place to repeat previous successes in similar projects.	Software configuration management, software quality assurance, software sub-contract management, software project tracking and supervision, software project planning, software requirements management
level defined	Software processes in both management and engineering have been documented, standardized, and integrated into standard software processes for the entire software development organization . All projects use standard software processes modified according to actual conditions to develop and maintain software .	Peer review, inter-group coordination, software product engineering, integrated software management, training outline, organizational process definition, organizational process focus
Already managed	Detailed metrics for software process and product quality are developed . Have quantitative understanding and control of software processes and product quality.	Software quality management and quantitative process management
Optimization level	Quantitative analysis has been strengthened, and the process can be continuously improved through feedback from process quality and feedback from new concepts and new technologies .	Process change management, technology change management and defect prevention

Capability Maturity Model Integration for Software (CMMI)
stage model. CMMI is developed on the basis of CMM and focuses on the maturity of the organization.

Ability level	Features	key process areas
initial level	Process is unpredictable and lacks control
Already managed	Process serves the project	Requirements management, project planning, configuration management, project supervision and control, supplier contract management, measurement and analysis, process and product quality assurance
level defined	Process serves the organization	Requirements development, technical solutions, product integration, verification, validation of organizational process focus, organizational process definition, organizational training, integrated project management, risk management, integrated teams, decision analysis and solutions, organizational integrated environment
Quantitative management	Process is measured and controlled	Organizational process performance, quantitative project management
Optimization level	Focus on process improvement and optimization	Organizational level reform and implementation, cause and effect analysis and solutions

3. Software process model

3.1 Waterfall model

The waterfall model (SDLC), also known as the life cycle method, is the most commonly used development model in the life cycle method. Software development is generally divided into: feasibility analysis (plan), requirements analysis, software design (outline design, detailed design), The stages of coding (including unit testing), testing, operation and maintenance, etc., stipulate their fixed order from top to bottom and interconnected with each other, like a waterfall, falling step by step. As shown in the picture:

Features of waterfall model:

• Accepts as input the work objects of this activity from the previous development activity .
• Using this input, implement the work that should be accomplished by the activity.
• The work results of this activity are given and passed to the next development activity as output.
• Review the results of the implementation of this activity. If the work results are confirmed, continue with the next development activity; otherwise, return to the previous or even more previous activity. Minimize repetitions between multiple stages. Develop software at a relatively small expense

The waterfall model is conducive to the organization and management of personnel in the large-scale software development process , and is conducive to the research and use of software development methods and tools, thus improving the quality and efficiency of large-scale software project development. However, the practice of software development shows that the above activities are not completely top-down, but are shown in a linear diagram. Therefore, the waterfall model has serious flaws:

• Because the development model is linear, users cannot see the effects of the software when the development results have not been tested. In this way, the time interval between the software and the user is longer, which also increases certain risks.
• When errors that are not discovered in the early stages of software development are spread to subsequent development activities, they may spread, which may lead to the failure of the entire software project.
• In the software requirements analysis stage, it is difficult, or even impossible, to completely determine all the user's needs.

3.2 Prototype model

The prototyping model is mainly aimed at software development where the requirements cannot be fully defined in advance. Based on the rapid development of a prototype , the prototype is improved and a new version of the prototype is obtained based on the feedback and suggestions provided by the user in the process of calling the prototype. This process is repeated until it evolves into the final software product.

The prototype method believes that when it is difficult to fully and accurately present user needs at once, the prototype should have the following characteristics:

• Practical and feasible .
• Has the basic characteristics of the final system .
• The structure is convenient and fast, and the cost is low . The characteristic of the prototype method is that the prototype method dynamically responds to user needs and gradually incorporates them .

About prototyping methods/models:

A software prototype is a partial implementation of a proposed new product. The main purpose of establishing a prototype is to solve the problem of uncertain requirements in the early stages of product development. Its purpose is to clarify and improve requirements, explore design options, and develop into the final product. product. Prototype models are more suitable for projects whose requirements are not clear enough .

There are many ways to classify prototypes. Depending on whether implements functions , software prototypes can be divided into two types : horizontal prototypes and vertical prototypes . Horizontal prototypes, also called behavioral prototypes, are used to explore some specific behaviors of the expected system and achieve the purpose of refining requirements. Horizontal prototypes are often just a navigation of functionality without actually implementing it. Horizontal prototypes are mainly used in interfaces . Vertical prototypes, also called structured prototypes, implement part of the functionality. Vertical prototyping is mainly used in complex algorithm implementations .

From the perspective of the final result of the prototype , software prototypes can be divided into throwaway prototypes and evolutionary prototypes . A discarded prototype is also called an exploratory prototype, which means that the prototype itself is abandoned after the expected purpose is achieved. Throwaway prototypes are mainly used to solve demand uncertainty, ambiguity, incompleteness, ambiguity, etc. Evolutionary prototypes provide the basis for developing incremental products and are part of the spiral model and part of the object-oriented software development process. Evolutionary prototypes are mainly used in projects that must be easy to upgrade and optimize, and are suitable for Web projects .

Some literature divides prototypes into experimental, exploratory and evolutionary types. The purpose of exploratory prototyping is to clarify the requirements for the target system, determine the desired features, and explore the feasibility of multiple solutions. Before experimental prototypes are used for large-scale development and implementation, assess whether the plan is suitable and whether the specifications are reliable. The purpose of evolutionary prototyping is not to improve specifications, but to build the system to be easy to change, and in the process of improving the prototype, gradually evolve the prototype into the final system.

Some literature also divides prototypes into throwaway prototypes, evolutionary prototypes and incremental prototypes.

The prototyping method is suitable when users do not have clear content to determine their needs. It first establishes an original model based on the given and analyzed requirements. This is a model that can be modified (in the life cycle method, after the requirements are analyzed into documents, no more modifications are generally required).

At each stage of software development, relevant information is fed back to each other until the model is modified, making the model gradually more perfect. In this process, user participation and decision-making are strengthened, and the final result is more suitable for user requirements.

This type of prototyping technology can be divided into three categories: throwaway, evolutionary, and incremental. The key to the success and efficiency of this prototype method lies in the establishment of the model and the speed of modeling.

3.3 Incremental model

The incremental model combines the basic components of the waterfall model (repetitive application) with the iterative characteristics of prototype implementation . The incremental model uses linear sequences that stagger over time, with each linear sequence producing a releasable "increment" of the software. When using the incremental model, the first increment is often the core product, which means that the first increment implements the basic requirements , but many additional features have not yet been released. Customer use and evaluation of each increment serve as new features and functionality released in the next increment. This process is repeated after each incremental release until the final, polished product is produced.

The incremental model emphasizes that each increment releases an operational product . As shown in the picture:

Incremental models, like prototype implementation models and other evolutionary methods, are iterative in nature . But unlike prototype implementation, the incremental model emphasizes that each increment releases an operational product . Early increments are "detachable" versions of the final product, but they do provide functionality to serve users and provide a platform for user evaluation. The characteristic of the incremental model is that it introduces the concept of incremental packages. There is no need to wait for all requirements to be released . Development can be carried out as long as the incremental package of a certain requirement is released. Although a certain incremental package may need to be further adapted to customer needs and needs to be changed, as long as the incremental package is small enough, its impact on the entire project will be bearable.

The advantage of using the incremental model is that personnel allocation is flexible , and there is no need to invest a lot of human resources in the beginning. If the core product is very popular, manpower can be added to realize the next increment; when the staff cannot complete the product within the set deadline, , which provides a way to launch the core product first, so that some features can be released to customers first, acting as a tranquilizer for customers. Additionally, increments enable planned management of technical risks. The disadvantage of the incremental model is that if there is intersection between incremental packages and it cannot be handled well, a comprehensive system analysis must be done, and the modules cannot be divided well . The incremental model applies the method of functional refinement and separate development to the software development process where requirements frequently change.

3.4 Spiral model

The spiral model combines the waterfall model and the prototyping (evolution) model . It combines the advantages of both and adds risk analysis . It is based on the prototype and rotates from the inside out along the spiral . Each rotation requires planning, risk analysis, implementation engineering, customer evaluation and other activities, and a new version of the prototype is developed .

The spiral model emphasizes risk analysis and is especially suitable for large, complex, and high-risk systems . After several spiral processes, the final system is obtained, as shown in the figure: (The requirements are often vague at the beginning of the project, but will gradually become clear as the project progresses, that is, the requirements are gradually detailed. .)

3.5V model

In the development model, testing is often used as an afterthought to remedy the situation, but there is also a development model centered on testing , which is the V model. The V model has only received vague recognition in the software industry. The V model claims that testing is not an act of making up for it afterwards, but a process that is as important as the development process, as shown in the figure:

The V model is the most representative testing model. It is a variant of the waterfall model . It strengthens testing based on the waterfall model and reflects the relationship between testing activities and analysis and design. In the V model, the descending parts on the left are the stages of the development process, and the ascending parts on the right are the stages of the testing process. The software testing strategy of the V model includes both low-level testing and high-level testing. Low-level testing is for the correctness of the source code, and high-level testing is for the entire system to meet user needs. The V model has certain limitations. It only regards the testing process as a stage after requirements analysis, outline design, detailed design and coding. Make testing work throughout .

The V model emphasizes collaboration and speed of software development, organically combines software implementation and verification, and shortens the development cycle while ensuring high software quality. The V model is suitable for enterprise-level software development , and it more clearly reveals the characteristics and essence of the software development process.

The value of the V model is that it very clearly indicates the different levels that exist in the testing process and clearly describes the correspondence between these testing phases and the stages during the development process:

• The main purpose of unit testing is to target various errors that may exist during the coding process. For example: errors in boundary values ​​during user input validation.
• The main purpose of integration testing is to target possible problems in the detailed design, especially to check possible errors in the interface between each unit and other program parts.
• System testing focuses on the outline design and checks whether the system as a whole is operating effectively. For example: whether the expected high performance is achieved in product settings.
• Acceptance testing is usually conducted by business experts or users to confirm that the product can truly meet the user's business needs.

The concept of iteration and increment

3.6 Fountain model

The fountain model provides support for software reuse and the integration of multiple development activities in the life cycle . It mainly supports object-oriented development methods. It is a model that is driven by user needs and driven by objects . The word "fountain" itself embodies the iterative and gapless nature. A certain part of the system is often reworked multiple times, with related functionality added to the evolving system in each iteration . The so-called no gap means that in development activities, there is no obvious boundary between analysis, design and coding, as shown in the figure:

3.7 CBSD component-based model (component assembly model/component-based software development)

A component (Component) is a software unit with reusable value and relatively independent functions. The Component-Based Software Development (CBSD) model uses modularization methods to modularize the entire system, and with the support of a certain component model, reuses one or more software components in the component library through combination means. The process of constructing application software systems with high efficiency and high quality.

The component-based development model incorporates many characteristics of the spiral model, is evolutionary in nature, and the development process is iterative. The component-based development model consists of five stages: software requirement analysis and definition, architecture design, component library establishment (the component library includes component acquisition and component management), application software construction, testing and release . As shown in the picture:

CBSE components should have the following characteristics:

• Assemblability: All external interactions must occur through publicly defined interfaces.
• Deployability: Components are always in binary form and can run on the platform as an independent entity.
• Documentation: Users judge whether the component meets the requirements based on the documentation.
• Independence: Can be assembled and deployed without other special components.
• Standardization: A component model that conforms to a certain standard.

Assembly sequence of CBSE components:

• Sequential assembly: Call existing components in sequence. You can use two existing components to create a new component.
• Hierarchical assembly: The "provided" interface of the called component must be compatible with the "request" interface of the calling component.
• Overlay assembly: Multiple components are merged to form a new component. The new component integrates the functions of the original components and provides new interfaces to the outside world.

As an important software technology and tool, components have been greatly developed. These new technology standards and tools include Microsoft's DCOM/COM, Sun's EJB, OMG's CORBA, etc. Component-based development activities start with identifying candidate components . By searching the existing component library , confirm whether the required component already exists. If it already exists , extract it from the component library for reuse ; if it does not exist , use the object-oriented method. Develop it. After the extracted components pass syntax and semantic checks, these components are assembled together through glue code to implement the system. This process is iterative.

The component-based development method makes software development no longer start from scratch. The development process is the process of component assembly, and the maintenance process is the process of component upgrade, replacement and expansion. Its advantage is that the component assembly model leads to software reuse and improves Improves the efficiency of software development ; components can be defined by one party, implemented by another party, and then provided to a third party for use; the component assembly model allows multiple projects to be developed simultaneously, reducing costs, improving maintainability, and enabling step-by-step submission Software Products.
The disadvantage is that due to the use of customized assembly structure standards, there is a lack of universal assembly structure standards , and the introduction is risky; reusability and software efficiency are not easy to coordinate, requiring capable and experienced analysts and developers. Generally, If developers are unable to get involved, customer satisfaction is low; too much reliance is placed on components, and the quality of the component library affects product quality .

3.8 Agile model

Development Manifesto: Individuals and interactions over processes and tools, working software over exhaustive documentation, customer collaboration over contract negotiation, responding to change over following a plan .

Agile development methods

Two characteristics distinguish agile methods from other methods:
(1) It is "adaptive" rather than "preset".
(2) It is "people-oriented" rather than "process-oriented".
Core ideas of agile development:
(1) Agile development is adaptive , not predictable. Embrace change and adapt to change.
(2) Agile development is people-oriented , not process-oriented. Bring out human characteristics.
(3) Iterative and incremental development process. Based on the idea of ​​prototype development, the method is used to replace incremental development, and the release version is miniaturized.

XP Extreme Programming

XP is a lightweight (agile), efficient, low-risk, flexible, predictable, scientific and fun software development method. Compared with other methodologies, its biggest differences are:

(1) For code-driven rules, the important document is the source code.
(2) Provide specific and continuous feedback information earlier and in a shorter cycle.
(3) Plan iteratively, first quickly generating a master plan at the beginning and then evolving it throughout the project development process.
(4) Rely on automated testing programs to monitor development progress and catch defects early.
(5) Rely on verbal communication, testing and source programs for communication.
(6) Advocate continuous evolutionary design.
(7) Relies on close collaboration within the development team.
(8) Try to achieve a balance between the short-term interests of programmers and the long-term interests of the project as much as possible.

Four values:

• communication, strengthen face-to-face communication
• Simple, not overly designed
• feedback, timely feedback
• Courage, the courage to accept change

XP is a near-spiral development method that breaks down the complex development process into relatively simple cycles: through active communication, feedback, and a series of other methods, developers and customers can be very clear about the development progress. , change the problems to be solved and potential difficulties, etc., and adjust the development process in a timely manner according to the actual situation.

XP advocates testing first in order to minimize the chance of bugs in the future.

XP is used very effectively in some companies that have strict cost control .

crystal method

The Crystal Series method, like the XP method, has a people-centered philosophy, but it is different in practice. The aim is to develop an approach that promotes "mobility" and contains common core elements, each with unique roles, process models, work products and practices.

The Crystal Method explores ways to achieve success with the least amount of discipline , thus achieving a balance between productivity and ease of operation.

open source

Open source: Program developers are widely distributed geographically [other methods emphasize centralized offices] .

Arguing for law in parallel

SCRUM is an iterative and incremental process. One iteration per period (such as 30 days) is called a "Sprint", and products are implemented according to the priority level of requirements. Self-organizing and autonomous teams incrementally implement the product in parallel.

SCRUM: A clearly defined, repeatable methodological process focused on project management. .

Feature-Driven Development (FDD)

Feature-driven development (FDD) is an iterative development model. It is believed that effective software development requires 3 elements: people, process and technology. There are 5 core processes: developing the overall object model, constructing the feature list, planning feature development, feature design, and feature construction. Six key project roles are defined: project manager, chief architect, development manager, lead programmer, programmer, and domain expert.

Function-Driven Development (FDD): Programming developers are divided into two categories: lead programmers and "class" programmers .

ASD method

ASD method : At its core are three non-linear, overlapping development phases: guessing, collaborating and learning .

Dynamic System Development Methods

Dynamic System Development Method (DSDM) : advocates taking __ business as the core.

3.9 RAD model (rapid application development model)

The Rapid Application Development (RAD) model is an incremental software development process model that emphasizes an extremely short development cycle. The RAD model is a "high-speed" variant of the waterfall model , which uses a component-based construction method to achieve rapid development through the extensive use of reusable components . If the requirements are well understood and the scope of the project is constrained, a fully functional "information system" can be quickly created using this model. The process starts with business modeling, followed by data modeling, process modeling, application generation, testing and iteration. The comprehensive development model of the waterfall model and CBSD (Component-Based Software Development) , as shown in the figure:

The tasks to be completed in each activity period of the RAD model are as follows:

• Business modeling : What information drives business processes? What information is to be generated? Who generates it? Where does the information flow go? By whom? This can be supplemented by data flow diagrams.
• Data modeling : In order to support the data flow of business processes, find a collection of data objects, define data object attributes, and form a data model in relationship with other data objects, which can be supplemented by ER diagrams.
• Process modeling : enable data objects to complete various business functions in the information flow. Create a process to describe the addition, modification, deletion, and search of data objects, that is, refine the processing boxes in the data flow diagram.
• Application generation : Use the fourth generation language (4GL) to write processing programs, reuse existing components or create new reusable components, and use the tools provided by the environment to automatically generate and construct the entire application system.
• Testing and delivery , due to the large amount of reuse, generally only overall testing is done, but newly created components still need to be tested.

Compared with the waterfall model, the RAD model does not use traditional third-generation programming languages ​​to create software, but adopts a component-based development method, reusing existing program structures (if possible) or using reusable components. Or create reusable components if needed. In all cases, automated tools were used to assist software creation. Clearly, the time constraints imposed on a RAD model project require "a scalable scope." If a business can be modularized so that each major function can be completed in less than three months, then it is a candidate for RAD. Each major function can be implemented by a separate RAD group, and finally integrated to form a whole.

The RAD model speeds up development through extensive use of reusable components and is particularly effective in the development of information systems. But like all other software process models, the RAD approach has its flaws:

• Not all applications are suitable for RAD. The RAD model has relatively high requirements for modularity . If any function cannot be modularized, then there will be problems with the components required to build RAD; if high performance is an indicator, the indicator must be adapted to the system by adjusting the interface. Components can win, and the RAD approach may not work.
• Developers and customers must complete a series of demand analyzes in a very short period of time. Improper cooperation on the part of either party will lead to the failure of the RAD project.
• RAD can only be used for information system development and is not suitable for situations where technical risks are high . This happens when a new application uses a lot of new technology or when the new software requires a high level of interoperability with existing computer programs.

3.10 Unified Process Model (RUP/UP)

Features of RUP

(1) Use case driven : Activities such as requirements analysis, design, implementation and testing are all driven by use cases.
(2) Architecture-centered : including the overall organization and global control of the system, communication protocols, etc. It is a multi-dimensional structure and will be described using multiple views (4 + 1 views) .
(3) Iteration and increment : Divide the entire project development into multiple iterative processes. In each iteration, only part of the system's requirements are considered, and processes such as analysis, design, implementation, testing and deployment are carried out; each iteration is carried out on the basis of the completed parts, and some new functional implementations are added each time. This continues until the final project is completed.

There are 4 phases in RUP

The unified software development process defines four development stages, which are the initial stage, refinement stage, construction stage and delivery stage according to the process sequence. Among them, the main documents generated in the construction stage are design models.

• Initial stage : project blueprint document (core requirements, key features, main constraints), use case model, project plan

• Refining stage : complete the architectural design and eliminate high-risk elements

• Construction phase : UML model, test cases

• Delivery phase : Runnable software product, user manual, user support plan.

There are 9 core workflows in RUP

RUP's workflow is divided into two parts: core workflow and core support workflow. Core workflows (processes in projects) include business requirements modeling, analysis and design, implementation, testing, and deployment; core support workflows (processes in organizations) include environment, project management, configuration, and change management.

The RUP software development life cycle is a two-dimensional software development model . There are 9 core workflows in RUP , as follows:

• Business modeling : Understand the organization where the system to be developed is located and its business operations, ensure that all participants have a common understanding of the organization where the system to be developed is located, and evaluate the impact of the system to be developed on the organization.
• Requirements : Define system functions and user interface, let customers know the system's functions, enable developers to understand system requirements, and provide a basis for project budget and planning.
• Analysis and design : Convert the results of demand analysis into analysis and design models.
• Implementation : Convert the design model into implementation results, perform unit testing on the developed code, and integrate modules developed by different implementers into executable systems.
• Testing : Check the interaction and integration between subsystems, verify whether all requirements are correctly implemented, archive the discovered defects in software quality, and make suggestions for improving software quality.
• Deployment : Package, distribute, install software, upgrade old systems; train users and sales staff, and provide technical support.
• Configuration and change management : Track and maintain the integrity and consistency of all artifacts produced during system development.
• Project management : Provide guidance on planning, personnel allocation, execution, monitoring, etc. for software development projects, and provide a framework for risk management.
• Environment : Provide software development environment for software development organizations, that is, provide process management and tool support.

4. Reverse engineering

Reverse engineering is characterized by extracting data structure, architecture and programming information from existing programs.

Its process is: existing system → reverse engineering → considering new requirements → forward engineering → new system.

Reverse engineering of software is a process of recovering a design, extracting data, architecture, and process design information from an existing program. The completeness of reverse engineering can be described by the level of detail provided at a certain level of abstraction. In most cases, the higher the level of abstraction, the lower the completeness.

The domain-level abstraction level is the highest and the lowest completeness, and the implementation-level abstraction level is the lowest and the highest completeness.

Concepts related to reverse engineering include refactoring, design recovery, reengineering and forward engineering:

• Restructuring refers to transforming the system description form at the same level of abstraction .
• Design recovery refers to the use of tools to abstract information about data design, overall structure design, and process design from existing programs.
• Reverse engineering is the process of analyzing a program and trying to establish a representation of the program at a higher abstraction level than the source code. Reverse engineering is the recovery process of the design.
• Forward engineering refers to not only recovering design information from existing systems, but also using this information to change or reconstruct existing systems to improve their overall quality .
• Re-engineering is a process of redeveloping existing systems, including three steps: reverse engineering, consideration of new requirements, and forward engineering .

Methods for reverse engineering to recover information:

method	Export information
User-guided search and transformation methods	Implementation level, structure level
transformative method	Implementation level, structure level, function level
Domain knowledge based methods	Functional level, domain level
User-guided search and transformation methods	Lead plate recovery method implementation level, structure level

5. Requirements Engineering

2.1 Hierarchy of software requirements

2.2 Requirements Engineering

Software requirements refer to users ’ expectations for the system in terms of functions, behavior, performance, design constraints, etc.

Requirement Engineering (RE) refers to the application of proven and effective principles and methods to systematically describe the system to be developed, its behavioral characteristics and related constraints through appropriate tools and notations.

Requirements engineering consists of five stages: demand acquisition, demand analysis, demand specification formation (or demand documentation), demand confirmation and verification, and demand management, as shown in the figure:

Software Requirement Specification (SRS)
SRS specifically includes functional requirements, non-functional requirements and constraints . Constraints include design constraints and process constraints. An approved SRS isthe bridge between requirements development and requirements management .

Requirements Management
Requirements management is a process of changing, understanding and controlling system requirements, including change control, version control, requirements tracking and other activities.

2.5 Requirements development (main line, goals)

2.5.1 Requirements classification

• Requirements classification

(1) Business needs : Business needs reflect the high-level target requirements of the enterprise or customer for the system. They usually come from project investors, customers who purchase products, managers of customer units, marketing departments or product planning departments, etc. Business requirements determine the project view and scope.

(2) User requirements : User requirements describe the specific goals of the user, or the tasks that the user requires the system to complete. That is, user requirements describe what users can do with the system. User interviews and questionnaires are usually used to organize user usage scenarios (scenarios) to establish user needs.

(3) System requirements : System requirements describe the software requirements from a system perspective, including functional requirements, non-functional requirements and design constraints.

• Quality Function Deployment QFD

It is a technology that converts user requirements into software requirements, with the purpose of maximizing user satisfaction during the software engineering process. In order to achieve this goal, QFD divides software requirements into three categories, namely regular requirements, expected requirements and unexpected requirements.

(1) Basic needs : also called regular needs, the functions or performance that users think the system should achieve. The more functions or performances that are implemented, the more satisfied users will be.

(2) Expected requirements : Users take for granted the functions or performance that the system should have, but cannot correctly describe the functions or performance requirements they want. If expectations are not met, users will feel dissatisfied.

(3) Unexpected requirements : Unexpected requirements, also known as exciting requirements, are functions or performance outside the scope of user requirements (but usually technical features that software developers are happy to give to the system). Users will be happier if these requirements are realized, but they are not realized. Nor does it affect their purchasing decisions.

2.5.2 Requirements acquisition

method	Features
gather information	Collect information related to the system that is useful for system development.
Read historical documents	Useful for collecting data-based information.
User interviews	1 to 1-3, representative users, understanding subjective thoughts, good interaction. The cost is high and requires domain knowledge support.
Questionnaire	There are many users , it is impossible to conduct one interview, and the cost is low .
On-site observation	For more complex processes and operations.
Participate in business practice	Effectively discover the nature of problems and find solutions to them.
Joint Requirements Planning (JRP)	Highly organized group meetings, involving all parties, understanding ideas, eliminating differences, good interaction, and high cost.
Storyboard ( prototyping method)	A series of pictures through which a story is told.
Sample survey/sampling	Based on mathematical statistics, reduce costs and obtain quickly. Sample size = a*(credibility coefficient/acceptable error)2 Note: a is generally 0.25

• User interviews
  User interviews are the most basic means of obtaining requirements, and their forms include structured and unstructured . Structured means preparing a series of questions in advance and conducting them in a targeted manner; unstructured means only listing a rough idea and developing it according to the specific situation of the interview . The most effective interviews are conducted by combining these two methods. After all, it is impossible to plan everything clearly, and good flexibility should be maintained.
  User interviews have good flexibility and a wide range of applications . However, there are also many difficulties. For example, users are often busy and have difficulty arranging time; the amount of information during interviews is large and recording is difficult ; communication requires many skills andsystem analysts must have sufficient domain knowledge , etc. In addition, during the interview, you may also encounter some confidential and sensitive topics for the company. Therefore, this seemingly simple technology also requires system analysts to have rich experience and strong communication skills.

• Questionnaire
  survey Compared with user interviews, questionnaire survey can collect data from a large number of responses in a short time and at low cost; questionnaire survey allows respondents to fill in anonymously, and most users may provide real information ; questionnaire survey The results are easier to organize and count . However, the biggest shortcoming of the questionnaire survey is the lack of flexibility. Other shortcomings include:
  ① The two parties have not met. The system analyst cannot obtain some more implicit information from the user's expression and other actions, and the user has no opportunity to immediately clarify his or her opinion on the question. Vague or incorrect answers.
  ② Users may psychologically not pay attention to a small form and not take it seriously, resulting in incomplete feedback information.
  ③ The questionnaire is not conducive to answering the questions and cannot understand some details.
  ④ The number of responders is often less than expected, and there is no guarantee that users will answer questions or further explain all questions.

• Sample survey/sampling Sample
  survey/sampling refers to the process of systematically selecting a representative sample set from a population . Through careful study of the selected sample set, useful information about the population as a whole can be revealed. For the development of information systems, the documentation (files) of the existing system is the sampling population. When starting to do a requirements analysis on a system, reviewing the documentation of the existing system is the best way to get a preliminary understanding of the system. However, what types of documents should system analysts look at? When the data in the documents is too large to be studied one by one, sampling techniques need to be used to select representative data . Sampling technology can not only be used to collect data, but can also be used to collect interviews with users or collect and observe users. The same sampling techniques described above apply when sampling people. Through sampling technology, selecting parts rather than the entire population not only speeds up the data collection process but also increases efficiency, thereby reducing development costs. In addition, sampling technology uses the principles of mathematical statistics to reduce bias in data collection.
  However, since the sampling technology is based on statistical principles, the determination of the sample size depends on the expected credibility and existing prior knowledge, and largely depends on the system analyst's subjective factors, personal experience and experience of the system analyst. The ability is highly dependent and requires system analysts to have a high level and rich experience.

• Joint Requirements Planning (JRP)
  JRP is a relatively expensive method of obtaining requirements, but it is also a very effective one. It discusses requirementsthrough organized . Usually the number of participants in this meeting is 6 to 18 people, and the duration is 1 to 5 hours .
  The main intention of JRP is to collect requirements rather than to analyze and verify the requirements . The following main principles should be grasped when implementing the JRP:
  ① Before the implementation of the JRP, a detailed agenda should be formulated and strictly followed.
  ② Carry out according to the established time schedule.
  ③ Try to record the content of the meeting as completely as possible.
  ④ Try to avoid using professional terms during the discussion.
  ⑤ Make full use of conflict resolution skills.
  ⑥ Sufficient intermission time should be set during the meeting.
  ⑦Encourage the team to reach a consensus.
  ⑧ Ensure that all personnel participating in the JRP can abide by the rules agreed in advance.

2.5.2 Requirements analysis

Requirements analysis : A good requirement should have characteristics such as unambiguity, completeness, consistency, testability, certainty, traceability, correctness, and necessity. Therefore, analysts need to combine messy user requirements with Converting expectations into user needs is the job of requirements analysis.

Tasks of requirements analysis :
(1) Draw system context scope diagram
(2) Create user interface prototype
(3) Analyze the feasibility of requirements
( 4) Determine the priority of requirements
(5) Establish a model for requirements
(6) Create a data dictionary
(7) Use QFD (Quality Function Deployment)

2.5.2.1 Structured Analysis Method - SA

The core of the structured analysis method SA is the data dictionary . There are three levels of models surrounding this core, namely data model, functional model, and behavioral model (state model) .

The steps of structured analysis are as follows:
(1) Analyze the business situation and make a data flow diagram (Data Flow DiagramDFD) that reflects the current physical model.
(2) Derive the DFD of the equivalent logistic model.
(3) Design a new logic system and generate data dictionary and primitive description.
(3) Establish a human-machine interface and propose an alternative DFD of the physical model of the target system.
(5) Determine the costs and risk levels of various options, and analyze various options accordingly.
(6) Choose a plan.
(7) Establish a complete requirements specification.

The structured analysis method SA is data flow and control flow. Commonly used methods are data flow diagram (DFD) and data dictionary.

2.5.2.1.1 SA - Data Dictionary DD

The data dictionary is the core of the requirements analysis model. It is a description of each data flow, file, process, and data item that makes up the data flow or file in the data flow diagram.

The data dictionary has four categories of entries: data flow, data items, data storage and basic processing. Including data elements, data structures, data flows, processing logic and external entities. As shown below:

2.5.2.1.2 SA - Data Flow Diagram DFD

Data flow diagram (DFD) uses a data flow diagram to represent a functional model. DFD describes the functions completed by the system. From the perspective of data transmission and processing, graphic symbols are used to describe the functions of each component of the system and the data transfer between them through layer-by-layer subdivision. situation to illustrate the functions completed by the system. As shown below:

Among them, DFD will also have "top-level DFD map" and "0-layer DFD map".

As shown in the figure above, there are the following "picture elements" descriptions:

Attached is an incorrect DFD diagram, as follows:

Error as shown above:

Processing 3.1.2 has input but no output, which is called a "black hole".
Processing 3.1.3 has output but no input. Call it a "miracle."
In processing 3.1.1, the input is not enough to produce the output, which we call a "gray hole".

2.5.2.1.3 SA - State Transition Diagram STD

A state transition diagram is used to represent a behavioral model. STD represents the behavior of the system by describing the state of the system and the events that cause the system state transition, indicating what actions will be performed as a result of specific events. As shown below:

2.5.2.1.4 SA - ER diagram/entity relationship diagram

ER diagram mainly describes entity attributes and relationships between entities. In addition, the ER model is a model and product of the structured era and does not exist in object-oriented and UML. As shown below:

What is a weak entity?
For example: In the personnel management system, the information about employees' children is based on the existence of employees. The children entity is a weak entity, and the relationship between children and employees is a dependent relationship. Therefore, employees are entities and can also become strong entities.
The relationship between strong entities and weak entities can only be 1:1 or 1:N.

2.5.2.2 Object-oriented analysis method - OOA

Several related concepts

object	Attribute [data] + method [operation] + object ID/identification ID
Class [see details below]	Entity class/control class/boundary class Entity class: often has a corresponding relationship with the database, whether it is a data type Control class: a class that connects entity classes and boundary classes Boundary class: a class that communicates with the outside at the boundary of a system The relationship between three similar MVC models, their ideas are the same
Inheritance and generalization	Reuse mechanism, it is a kind of tight coupling. Because when the parent class changes, the subclass has to change. Inheritance is based on existing instances
encapsulation	Hide the properties and implementation details of the object and only expose the interface to the outside world
Polymorphism	Different objects receive the same information and produce different results.
interface	A special class that only has method definitions but no method implementations
Overload	A class can have multiple methods with the same name and different parameter types. The characteristic of a function with the same name but different parameters is that
news communication	Messages are communicated asynchronously
Overwrite and rewrite	The method with the same name of the subclass overrides the method with the same name of the parent class
Combination and aggregation	Aggregation relationship: the relationship between automobile parts and the entire vehicle (the life cycle of the whole and the part is different) combination relationship: the relationship between departments and companies. If the company goes bankrupt, the departments will be finished (the whole life cycle is the same as the part life cycle)

OOA roughly follows the following 5 basic steps:

（1）确定对象和类：这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中建立一个新对象的描述。
（2）确定结构：结构是指问题域的复杂性和连接关系。类成员结构反映了泛化-特化关系，整体-部分结构反映整体和局部之间的关系。
（3）确定主题：主题是指事物的总体概貌和总体分析模型。
（4）确定属性：属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。
（5）确定方法：方法是在收到消息后必须进行的一些处理方法:方法要在图中定义，并在对象的存储中指定。对于每个对象和结构来说，那些用来增加、修改、删除和选择的方法本身都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。

2.5.2.2.1 OOA - UML

OOA需求分析的UML（统一建模语言，与平台和语言无关）由基本构造块，规则和公共机制构成。

UML基本构造块之事物【重要组成部分】

事务	描述
结构事物	最静态的部分，包括类，接口，协作用例，活动类，构件和节点
行为事物	代表时间和空间上的动作，包括消息，动作次序，连接
分组事物	看成是个盒子，如包和构件
注释事物	UML模型的解释部分。描述，说明，和标注模型的元素

UML基本构造块之关系【把事物紧密联系在一起】

关系	描述
依赖关系	一个事物发生变化影响另一个事物，包含关系和扩展关系都属于依赖
泛化关系	特殊一般关系，特殊元素的对象可替换一般元素的对象
关联关系	描述了一个链，链是对象之间的连接
实现关系	接口与类之间的关系，一个类指定了由另一个类保证执行的契约

UML基本构造块之图【多个相互关联的事物的集合】

图	描述
静态图	结构图
类图	描述一组类，接口协作和它们之间的关系。
对象图	描述一组对象以及它们之间的关系。对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象。
构件图	也叫组件图，是描述软件内部物理组成的一种图。系统里有哪些构件 构件之间有啥联系。描述一个封装的类和它的接口，端口，以及由内嵌的构件和连接件构成的内部结构。强调由小的部件构件大的系统。
部署图	表示为软件和硬件之间的映射。为了完成系统需要什么样配置的操作系统，内存，CPU等不在它范畴内，它只解决开发的系统如何去部署的问题。
制品图	描述计算机中一个系统的物理结构。制品包括文件，数据库，和类似的物理比特集合。
包图	将某些类放入“包”中，通过包图来组织业务概念图。
组合结构图	展示该部分内容“内部”参与者的配置情况。这个图不常用。
动态图	行为图
用例图	系统与外部参与者的交互。描述一组用例，参与者及他们之间的关系的图。
顺序图	强调按时间顺序。顺序图和通信图我们又称其为交互图。顺序图能够表达用户与系统的复杂交互过程。
通信图	也叫协作图，它强调的是相互之间关系，是顺序图的另外一种表达。
定时图	消息跨越不同对象或角色的实际时间。交互图的一种。
交互概览图	活动图与顺序图的结合。这个图不常用。
活动图	类似程序流程图，表示流程性的东西和并行的行为。它将进程或其他计算结构展示为计算内部一步步的控制流和数据流，它专注于系统的动态视图，它对系统功能建模和业务流程建模特别重要；并强调对象间的控制流程。
状态图	从某个物品的状态是如何变化的角度来展示流程。

UML规则

是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性；运行或模拟动态模型的含义是什么，即执行。

UML公共机制

是指达到特定H标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制4种。规格说明是事物语义的细节描述，它是模型真正的核心：UML为每个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；UML包括两组公共分类：类与对象（类表示概念，而对象表示具体的实体)、接门与实现（接口用来定义契约，而实现就是具体的内容)；扩展机制包括约束（扩展了UML构造块的语义，允许增加新的规则或修改现有的规则）、构造型（扩展UML的词汇，用于定义新的构造块）和标记值（扩展了UML构造块的特性，允许创建新的特殊信息来扩展事物的规格说明）。

UML中的概念

• 类：是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口。
• 接口：是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作。
• 构件：是物理上或可替换的系统部分，它实现了一个接口集合。提供一组接口的实现，是组成事物的元素。
• 包：是用于把元素组织成组的通用机制，它一个构件的抽象化的概念，是把类元按照一定的规则分成组（或称为模块）。
• 用例：是描述一系列的动作，产生有价值的结果。
• 协作：定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大。
• 节点：是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。

2.5.2.2.2 OOA - UML 4+1视图

现有的UML，再有的UML视图

UML采用4+1视图来描述软件和软件的开发过程，其中进程视图绘制了所设计的并发与同步结构；部署视图表示软件到硬件的映射和分布结构；UML中的类图可以用来表示4+1视图中逻辑视图；最终形成用例视图，用来得到需求分析模型。

“4+1”视图模型是从不同的视角、使用多个并发的视图来组织软件架构的描述。

“4+1”视图模型具有普遍适用性，实践证明能在许多大型项目中成功运用。

2.5.2.2.3 OOA - 用例模型与分析模型

在OOA的需求分析中，图的应用是经常被用到的。大部分的以用例模型和分析模型的建立为主线，其中用例模型采用用例图来构建，分析模型用类型表示。其它细节情况，也可以建立其它交互图。

2.5.2.2.4 需求分析工具

2.5.2.2.4.1 使用用例建模系统需求

用例建模来源于面向对象建模技术，但该技术也在非对象开发环境中比较流行，用例建模技术对传统的系统分析和设计工具进行了补充，例如数据建模和过程建模， 也提供了架构决策和用户界面设计决策的基础。

用例建模促进并鼓励了用户参与，具有如下优点：

• 提供了捕捉功能需求的工具。
• 有助于将系统分解为更易于管理的小块。
• 提供了与用户以及其他关心系统的关联人员进行交流的工具。
• 辅助估计项目范围、投入和进度。
• 提供了需求跟踪的工具。
• 提供了确定数据对象或实体的起点。
• 提供了设计用户和系统接口的功能规格说明。

为了决定用例的重要性，项目经理或者系统分析员将填写用例分级和评估矩阵，并使用来自关联人员和开发团队的输入构造用例依赖关系图。

1、项目经理使用称为用例分级和评估矩阵，决定用例的优先级。该矩阵使用6个标准按1 ~ 5级评估用例。6个标准是：

• 对架构设计的重要影响。
• 容易实现但包含重要功能。
• 包含有风险、时间紧迫或复杂的功能。
• 需要大量的研究或者新的、有风险的技术。
• 包含主要的业务功能。
• 将增加或者减少费用。

2、有些用例依赖于其他用例，其中一个用例使系统处于一种状态，该状态是另一个用例的前置条件。我们使用用例依赖关系图建模这种依赖关系。用例依赖关系图具有以下优点：

• 系统事件及其状态的图形化表述有利于对系统功能的理解。
• 有助于确定遗漏的用例。
• 通过描述哪个用例更关键并需要最高优先权，有助于推动项目管理。

2.5.2.2.4.1 数据建模与分析

数据建模是一种为数据库定义业务需要的技术，因为数据模型最终要实现成数据库，所以数据建模有时称为数据库建模。下图是一个简单的数据模型，称为实体关系图。

数据建模的系统概念：

• 实体
• 属性（数据类型、域、默认值）（键）
• 关系

如何构造数据模型？

• 获取实体。
• 构造上下文数据模型：包含基本业务实体及它们之间的自然关系。
• 基于键的数据模型：确定每个实体的键。
• 泛化层次体系：父实体、子实体。
• 具有完整属性的数据模型。
• 分析数据模型：规范化（第一范式、第二范式、第三范式）。
• 将数据需求映射到地点：数据–地点–CRUD矩阵。

2.5.2.2.4.1 过程建模

过程建模源自传统的软件工程方法，可能的过程模型包括程序结构图、逻辑流程图或决策表。本节重点介绍系统分析的过程模型，即数据流图。 数据流图是一种描述通过系统的数据流以及系统实施的工作或处理过程的工具。同义词包括泡式图、转换图和过程模型。

过程建模的系统概念：

• 外部代理：常见的同义词包括外部实体。
• 数据存储：是一个数据的“仓库”，同义词包括文件和数据库。
• 过程：即处理，是在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作，同义词是转换。分解图、层次图。注意避免过程中三种常见的错误：1）有输入没有输出，黑洞；2)有输出但没有输入，奇迹；3)输入不足以产生输出，灰洞（如输入一个雇员地址，输出一张财务报表）。
• 数据流：所有的过程至少都有一个输入流和一个输出流。数据流是过程与系统环境之间的通信。在数据流图中，有时需要描述分支的数据流或合并的数据流。分支的数据流是一个分成多个数据流的数据流，表示一个数据流的所有或者部分路由到不同目的地。合并的数据流是多个数据流合并成一个数据流后的数据流。合并的数据流指示了不同来源的数据流可以合并成一个报文供后续处理。

如何构造过程模型：

• 构造上下文数据流图：0号数据流图。
• 构造系统功能分解图。
• 事件响应或用例清单：构建分解图后，下一步是确定系统必须响应什么业务事件，（外部事件、时序事件、状态事件）。发现并确定事件和响应的更成功的方法之一是用例的技术。用例分析是确定并建模业务事件、谁触发事件以及系统如何响应事件的过程。
• 事件分解图：把事件处理过程增加到分解图中。
• 事件图：以分解图为提纲，可以为每个事件过程绘制一个事件图。
• 构造系统图：从原始的上下文图中的单个过程“爆炸”出来，在单张图中显示了系统的所有事件，显示了子系统的所有事件。 构造基本图：具有较复杂的事件图的事件过程应该扩展成一个更详细的基本数据流图，每个基本过程都是内聚的，也就是说仅完成一件事。
• 完成规格说明：对以上完成的数据流图中的每个数据流、数据存储和基本过程进行描述，并写进资料库中。对于过程内部的逻辑描述，我们可以使用结构化英语（自然英语+编程逻辑），用于说明过程模型中的基本过程的内部逻辑。但许多过程是由复杂的条件组合的（即业务策略），使用结构化英语不容易表达，此时可以使用决策表。

2.5.2.2.4.1 面向对象分析与建模

面向对象分析涉及到定义信息系统的静态和动态行为模型，而非定义数据和过程模型（这是传统开发方法的特点）。对象的标识，对象的数据部分（属性），对象的行为。

2.5.3 需求定义（形成需求规格）

需求定义的过程也就是形成需求规格说明书SRS的过程，通常有两种需求定义的方法，分别是严格定义方法和原型方法。

严格定义法的特点：所有需求都能够被严格定义；开发人员和用户之间能够准确而清晰的交流；采用图形文字能够充分体现最终系统。

原型法：并非所有的需求都能在开发前被准确的说明；项目参加者之间通常存在交流上的困难；需要实际的可供用户参与的系统模型；有合适的系统开发环境；反复是完全需要和值得提倡的，需求一旦确定就应该遵从严格的方法。

2.5.4 需求确认与验证

需求规格说明书SRS的需求验证也称为需求确认，其活动是为了确定以下几个方面的内容：

（1）SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征。
（2）SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的。
（3）需求是完整的和高质量的。
（4）需求的表示在所有地方都是一致的。
（5）需求为继续进行系统设计、实现和测试提供了足够的基础。

需求验证包括了需求评审和需求测试。

需求评审包括了：正式评审和非正式评审。需求验证是需要做用户签字确认，但往往实施起来比较困难，因为需求验证时签字就要负责任，它是验收的标准之一（此时的规格说明书SRS就是需求基线）。需求的评审需要用户的参与。

需求测试，不是运行类的测试而是设计测试用例进行测试，比如告诉你输入是什么输出是什么，所以更加接近于想像性测试，它是验证方向对不对该不该做的过程。需求测试仅仅是基于文本需求进行“概念”上的测试。然而，以功能需求为基础（SA方法）或者从用例派生出来（OO方法）的测试用例，可以使项目干系人更清楚地了解系统的行为。虽然没有在系统上执行测试用例，但是涉及测试用例的简单动作可以解释需求的许多问题。这种测试用例通常称为概念测试用例，即不是真正执行的测试用例，它们可以发现SRS中的错误、二义性和遗漏，还可以进行模型分析，以及作为用户验收测试的基础。在正式的系统测试中，还可以将它们细化成测试用例。

2.6 需求管理（支持，保障）

在软件需求工程中，需求管理贯穿于整个过程中，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理是可重复级的一个关键过程域，其目标是为软件需求建立一个基线，供软件开发及其管理使用，使软件计划、产品和活动与软件需求保持一致。从软件需求工程的角度来看，需求管理包括在软件开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

2.6.1 定义需求基线

需求开发的结果应该有项目视图和范围文档、用例文档和SRS，以及相关的分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在用户和开发人员之间就构成了软件需求的一个约定，它是需求开发和需求管理之间的桥梁。

基线是一个软件配置管理的概念，它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。根据IEEE的定义，基线是指已经通过正式评审和批准的规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变更控制系统进行变化。在软件工程范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。例如，SRS文档通过评审，其中的错误已经被发现并纠正，则就变成了一个基线。根据国家标准《计算机软件配置管理计划规范》（GB/T 12505-1990）的规定，基线可以分为功能基线、指派基线和产品基线三种，通过评审后的SRS（软件需求规格说明书）属于指派基线。

2.6.2 需求的状态

在需求状态的变化中，项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。因为这些需求有可能是应该被接受和并被实现的需求，如果不是通过有管理的处理过程，就有可能因为疏忽而被遗漏。同时，也应关注被交付的需求，因为可交付物是项目的成果体现，而可交付物的主要内容就是对需求的实现。

2.6.3 需求变更管理

CCB，变更控制委员会，也成配置控制委员会。
要让变更有序进行，首先需要有一个统一的单位来负责，这个单位一般叫变更控制委员会（Change
Control Board），也叫配置控制委员会（Configuration Control
Board）。CCB由项目干系人中有代表性的人员组成，人数没有限制，一个人也可以。CCB有能力在管理上做出承诺，对建议的配置项变更做出评价、审批及监督已批准变更的实施。CCB是决策机构，一般不参与具体的变更执行工作。

2.6.4 需求变更管理过程

（1）问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
（2）变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
（3）变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤;在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中。

常见的需求变更策略：

(1) All requirements changes must follow the change control process.
(2) Design and implementation work should not be done for changes that have not been approved.
(3) Changes should be decided by the Project Change Control Board which changes should be implemented.
(4) Project risk holders should be able to understand the content of the changes.
(5) The original document of the change request must not be deleted or modified from the project configuration library.
(6) Each integrated requirement change must be traceable to an approved change request to maintain horizontal traceability.

2.6.5 Demand risk

Risky practices include: ① Not enough users to participate. ②User classification is ignored. ③User demands continue to increase. ④ Ambiguous needs. ⑤Unnecessary features. ⑥Overly streamlined SRS. ⑦Inaccurate estimation.

Reasons for changes: ① Changes in the external environment. ②The requirements and design are not complete enough. ③The emergence of new technologies. ④ The reorganization of the company's organization results in changes in business processes.

2.6.6 Requirements tracking

The requirements of each software configuration item in the SRS must be bidirectionally traceable to the requirements of the systems (or subsystems) involved. The so-called two-way tracking includes forward tracking and reverse tracking. Forward tracking refers to checking whether each requirement in the SRS can find a corresponding point in the subsequent work results; reverse tracking, also called reverse tracking, refers to checking the design. Whether documents, codes, test cases and other work results can all be found in SRS.