Project management: How to do demand analysis (I.)

If the requirements analysis phase of the work is attributed to the preparation of requirements specification, this simplification is often the cause of the problem in the late stage of the project is the culprit. It is recommended to use the following steps to form a software requirement: Get user requirements → analyze user requirements → write requirements documentation → review requirements documentation → management requirements. Let's talk about the first two steps (getting the user's needs, analyzing the user's needs).

Get user Requirements

This is one of the most important tasks of this stage. The following are the activities needed to get the user's needs (see Figure 1).

Understand all user types and potential types of the client side. Then, according to their requirements to determine the overall objectives of the system and the scope of work of the system.

Interviews and surveys of users. Communication can take the form of meetings, phone calls, e-mails, group discussions, mock presentations, and more. It is important to note that each communication must be recorded, and the results of the communication can be categorized to facilitate subsequent analysis activities. For example, you can subdivide the requirements into functional requirements, non-functional requirements (such as response time, mean time to failure, automatic recovery time, and so on), environmental restrictions, design constraints, and so on.

The demand analyst makes further analysis and collation of the collected user requirements. Here are a few common guidelines:

⑴ should Know "why" for each requirement of the user, and judge whether there is sufficient reason for the user's request.

　　

Figure 1 Getting the user's needs activity

⑵ the "How to do" approach to "what to achieve", because the goal of the demand analysis phase is "what to do" rather than "how";

⑶ analyzes the implicit requirements derived from user requirements and identifies implicit requirements that are not explicitly proposed by the user (which may be a precondition for user requirements), which is often overlooked, often due to a lack of sufficient consideration of implied requirements to cause demand changes.

The demand analyst submits the survey user's needs in the appropriate way to the user and the developer's stakeholders. Together, we confirm that the results submitted by the demand analysts reflect the user's intentions. The requirements analyst needs to perform the following activities in this task:

⑴ clearly identifies those that are not identified (there are often many such pending items in the early stages of demand analysis);

⑵ The requirements to meet the overall objectives of the system;

⑶ guarantees consistency between requirements items and resolves possible conflicts between requirements items.

Analyze user needs

In many cases, the analysis of user needs is in parallel with the acquisition of user requirements, mainly through the establishment of models to describe the needs of users, for customers, users, developers and other different participants to provide a channel for communication. These models are an abstraction of demand, providing a bridge of ease of communication in a visual way. The analysis of user requirements and the acquisition of user requirements have similar steps, the difference is to analyze the user needs to use the model to describe, in order to obtain a clearer user needs. Analysis of user requirements requires the following activities to be performed:

A graphical representation of the overall structure of the system, including the boundary and interface of the system;

By prototyping, page flow or other ways to provide users with a visual interface, users can make their own evaluation of the needs;

System feasibility analysis, technical feasibility of requirement realization, environmental analysis, cost analysis, time analysis, etc.

It describes the contents of the system's function items, data entities, external entities, relationships between entities, state transitions between entities, and so on.

　　

Fig. 2 schematic diagram of DFD

There are many ways to model requirements, and the most common are three ways of using a dataflow diagram (DFD), an Entity Relationship Diagram (ERD), and a use case diagram. As the main method of structural system analysis and design, DFD has been widely used, and DFD is especially suitable for the expression of MIS system. DFD uses four basic elements to describe the behavior of the system, processes, entities, data streams, and data storage. The DFD method is easy to understand, and the user can easily get the logical model and physical model of the system, but it is impossible to judge the temporal relation of the activity from the DFD diagram. Figure 2 depicts the DFD diagram for a project.

The

Erd method is used to describe the correspondence between system entities, and the requirements analysis phase uses the ERD to describe the logical relationships of entities in the system, and in the design phase, the ERD describes the relationships between physical tables. The requirements Analysis phase uses the ERD to describe objects in the real world. The ERD only focuses on the relationship between the data in the system, and lacks a description of the system's functions. 　　If you combine the ERD with the two methods of DFD, you can more accurately describe the requirements of your system. Use cases are often used in object-oriented analysis methods to obtain the software requirements. Use case describes the behavior of the system by describing the interaction between the system and the active person. By decomposing the system target, the use case describes all the steps that the active person performs to achieve these goals. The main advantage of the use case method is that it is user-oriented, and users can refine their own needs according to their own case. In addition, you can easily get test cases for system functionality by using the use case.