Give me an example to explain how to do software requirements analysis.

Project demand analysis is the beginning of a project and the cornerstone of project construction. 80% of failed projects in the past were caused by unclear demand analysis. Therefore, one of the key factors for the success of the project is the degree of grasping the demand analysis.

Project demand analysis is the beginning of a project and the cornerstone of project construction. 80% of failed projects in the past were caused by unclear demand analysis. Therefore, one of the key factors for the success of the project is the degree of grasping the demand analysis. In principle, the supervision in the demand stage should respect the contractor's project management and project analysis ability; In the development of specific tasks, don't go deep and interfere with the autonomy of the undertaker, unless there is a big gap and deficiency in the project management and project analysis ability of the undertaker during the project cooperation. In order to ensure the success of the project, the supervisor must strengthen project management and project analysis, and adhere to the methods and means of absorption, assimilation and implementation in specific operations. Among them, demand analysis is the beginning of a project and the cornerstone of project construction. 80% of failed projects in the past were caused by unclear demand analysis. Therefore, one of the key factors for the success of the project is the degree of grasping the demand analysis. The overall risk of the project is often manifested in unclear demand analysis, unreasonable business process, and users are not used to or unwilling to use the contractor's software. As a third-party supervision company, we must remind contractors and clients of the importance of demand analysis and take 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 truly grasp the needs and direction of users and have a say in the future functional definition and development scope. How to conduct demand analysis? Demand analysis does not need to start with clues like detective reasoning, but should first understand the macro issues and then understand the details. An application software system (labeled S) can cover a large area and can be classified into different problem domains (labeled D), and each problem domain corresponds to a software subsystem. S={D 1, D2, D3, …Dn} The problem domain Di consists of several problems (denoted as p), each of which corresponds to a soft component in the subsystem. Di={P 1, P2, P3, …Pm} The problem Pj has several behaviors (or functions, denoted as f), and each behavior corresponds to the implementation interface in the software component. Pj={F 1, F2, F3, ... fk} Requirements specifications should be suitable for leaders who only want to know the macro requirements and technicians who need to know the details. There are two problems to pay attention to when writing the requirement specification: 1. It is best to indicate "why" for each requirement, so that programmers can understand the essence of the requirement and choose the most appropriate technology to realize it. 2. The demand statement should not be ambiguous, let alone inconsistent. If there is ambiguity or inconsistency, this requirement should be re-analyzed. Focus on monitoring requirements analysis Because of the particularity of the project and the universality of the industry, as well as the high risk of requirements analysis, the importance of software requirements analysis is self-evident, and requirements analysis is really difficult to do. The reason is basically due to the following conditions. The customer can't explain the demand clearly. Some customers just have a vague feeling about the demand, and of course they can't tell the specific demand clearly. For example, when many departments, institutions and units in China are building application systems and networks, most office workers at the client side are not clear about the use of computer networks, and they lack experts and knowledge in IT system construction. At this point, users will ask software system analysts to imagine requirements for them. The demand of the project is subjective, which lays a potential risk for the future construction of the project. According to the past historical experience, with the customers' understanding of information construction and the improvement of their own business level, new requirements and changes will be put forward to the needs of the project at different stages and periods. In fact, there is no software requirement change less than three times in history! Therefore, we must accept the fact that "demand will change". When analyzing requirements, we should know how to nip in the bud and try to analyze which requirements are stable and which are variable, so as to build the core of software on stable requirements and leave room for change when designing the system. The consulting supervisor plays an intermediary, fair and just role in defining the function of demand analysis, so he must also actively participate in the preparation of demand analysis, thus helping customers and contractors to define the system function boundary of "what to do" and "what not to do". Analysts or customers misunderstand that software system analysts can't all be generalists, let alone experts in the industry. Different analysts may have different understandings of the needs expressed by customers. If the analyst understands it wrong, it may lead to the waste of future development work. I remember a joke that an alien spy sneaked into the earth to spy on information. He wrote a report to his boss: "Cars dominate the earth. They drink gasoline and roll forward with four wheels. The sound is very loud, and their eyes can emit strong light at night ... Interestingly, there is a parasite called' people' in the car, and these parasites completely control the car. " Therefore, the specificity of analyst's knowledge will also lead to misunderstanding and failure of demand analysis. At this time, the consulting supervision company must study the scheme according to the actual project requirements, reminding the contractor to strengthen business understanding and pay attention to communication skills. Methodology of requirement analysis According to previous engineering experience, the working method of requirement analysis should be positioned in "three stages" (also called "three-step method"). The first stage: "interview" is to communicate with the leaders and business personnel of specific users. The main purpose is to grasp the specific demand direction and trend of users from a macro perspective, and understand the specific access and objective information such as the existing organizational structure, business process, hardware environment, software environment and existing operating system. Establish good communication channels and ways. For specific functional departments, it is best to specify the interface person of this project. Means of implementation: interview, survey form output: survey report, business process report Phase II: "Induction" This phase is to make a simple user process page based on the contractor's understanding of specific practical and objective information such as organizational structure, business process, hardware environment, software environment and existing operating system. Combined with the existing software and hardware implementation scheme. At the same time, combined with previous project experience, the rationality, accuracy, convenience and habit of business process design are discussed with users by inductive and heuristic research methods and means. Users can feel the rationality and accuracy of the design of the whole business process by operating a simple DEMO, and put forward suggestions and methods for improvement in time. Implementation means: visit (induction), prototype demonstration, output results: investigation and analysis report, prototype feedback report, business process report. The third stage: "Afirm" is the stage of process refinement and data item confirmation according to the results of the above two stages. At this stage, the contractor must provide the prototype system, clear business process report and data list, and clearly describe the business process design objectives of the system to users. Users can give feedback by viewing the business process report, data item list and running the demonstration system provided by the contractor, and sign the accepted reports and documents for confirmation. Means of implementation: visit (review and confirm) and submit business process report and data item list; Output of prototype demonstration system: requirement analysis report, data item, business process report and prototype system feedback (the latter three can be unified in the requirement analysis report and submitted to users and supervisors for confirmation and filing). Generally speaking, the three stages of demand analysis are an important part of demand investigation, and the implementation and adoption of the three stages or three-step method also provide a guarantee for the success of the project for both users and contractors. Of course, in the process of system construction, especially when the iterative development mode is adopted, the requirement analysis needs to be carried out all the time, and in the later requirement improvement, the work is basically concentrated in the latter two stages.