What Is Requirements Engineering?

Requirements engineering refers to a discipline that uses proven technologies and methods to conduct requirements analysis, determine customer needs, help analysts understand problems, and define all external characteristics of the target system. It systematically describes the system to be developed and its behavioral characteristics and related constraints through appropriate tools and signs, forms requirements documents, and supports the changing needs of users.

Requirements engineering refers to the application of proven principles and methods to systematically describe the system to be developed and its behavioral characteristics and related constraints through appropriate tools and symbols. Requirements engineering covers

With the development of software engineering technology, requirements engineering has drawn more and more attention. Especially in the era of "service-oriented" software engineering, requirements engineering occupies an unprecedentedly important position. A full understanding of the development process of requirements engineering is of great help in grasping its development direction. The following table shows the important stages of the development of requirements engineering ^[2]

Requirements engineering is a process of repeated requirements definition, documentation, and requirements evolution. Finally, the requirements specification is completed on the basis of verification. In order to improve the quality of target software requirements specifications, requirements engineering proposes the following methods. ^[2]

Combining several perspectives, the requirements engineering activities can be divided into the following five independent phases:

1. Requirements acquisition: through communication with users, observation of existing systems and analysis of tasks to develop, capture and modify user requirements;

2. Requirements modeling: establish a conceptual model for the system seen by the end user as an abstract description of the requirements, and capture as much of the real-world semantics as possible;

3. Forming requirements specifications: Generate precise formal descriptions of the requirements model components as an agreement between users and developers;

4. Requirement verification: Take the requirement specification as input, analyze the correctness and feasibility of the requirement specification through symbol execution, simulation or rapid prototyping, including validity check, consistency check, feasibility check and confirmation verifiability;

5. The role of requirements engineering is mainly manifested in: enhancing the project stakeholders 'understanding of the details and interdependence of complex product features, and enhancing the project stakeholders' grasp of requirements (especially complex requirements) ^[4]

   Requirements engineering requirements acquisition phase

   The first requirement acquisition is technical support. Secondly, there are three important factors involved in the requirement acquisition: what information should be collected; what source should be used to collect information; and what mechanism or technology should be used to collect information. Once again, the beginning of demand acquisition represents the formal implementation of software projects. It is difficult to start everything. The combination of the above three points makes requirements acquisition the most difficult, critical, error-prone, and most communicative aspect of software development. In the development of work, we mainly communicate about business processes, organizational structures, software and hardware environments, and existing systems, and explore the true needs of system end users and grasp the direction of the needs. The requirements acquisition method was first verified in the requirements acquisition survey. Current requirements acquisition methods generally include survey-based requirements acquisition methods, use-case-based requirements acquisition methods, and prototype methods. There are advantages and disadvantages to each method of demand acquisition. ^[7]

   Requirements Engineering Requirements Analysis Phase

   Demand analysis and demand acquisition are closely related. Demand acquisition is the basis of demand analysis. Demand analysis is the direct performance of demand acquisition. The two promote each other and restrict each other. The difference between demand analysis and demand acquisition is that the demand analysis is based on the actual objective and comprehensive business and related information of the contractor, combined with the software and hardware implementation schemes, and makes a preliminary system prototype to the contractor Do a demo. The contractor experienced the rationalization, accuracy, and ease of business processes through prototype demonstrations. At the same time, users should find and propose problems and suggestions for improvement in a timely manner through prototype demonstrations.

   Requirements Engineering Document Writing Phase

   The final result of requirements development is the specific documents written after reaching a consensus on the product to be developed. The requirements document is generated at the end of the two phases of requirements acquisition and requirements analysis, so the document should include all requirements. At this stage, from the perspective of software engineering and document management, the requirements document content should be reviewed according to relevant standards to determine whether the requirements document content is complete. Efforts to modify the problems in the requirements document.

   Requirements Engineering Requirements Confirmation Phase

   The requirement confirmation is mainly for the review of the "Requirement Specification" to ensure that the requirements meet the characteristics of excellent requirements and maturity and the characteristics of good requirements specifications. The following points need to be ensured during the requirements confirmation phase:
   (1) The software requirements specification correctly describes the expected system capabilities and characteristics to meet the needs of all stakeholders.
   (2) Derive software requirements correctly from system requirements, business rules, or other sources.
   (3) The requirements are complete and of high quality.
   (4) The expression of demand is consistent everywhere.
   (5) Demand provides a sufficient basis for continuing product design and construction.

   Requirements engineering requirements tracking phase

   Requirements tracking refers to comparing the correspondence between requirements documents and subsequent work results to ensure that products are developed according to the requirements documents, to establish and maintain consistency between "requirements-design-programming-test" and ensure all work The results meet user needs. Demand tracking is a task that requires a lot of manual labor. The tracking contact chain information must be updated at any time during the system development and maintenance process. The quality of demand tracking directly affects product quality, reduces maintenance costs, and is easy to reuse. At the same time, demand tracking requires the support of the builder.

   Requirements Engineering Requirements Reuse Phase

   During the implementation of software projects, there are many similar requirements between many different projects. Especially when the projects of the same type are implemented by different users, the similarity of requirements is more obvious and more common. With the requirement reuse, the builder can quickly form a prototype of the requirements. In this way, the subsequent requirements work only needs to be modified, expanded and improved based on this prototype, which greatly improves the progress of the requirements analysis. Therefore, it is necessary to pay attention to the reuse of requirements. For demand reuse, the primary responsibility is to extract reusable requirements and understand and expand demand reuse. The second is to ensure that there is no conflict in demand reuse.

   Requirements Engineering Change Control Phase

   Changes in requirements are inevitable in software project development. Endless demand changes will only cause endless waste of various resources, but many of them are necessary and reasonable demand changes. As for demand changes, the first thing is to find them as early as possible to avoid greater losses. Secondly, it is necessary to adopt corresponding and reasonable change management systems and processes, which can also reduce the risks brought by changes in requirements.

   Requirements engineering version control phase

   Version control is an essential aspect of managing requirements specifications and other project documentation, and is the most effective way to document requirements management. It can record in detail the version of the requirement document version where the requirement change occurred, the reason for the change, the control record of the occurrence of the change, and identify the unique version number of the changed requirement document. Provides every member with timely access to the latest version of the requirements document.

   The basis for implementing version control is the requirements baseline. The so-called requirements baseline is the set of functional and non-functional requirements that project team members promise to implement in a specific product version. The determination of the requirements baseline can ensure that all stakeholders in the project can have a consistent understanding of the functions and attributes expected in the released product.