Collection of Software Requirement Analysis Methods (summary by the company's project manager)

Note: project requirement analysis is the beginning of a project and the cornerstone of project construction. In previous construction failures, 80% of the projects were caused by unclear demand analysis. Therefore, one of the key factors for a project's success is to grasp the degree of requirement analysis.
Project requirement analysis is the beginning of a project and the cornerstone of project construction. In previous construction failures, 80% of the projects were caused by unclear demand analysis. Therefore, one of the key factors for a project's success is to grasp the degree of requirement analysis. In principle, in the demand phase, the supervisor should respect the project management and project analysis capabilities of the supervisor. In the specific task development, the supervisor should focus on the autonomy of the supervisor without in-depth or interfering with the supervisor, unless there are many gaps and deficiencies in the project management and project analysis capabilities of the project team during the project cooperation process.

To ensure the success of the project, the supervisor must strengthen the project management and project analysis work, and adhere to the methods and means of absorption, assimilation and implementation in specific operations. Demand analysis is the beginning of a project and the cornerstone of project construction. In previous construction failures, 80% of the projects were caused by unclear demand analysis. Therefore, one of the key factors for a project's success is to grasp the degree of requirement analysis. The overall risk of a project is often manifested in unclear demand analysis, unreasonable business processes, and users' inhabits or willingness to use the software of the consumer. As a third-party supervision company, the customer and the customer must pay attention to the importance of demand analysis and use necessary means and methods to conduct demand research, at the same time, the supervisor should also conduct in-depth research on specific needs. Only in this way can we fully grasp the user's needs and directions, and have a say in defining functions and developing scopes in the future.

How to analyze requirements
Unlike detective reasoning, demand analysis needs to start with clues. Instead, we should first understand macro problems and the details.

An application software system (recorded as s) may involve a wide range of topics and can be classified by different problem domains (recorded as D). Each problem domain corresponds to a software subsystem.
S = {D1, D2, D3 ,... DN}
The problem domain Di is composed of several problems (recorded as P). Each problem corresponds to a software component in the subsystem.
DI = {P1, P2, P3 ,... Pm}
The PJ has several behaviors (or functions, marked as F), each of which corresponds to the implementation interface in the software component.
PJ = {F1, F2, F3 ,... FK}

The requirement statement should be suitable for leaders who only want to understand the macro needs and technicians who need to understand the details. Pay attention to two issues when writing the Requirement Specification:
1. It is best to comment out "why" for each requirement so that programmers can understand the nature of the requirement so that the most appropriate technology can be used to achieve this requirement.
2. The Requirement Description cannot be ambiguous, and cannot be in conflict with each other. If there is ambiguity or inconsistency, you need to re-analyze this requirement.

Analysis of key monitoring requirements
Due to the special nature of the project, the broad coverage of the industry, and the high risk of demand analysis, the importance of software demand analysis is self-evident, while demand analysis is indeed difficult to do. The reason is basically due to the following situations.
The customer cannot clarify the requirement
Some customers only have a vague feeling about their needs. Of course, they cannot clearly describe the specific requirements. For example, when many departments, institutions, and units throughout the country are building application systems and networks, most of the customer's office staff are not clear about the use of computer networks, lack of IT system construction experts and knowledge. At this point, the user will ask the software system analysts to imagine the demand for them. Project requirements are subjective, which may pose potential risks for future project construction.
Requirements change frequently
Based on past experience, with the customer's understanding of information construction and improvement of their business level, they will put forward new requirements and demand changes for the project at different stages and periods. In fact, there have never been any software requirement changes less than three times in history! Therefore, we must accept the fact that "requirements will change". When conducting demand analysis, we must understand how to prevent problems before they happen, and try to analyze as much as possible what are stable requirements and what are easy-to-change requirements, in order to design the system, the core architecture of the software must be stable, while leaving room for change. The consulting authority assumes an intermediate, fair, and impartial role in defining the demand analysis function. Therefore, the consulting authority must actively participate in the preparation of the demand analysis, this allows customers and administrators to define system functional boundaries of "what to do" and "nothing to do.
Incorrect understanding of analysts or customers
It is impossible for software system analysts to be full talents, not industry experts. Different analysts may have different understandings of customer requirements. If the analyst understands the error, it may lead to unnecessary development work in the future. One joke is that an alien spy lurks into the earth's spying information and writes a report to his boss: "cars dominate the earth. They drink gasoline and move on with four wheels. They have a loud voice, and their eyes can emit intense light at night ...... Interestingly, there is a kind of parasite called 'people' in the car, which completely controls the car ." Therefore, the uniqueness of the analyst's knowledge may cause misunderstanding and failure of the requirement analysis. At this time, the consulting and supervision company must follow the actual project demand survey plan to remind the Party to enhance business understanding and focus on communication skills.

Demand Analysis Methodology
Based on past engineering experience, the requirement analysis work method should be positioned in "three stages" (also known as "three-step method ").

Stage 1: Visitation)
This stage is an interview with the leadership and business personnel of a specific user. The main purpose is to grasp the specific demand direction and trend of the user from a macro perspective, measure the test taker's knowledge about the specific situation and objective information about the existing organizational structure, business processes, hardware environment, software environment, and operating systems. Establish good communication channels and methods. It is best to specify the contact person for this project for specific functional departments and committees.
Implementation Methods: Interview and survey forms
Output results: Survey Report and Business Process report
Stage 2: "induction)
This stage is based on the actual and objective information that the publisher has learned about the organizational structure, business processes, hardware environment, software environment, and existing operating systems of specific users, make a simple user process page based on existing hardware and software implementation solutions, and use inductive and heuristic survey methods and methods based on previous project experience, discuss with users the rationality, accuracy, ease of use, and habit of business process design. You can use a simple demo to check the rationality and accuracy of the entire business process, and provide suggestions and methods for improvement in a timely manner.
Implementation Methods: Visiting (induction) and prototype demonstration
Output results: survey and analysis report, prototype feedback report, and Business Process report
Stage 3: "validation" (afrem)
This stage is based on the results of the above two stages, and carries out specific process refinement and data item validation stages. At this stage, the producer must provide the prototype system and clear business process reports and data item tables, it can clearly describe the business flow design objectives of the system to users. The user can provide feedback by reviewing the Business Process report, data item table, and the demo system provided by the operator, and sign and confirm the accepted reports and documents.
Implementation Means: visit (review and confirmation), submit Business Process report and data item table; prototype demonstration System
Output results: requirement analysis report, data items, business process report, and prototype system feedback (the latter three can be included in the requirement analysis report and submitted to the user and supervisor for confirmation and archiving)
On the whole, the three stages of demand analysis are an important part of demand research. The implementation and adoption of the three stages or three-step method, both the user and the publisher are guaranteed to succeed in the project. Of course, in the process of system construction, especially when the iterative development model is adopted, the demand analysis work should be carried out continuously, and in the later stage of demand improvement, work is basically concentrated in the next two stages.