How to analyze requirements

If the work in the demand analysis stage is attributed to the preparation of the requirement specification, this simplified approach is often the culprit of the problems that may arise in the later stages of the project. We recommend that you use the following steps to form software requirements: obtain user requirements, analyze user requirements, write Requirement documents, review requirement documents, and manage requirements. Next we will discuss the practices of the first two steps (getting user requirements and analyzing user needs.

Obtain user requirements

This is one of the most important tasks in this phase. The following lists the activities that need to be performed to obtain user requirements (1 ).

● Understand all user types and potential types of the customer. Then, determine the overall goal of the system and the scope of work of the system according to their requirements.

● Conduct user interviews and surveys. The communication mode can be meetings, calls, emails, group discussions, simulated demonstrations, and other forms. Note that each communication must be recorded and the communication results can be classified to facilitate subsequent analysis activities. For example, requirements can be subdivided into functional requirements, non-functional requirements (such as response time, average working time without fault, automatic recovery time, etc.), environmental restrictions, design constraints, and other types.

● The requirement analysts further analyze and sort out the collected user requirements. Below are several common principles:

(1) You must know the "why" for each requirement raised by the user and determine whether there are sufficient reasons for the requirement;

　　

Figure 1 activity for Obtaining user requirements

(2) convert the expression "How to Achieve" to "what to achieve", because the goal of the demand analysis stage is "what to do", rather than "how to do ";

(3) analyze the implicit requirements derived from user requirements and identify the hidden requirements that are not explicitly proposed by the user (which may be a prerequisite for implementing user requirements). This is often overlooked, demand changes are often caused by insufficient considerations for implicit requirements.

● The requirement analyst submits the survey user requirements to the users and developers in an appropriate manner. Check whether the results submitted by the requirement analysis personnel reflect the user's intention. In this task, the requirement analyst needs to perform the following activities:

(1) clearly identify the undetermined demand items (there are often many such undetermined items at the beginning of the demand analysis );

(2) meet the overall objectives of the system;

(3) ensure consistency between requirements and resolve potential conflicts between requirements.

Analyze user requirements

In many cases, the analysis of user requirements is in parallel with the acquisition of user requirements, mainly through the creation of models to describe user needs, provides communication channels for customers, users, and developers. These models are abstract requirements and provide a bridge that is easy to communicate in a visualized manner. The analysis of user requirements is similar to the acquisition of user requirements. The difference is that the analysis of user requirements is described using models to obtain more specific user requirements. To analyze user requirements, perform the following activities:

● The overall structure of the system, including system boundaries and interfaces, is illustrated in graphs;

● Provide users with visual interfaces through prototypes, page streams, or other methods, so that users can make their own comments on their needs;

● System feasibility analysis, technical feasibility, environment analysis, cost analysis, and time analysis of demand implementation;

● Describe the system's function items, data entities, external entities, relations between entities, and state transition between entities using models.

　　

Figure 2 DFD

There are many methods for requirement modeling. The most common methods include data flow diagram (DFD), object Relation Diagram (ERD), and Use Case diagram (Use Case. DFD, as the main method of structural system analysis and design, has been widely used. DFD is especially suitable for the presentation of MIS systems. DFD uses four basic elements to describe system behaviors, including processes, entities, data streams, and data storage. The DFD method is intuitive and easy to understand. You can easily obtain the logical and physical models of the system. However, you cannot determine the time sequence relationship of the activity from the DFD diagram. Figure 2 describes the DFD of a project.

The ERD method is used to describe the ing between system entities. In the requirement analysis stage, ERD is used to describe the logical relationship between system entities. In the design stage, ERD is used to describe the relationship between physical tables. In the demand analysis stage, ERD is used to describe objects in the real world. ERD only pays attention to the relationship between data in the system, but lacks the description of the system function. If the ERD and DFD methods are combined, the system requirements can be described more accurately.

In object-oriented analysis, Use Case is usually used to obtain software requirements. Use Case describes the system behavior by describing the interaction between the system and the activator. By breaking down system goals, Use Case describes all the steps that the operator performs to achieve these goals. The main advantage of the Use Case method is that it is user-oriented. You can refine your needs based on your own Use cases. In addition, you can Use cases to conveniently obtain test cases for system functions.

========================================================== =====

In the previous issue, we introduced the first two steps (getting user requirements and analyzing user needs) in the five steps of requirement analysis ), this article will continue to introduce the next three steps (Writing Requirement documents, reviewing Requirement documents, and managing requirements), and discuss relevant practical issues with you.

　

1. Write Requirement documents

Requirement documents can be described in natural or formal languages, and graphic expressions and model representations can be added. The requirement document should cover all user requirements (functional requirements and non-functional requirements ).

2. Review Requirement documents

After the requirement documents are completed, they must be formally reviewed to serve as the basis for the next phase of work. General reviews are divided into user reviews and peer reviews. The user and the developer's description of the software project is based on the requirement specification. The user acceptance standard is formulated based on the content in the requirement specification, therefore, when reviewing the requirement document, users' opinions are the first. The purpose of peer review is to discover potential defects or errors in the early stage of the software project, so as to avoid these errors and defects missing into the subsequent stage of the project.

3. management requirements

　　

Figure 1 requirement change process

Demand changes are inevitable. How to manage software requirements in a controllable manner is of great significance for the smooth development of the project. If you perform user research and analysis in a hurry, it usually means unstable requirements. Therefore, demand management should ensure that all requirements analysis activities are fully executed. For the management of demand changes, we mainly use the demand change process and Demand Tracking matrix management methods. The demand change process and Demand Tracking matrix are shown in Figure 1 and figure 2 respectively.

　　

Figure 2 requirement tracking matrix

FAQs and Suggestions

Q. What are the differences between customers and end users?

A. You can use Figure 3 to illustrate the differences between them.

　　

Figure 3 requirement acquisition Channel

The software requirements come from two aspects: system engineering and customer. The customer is the main requirement provider (the system engineering requirements also come from the customer ). The customer needs to collect the needs of its end users, consider their own needs, and then provide them to the developers. If the customer does not carefully collect the requirements of end users, the system must meet the requirements of end users for convenient development.

Q. How do I conduct user interviews?

A. First, the purpose and outline of the interview must be determined in advance. Second, because users often do not know what needs to be provided, they need to be guided by developers.

Q. What is the user interview content?

A. First, ask the user to describe how they can complete their current work and abstract A workflow or work model with the user. Then, after receiving the user's approval, explain to the user how to implement these functions, and explain which steps can be implemented in an automated manner.

Q. which method is the best for requirement analysis?

A. Different demand analyses have different characteristics. No method can replace other methods completely. Otherwise, there will be no different requirement modeling methods. In general, DFD + ERD can be used to describe those with clear functional layers, while use case is suitable for describing complex functional structures. The purpose of requirement analysis is to establish a requirement model. Different subsystems may use different modeling methods.

Q. What is the purpose of prototype?

A. The prototype analysis method is usually used to help developers further obtain user requirements or ask users to confirm the requirements. Developers often provide users with a visual interface as a prototype, and arrange necessary elements on the interface to demonstrate the functions required by users. You can use the fourth generation of languages (such as Visual Basic and Delphi) to quickly generate user interfaces. You can also use FrontPage and other online page creation tools to generate Visual page streams for users.

The purpose of a prototype is to obtain requirements. However, prototype verification is sometimes used to verify key technologies or technical difficulties. For technical prototypes, the interface is often ignored.