User Experience Design: A 20-rule study of customer demand view

Web page Production WEBJX article introduction: how to effectively collect and analyze customer requirements?

All project stakeholders are interested in the requirements analysis phase during project development. The stakeholders referred to here include the project leader and user of the customer, the development analyst and the project manager.

For business users, behind them are hundreds of suppliers, with thousands of consumers ahead. How to use Software management complex suppliers and consumer customers, how to do a fine to a small seasoning package into, sell, adjust, storage of the commodity circulation, these are commercial enterprises need information management system reasons. This is what software development is all about. It is the key to success in software development to figure out the true nature of the complex needs of business users.

Manager: "We want to establish a complete business management software system, including the goods into, sales, adjustment, storage management, is the headquarters-store chain business model." Through the means of communication store automatic ordering, supplier automatic settlement, store by sweeping bar code to achieve sales, managers can always check the store merchandise sales and inventory situation. In addition, we have to provide government departments with reports on the operation of commodities. ”

Analyst: "I already understand the overall structure of the project, which is very important, but before we make a plan, we have to collect some requirements." ”

The manager wondered, "Didn't I just tell you what I need?" ”

Analyst: "In fact, you only describe the concept and objectives of the entire project." These high-level business requirements are not sufficient to provide the content and time of development. I need to discuss with the business people who are actually going to use the system, and then I can really understand the functionality and user requirements that are needed to achieve the business goals, and understand what is available and what needs to be developed to save a lot of time. ”

Manager: "The business people are attracting investment." They are very busy and have no time to discuss the details with you in detail. Can you give me a description of your existing system? ”

Analysts try to explain the rationality of collecting requirements from users: "If we just speculate on the user's request, the results will not be satisfactory." We're just software developers, not procurement experts, business experts, or financial experts, and we don't really understand what you need to do to get inside your company. I have tried, not really understand these problems began to code, the result of no one is satisfied with the product. ”

The manager insists: "OK, OK, we don't have that much time." Let me tell you about our needs. Actually, I'm very busy, too. Please start developing at once and keep me informed of your progress. ”

Risk hiding behind the fog of demand

The above we see is a customer project manager and the system development team analyst discuss business requirements. All project stakeholders are interested in the requirements analysis phase during project development. The stakeholders referred to here include the project leader and user of the customer, the development analyst and the project manager. This part of the work done in place, can develop a very good software products, but also to customer satisfaction. Poor handling can lead to misunderstandings, setbacks, obstacles, and potential quality and business value threats. Therefore, it is obvious that the requirement analysis lays the foundation of software engineering and project management.

To push through the fog of demand analysis

Conversations like this often appear in the process of software development. The needs of the customer project manager are vague and confusing to the analyst, like "Smoke and mirrors". So, let's just go through the fog and analyze the specific content of the demand:

• Business requirements reflect the organization's or customer's high level of system and product objectives, usually described in the project definition and scope documentation.

• User Requirements-Describes the tasks that users must complete to use the product, as described in the use instance or scenario scripts.

• Functional requirements-Defines the software features that developers must implement to enable users to take advantage of the system to accomplish their tasks, thus satisfying business needs.

• Non-functional Requirements-describes the behavior and actions that the system presents to the user, including the standards, specifications, and constraints that the product must comply with, the specifics of the operation interface, and the structural constraints.

• Requirements Analysis Report-The functional requirements described in the report adequately describe the external behavior that the software system should have. The requirements analysis report plays an important role in development, testing, quality assurance, project management, and related project functions.

The customer project manager mentioned above usually clarifies the high-level concept and main business content of the product and establishes a guiding framework for subsequent work. Any other description should follow the "business requirements" requirement, but "business requirements" do not provide developers with many of the details needed for development.

The next level of requirements--user requirements--must be collected from users who use the product. As a result, these users constitute another software customer who knows what tasks to accomplish with the product and some non-functional feature requirements. For example, the ease of use, robustness, and reliability of programs, which will allow users to accept software products with that feature well.

Managers sometimes try to speak in lieu of actual users, but often they cannot accurately describe "user needs." User requirements come from the real users of the product and must involve the actual user in the process of gathering requirements. If you do not, the product is likely to be a lack of sufficient information and left a lot of hidden trouble.

In the actual requirements analysis process, both of these customers may feel that there is no time to discuss with the requirements analyst, sometimes the customer also hope that analysts do not need to discuss and write requirements to explain the needs of users. This cannot be done unless the demand is extremely simple. If your organization wants software to succeed, it must take a few days to eliminate the ambiguities in the requirements and some aspects that confuse developers.

Excellent software products are built on the basis of excellent requirements, and excellent requirements from the customer and developers effective communication and cooperation. A good partnership can only be established if both participants understand what they need and what they need to succeed in their cooperation.

Due to the increasing pressure on the project, all project stakeholders have a common goal, that is, everyone wants to develop a business value can meet the requirements of users, but also make developers feel satisfied with the excellent software products.

Customer's demand view

Customers need a good way to communicate with developers. Here are 20 guidelines that customers and developers can use to review and reach consensus. In the event of disagreement, mutual understanding of their respective obligations will be reached through consultation in order to reduce future friction (if one party requests and the other party is unwilling or unable to meet the requirements).

1, the analyst should use the expression which conforms to the customer language habit

The requirements discussion focuses on business requirements and tasks, so use terminology. The customer should teach the analyst the terms (e.g., purchasing terms such as price, printing, etc.), and the customer does not necessarily have to understand the terminology of the computer industry.

2, analysts to understand the customer's business and objectives

Only analysts can better understand the customer's business to make the product better meet the needs. This will help developers design excellent software that truly meets customer needs and achieves expectations. To help developers and analysts, customers can consider inviting them to watch their workflows. If you are switching to a new system, then developers and analysts should use the current legacy system to help them understand how the system works, what the process is, and where it can be improved. `

3, the analyst must write the software requirement report

The analyst should collate all the information obtained from the customer to differentiate between business requirements and specifications, functional requirements, quality objectives, solutions, and other information. With these analyses, customers get a "Requirements Analysis report" that enables developers and customers to reach agreement on the product content to be developed. Reports should be organized in a way that customers find easy to read and understand. The customer reviews This report to ensure that the report content is accurate and complete in expressing its needs. A high-quality "Demand Analysis report" helps developers develop the products they really need.

4. Explanation of requirements for results of work

Analysts may use a variety of charts as supplemental explanations for the textual "requirement Analysis report," because the work chart clearly describes some aspects of the system's behavior, so the various charts in the report are of great value; although they are less difficult to understand, customers may not be familiar with it, So customers can ask analysts to explain the role of each chart, the meaning of the symbol, and the results of requirements development work, and how to check for errors and inconsistencies in the chart.

5, developers to respect the views of customers

If the user and the developer do not understand each other, there will be a barrier to the discussion of requirements. Working together can make everyone "instead". Customers involved in the requirements development process have the right to ask the developers to respect them and to cherish the time they have paid for the project's success, and the customer should also respect the efforts of the developers to achieve the common goal of project success.

6, developers to demand and product implementation of recommendations and solutions

What customers call "demand" is already a practical implementation plan, the analyst should try to understand the real business requirements from these solutions, and should also identify the existing system and current business discrepancies to ensure that the product will not be ineffective or inefficient; after thoroughly clarifying things in the business area, Analysts will be able to put forward fairly good improvements, and experienced and creative analysts can also offer valuable system features that are not found by users.

7. Describe product usage characteristics

Customers can ask analysts to implement functional requirements while also paying attention to the ease of use of software, because these ease-of-use features or quality attributes enable customers to accomplish tasks more accurately and efficiently. For example, customers sometimes require that the product be "interface friendly" or "robust" or "efficient", but too subjective for developers to have no practical value. The right thing to do is by asking and investigating, the analyst understands what the customer wants to "be friendly, robust, and efficient," specifically analyzing which features have a negative impact on which features, and trade-offs between the performance cost and the expected benefits of the proposed solution to ensure that reasonable trade-offs are made.

8. Allow reuse of existing software components

Requirements usually have a certain flexibility, analysts may find that an existing software component is in line with the requirements described by the customer, in which case the analyst should provide some choice of modification requirements so that the developer can reduce the development cost and save time for the new system without having to develop it in strict accordance with the original requirements. So, if you want to use some of your existing commercial components in your product, and they don't exactly fit the features you need, then a certain degree of demand flexibility is critical.

9. Require a true and reliable assessment of the cost of the change

Sometimes people make different choices when they are faced with better and more expensive alternatives. At this point, it is necessary to evaluate the impact of changes in requirements to help business decisions. Therefore, the customer has the right to ask the developer to provide a true and credible assessment, including impact, cost and gain and loss, through analysis. Developers cannot exaggerate the cost of an assessment without having to implement a change.

10, to meet customer function and quality requirements of the system

Everyone wants the project to be successful, but not only does it require the customer to clearly tell the developer all the information that the system needs to "do". It also requires developers to understand the trade-offs and limitations through communication, and make sure that your assumptions and potential expectations are clearly stated, otherwise the product developed by the developer may not be satisfying.

11, explain your business to the analyst

Analysts rely on customers to explain business concepts and terminology, but customers cannot expect analysts to become experts in the field, but to let them understand your problems and goals; Don't expect analysts to grasp the nuances of customer business, and they may not know what "common sense" is for the customer.

12, take time to clearly explain and improve demand

Customers are busy, but in any case it is necessary for the customer to take the time to participate in brainstorming sessions, interviews or other needs-gathering activities. Some analysts may understand your point of view, and later found that you need to explain, then please be patient with some needs and needs of the refined work process of repetition, because it is a natural phenomenon of people communication, not to mention this is very important to the success of software products.

13, accurate and detailed description of requirements

It is difficult to write a clear and accurate requirement document. Because dealing with details is not only annoying but time-consuming, it is easy to leave vague demands behind. But in the development process, we must address this ambiguity and inaccuracy, and the customer is precisely to solve these problems to make the best choice, otherwise, we have to rely on developers to correctly guess.

The temporary addition of the "pending" flag in the requirements analysis is a method. Use this flag to identify where you need to further discuss, analyze, or add information, and sometimes to label "pending" because a particular requirement is difficult to resolve or if no one is willing to deal with it. Customers try to articulate the content of each requirement so that analysts can accurately write them down in the software requirements report. If the customer is unable to express accurately, it is usually required to use prototyping technology, through prototyping, customers can be modified with the developers, and constantly improve the definition of requirements.

14. Make a decision in time

The analyst will ask the customer to make some choices and decisions that include the approach from multiple users or select a compromise in the quality characteristics conflict and information accuracy. Customers who have the right to make decisions must take the initiative to deal with it and make decisions as quickly as possible, because developers usually have to wait for customers to make a decision to act, which delays the progress of the project.

15, respect the needs of developers and the feasibility of cost assessment

All the software features have their costs. Some of the product features that customers want may not be technically feasible, or they can be implemented at a very high cost, and some requirements try to achieve performance that is not possible in the operating environment, or try to get some information that is not available at all. Developers will comment negatively on this, and customers should respect their opinions.

16, divide the priority of the requirements

Most projects do not have enough time or resources to achieve every detail of functionality. Deciding which features are necessary and what is important is the main part of requirements development, which can only be set by the customer to prioritize requirements because the developer is not likely to prioritize the requirements according to the customer's point of view, and developers will give you the priority to provide information about the cost and risk of each requirement.

With time and resource constraints, the views of the developer should be respected as to whether the required features can be completed or completed. Although no one wants to see what they want in a project that is not implemented, it is, after all, the reality that business decisions sometimes have to be prioritized to reduce the scope of the project or extend the duration, or to increase resources, or to find tradeoffs in quality.

17. Review requirements documentation and prototypes

The customer review requirements document is an opportunity to bring feedback to the analyst. If the customer believes that the "demand Analysis report" is not accurate enough, it is necessary to inform the analyst as early as possible and provide recommendations for improvement.

A better idea is to develop a prototype for the product first. This allows customers to provide more valuable feedback to developers to better understand your needs; prototypes are not a practical application, but developers can transform them into fully functional systems.

18, change of requirements to contact immediately

Continuous changes in requirements will have a serious adverse impact on the quality products completed within the planned schedule. Changes are unavoidable, but in the development cycle, the more advanced the changes occur, the greater the impact, the change will not only lead to costly rework, and the duration will be delayed, especially when the general structure has been completed and need to add new features. So, once the customer discovers the need to change needs, please notify the analyst immediately.

19, follow the development team process requirements change

To minimize the negative impact of the change, all participants must follow the project change control process. This requires that you do not discard all proposed changes, analyze, synthesize, and finally make appropriate decisions about which changes should be introduced into the project.

20, respect the needs of developers to analyze the process of use

The most challenging thing in software development is to collect requirements and determine their correctness, and the methods used by analysts are reasonable. Customers may think that the process of collecting requirements is not a good deal, but believe that the time spent on demand development is valuable; If you understand and support the technology that analysts use to collect, write, and ensure the quality of your requirements, the process will be more successful.

What does "need confirmation" mean?

Signature confirmation on "Demand Analysis report" is usually considered as a sign of customer's consent to demand analysis, but in practice, customers often regard "signature" as meaningless matter. "They wanted me to sign under the last line of the requirements document, so I signed it, otherwise the developers don't start coding." ”

This attitude will cause trouble, such as customers want to change the demand or dissatisfaction with the product will say: "Yes, I was in the requirements analysis report signed, but I do not have time to read all the content, I believe you, you are not to let me sign." ”

The same problem will occur when the "signature confirmation" is seen as the analyst who completes the task, once a demand change occurs, he points to the "Demand analysis report" and says, "You have signed the requirements, so these are the things we developed, and you should have told us earlier if you wanted anything else." ”

Neither of these attitudes is right. Since it is not possible to understand all the requirements early in the project, and there is no doubt that the requirements will change, signing the requirement Analysis report is the right way to terminate the requirements analysis process, so we must understand what the signature means.

The signature of the requirement Analysis report is based on the baseline of a requirement agreement, so we should understand the signature as follows: "I agree that this requirement document describes our understanding of project software requirements, and further changes can be made through the project-defined change process on this baseline." I know that changes may allow us to renegotiate costs, resources, and project-phase tasks. "Reaching a consensus on demand analysis will make it easy for both sides to tolerate future friction, which stems from improvements in the project and error in requirements or new requirements for the market and business."

The need to confirm the fog scattered, showing the true face of demand, to the preliminary requirements of the development of the work to draw a clear end of both sides, and contribute to the formation of a continuous good customer and developer relations, for the success of the project laid a solid foundation.