Software Engineering 3: 20 Requirements Analysis Rules (from Software Engineering expert network)

20 Requirements Analysis Rules

(From Software Engineering expert network)

The customer needs a good way to communicate with developers. The following 20 rules are recommended. Customers and developers can review the following content and reach consensus. In the event of any divergence, mutual understanding of their respective obligations will be achieved through negotiation in order to reduce future friction (for example, if one party requests and the other party does not want or cannot meet the requirements ).

1. Analysts should use expressions that conform to customers' language habits.

The requirement discussion focuses on business requirements and tasks, so you need to use the terminology. The customer shall teach analysts the terms (for example, procurement terms such as price collection and Printed Goods), and the customer does not have to understand the terms in the computer industry.

2. Analysts should understand the customer's business and objectives

Only by better understanding the customer's business can analysts make the product better meet their 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 workflows. If you want to switch to a new system, developers and analysts should use the existing system to understand how the current system works, the process, and the improvements they can make.

3. Analysts must prepare software requirement reports

Analysts should organize all the information they obtain from the customer. charts have high value. Although they are not difficult to understand, the customer may not be familiar with them, therefore, the customer can differentiate business requirements and specifications, functional requirements, quality objectives, solutions, and other information. Through these analyses, the customer can obtain a "Requirement Analysis Report", which allows developers and customers to reach an agreement on the content of the product to be developed. The report should be organized and written in a manner that the customer deems easy to read and understand. The customer reviews the report to ensure that the report content is accurate and complete. A high-quality Requirement Analysis Report helps developers develop products they really need.

4. Explanation of requirements

Analysts may use a variety of charts as a supplement to the text requirement analysis report, because the work chart can clearly describe some aspects of system behavior, therefore, the report requires analysts to explain the role of each chart, the significance of the symbol and the results of requirement development, and how to check whether the chart has errors and inconsistencies.

5. Developers should respect customers' opinions.

If users and developers cannot understand each other, there will be obstacles to the discussion of requirements. Joint Cooperation can enable everyone to "Listen to things ". Customers involved in the demand development process have the right to ask developers to respect them and cherish the time they have paid for the success of the project. Similarly, the customer should also respect the efforts made by developers for the joint goal of project success.

6. Developers should provide suggestions and solutions for requirements and product implementation.

What the customer calls "demand" is already a practical implementation solution. Analysts should try their best to understand the real business needs from these solutions, at the same time, it is necessary to find out the inconsistency between the existing system and the current business to ensure that the product will not be ineffective or inefficient. After thoroughly understanding the affairs in the business field, the analysts can propose a very good improvement method, experienced and creative analysts can also propose more valuable system features that users have not discovered.

7. describe product features

Customers can ask analysts to pay attention to the ease of use of software while implementing functional requirements, because these easy-to-use features or quality attributes can help customers complete tasks more accurately and efficiently. For example, customers sometimes require "user-friendly", "robust", or "efficient" products, but developers are too subjective and have no practical value. The correct method is to ask and investigate the customer's "friendly, robust, and efficient" specific features, and analyze which features have a negative impact on which features, balance the performance cost with the expected benefits of the proposed solution to ensure reasonable trade-offs.

8. allow reuse of existing software components

The requirement is usually flexible. Analysts may find that an existing software component is consistent with the requirement described by the customer. In this case, analysts should provide some options for modifying requirements so that developers can reduce the development cost and save time for the new system, without having to strictly describe the development according to the original requirements. Therefore, if you want to use some existing frequently-used commercial components in the product, and they are not fully suited to the features you need, the demand flexibility to a certain extent becomes extremely important.

9. A true and reliable assessment of the cost of the change is required.

Yes ?? . At this time, it is necessary to evaluate the impact of demand changes to help with business decision-making. Therefore, the customer has the right to require developers to provide a true and credible assessment through analysis, including impact, cost, and gains and losses. Developers cannot arbitrarily exaggerate evaluation costs because they do not want to implement changes.

10. Obtain a system that meets the customer's functional and quality requirements

Everyone wants the project to succeed, but this not only requires the customer to clearly inform developers of all the information required for the system "what, in addition, developers are required to clearly understand the trade-offs and restrictions through communication. Your assumptions and potential expectations must be clearly stated. Otherwise, the products developed by developers may not satisfy you.

11. Explain your business to analysts

Analysts rely on customers to explain business concepts and terms, but they cannot expect them to become experts in this field, rather they can only understand your problems and objectives; do not expect analysts to grasp the subtle potential of the customer's business. They may not know the "common sense" that is appropriate for the customer ".

12. Take the time to clearly describe and improve the requirements

The customer is very busy, but in any case, it is necessary for the customer to take time to participate in discussions, interviews, or other activities to obtain the demand. Some analysts may have explained your point of view first, but later I found that you still need to explain it. At this time, please be patient with the repetitive work of refining some requirements and requirements, because it is a natural phenomenon in people's communication, it is very important for the success of software products.

13. Describe requirements accurately and in detail

It is very difficult to compile a clear and accurate requirement document. Because it is not only annoying and time-consuming to deal with details, it is easy to leave ambiguous demands. However, this ambiguity and inaccuracy must be solved during the development process, and the customer is the best candidate to make a decision to solve these problems. Otherwise, developers have to make a correct guess.

Adding the "TBD" sign to the demand analysis is a method. This flag can be used to indicate which information needs to be further discussed, analyzed, or added. Sometimes it may be difficult to solve a special requirement or no one is willing to deal with it and marked with "TBD ". The customer should try to clarify the content of each requirement so that analysts can accurately write them into the "software requirement report. If the customer cannot accurately express it at the moment, it usually requires the use of prototype technology. Through prototype development, the customer can repeatedly modify it with the developer to continuously improve the requirement definition.

14. make a timely decision

Analysts will ask the customer to make some choices and decisions, including the handling methods proposed by multiple users or the selection of compromise schemes in quality characteristics conflicts and Information accuracy. Customers with the right to make a decision must actively take this action and make a decision as soon as possible, because developers usually wait until the customer makes a decision, and such a wait will delay the progress of the project.

15. Respect the feasibility and cost assessment of developers' needs

All software functions have their own costs. Some of the product features the customer hopes may not work technically, or they may have to pay a very high price to achieve it, while some of the requirements try to achieve performance that is not possible in the operating environment, or try to get some data that is not available at all. Developers will make negative comments on 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. Determining what features are necessary and what are important is the main part of demand development. This is only the responsibility of the customer to set the demand priority, because developers cannot determine the demand priority based on the customer's point of view; developers will give you priority information on the costs and risks of each requirement.

The opinions of developers on whether or how many features are required should be respected under time and resource restrictions. Although no one is willing to see that their desired needs are not implemented in the project, after all, it is necessary to face the reality that business decisions sometimes have to narrow down the project scope or extend the construction period based on priorities, or increase resources, or find a compromise on quality.

17. Review Requirement documents and prototypes

The customer review requirement document is an opportunity for analysts to provide feedback. If the customer deems that the "Requirement Analysis Report" is not accurate enough, it is necessary to inform the analysts as early as possible and provide suggestions for improvement. A better solution is to first develop a prototype for the product. In this way, the customer can provide more valuable feedback to developers so that they can better understand your needs. The prototype is not a practical application product, however, developers can convert and expand the system into a complete system.

18. contact us immediately for request changes.

Constant demand changes will have a serious adverse impact on the quality products completed in the planned plan. Changes are inevitable. However, during the development cycle, the more advanced the changes appear, the greater the impact will be. changes will not only lead to costly rework, but also delay the construction period, especially when new features need to be added after the general structure is completed. Therefore, once the customer finds that the requirement needs to be changed, inform the analysts immediately.

19. Follow the development team's process of handling demand changes

To minimize the negative impact of changes, all participants must follow the project change control process. This requirement does not discard all proposed changes, analyze and comprehensively consider the changes in each requirement, and finally make appropriate decisions to determine which changes should be introduced into the project.

20. Respect the demand analysis process adopted by developers

The most challenging thing in software development is to collect requirements and determine their correctness. The methods adopted by analysts are justified. The customer may think that the collection process is not cost-effective, but please believe that the time spent on demand development is very valuable; if you understand and support the technologies used by analysts to collect, compile Requirement documents and ensure their quality, the entire process will be smoother.