Demand development and management is a very important task in software projects. According to the survey, among the many failed software projects, about 45% of the requirements are caused, demand work will have a crucial impact on the final implementation of software projects. Even so, in project development, many people do not have enough understanding of their needs. From the perspective of projects I have participated in or come into contact with, the amount is as small as RMB 100,000, there are problems with the demand for hundreds of millions of software projects, some developers do not pay attention to the reasons, some are technical reasons, some are personnel organization reasons, some are communication reasons, and some are mechanism reasons. The above reasons all indicate that developing software requirements is a systematic task, instead of simple technical work, only the system can understand and master the basic concepts, methods, methods, evaluation criteria, risks, and other related knowledge of the needs, and apply them in practice, in order to truly develop and manage requirements. This article will introduce the basic knowledge about software requirements and some personal experience in practical work to help readers understand software requirements and learn some basic methods of demand development, avoid project failures due to requirements. 1. What are software requirements and requirements engineering? 1.1 Definition of software requirements Define the software requirements in the IEEE software engineering standard vocabulary (1997): (1) Conditions or capabilities required by the user to solve the problem or achieve the goal. (2) systems or system components shall meet the conditions or capabilities required by the contract, standard, specification or other formal provision documents. (3) A document describing the conditions or capabilities described above (1) or (2. In layman's terms, "demand" is the user's needs. It includes the user's problems to be solved, the goals to be achieved, and the conditions required to achieve these goals, it is a description of the development work of a program or system, generally in the form of documentation. 1.2 Definition of demand Project The process of requirement analysis is also called the Requirement Engineering and requirement stage. It consists of two parts: requirement development and requirement management. Requirement development refers to a series of activities that generate requirements from situation collection, analysis and evaluation to document writing and review, which are divided into four stages: Situation acquisition, analysis, specification formulation and review. These four stages do not necessarily follow a linear sequence, and their activities are independent and repeated. Requirement management is an activity that controls and maintains requirements agreements during software project development. It includes change control, version control, requirement tracking, and requirement status tracking. 2. Risk of Demand Analysis The impact of objective factors such as the participants of requirement analysis, business model, investment, and time is subjective and descriptive. Therefore, demand analysis often faces some potential risks. These risks are mainly manifested in: (1) users cannot correctly express their own needs. In the actual development process, users often encounter situations where they are not very clear about their real needs. They think that computers are omnipotent, you just need to briefly explain what you want to do, but you do not want to talk about the business rules and workflows. This often increases the difficulty of requirement analysis. Analysts need to spend more time and energy communicating with users to help them sort out their ideas and find out their real needs. (2) Insufficient cooperation among business personnel. Some users are busy in their daily work. They do not want to spend more time and energy explaining their business to analysts. This will increase the difficulty and workload of analysts, the system may also be unavailable due to insufficient business requirements. (3) constantly changing user requirements. Due to incomplete requirement identification, business changes, request errors, and unclear requirements, requirements may change throughout the project lifecycle. Therefore, we must realize that, the process of software development is actually a process of struggle against changes. demand changes are a problem that every developer and Project Administrator may encounter. Once a demand change occurs, you have to modify the design, rewrite the code, modify the test cases, and adjust the Project Plan. The changes in requirements are like the source of all evil, which brings great trouble to the normal progress of the project. (4) requirement completeness. How can we eliminate any omissions in requirements? This is a big problem. It is almost impossible for a large system to raise the demand. Even for a small system, new demands will always come out from time to time. It is difficult for a system to determine a specific scope and put forward all the requirements at one time. This will lead developers to constantly improve the requirements in the project progress, first establish a system structure and then complete the Requirement Description, there is a high possibility of rework, which will bring frustration to developers and reduce their confidence in completing the project. (5) details of requirements. How detailed is the requirement? Although there are requirements for the compilation of national standards, it is difficult to give a specific indicator when it comes to a specific requirement. It can be said that the benevolent and wise have no final conclusion. The finer the requirements, the longer the cycle, the more possible changes, the stricter the design restrictions, and the higher the requirements for the extraction of common requirements. On the contrary, the thicker the requirements, the more people do not know about the technical design, the more they will influence the technical design. (6) ambiguity of the Requirement Description. The ambiguity of the Requirement Description refers to the fact that different readers have different understandings of the Requirement Description; the other is that the same reader can interpret a Requirement Description in different ways. Ambiguity may lead to different expectations for users, developers, and other project participants. It may also lead to a waste of time for developers and testers to have different understandings. The inevitable consequence is redo. (7) Ignore the analysis of user characteristics. Analysts tend to ignore the features of system users. Different users use different features of the system. The usage frequency varies, and the educational level and experience of users vary. If you ignore this, some users will be disappointed with the product. (8) requirement development time assurance. In order to ensure the correctness and integrity of requirements, the project owner often insists on spending a lot of time in the demand phase, but the user and development department leaders will be anxious because the project is delayed to see the actual results, they tend to force projects to move forward as soon as possible, and demand developers will be exhausted by the complexity and complexity of requirements, and they also hope to end the demand phase as soon as possible. 3. How to do a good job of demand Demand analysis is the most difficult task in software project development. It requires analysts to have rich demand analysis experience and good professional quality, analysts are also required to have good learning, PR, language, and organizational skills. In actual work, analysts should face different situations, such as different units, different departments, different personnel, different cultures, different relations, and different management levels, in the face of such a complex environment, how can we do a good job of demand analysis? First, we need to establish an effective working mechanism. Only by establishing a working mechanism can we ensure that the demand work is carried out in accordance with the established scheme, demand Development and Management participants will work in an orderly state. Second, we should make full use of our working mechanisms and personal abilities to obtain, analyze, compile Requirement documents, and manage requirements. 3.1 several factors to consider when establishing a demand analysis mechanism (1) grasp the most urgent and important issues of decision makers and draw greater attention. The importance that the user's decision makers pay to the project is the key to the smooth development of the project. The real intent of the decision makers is also the final demand of the user. Therefore, in the development process, we should take advantage of all the opportunities to understand the concerns of decision makers and the project information. In the process of negotiation, Special Report, Coordination Meeting, leadership inspection, and staged Result demonstration, use a short and clear language or text to grasp the issues most concerned by the leadership, guide them to understand and focus on project development. When the decision makers recognize the importance of the project, the demand analysis work is guaranteed in terms of manpower, material resources, and time. (2) establish organizational protection and clarify the division of responsibilities. Generally, project teams or engineering groups are set up for project development. Currently, common organizational forms include product management groups, quality and test groups, program development groups, user representative groups, and logistics support groups, the main division of labor of each group is: the product management group is responsible for determining and setting the project objectives, determining functional specifications based on the priority of the needs, and notifying the relevant personnel about the project progress. The Program Management Group is responsible for system analysis, and coordinates daily development work according to software development standards to ensure timely delivery of development tasks and control the project progress. The Development Team is responsible for delivering software systems as required by functional specifications. The quality and testing team is responsible for ensuring that the system complies with functional specifications. The testing and development work is independent and parallel. The user representative group is responsible for proposing requirements on behalf of users and testing software users. The Logistics Support Group is responsible for ensuring the smooth operation of the project. (3) Establish a good communication environment and atmosphere. The degree of communication between analysts and users is related to the quality of requirement analysis. Therefore, it is particularly important to establish a good communication atmosphere and handle the relationship between analysts and users, as investors, users will have some psychological advantages and hope their opinions will be paid enough attention. Analysts should fully recognize this and make psychological preparations to avoid disputes with them as much as possible, because our goal is to help users express their final needs. Analysts should pay attention to the following aspects during communication: 1) attitude should respect the other party, but it is not humble. Modesty may make users feel satisfied for a moment, but it is not good for long-term cooperation. Especially in the case of conflicts, users will habitually feel their advantages, without the comments of analysts. 2) analysts should work hard to adapt to the language expressions of different users. Everyone has their own expressions, so excellent analysts should be an excellent "listener" who can quickly adapt to the user's language style and understand what they mean. 3) be good at expressing yourself and asking questions. Analysts should first give the other party a full expression of his meaning before they speak. After understanding it, they should say it by themselves and try not to speak. 4) non-work Communication helps increase understanding and enhance communication. (4) Changes in requirement quality control must be institutionalized. changes in requirements are inevitable for software projects. Therefore, requirement quality control is a tough task. We must ensure the smooth implementation of this task, there must be a system guarantee. This system can be formulated in the project quality control plan, which mainly describes user requirements in a specific and quantitative manner, form a comprehensive, consistent, and standardized specification for software requirement analysis, clarify the working procedures and elements of the specification for requirement analysis, and standardize development activities, provide a basis for subsequent software design, implementation, testing, review and acceptance. In the plan, the responsibilities of all departments of the project team on Requirement quality control should be clarified, and the working procedures for requirement analysis should be formulated, including preparing the demand analysis work plan, preparing the requirement analysis statement, reviewing and confirming the requirement analysis specification statement, modifying and controlling the requirement analysis specification statement, and determining the quality of the requirement quality control. record document specifications. 3.2 requirements development and management methods Requirement development is a complex task, and many methods are used. Different development methods have different methods. Here we will briefly introduce some related methods: (1) Draw Association diagram: Draw a system Association diagram is a simple model used to define the boundaries and interfaces between the system and external entities of the system. (2) Feasibility Analysis: analyzes the feasibility of implementation of each requirement under the allowable cost and performance requirements, and puts forward the risks related to implementation of the requirement, including conflicts with other requirements, reliance on external factors and technical barriers. (3) demand priority: determine the priority level for using instances, product features, or individual requirements. Determine the features or requirements of the product version based on the priority. (4) system prototype: when users have unclear requirements, we can build a system prototype to better understand the problems to be solved by evaluating the prototype .. (5) graphic analysis model: drawing a graphic analysis model is an important means to describe Software Requirement Specifications. They help analysts clarify data, business models, workflows, and relationships between them, and identify missing, redundant, and inconsistent requirements. Such a model includes a data flow diagram, an object diagram, a State Transformation Diagram, a dialog box diagram, an object class diagram, and an interaction diagram. (6) data dictionary: a data dictionary defines all data items and structures used by the system to ensure that developers use a unified data definition. In the demand phase, the data dictionary should at least define customer data items to ensure that the customer and the development team use consistent definitions and terms. (7) Quality Function allocation: Quality Function allocation is an advanced system technology that associates product features and attributes with the importance to customers. This technology provides an analytical method to identify which features are most concerned by customers. It divides requirements into three types: expectation, common, and exciting. The purpose of requirement management is to control and maintain the requirements agreed in advance to ensure the consistency of the project development process, so that users can get the products they finally want. The requirement management methods mainly include the following: 1) determine the demand change control process. Make a selection, analysis, and decision-making process for demand changes. All demand changes must follow this process. 2) analyze the impact of demand changes. Evaluate each requirement change to determine its impact on the project plan and other requirements, clarify the tasks related to the change and assess the workload required to complete these tasks. These analyses will help the demand change control department make better decisions. 3) create a requirement baseline version and requirement control version document. Determine the requirement benchmark. This is a snapshot of the time when the project parties agree on the requirements. Subsequent demand changes follow the change control process. The requirement specifications for each version must be described independently to avoid confusion between the draft and the benchmark or between the old and new versions. 4) maintain the historical records of demand changes. Write the requirement change information into a document, record the change date, reason, owner, version number, and other content, and notify the personnel involved in the project development in a timely manner. In order to minimize confusion, conflicts, and false positives, a dedicated person should be designated to update requirements. 5) track the status of each requirement. You can save the status attributes of each requirement (such as recommended, approved, implemented, or verified) to the database, in this way, you can obtain the number of requests for each status class at any time. 6) Measure the stability of the demand. You can regularly compare the demand quantity with the demand change (ADD, modify, or delete) quantity. Too many demand changes "are an alarm signal", which means the problem is not really clear. 4. Requirements Analysis and Evaluation Criteria Different software engineering specifications have their own set of standards. Here we will introduce a common method recommended by nasa sel, it is one of the five common international software engineering specifications developed by the National Aviation and Space Administration Software Engineering Laboratory. Its Evaluation Criteria for the software demand process are: clear, complete, consistent, and testable. (1) clear: at present, most demand analysis still uses natural language. The biggest drawback of natural language demand analysis is its ambiguity, therefore, developers need to impose certain restrictions on the languages used in requirement analysis. For example, try to use a simple expression of Subject + action. The description in the demand analysis must be simple. Do not use questions or modify these complex expressions. In addition to the ambiguity of language, be sure not to use slang, that is, computer terminology. The most important part of requirement analysis is to communicate with users. However, most users are not computer professionals. If you use a line in requirement analysis, it will cause difficulties for users to understand. (2) integrity: the integrity of the demand is very important. If there is any missing demand, it will have to be reworked. During the software development process, the worst thing is that a requirement is missing when software development approaches completion. However, the actual situation is that the omission of requirements is a common occurrence. This is not only a problem of developers, but also occurs to users. It is very difficult to ensure the integrity of requirements. It involves all aspects of the demand analysis process, throughout the process, from initial requirement plan formulation to final Requirement Review. (3) Consistency: user needs must be consistent with business needs, and functional requirements must be consistent with user needs. In the demand process, developers need to refine the consistency relationship. For example, the user requirements cannot exceed the pre-defined range. Strictly observe the consistency between different levels to ensure that the last developed software system will not deviate from the initial goal. (4) testability: When will the testing of a project start? Some people say that it starts after encoding, some say that unit testing is performed at the same time during encoding, and system tests are conducted after encoding. These conclusions are not completely correct. In fact, the test starts from the demand analysis process, because the requirement is the input and reference of the test plan. This requires that demand analysis be testable. Only when all requirements of the system can be tested can the software always focus on the needs of users and ensure that the software system is successful. |
