Top 10 tips for getting user requirements

Successful software products are built on the basis of successful requirements, and high-quality requirements come from effective communication and cooperation between users and developers. When a user has a problem that can be solved by a computer system, and the developer starts to help the user solve the problem, the communication starts.

Requirement acquisition may be the most difficult, critical, error-prone, and communication activity in software development. Users often have a wrong understanding of the requirement acquisition: users know what the requirement is. All we need to do is to talk to them and get the requirement from them. If we need to ask the Target Characteristics of the user system, what is to be done, and what kind of system can be suitable for commercial needs, but in fact the demand acquisition is not as simple as imagined, this communication path is full of thorns. First, the problem scope needs to be defined. The boundaries of the system are often difficult to clarify. users do not understand the technical implementation details, which leads to confusion of the system objectives.

The second is the understanding of the problem, the lack of understanding of the capabilities and limitations of computer systems, any system will have a lot of users or different types of users, every user only knows the system they need, but does not know the overall situation of the system. They do not know how the system can work better as a whole, or how the work can be handed over to the software, they do not know what the requirement is, or how to describe the requirement in a precise way. They need assistance and guidance from developers, however, communication between users and developers is prone to obstacles, ignoring the information that is considered "very clear. Finally, it is the confirmation of the demand, because the instability of the demand often changes over time, making it difficult to confirm. In order to overcome the above problems, an organizational acquisition activity is required for execution.

The 11 tasks or steps recommended for the requirement acquisition activity are to determine the requirement process, compile the project view and scope document, classify the user group, select the user representative, select the user representative, establish the core team, determine instances, hold joint meetings, analyze user workflows, determine quality attributes, Check Problem Reports, and reuse requirements. Of course, appropriate reduction should be made based on the specific circumstances of the organization and the project. For example, the requirement acquisition meeting should be changed to a questionnaire survey or discussion based on the project and user conditions.

1. compile the project view and scope documents

System Requirements include four different levels: business requirements, user requirements and functional requirements, and non-functional requirements. Business Requirements describe the initial benefits provided to the user's new system, reflecting the high-level objectives of the organization or user for the system and product. They 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, which are described in the instance document or solution script description. Functional requirements define the software functions that developers must implement so that users can complete their tasks and meet business needs.

Non-functional requirements are users' expectations for good system operation, including usability, response speed, fault tolerance, robustness, and other quality attributes. Requirement acquisition is to obtain system user requirements based on system business needs, and then obtain system functional and non-functional requirements through requirement analysis. The project view and scope document describe the business requirements of the system at a high-level level. It should include high-level product business objectives and evaluate the commercial and technical feasibility of the problem solution, all use instances and functional requirements must comply with the standards. The scope document defines all the work of the Project product and the process used to generate the product. Project personnel can reach consensus on the objectives and scope of the project. The whole project team should focus on the project objectives and scope.

2. user group classification

There are many differences between system users, such: the frequency and degree of use of the system, application fields and computer system knowledge, system features used, business processes, access permissions, geographical layout, personal qualities and preferences, etc.. Based on these differences, you can divide these different users into different user classes. Like usecase actor in UML, user classes do not necessarily refer to people, but also include other application systems, interfaces, or hardware, this makes the interface outside the system boundary also a system requirement. User groups are classified and summarized into their respective characteristics, and their individual characteristics and task status are described in detail, which will help to acquire the requirements and design the system.
3. Select a user representative

It is impossible to obtain requirements for all users, and the effect is not necessarily good. Therefore, it is necessary to identify the users who can determine the requirements and understand the business process as representatives of each type of users. Each type of user should be represented by at least one person who truly represents their needs and can make decisions. The user representatives are usually three types of users in this category: leaders who have the right to decide on the project, experts who are familiar with business processes, and end users of the system.

Each user representative represents a specific user class and acts as the main interface between the user class and the developer. The user representative collects requirement information from the user class they represent, at the same time, each user representative is responsible for coordinating the inconsistency and incompatibility of the users they represent in the requirement expression.

4. Establish a core team

Generally, users and developers do not consciously have an idea of "We and them", which creates a confrontation between them and places them on the opposite side. Each side defines its own "boundary ", ignore the thoughts of the other party just for your own interests. They communicate through documents, records, and conversations, rather than identifying and determining requirements to complete tasks as a cooperative whole. Practice has proved that this method is incorrect and will not bring any benefit to both parties. The absence of a good communication relationship leads to misunderstanding and neglect of important information. Only when both parties understand what they need to succeed and what they need to succeed can they establish a cooperative relationship.

In order to establish a cooperative relationship, a team is usually used to obtain the requirement. A team composed of user representatives and developers is established as the core team for obtaining the requirement. The joint team will be responsible for identifying requirements, analyzing solutions and negotiating differences. Group members can communicate through meetings, emails, and the integrated office system. However, the following principles should be noted during the communication: group meeting should be in progressCubeBoth users and developers are required to participate in the organization and hosting of communications; preparations and participation rules should be determined in advance; topics should be clear and cover all key points, but information sources should be free; the communication goals should be clear and all members should be informed.

5. Confirm to use the instance

Collect descriptions of the tasks required by the system from the user representative office and discuss the interaction methods and dialog requirements between the user and the system, A single use instance may include many logic-related tasks and interaction sequence for completing a task. The benefit of using the instance method to obtain requirements comes from the task-centric and user-centric approach, compared to using a function-centric and developer-centric approach, using the instance method can give users a clearer understanding of what and how new systems allow them to do. When describing the use of instances, pay attention to the use of concise and straightforward expressions. Try to use the active voice, "system" or "user" as the subject, for example, "the user submits the user password, the system verifies that the user password is correct. Do not design the interface details in the description, for example, "select a product type from the drop-down list ". the example provides materials for the basic path and extension path in the scenario description for future use cases.

6. hold a joint meeting

The most common way to obtain requests is to hold meetings or interviews. Joint Meetings are wide-ranging and simple seminars, and they are also a good way of communication between core team members, through close and concentrated discussions, the meeting was able to put the partnership between user representatives and developers into practice and draft the requirement document accordingly. The first topic of the Joint Meeting is the necessity and rationality of the system. It is necessary and reasonable for all members to agree on the system. Next, we can discuss how to use the instance list. The list can be printed on a large wall, written on a blackboard, or made into demonstration materials. Remove duplicate items from each list and add additional content to get a general list. Avoid using negative "too bad" not feasible "to deny users' ideas, all these ideas should be retained as the list items to be reviewed, which protects the open thinking of group members. Finally, the list is discussed. The meeting members must check each use instance and determine whether they are within the scope defined by the project before they are included in the requirement to form the final requirement report.

During the discussion, we should also avoid being affected by immature details. Before reaching consensus on system requirements, users can easily list some precise designs in a report or dialog box, if these details are recorded as requirements, they will impose unnecessary restrictions on the subsequent design process, ensure that user participants focus on the appropriate abstraction layer for the topic to be discussed, focusing on what to do rather than what to do. It is very important to let users understand that the discussion of some features does not mean that it will be implemented in the system, not to imply or promise when to fulfill the requirements. After the discussion, write down the items discussed and ask the users involved in the discussion to comment and correct them, because only those who provide the requirements can determine whether to actually obtain the requirements. When a detailed and accurate demand report was obtained, the meeting was completed successfully. However, it should be clear that the demand process itself is an iterative process, and this report will inevitably be modified and improved in future process activities.

7. Analyze user Workflow

Analyze the user's work flow, observe the user's process of executing business tasks, and analyze the instance to obtain the system's use case diagram. The preparation of the use case diagram document will help to clarify the use cases and functional requirements of the system, and the use of a unified modeling language will help to further communicate with users. The description of each use case should include: number, which is assigned a unique number for each use case, providing convenience for traceability of requirements; actors for participants to interact with the use case; preconditions, the system status that must be met before the use case starts; the post condition, the state that the system reaches after the use case is completed; the basic path and the Key Path of the use case completion are also the path that the user expects; the extension point, the branch of the basic path, indicating an unexpected situation. Field description, further decomposition of the name in the path, takes effect for future class attribute definitions and database field design; design constraints, non-functional constraints for implementing use cases. When writing a basic path, you should use an active statement. The sentence uses an actor or system as the subject. One sentence represents an actor action, and the other one represents system action. The interaction is cross-representation. The interface details are not involved, for example, "enter a name in the text box and select a type from the drop-down box ".

Use Case: User Registration, user registration as a system Member

Uc1
Participant user
The system runs normally when users access the system with preconditions
Post-condition system records user registration information
Basic Path 1. User request registration.
2. The registration page is displayed.
3. the user submits registration information.
4. Check whether the registration information is correct.
5. The system generates the user name and password to save registration information.
6. The system displays "successfully registered" information to go to the member page.

Extension 4A. The information provided by the user is incorrect: 4a1. The system prompts you to enter the correct information 4a2. 3 is returned.
Supplementary instructions: registration information includes = user real name + phone number + Fax + email + contact address = province + city + street + Zip code
Design constraint registration response time cannot exceed 3 seconds

8. determine quality attributes

In addition to functional requirements, consider the quality characteristics of non-functional features and determine the functional or performance constraints imposed on the system due to the special commercial application environment, this will make your product meet and exceed the customer's expectations. The statement on how the system can perform certain behaviors well or allow users to take certain measures is the quality attribute, which is a non-functional requirement. Listen to the opinions that describe reasonable features: fast, simple, intuitive, user-friendly, robust, reliable, secure and efficient. You are going to discuss with users how to precisely define the true meanings of their vague and subjective words, and assign quality attributes to the design constraints of each use case.

9. Check the problem report

By checking the Problem Reports of the currently running system, we can further improve the Problem Reports of the requesting customers and supplement the demands. The new system or new version provides a lot of ideas for improving and adding features, persons responsible for providing user support and help can provide valuable information for the collection of demand processes.

10. Demand Reuse

If the features required by the customer are similar to those of an existing system, you can check whether the requirement is flexible enough to allow reuse of some existing software components. The best way to reuse business modeling and domain building patterns is to have your own needs, just like the analysis and design patterns.