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

Reprinted from: http://www.mypm.net/articles/show_article_content.asp?articleID=5369

In the previous issue, we introduced the first two steps in the five-step requirement analysis (acquiring user requirements, analyzing user needs), and this issue will continue with the next three steps (writing requirements documents, reviewing requirements documents, managing requirements), and discussing relevant practice issues with you.

　1. Writing Requirements Documents

Requirements documents can be described in natural or formal languages, as well as the way in which graphics are expressed and modeled. The requirements documentation should include all of the user's needs (functional requirements and non-functional requirements).

　2. Review requirements Documentation

Once the requirements document is completed, a formal review is required to serve as a basis for the next phase of work. The general review is divided into two categories: User review and Peer review. The user and Developer's description of the software project content is based on the requirement specification, and the user acceptance criterion is based on the content of the requirement specification, so the user's opinion is the first when the requirement document is reviewed. The goal of peer review is to identify potential defects or errors at the beginning of a software project and to avoid these errors and pitfalls from being missed in the project's subsequent stages.

　　3. Management Requirements

　　

Figure 1 Requirements Change process

The change of demand is unavoidable, how to manage the software demand in a controllable way is of great significance to the smooth progress of the project. If user research and analysis is done in a hurry, it often means unstable demand. Therefore, demand management to ensure that the needs of the various activities have been fully implemented. For the management of requirements change, we mainly use the requirement change process and the management mode of the requirement tracking matrix. The requirements change process and the requirements tracking matrix are shown in Figure 1 and Figure 2, respectively.

　　

Figure 2 Demand Tracking matrix

Frequently asked questions and suggestions

Q, what is the difference between a customer and an end user?

A, you can use the map to explain the difference between them.

　　

Fig. 3 schematic diagram of demand acquisition channel

Software requirements come from two aspects of systems engineering and customers, where customers are the main demand providers (systems engineering requirements also come from customers). Customers need to gather their end users ' needs and consider their own needs before they are available to developers. If the customer does not collect the end user's demand earnestly, the development convenience needs to do this, because the system finally satisfies the end user's demand.

Q, how to conduct user interviews.

A, first, we must determine the purpose and outline of the interview beforehand. Second, because users often don't know what needs to be provided, they need to be guided by the developer.

Q, what is the user interview content.

A, first, ask the user to describe how they are doing their current work, and work with the user to abstract a workflow or work model. Then, after getting the user's approval, explain to the user how to implement these functions, and explain which links can be realized by automated means and so on.

Q, which is the best way to do the demand analysis.

A, different needs analysis has different characteristics. There is no way to completely replace other methods, otherwise there will be no different requirements modeling now. In general, Dfd+erd can be used to describe the requirements that are more clearly functional, while the use case is suitable for describing the complex requirements of a functional structure. The purpose of the requirement analysis is to establish a model of demand, and different subsystems may use different modeling methods.

Q, how to prototype, what is the purpose of the prototype.

A, the prototype analysis method is often used to help developers to further obtain user requirements or to allow users to confirm the requirements. Developers often first provide the user with a visual interface as a prototype and layout the necessary elements on the interface to demonstrate the functionality required by the user. You can use the fourth generation language (such as Visual Basic, Delphi, and so on) to quickly build the user interface, or you can use Web authoring tools such as FrontPage to generate user-viewable page flows.

The purpose of prototypes is often to obtain demand. But sometimes prototypes are used to validate key technical or technical difficulties. For technical prototypes, the interface is often ignored.