The annoying demand changes in software development have always encountered the following problem: a new customer's idea overturned the requirements that have been confirmed after repeated discussions with the customer. Changes to functional requirements will make it easy to accept. After all, the failure to implement functional requirements will greatly affect the quality of software products. However, some non-functional changes can be a headache. Many of them are seemingly irrelevant, trivial changes, but they are extremely speechless and helpless, and even annoying and annoying.
(1) What are software requirements? In IEEE, software requirements are defined as the conditions or functions required for a user to resolve a problem or achieve the goal. It generally includes business requirements, user requirements, functional requirements, industry implicit requirements, and some non-functional requirements. Business Requirements reflect customers' high-level system and product objectives. Functional requirements define the software functions that developers must implement. Non-functional requirements refer to the features that must meet users' business needs except functional requirements. Including system performance, reliability, maintainability, usability, and adaptability to technologies and services. The most common requirements are software interfaces and convenient operations.
(2) changing non-functional requirements allows us to look at the characteristics of non-functional requirements from the perspective of customers and developers. First of all, some non-functional small demands seem to have little workload from the customer's perspective, but in fact developers need to spend a relatively long time to complete these small features. Second, many non-functional requirements, such as beautiful interfaces and convenient operations, are the demands of customers who are eager to develop their minds, or leaders who are able to deploy their minds at a glance, it is often the content that was not paid attention to in the demand analysis phase.
In fact, non-functional requirements are often ignored. The reason is that it is difficult to describe non-functional requirements. It is difficult to describe the functional requirements clearly by using structured and quantified words. When describing such requirements, we often use vague descriptions such as good software performance, convenient operations, and elegant software interfaces. For example, ease of use involves both art and UI interfaces, human-machine engineering, interactive design, psychology, user behavior patterns, and so on. These descriptive terms are separated from the software execution environment and are used to describe people and related scenarios. Therefore, it is difficult to reflect the software architecture design and implementation.
Many software companies in China consider this situation as a burden, which affects the work arrangement, workload, and progress of software companies and directly leads to the benefits of software companies, it is almost the biggest hidden danger of many software companies. Therefore, how we understand and treat this common problem becomes a problem that needs to be solved by software companies and employees;
1) first, we need to fundamentally eradicate the fear of demand change from the psychological perspective, and clearly understand that demand change is an indispensable part of the software development process, clarify the existence and inevitability of demand changes from the principle;
A) from the perspective of software companies, recognize their own shortcomings and objectively face changes in demand
B) improve their business and technical capabilities from the perspective of employees
2) simplify, clarify, and increase maintainability of demand changes from a technical perspective;
A) use better technical means and design more flexible to adapt to more changing needs;
B) use a more sophisticated software engineering philosophy to refine the software steps and make them easier to maintain and modify;
C) use a complete testing process to minimize software risks arising from demand changes;
3) Effectively manage demand changes so that demand changes can be managed in a standardized manner, so as to effectively handle demand changes and maximize the benefits with limited resources;
A) in the early stage of the software, it is necessary to consider minimizing potential demand changes in the future.
B) control the demand, reduce the source of the demand, and filter out unreasonable demands.
C) document-based management, with backup and traceable evidence;
D) Appropriate company system and operation, and find an operating system and management model suitable for your company's development;
You may think the above is a bit empty, so I will talk about it from a technical point of view. As we have just said, demand changes are inevitable. It is extremely important to reduce or avoid the impact of demand changes from a technical perspective.
1. At the beginning of the design, fully understand the requirements, better organize and plan the requirements, and predict the requirements that may change. Demand is hard to implement, business is hard to do, and non-functional demand changes are even more difficult. Therefore, after collecting user requirements, we should not only simply classify them, but also develop them step by step. Instead, we should thoroughly explore the needs of some seemingly fixed businesses, your system may be unavailable due to business changes. What we need to do is split the requirements and change some of the requirements that may change into configurable workflow. As with the transition from process-oriented to object-oriented, process-oriented is dead, and the re-combination of object-oriented is very simple.
Let's talk about the cash register system we just created. When the user asks for a bill, he needs to print a small ticket and open the cash box automatically. This is the most primitive requirement. But we finally made it like this: the printer is an external device that can be added, deleted, and configured; the number of prints can be configured; the print style can be configured; when printing, You need to determine the printer status, various prompts (not listed one by one) are required for abnormal status. The cash box can be opened automatically or manually. In addition, many function configurations are also set: for example, to disable/enable all printers, to disable/enable a printer, to print the order ticket, to enable the cash box automatically, to display error messages, and so on (). We split this fixed requirement into configurable ones, so that we can analyze the possible changes to this requirement. No matter how it changes, our response will become calm. There was a problem during the deployment in the previous two days. The printer was newly bought, not just for any reason. After printing multiple line breaks, it would fail and cannot be printed again. This problem is unexpected, because all the printers we tested here are printed perfectly, and the newly purchased printers are of the same brand and model. After the problem is finally analyzed, we don't need to change the system. We just need to modify the small ticket style configuration to print it perfectly.
Ticket style settings (figure): hardware settings (figure): single printer settings (figure): function settings (figure ):
2. After the system is complete and the customer raises a new requirement, it is necessary to analyze the Deep Meanings of the requirement and what the customer wants. If some requirements are suitable for most customers and few changes can be completed, they can be integrated in the next upgraded version. For some non-functional requirements, if the changes are too large or basic core functions need to be changed, do not rush to implement them, but put them in place, when the system needs to be upgraded or restructured, consider adding it. In addition, it is necessary to prevent customers from abusing the power to raise demands. For some unreasonable demands, it is also necessary to guide customers to understand the unreasonable aspects of this function, so as to re-modify the requirements or give up.
