What are software requirements? What does software demand mean?

What are software requirements? What does software demand mean?   　　For most people, if they want to build a house of millions of yuan, they will certainly discuss various details with the project owner. They all understand that the modifications after the project is completed will cause losses, and the dangers of the change details. However, when it comes to software development, people become "awesome. In software projects, 40% to 60% of the problems are the root of the need analysis phase (leffingwell 1997 ). Many organizations can still adopt some nonstandard approaches to basic project functions, resulting in a gap (expect difference) -There is a huge expectation difference between the software developed by the developer and the software that the user thinks. In software engineering, all risk owners (stakeholder) are very interesting. I have seen many translations, including those translated into stakeholders and some translated into participants, but I think the main meaning of this translation is people who have close interests in this project) all of them are interested in the demand analysis stage. These risk owners include customers, users, business or demand analysts (persons responsible for collecting customer requirements and preparing documents, and persons responsible for communications between customers and Development Institutions), developers, testers, user document writers, project managers, and customer managers. If this part of work is done well, it can develop excellent products, and make customers satisfied, developers also feel satisfied and enriched. Otherwise, misunderstandings, setbacks, obstacles, and potential threats to quality and business value may occur. Because demand analysis lays the foundation for software engineering and project management, it is best for all risk owners to adopt an effective demand analysis process. Definition of software requirements

The requirements defined in the IEEE software engineering standard vocabulary (1997) are: (1) the conditions or capabilities required by the user to resolve the problem or achieve the goal ). (2) systems or system components shall meet the conditions or capabilities required by contracts, standards, norms or other formal provision documents. (3) A document describing the conditions or capabilities described above (1) or (2.

Requirement levelThe following are definitions of common terms in the field of demand engineering. Software requirements include three levels-business requirements, user requirements, and functional requirements-and non-functional requirements. Business requirement reflects the high-level objective requirements of organizations or customers on systems and products, which are described in the project view and scope document. The user requirement document describes the tasks that must be completed by the user to use the product. This is described in the use case document or solution script (scenario) description. Functional requirements define the software functions that developers must implement so that users can complete their tasks and meet business needs. A feature is a set of logical functional requirements that provide processing capabilities and meet business needs. Relationship between components of software requirements. In addition, the specification of software requirements should include non-functional requirements, which describe the behaviors and operations performed by the system to users. It includes standards, specifications, and contracts that must be followed by the product, details of the external interface, performance requirements, design or implementation constraints and quality attributes. The constraint refers to the limitation on the design and construction of software products by developers. Quality Attributes describe product features from multiple perspectives to reflect product features. It is extremely important for users and developers to describe products from multiple perspectives. It is worth noting that the requirements do not include design details, implementation details, project plan information or test information. The requirement has nothing to do with it. It focuses on fully explaining what you want to develop. Frederick Brooks fully demonstrated the important role of the demand process in software projects in his 1987 classic article "no silver bullet: essence and accidents ofsoftware engineering: the most difficult part of developing a software system is to accurately describe what to develop. The most difficult conceptual task is to compile detailed technical requirements, including all interfaces for users, machines, and other software systems. At the same time, this is also part of the system that will eventually cause great damage if you do something wrong, and it is extremely difficult to modify it later. In most software systems, end users may not know what their needs are. If your user tells you that this is all about your needs, don't trust him and continue to ask questions until you are exhausted. Although it sounds incredible, this is a lesson. In my project, no one of the users called me when the software was nearing completion and said, "I have read your software, I think I have to make some changes. In those days, I even got a call-tone phobia.     Demand riskThe following lists some very dangerous methods used in demand analysis. If you find that some of your methods are similar, give yourself some time and think about them, these practices will have a fatal impact on your software. 1. customers who do not have enough users to participate often do not understand why it takes so much effort to collect requirements and ensure the quality of requirements. Developers may not pay attention to user participation. The reason is: first, it is not as interesting to write code as it is to work with users; second, it is because developers feel that they have understood the needs of users. In some cases, it is difficult for the customer to directly contact the user who actually uses the product, and the customer does not understand the real needs. However, representative users should be directly involved in the development team in the early stage of the project and go through the entire development process together. The most important thing is that the user must pay attention to his software and make him understand that if he fails, his loss will be the greatest (of course, your loss will not be small, but at this time you must let him pay attention to this job ). If the user does not pay enough attention to it, find a solution. Otherwise, you will not need to continue. 2. The increasing user requirements. If the demand is constantly supplemented during development, the project will become larger and larger, thus exceeding the planning and budget scope. This makes the problem more difficult to solve. In fact, the root cause of the problem is changes in user requirements and changes made by developers to new requirements. To minimize the scope of demand changes, the project view, scope, objectives, constraints, and success criteria must be clearly stated at the beginning, this description serves as a reference framework for evaluating demand changes and new features. The description includes the change control process for analyzing the impact factors of each change, which helps all risk owners understand the rationality of business decisions, that is, why some changes are made, time, resource, or feature compromise. Continuous changes in product development will cause increasingly disordered overall structure, and patch code will make the entire program difficult to understand and maintain. Inserting the patch Code violates the strong cohesion and loose coupling design principles. In particular, if the project configuration management is not complete, revoking the change and deletion features will cause problems. If you differentiate the features that may bring changes as soon as possible, you can develop a more robust structure and better adapt to it. In this way, the requirement changes in the design phase will not directly cause the patch code, but will also help reduce the quality reduction caused by changes. The worst thing is that users feel sorry if they don't add any more features. I have seen a data warehouse Phase I project and there is no well defined scope in the design phase. When I asked the project manager this question, he thought it was all done, the contract was also clearly written and not paid much attention. However, the user's suggestion for modification is far beyond the scope, and the project time is doubled. The entire project team members were exhausted, but they repeatedly received complaints from users that the project failed. 3. Ambiguous requirements ambiguity is the most terrible problem in the Requirement Specification Description (Lawrence 1996 ). The meaning of this layer means that many readers have different understandings of the requirement description, and the meaning of this layer means that a single reader can explain a Requirement Description in more than one way. Ambiguous requirements may lead to different risk owners to have different expectations, which will waste time on errors and make the tester and developer expectations different. A system tester once told me that her test group often had to rewrite many test cases and redo many tests because she had to understand the requirements. The inevitable consequence of ambiguous demands is rework-redo what you think is done well. Rework will consume 40% of the total development cost, and 70% ~ 85% of redo results from demand side errors (leffingwell 1997 ). Imagine what would happen if you could reduce the number by half? You can develop products faster, develop more and better products in the same time, and even occasionally go home to rest. One way to deal with ambiguous needs is to organize teams responsible for reviewing requirements from different perspectives. Simply browsing the requirement document cannot solve the problem of ambiguity. If different reviewers explain the requirements from different perspectives, but each reviewer truly understands the requirements document, the ambiguity will not be discovered until the project is later, if we find it again, it will make the correction very costly. 4. the unnecessary feature "Superfluous" refers to the new features that developers try to add "user appreciation" but are not involved in the Requirement Specification Description. It is often the case that users do not think these functions are very useful, so that the effort spent on them is "useless. Developers should design solutions for customers and provide them with innovative ideas. Specific functions should be balanced between the customer's needs and the technical feasibility of developers within the allowed time limit, developers should strive to make the functions simple and easy to use, instead of leaving the customer's requirements without the customer's consent and making their own claims. Similarly, customers may sometimes require functionality that looks "cool" but lacks practical value. However, implementing these features only consumes time and costs. In order to minimize the harm caused by "image farming", you should be sure that you understand why these features should be included and the "ins and outs" of these features ", in this way, the demand analysis process always focuses on the core functions that allow users to complete their business tasks. Keep in mind that the software's success standard is to determine whether to solve the user's problems, rather than having multiple cool functions. 5. sometimes, the customer does not understand the importance of requirement analysis. Therefore, the customer only provides a brief description of the specifications, which only covers the concept of the product, then let the developers improve the project progress. what is likely to happen is that the developers first establish the product structure and then complete the Requirement Description. This method may be suitable for cutting-edge research products or needs (McConnell 1996), but this is not the case for most commercial applications. In most cases, this will bring setbacks to developers (so that they can work under incorrect assumptions and extremely limited guidance ), it will also bring troubles to customers (they cannot get the products they imagined ). 6. Ignoring User Classification most products use different features by different people. The usage frequency varies, and the user's educational level and experience level are also different. If you cannot classify all these major users in the early stages of the project, some users will be disappointed with the product. For example, menu-driven operations are too inefficient for advanced users, but undefined commands and shortcut keys make them difficult for unskilled users. 7. inaccurate plan "The above is my opinion on new products. Well, can you tell me when you will finish it ?" Many developers have encountered this problem. A lack of understanding of demand analysis will lead to overly optimistic estimates, which may cause a lot of trouble when overspending is inevitable. According to reports, the main reasons for the inaccurate estimation of software costs during the demand process are as follows: frequent demand changes, missing demands, insufficient communication with users, low quality requirement specification descriptions, and imperfect Demand Analysis (Davis 1995 ). The correct response to the question asked for inaccurate requirements is "I will tell you when I really understand your needs ". The estimation of immature requirements based on inadequate information and unthought-provoking requirements is easily caused by some factors. To make an estimate, it is best to give a range (for example, the best case, the most likely, the worst case) or a trustable degree (I have 0% confidence, can be completed within 8 weeks ). Unprepared estimates are usually given as a kind of speculation, but the listener thinks it is a kind of promise. Therefore, we should try our best to give what can be achieved and stick to it. What are excellent demands?There are many articles about software requirements, and the requirements vary. Here I want to use the concept of NASA's software development process. The software requirements process standards are: Clear), complete, consistent, and testable. In addition, there are other concepts, such as trackable and modifiable. Clear: at present, most demand analysis still uses natural language (because communication with users becomes a major problem if formal language is used, this means that the customer must first perform formal language training before developing the software. This is unrealistic ). The biggest drawback of natural language demand analysis is its ambiguity. Therefore, we have to impose certain restrictions on the language used in the requirement analysis. For example, try to use a simple expression of Subject + action. To put it bluntly, the description in the demand analysis looks like a child who has just learned to write. Do not use questions or modify these gorgeous expressions. In addition to the ambiguity of language, it is a computer term. 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. For example, if you want to create a bank's credit card system, you can describe the software requirement as follows: the Bank's card Department manages credit cards, and each credit card belongs to only one account. The credit card has a card number and balance. A credit card has multiple transaction records. Complete: nothing is worse than finding a demand that is close to completion than software development. The integrity of the demand is very important. It is a nightmare to imagine that the demand has to be reworked due to omission. Unfortunately, the omission of requirements often occurs, not just your problems, but also users who don't know what to do. It is very difficult to ensure the integrity of the demand. It involves all aspects of the demand analysis process, from initial planning to the final demand review. As for the detailed discussion of integrity, we will discuss it in the following chapter. Now you only need to think hard about the disadvantages of integrity until you get out of a cold sweat. Are you out? Okay, let's continue. Consistency: consistency is also a big concept and it is difficult to make it clear in a few words. Do you still remember the level of requirements we mentioned at the beginning? Simply put, user needs must be consistent with business needs, and functional requirements must be consistent with user needs. Strictly observe the consistency between different levels to ensure that the last developed software system will not deviate from the initial goal. In the implementation process, we must also refine the consistency relationship. For example, the user requirement cannot exceed the previously specified range. Testable: When do you think a project test starts? Some people say that it starts after the encoding is complete. More clearly, unit tests are conducted at the same time during encoding, and the system tests are conducted after encoding. None of these errors. However, the test starts from the requirement analysis process. Requirement analysis is the input and reference of the test plan. This requires that the requirement analysis be testable. What is testability? "We need to use a new system to automate report processing". Do you think this requirement is testable? Of course not. What are the reports? What are the criteria for automated processing? These are not described in the requirements. Therefore, this requirement cannot be tested, that is, it is not testable. Speaking of this, you may understand the previous requirements to ensure the testability of the requirements. The fact is that 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.