For business users, behind them are hundreds of suppliers and thousands of consumers in front. How to use software to manage the intricate supplier and consumer customers, how to do the fine-grained commodity circulation work of the purchase, sale, adjustment, and storage of a small spice package are all reasons why commercial enterprises need an information management system. This is the meaning of software development. Understanding the true face of such complex needs of business users is the key to successful software development.
Manager: “We want to establish a complete business management software system, including the management of commodity purchase, sale, adjustment, and storage. It is a headquarters-store chain business model. Stores automatically order orders through communication means, suppliers automatically settle accounts, and stores pass Scan barcodes to achieve sales, and managers can inquire about store sales and inventory at any time. In addition, we have to provide government departments with reports on product operations.”
Analyst: “I already understand the general structural framework of this project, which is very important, but before making a plan, we must collect some requirements.”
The manager felt strange: “Didn’t I just tell you my needs?”
Analyst: “Actually, you only explained the concept and goals of the entire project. These high-level business requirements are not enough to provide development content and time. I need to discuss with the business people who will actually use the system before I can really understand The functions and user requirements required to achieve the business goals are clearly understood, and then you can discover which components can be achieved and which need to be developed. This saves a lot of time.”
Manager: “Business people are attracting investment. They are very busy and don’t have time to discuss various details with you in detail. Can you explain your existing system?”
Analysts try to explain the rationality of collecting requirements from users: “If we just guess the requirements of users out of thin air, the results will not be satisfactory. We are only software developers, not procurement experts, operations experts or financial experts. I don’t really understand what you need to do for the internal operations of your company. I have tried and started coding without really understanding these problems. As a result, no one is satisfied with the product.”
The manager insisted: “Okay, okay, we don’t have so much time. Let me tell you our needs. Actually I am very busy. Please start development immediately and let me know your progress at any time.”
Risk hides behind the fog of demand
What we saw above is a customer project manager discussing business requirements with the analysts of the system development team. In project development, all project stakeholders are interested in the requirements analysis phase. The risk-takers referred to here include project leaders and users on the customer side, demand analysts and project managers on the development side. This part of the work can be done well, can develop very good software products, but also satisfy customers. If not handled properly, it will lead to misunderstandings, frustrations, obstacles and potential threats to quality and business value. Therefore, it can be seen that demand analysis has laid the foundation for software engineering and project management.
Remove the fog of demand analysis
Dialogues like this often appear in the process of software development. The needs of the customer project manager are as vague as “seeing flowers in the fog” for analysts and confusing developers. Then, let’s remove the haze and analyze the specific content of the demand:
·Business requirements—reflect the high-level target requirements of the organization or customer for the system and products, which are usually stated in the project definition and scope documents.
·User requirements—Describe the tasks that users must complete to use the product, which are explained in the use cases or program scripts.
·Functional requirements-defines the software functions that developers must implement so that users can use the system to complete their tasks, thereby meeting business needs.
·Non-functional requirements-describes the behaviors and operations performed by the system to users. It includes the standards, specifications and constraints that the product must comply with, as well as the specific details and structural restrictions of the operation interface.
·Requirement analysis report-the functional requirements described in the report fully describe the external behavior that the software system should have. “Requirements analysis report” plays an important role in development, testing, quality assurance, project management and related project functions.
The aforementioned customer project managers usually clarify the high-level concepts and main business content of the product, and establish a guiding framework for subsequent work. Any other instructions should follow the provisions of “business requirements”, but “business requirements” can not provide developers with many detailed instructions needed for development.
The next level of requirements-user requirements, must be collected from the users who use the product. Therefore, these users constitute another kind of software customers, who know what tasks and some non-functional feature requirements need to be accomplished with the product. For example: the ease of use, robustness and reliability of the program, and these features will make users well accept software products with this feature.
Managers sometimes try to speak on behalf of actual users, but usually they cannot accurately explain “user needs.” User needs come from real users of the product, and real users must be involved in the process of collecting requirements. If this is not done, the product is likely to leave many hidden dangers due to lack of sufficient information.
In the actual demand analysis process, the above two kinds of customers may feel that there is no time to discuss with the demand analyst, and sometimes the customer also hopes that the analyst can tell the user’s needs without discussing and writing a demand statement. Unless the requirements encountered are extremely simple; otherwise, this cannot be done. If your organization wants the software to succeed, it must take several days to eliminate the ambiguities in the requirements and the areas that confuse developers.
Excellent software products are based on excellent requirements, and excellent requirements stem from effective communication and cooperation between customers and developers. Only when both participants understand what they need and what is needed for successful cooperation can a good cooperative relationship be established.
Due to the increasing pressure of projects, all project stakeholders have a common goal, that is, everyone wants to develop an excellent software product that can achieve commercial value and meet user requirements, and also satisfy developers.
Customer demand view
Customers and developers need good ways to communicate. The following 20 rules are suggested. Customers and developers can review the following and reach a consensus. If there is a disagreement, mutual understanding of their respective obligations will be reached through negotiation in order to reduce future friction (such as one party’s request but the other party’s unwillingness or inability to meet the request).
1. Analysts should use expressions that conform to the customer’s language habits
Requirements discussions focus on business requirements and tasks, so terminology is used. The customer should teach the analysts the relevant terms (for example, procurement terms such as price acquisition, printed goods, etc.), and the customer does not have to understand the terminology of the computer industry.
2. Analysts must understand the customer’s business and goals
Only when analysts have a better understanding of the customer’s business can the product better meet the needs. This will help developers design excellent software that truly meets customer needs and meets expectations. To help developers and analysts, customers can consider inviting them to observe their work processes. If it is to switch to a new system, then developers and analysts should use the current old system to help them understand how the current system works, its process conditions and what can be improved. s
3. The analyst must write a software requirement report
Analysts should organize all the information obtained from customers to distinguish business requirements and specifications, functional requirements, quality objectives, solutions and other information. Through these analysis, the customer can get a “requirement analysis report”, this report enables the developer and the customer to reach an agreement on the content of the product to be developed. The report should be organized and written in a way that customers consider easy to read and understand. Customers should review this report to ensure that the content of the report accurately and completely express their needs. A high-quality “requirements analysis report” helps developers develop the products they really need.
4. Request an explanation of the required work results
Analysts may use a variety of charts as a supplement to the textual “requirements analysis report”. Because the work charts can clearly describe some aspects of the system behavior, the various charts in the report have extremely high value; although they It is not too difficult to understand, but the customer may not be familiar with it. Therefore, the customer can ask the analyst to explain the function of each chart, the meaning of the symbol and the result of the requirement development work, and how to check the chart for errors and inconsistencies.
5. Developers must respect the opinions of customers
If the user and the developer cannot understand each other, then there will be obstacles to the discussion of requirements. Working together can enable everyone to “listen and understand.” Customers participating in the requirements development process have the right to require developers to respect them and cherish the time they have spent on project success. Similarly, customers should also respect the efforts made by developers for the common goal of project success.
6. Developers should make suggestions and solutions for requirements and product implementation
Usually the “requirements” referred to by customers are already a practical and feasible implementation plan. Analysts should try their best to understand the real business needs from these solutions, and at the same time should find out the discrepancies between the existing system and the current business to ensure The product will not be ineffective or inefficient; after thoroughly clarifying things in the business area, analysts can propose fairly good ways to improve, and experienced and creative analysts can also propose to increase some users that have not found it. System characteristics of value.
7. Describe product usage characteristics
Customers can require analysts to pay attention to the ease of use of the software while fulfilling functional requirements, because these ease of use features or quality attributes enable customers to complete tasks more accurately and efficiently. For example: customers sometimes require products to be “friendly” or “robust” or “efficient”, but for developers, it is too subjective and has no practical value. The correct approach is that analysts understand the specific characteristics of “friendliness, robustness, and efficiency required by customers through inquiries and investigations, and specifically analyze which characteristics have a negative impact on which characteristics, in terms of performance costs and the expected benefits of the proposed solution. Make trade-offs between to ensure that reasonable trade-offs are made.
8. Allow reuse of existing software components
Requirements usually have a certain degree of flexibility. Analysts may find that an existing software component is very consistent with the requirements described by the customer. In this case, the analyst should provide some options to modify the requirements so that the developer can reduce the development of new systems Cost and time-saving, without having to develop strictly according to the original requirements. Therefore, if you want to use some of the existing commercial components in your products, and they are not completely suitable for the features you need, then a certain degree of demand flexibility is extremely important.
9. Require a true and reliable assessment of the cost of changes
Sometimes people will make different choices when faced with a better and more expensive solution. At this time, it is very necessary to evaluate the impact of changes in requirements to help business decisions. Therefore, customers have the right to require developers to give a true and credible assessment through analysis, including impact, cost, gains and losses, etc. Developers can’t exaggerate the cost of evaluation because they don’t want to implement changes.
10. Obtain a system that meets customer’s functional and quality requirements
Everyone wants the project to succeed, but this not only requires the customer to clearly inform the developer of all the information required for the system “what”, but also requires the developer to understand the trade-offs and limitations through communication, and you must clearly state your Assumptions and potential expectations, otherwise, the products developed by the developers may not satisfy you.
11. Explain your business to analysts
Analysts rely on customers to explain business concepts and terminology, but customers cannot expect analysts to become experts in the field, but only let them understand your problems and goals; don’t expect analysts to grasp the subtle potential of the customer’s business. They may not know the “common sense” that is taken for granted by the customer.
12. Take time to clearly explain and improve requirements
The customer is very busy, but in any case it is necessary for the customer to take time to participate in the discussion of the “head meeting”, accept interviews or other activities to obtain demand. Some analysts may understand your point of view first, and later find that you still need your explanation. At this time, please be patient with some needs and repetitions in the refinement of the needs, because it is a natural phenomenon in people’s communication, not to mention This is extremely important to the success of software products.
13. Explain requirements accurately and in detail
It is difficult to write a clear and accurate requirements document. Since dealing with details is both annoying and time-consuming, it is easy to leave ambiguous requirements. However, in the development process, this ambiguity and inaccuracy must be resolved, and the customer is the best person to make a decision to solve these problems, otherwise, the developer has to make the correct guess.
Temporarily adding the “pending” sign in the demand analysis is a method. The sign can be used to indicate which areas require further discussion, analysis or additional information. Sometimes it may be marked as “pending” because a special need is difficult to solve or no one is willing to deal with it. Customers should try to explain the content of each requirement clearly so that analysts can accurately write them into the “software requirements report”. If the customer cannot accurately express it for a while, it usually requires the use of prototype technology. Through prototype development, the customer can repeatedly modify it together with the developer to continuously improve the requirement definition.
14. Timely decision
The analyst will ask the customer to make some choices and decisions. These decisions include processing methods proposed by multiple users or choosing a compromise between quality characteristic conflicts and information accuracy. Customers who have the right to make decisions must treat all of this positively, deal with them as soon as possible, and make decisions, because developers usually only wait for the customer to make a decision before they can act, and such waiting will delay the progress of the project.
15. Respect the feasibility and cost evaluation of developers’ needs
All software functions have their costs. Some product features that customers want may not be technically feasible, or to achieve it at a very high price, and some requirements try to achieve performance that is impossible in the operating environment, or try to get some data that is not available at all . Developers will make negative comments about this, and customers should respect their opinions.
16. Prioritize requirements
Most projects do not have enough time or resources to implement every detail of functionality. Deciding which features are necessary and important is the main part of requirements development. This can only be the responsibility of the customer to set the priority of the requirements, because the developer cannot decide the priority of the requirements according to the customer’s point of view; the developer will do it for you Prioritization provides information about the cost and risk of each requirement.
Under time and resource constraints, developers’ opinions should be respected as to whether or how much required features can be completed. Although no one wants to see that their desired needs are not fulfilled in the project, they have to face reality after all. Business decisions sometimes have to narrow the scope of the project or extend the construction period, or increase resources, or in terms of quality based on priorities. Find a compromise.
17. Review requirements documents and prototypes
Customer review of requirements documents is an opportunity for analysts to bring feedback information. If the customer believes that the “requirements analysis report” prepared is not accurate enough, it is necessary to inform the analyst as soon as possible and provide suggestions for improvement.
A better way is to develop a prototype for the product first. In this way, customers can provide more valuable feedback information to developers, so that they better understand your needs; prototype is not a practical application product, but developers can transform and expand it into a fully functional system.
18. Contact immediately for changes in requirements
Constant demand changes will have serious adverse effects on the quality products completed within the scheduled schedule. Changes are inevitable, but in the development cycle, the later the changes occur, the greater the impact; changes will not only lead to costly rework, but also the construction period will be delayed, especially after the general structure has been completed. When new features. Therefore, once the customer finds that the requirement needs to be changed, please notify the analyst immediately.
19. Follow the development team’s process of handling requirements changes
In order to minimize the negative impact of changes, all participants must follow the project change control process. This requires not to abandon all proposed changes, to analyze and comprehensively consider each required change, and finally make an appropriate decision to determine which changes should be introduced into the project.
20. Respect the requirements analysis process adopted by developers
The most challenging aspect of software development is to collect requirements and determine their correctness. The methods used by analysts are reasonable. Perhaps the customer thinks that the process of collecting requirements is not cost-effective, but please believe that the time spent on requirements development is very valuable; if you understand and support the technology used by analysts to collect, write requirements documents and ensure their quality, then The whole process will be smoother.
What does “demand confirmation” mean
Signing a confirmation on the “requirements analysis report” is usually regarded as a sign that the customer agrees to the requirements analysis. However, in actual operation, customers often regard “signing” as a meaningless thing. “They asked me to sign under the last line of the requirements document, so I signed it, otherwise these developers would not start coding.”
This attitude will cause trouble. For example, when customers want to change their needs or are dissatisfied with the product, they will say: “Yes, I signed the demand analysis report, but I don’t have time to read all the content. Believe in you, you have to let me sign.”
The same problem also occurs to analysts who only regard “signature confirmation” as completing the task. Once there is a demand change, he points to the “requirement analysis report” and says: “You have signed the demand, so these It’s what we developed. If you want something else, you should tell us earlier.”
Both attitudes are wrong. Because it is impossible to understand all the requirements in the early stages of the project, and there is no doubt that the requirements will change, signing on the “requirements analysis report” is the correct way to terminate the requirements analysis process, so we must understand what signing means .
The signature of the “requirements analysis report” is based on the baseline of a requirements agreement, so we should understand the signature as follows: “I agree that this requirements document expresses our understanding of the project software requirements, and further changes can be made in this baseline The above is carried out through the change process of the project definition. I know that the change may cause us to renegotiate matters such as costs, resources, and project phase tasks.” Reaching a certain consensus on the requirements analysis will make it easier for both parties to tolerate future frictions, which come from Project improvement and demand errors or new market and business requirements.
Demand confirmation disperses the fog, reveals the true face of the demand, draws a clear end to the initial demand development work, and helps to form a sustained and good relationship between customers and developers, and lays a solid foundation for the success of the project. Foundation.
