PM "Requirements" project management-Requirements: Managing the software Requirements analysis process

The article summarizes, longitudinal, transverse, from the surface to the point, finally is the demand quality control.

The requirement analysis of software must have a deep understanding of the original business, extraction, abstraction, sublimation process.

Software requirements analysis is to extract from the user's business software system can help users solve the business problems, through the user's business problem analysis, the planning of our software products. This step is a distillation of the user's business needs, is a user business management process optimization, conversion to software products, thereby improving the management of the quality of the leap, this step is a success, directly related to the development of software products can be recognized by users, smooth delivery to customers, Customers can really use our products to help him solve business or management problems.

According to the description of software development process, the requirement stage can be subdivided into two small phases: demand research and requirement analysis, demand research needs to understand customer's target, user's business content, process, etc., which is a collection process of demand, and is the basic preparation of demand analysis. When we have understood and understood the user's business, we can begin to analyze the requirements. The requirements analysis of a software system can be performed by a product engineer or a system analyst or both in a phased collaboration.

First, extract the core, the main, urgent business, clear business process

Through the demand research, we will find that the users of various aspects of the business, from Think big, including the user's various business projects, business processes, and then detailed to the business process of each document, each record, such as the production process of each link in the record, the office of every notice, and even the document of the newspaper and send and receive, Family planning indicators statistics and so on. Such a complex variety of business, we start from where. At this time we need to look back to the software project specification, again warm the customer to the software project or product of the initial demand for the target and scope, our software is mainly for users to solve what kind of problem. Extracting the user's core, main, and much needed business from a multitude of businesses is a major concern for our software needs. Writing an article needs to be focused and prioritized, and I think planning a software PRODUCT is the same.

Extracting business and business processes from the user's complex business and extracting the same kind of business that is distributed across departments. For example, the management of materials, related to the production department needs planning, summary to the material department procurement plan, plan approval, procurement contract, material procurement, material Department of the receiving and depositing business, production department of material consumption and so on, I need to analyze the user of this business process which is the system can help management, Which is to be processed outside the system, fully analyze the user's existing business and business processes, we go to the next step.

second, the use of management ideas to optimize business processes

We provide management software products, to help users solve the management problem, then the user is such a business process, we need to analyze such a process is reasonable, there are defects, how to improve efficiency, solve problems, can use more advanced management ideas .... In general, we need to consider the optimization of business processes from two aspects. First, we use the network computer These new technology means, compared to the original manual, telephone and other ways in the transmission of information, information sharing, data processing and other aspects will bring new ways, will change the original business process. On the other hand, we consider whether we can use advanced management ideas, such as Mrpii, ERP, SCM, CRM, JIT, EIA, e-business and so on, to reorganize or optimize the existing business processes according to the understanding of the user's business. Of course, once involved in the business process changes must be with the customer's senior management to fully communicate, only the customer identification can be determined, because this will be in the software implementation needs the corresponding management system supporting implementation.

Iii. conducting business classifications and planning system blueprints

The above is clear, we can describe the system blueprint. The system has several subsystems, each subsystem has what modules, each module to deal with which business, it is important that each subsystem module between the data interface relationship, the basic data from where to enter, through what processing generated what results and so on. This process needs to collate and abstract the user's business, plan the software implementation, and plan the logical relationship between the software system modules. Because the system's page realization is according to the system module plan, should try to adopt the user easy understanding, the familiar way, the word carries on the module description. For example, the material management subsystem in ERP system, firstly make it clear that this subsystem is the material-related business processing system in ERP system, and it provides the data support of production material supply, consumption accounting and so on for the main production system and cost management subsystem. Therefore, in planning the subsystem module, according to the business process model, should include material needs planning, material procurement plan, out of stock management, inventory management and other major business modules, and then consider the initial data set required for software operation, add a basic information maintenance module (including material category, material coding and other information maintenance), It also takes into account the different needs of different users for this system, such as more production personnel, management personnel needs, and then add a separate comprehensive query and analysis module. In addition, the procurement of goods related to procurement contracts, can be placed in the contract management subsystem for unified consideration, here only to do the inquiry. In this way, the software system to manage the material management business, check whether it contains all the core of material management, the main business, then we found that such as material procurement, acceptance, library and other business or need material management business personnel to complete, the system can do is record results. Software system is the assistant system of management, can not completely replace all the work of man. Management software, together with the management system, the operation of the business personnel to constitute a complete set of management system.

Iv. Detailed description of software function points

Planning out the function module of software, just the functional framework of software, the next step needs to clearly describe the specific content of each module. What to include, what to do, a description of each function point, priority, business rules, detailed function descriptions, and more. These are also what the software Requirements specification must describe.

The performance of demand analysis, we now use the Requirements Specification document, UML language description of Use case diagram, Class diagram, activity diagram, as well as entity Relationship diagram, interface prototype and so on, from different angles, different requirements description of the software planning out of the picture.

v. Quality control of demand analysis

Software requirements analysis is directly related to the direction of software products, so the quality of demand analysis is critical. for this key point of quality control, it can be through internal review and peer review, and then the client side of the review . The internal review or peer review of the project team is mainly based on the company's standards and the experience of the reviewers themselves on the requirements of the analysis of ambiguous, unreasonable, illogical, non-conforming to the place to correct. And the customer's review is mainly to the description of the software implementation is really in line with their needs, can help them to solve problems and other aspects to make assessment.

software needs analysis must have a deep understanding of the original business, extraction, abstraction, sublimation process, especially the management software requirements analysis.

When you do a project, you often encounter such a thing.
Customers tell us that when talking about demand with your engineers, they always say yes. But when they do, take a look, it is not the case at all. And developers are complaining: users do not understand anything, and their needs are constantly changing, time is so tight, you let us do.
I think if the developer in the needs analysis, if the attention of the following points, may be able to avoid the passive situation.

1, master the relevant industry knowledge
Before communicating with customers, it is best to understand the relevant industry knowledge.
There is a project manager said: Industry knowledge is dispensable, as a demand for personnel, the most important thing is to communicate with customers. It is best to write down what the client says. Then, the project team decides, then feedback to the user. This kind of communication, can not effectively find the problem, but also easy to delay project time.

2, the heavy communication
Communication can take the form of interviews and research, meetings, phone calls, e-mails, group discussions, mock presentations, and more. My opinion is that it is best to communicate with the customer face to head. Jin Yong Martial Arts in the master battle, are smiling, poker face, competition is the internal force. Face-to-head communication is the internal force. So make sure you get the job done.
Communication is, in fact, mutually compromised. To the user reasonable requirements, to try to meet. Users of some unreasonable requirements, to find ways to avoid. Be tactful to remind users that if you do this, you may want to increase the project time or have higher requirements for the operating environment.
Communication must be documented, and the results of the communication can be categorized to facilitate subsequent analysis activities.

3. Dig into the details
Don't wait until the project is done, before you let the customer discover the problem.
Customers can provide you with only the functional requirements they think of, many issues are not within their consideration, if as the project stakeholders do not do analysis, simple according to functional requirements to design, planning, and ultimately Out of the system is very difficult to fully meet the customer's business process. At this point, the customer seems to need to change. But this change is seen as a change in demand. Since it is a change in requirements, you need to increase project costs (resources) or extend project time. I read an article saying that if you want the project to be successful, you have to build a close partnership with the user. However, this change in demand as a reason to let users out of pocket money, brothers do not do.
Therefore, demand analysis is not only to get the customer's needs, but more importantly, we need to analyze, understand the details, and the details and customer consultation, to obtain the most detailed information.

Demand is the most important job and the most troublesome. The customer does not understand the demand, their mind does not have this concept, they only want you to make the system that can use, with the good.
I think there are several places where it's more critical to make a demand.
1. Interpersonal communication skills. It's the most fundamental thing to say.
2. After understanding the requirements of the timely make a demo to confirm the customer, after confirmation to sign. This is very important, many times we understand the needs of the development, and so on after the development, but not what the customer wants, resulting in a huge waste; signed in order to let customers take this demo seriously
3. It is good to use, do not pursue too much. Programmers tend to pursue perfection, trying to get the job done at once, and the most efficient way is to see the results as soon as possible and then refine them slowly. In the early stages of the project, demand changes often, and the goal is to avoid wasting too much time on useless needs.

People who have done the software have heard such complaints: demand changes too quickly, software systems often have to be modified, have been working overtime for several weeks ...

How do you deal with this problem in general?

First, the root of the problem is that demand is constantly changing.

Many people have this experience, in capturing the demand, according to the customer's elaboration, made a record, and then developed the software, the customer said many places do not meet their meaning, and asked to modify.

Let's analyze the problems that exist during the capture requirements process.

The customer is likely to know very little about the knowledge of software, and he doesn't know what you need to know.

For example, a business process, from business logic to being able to translate into software implementations, is likely to be problematic. This is said in the information process needs to be carried out business transformation, because can input the computer, and output results must be able to formalize the content, this is also a lot of enterprise employees to resist information, one of the reasons, because the information will lead to people's factors will be relatively weakened, their work process will be completely transparent.

In this way, we must let the customer know what you want to know. How do we do that?

For the product category of the project, your customer is not one, then it is necessary to consult widely, the demand questionnaire is usually a comprehensive understanding of customer needs have a certain role.

For specific customers, they need to communicate directly with them.

Communicate with customers to pay attention to ways and means, not blind appointment, the following are some effective methods.

first, will be prepared in front of the full

Usually the list of issues before you is prepared far more than the time of the meeting. Usually the customer loses enthusiasm and patience after 2 hours of conversation with you, which is a common feature of most people. So full preparation is important.

If you go to the customer to capture the demand, usually the customer will say, what kind of system I need to do, and then I can use it to do this, that, and that ... and then I don't know what to say. At this point, you must come up with a list of pre-prepared questions, for each of the major functions of each function point to ask questions, one can not let go. The need for non-functional also can not be missed, such as the customer needs of the system at least a continuous number of hours without problems, the system in a number of visitors access to the response time range.

If you are not in front of the customer to provide information, forms, etc. to conduct a comprehensive study, the customer needs can not be investigated comprehensively, you may need to meet him repeatedly, so that you will give the customer the impression of inefficient work, he will gradually get bored with you, you will lose confidence in your future work performance.

Second, let customers open the conversation

It is very important to ask questions and guide customers to tell their needs, which is a great learning.

Some people often ask the question: "What is your workflow like?", this problem is a very classic invalid problem.

When you ask a question to a customer, you can think about it first, and if someone asks you the question, how do you answer it? Is it a good answer? If even you feel that this problem is not good to answer, you need to consider changing a law.

Often people talk about things they are familiar with, there will be no words to say, for the customer to do their own daily work, why he can not talk to you?

Ask the right questions, ask the customer to open the question, you win.

At this point you will be in front of the preparation work is particularly important, you have to do for their software functions, part of the question, can not be anxious, to go deep, and meticulous, how they handle these things, the operating habits and so on, because to change their habits, A new way to get them to adapt to your software is usually to reduce customer satisfaction and even ask you to make changes.

For some of the features of your conjecture and assumptions, also must ask the customer, is not at all, the customer is sometimes in the face of the feeling embarrassed to say that your thoughts are not necessary or wrong, then you must be sensitive enough, and the courage to deny yourself, this will reduce unnecessary development work, will also leave you with a good impression of respect for the facts.

Third, do not waste the customer's time

and customers to pay special attention to the interview, is not to waste the customer's time, let him feel very bored, this is the biggest need to capture the taboo.

Once you've made such a mistake, it's hard to make an appointment with him, and he's probably not willing to meet you again. Especially in the corporate leadership, they are usually masterful, can take the time to meet you, you should feel very honored, so cherish the meeting time.

This is also a lot of people who need to complain about the problem, "customers often do not have time to see me, I have any way", if you encounter such problems, you must reflect on yourself, is not once made such a mistake, next time must not be repeated.

Iv. understand the person who can answer the question correctly

Different questions need to ask different people, many of the requirements are small operational levels of the problem, there are a lot of problems related to the overall, it is necessary to find out what questions to ask who.

Many people who capture demand complain that "customers can't answer these questions, they don't know what to do," and if you come across this kind of thing, you have to reflect on it, do you ask the right person?

Some of the customers are large cadres, some are middle managers, and operators. For the details of the operation of the problem, be sure to ask those responsible for the operation of the personnel, they will be more aware of how each step needs to be done, if you ask the big cadres these questions, you will usually be a stall, or to work too busy, and other things and other reasons to be sent away.

For a global problem, the answer given by the operator level is usually not authoritative, even if they answer you, you must go to the big cadre to confirm, and then start the development work, otherwise you will regret.

v. Exerting the effectiveness of the prototype

Prototypes are good for improving customer awareness of the software, enabling them to have an intuitive understanding of the software, and in the face of prototypes, they can better present their ideas and opinions, especially to those customers who lack knowledge of the software.

Modifications to the prototype, confirmation, and finally a stable prototype, which will make the requirements more stable, reduce many of the implementation of the work of repeated modification work or rework.

Vi. making full use of the requirements confirmation meeting
(This method costs too high, personal experience)
The requirement confirmation meeting is usually attended by all stakeholders (stakeholders), which is a rare opportunity to identify the needs, we can gather together, such an opportunity is actually very difficult, so must cherish.

In this kind of meeting, we must first deal with the overall problem (with all relevant issues) to communicate, do not focus on some of the people interested in the discussion of the endless, so that the people who are not interested will walk away, so that you want to ask questions related to their opinions when you can not find people. For questions that are only related to individual departments or people, you can find time to discuss them alone.

If the requirements analysis phase is attributed to the preparation of the requirements specification, this simplification is often the culprit in the late-stage problems of the project. 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 in this phase. The following are the activities needed to get the user's needs (see Figure 1). The

understands 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.

to interview and investigate 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

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

⑴ to Know "why" for every requirement that a user makes, and to determine whether a user's request is justified;
 

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 the ERD describes the relationships between physical tables in the design phase. 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.

This paper introduces the first two steps in the five Steps of requirement analysis (to obtain the user's needs, analyze the user's needs), and continue to introduce the following three steps (writing the requirement document, reviewing the requirement document, managing the requirement) and discussing the relevant practical 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

Project management: How to do the demand analysis collection

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 the ERD describes the relationships between physical tables in the design phase. 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.