Successful software products are based on successful demand, while high quality demand is derived from effective communication and cooperation between users and developers. When a user has a problem, you can use a computer system to solve it, and developers began to help users solve this problem, and communicate begins.
Demand acquisition may be the most difficult, key, most vulnerability, and most need to communicate with activities. Overview of demand often has wrong understanding: users know what needs, what we have to do is to talk to them from them, as long as they ask the target characteristics of the user system, what is to be completed, what system can be suitable Business needs can be, but actually demand acquisition is not imagined, this communication is covered with thorns. First of all, demand is to define the scope of the problem. The boundaries of the system are often difficult, and users do not understand the details of technology implementation, which causes confusion of system objectives.
Secondly, it is understood to understand the problem. The user's ability and restrictions on computer systems are lacking. Any system will have a lot of users or different types of users. Each user only knows what they need, and I don't know the overall situation of the system. They don't know how the system is better than working, and it is not very clear that those work can be handed over to software. They don't know what needs, or how to describe demand in a precise way, they need developers The assistance and guidance, but the exchange between users and developers is prone to obstacles, ignoring information about "very clear? Quot; final is the confirmation of demand, because the instability of demand often often The incremental changes make it difficult to confirm. In order to overcome the above problems, there must be an acquisition of organizational execution needs.
Demand Acquisition Activities It is recommended to complete 11 tasks or steps to determine the demand process, write project views, and scope documents, user group classification, select user representatives, select user representatives, establish core teams, and determine the use of examples, and convene a joint meeting. Analyze user workflows, determine quality properties, check problem reports, and demand reuse. Of course, appropriate cuts should be carried out in accordance with the specific circumstances of the organization and projects. For example, the demand will be changed to the questionnaire survey or discussion according to the information and user conditions.
1. Write project view and range documentation
The needs of the system include four different levels: business needs, user needs and functional requirements, non-functional needs. Business needs illustrate the initial benefits of providing users to the user, reflecting organizations or users on systems, high-level target requirements, which are described in project view and range documents. User Demand Document describes the task that users must be completed using the product, which is described in using the instance document or scheme script. Functional requirements define software features that developers must implement, so that users can complete their tasks to meet business needs.
Non-functional demand is the expectations of the user's good operation, including ease of use, reaction speed, fault tolerance, robustness, etc. Demand acquisition is to obtain system user needs based on system business needs, and then obtain the system's functional requirements and non-functional requirements by demand analysis. Project view and range documentation is from a high-level business requirement, which should include high-level product business objectives, assessment problem solutions, business and technical feasibility, and all instances and functional requirements must follow standards. The scope document defines all works included in the project product and the process used to generate products. Project-related personnel can reach the goals and scope of the project, and the entire project team should focus on project objectives and scope.
2, user group classification
System users have differences in many respects, such as: using system's frequency and degree, application domain, computer system knowledge, system characteristics used, business processes, access rights, geographic layouts, and personal qualities and Havilites, etc. Based on these differences, you can divide these different users into different user classes. Like UML's Actor concept, the user class does not necessarily refer to people, or other application systems, interfaces, or hardware, which makes the interface outside the system becomes system requirements. Classify the user groups and summarize their individual features, and describe their personal characteristics and task status, which will help require demand for acquisition and system design. 3, choose user representative
It is impossible to obtain demand for all users, which does not allow the effect of doing time, so it is not necessary to identify users who can determine the needs and understand business processes as representatives of each type of user. Each type of user chooses at least one person who really represents their needs as a representative and can make decisions, and user representatives are often three types of people in this type of user: leaders who have decisive rights to the project, familiar with business processes, system end users . Each user representative represents a specific user class and acts as the main interface between the user class and developers, and the user represents the collection information from the user classes they represent, and each user representative is also responsible for coordination. The users they represent are inconsistencies and incompatibility in demand expressions.
4. Establish a core team
Usually users and developers don't consciously have a good fortune? Quot; We and them ", produce an opposite relationship, put each other on the opposite side, each define your own" border ", just want your own interests and ignore The other party's idea. They communicate through documents, records, and dialogue, rather than as a whole to identify and determine demand completion tasks. Practice proves that this method is incorrect, will not bring a little benefit to both sides, good Communication does not establish information that leads to misunderstanding and ignoring important information. Only when both participants understand what they need to succeed, and also know what they need to succeed, in order to establish a cooperative relationship.
In order to establish a partnership, a team-based approach is usually taken to obtain a demand, and a joint team consisting of user representatives and developers is established as a core team that is demand. The Joint Team will be responsible for identifying requirements, analyzing solutions and negotiation points, and team members can communicate with meetings, email, integrated office systems, etc., but should pay attention to the following principles when communicating: The group meeting should be organized and hosted by China Cube. Users and developers must participate; exchange in advance to determine the rules for preparation and participation; the topic should be clear and overwritten all key points, but the source of information should be freedom; the exchange goals are clear and inform all members.
5. Determine the use example
Collecting them from the user representatives to use the system to complete the desired task, discuss the interactive mode and dialog requirements between users and systems, which is the use of instances, a single usage instance may include many logical related tasks that completed a task and Interaction order. The benefits of using an example method give to the demand acquisition are used by this method to be mission-centered and user-centered, compared to the use of functions centered and a developer-centric method, using an example method to make users Cain more clearly and recognize what new system allows them to do and how to do it. Be careful when describing the use of simple and straightforward expressions, try to use active voice,? Quot; system "or" user "as the subject, such as" user password, system authentication user password is correct ", there is a little Do not design interface details in the description, such as "Select Product Types from the drop-down box". Using the instance provides the material for the basic path and extension path in the subsequent scenario description.
6, convene a joint meeting
The most common demand acquisition method is to convene a meeting or interview. The United Conference is a wide range of seminars, and a good communication method between the core team members, the meeting to focus on the discussion of the user Partnerships between developers are put into practice and can thus draft demand documents. The first issue of the United Conference is the necessity and rationality of the system, and all members must agree that the system is necessary and reasonable. Next, you can discuss the list of uses, the list can be printed into large paper hung on the wall, written on the blackboard or make a demo material. To merge repetitions for each list, plus supplementary content, you can get a list of generals, pay attention to avoid adopting negative "too bad" "not feasible" to deny the idea of the user, these ideas should be retained as a review The list of lists, which protects the idea of the team members. Finally, discuss the list, the meeting member must check each usage example, determine whether it is within the scope defined by the project before deciding it into the demand, forming the final demand report. When discussing, it should also be avoided, and the user can easily list certain precise design in a report or dialog, if these details are recorded as a demand record. Next, they will bring unnecessary restrictions on the subsequent design process, and ensure that user participants will focus on the abstract layer that is suitable for the topic discussed, and the focus is to discuss what is doing, but not. It is important to let users understand that the discussion of certain functions does not mean that it is about to implement it in the system, do not hint or promise when to complete the needs. After discussion, you will read the entries discussed and participate in the discussed user comments and correct, because only those who provide demand can determine if they really get demand. When I finally got a detailed and accurate demand report, the meeting was successfully completed. However, it is necessary to clear the demand process itself is an iterative process, which is inevitable in future process activities will be modified and improved.
7, analyze user workflow
Analyze user workflows Observe the process of performing business tasks by analyzing the use of instances by analysis. The preparation example will help clarify the use of instances and functional requirements of the system, and the use of unified modeling languages helps to further communicate with users. The description of each use case should include: numbered, assigning a unique number for each use case, providing convenience for the retrospective of the demand; participant, interacting with this use case, an actor; front condition, the system that must have before the use case State; rear condition, the system reachable after the system; the basic path, the key path to the use case is also the path to the user's expectations; the expansion point, the branch of the basic path, indicating an accident; the field description, the name of the path Decompose instructions, the definition of later properties and the design of the database field; design constraints, implement the non-functional constraints of the use case. When you write the basic path; the sentence should be used as an actor or system; a sentence represents an actor action, a sentence represents a system action, cross-performance interaction; do not involve interface details, such as "User Enter Name, drop-down box Select Type ".
Use: User registration, user registration becomes a system member number UC1 Participant user pre-conditioner user access system, system running a normal post condition system Record User Registration Information Basic Path 1. User request registration. 2. The system displays the registration interface. 3. Users submit registration information. 4. The system verifies that the registration information is correct. 5. The system generates the username and password to save the registration information. 6. The system displays "Register Success" information and enter the member page. Extended point 4A. The information provided by the user is incorrect: 4A1. System prompts to enter the correct information 4A2. Return 3 Supplemental Description Registration information includes = user real name phone fax email contact address contact address = province city street zip code design constraint registration The reaction time cannot exceed 3 seconds 8, determine the quality properties
In addition to the functional requirements, consider the quality characteristics of non-function, as well as determining the constraints of the features or performance proposed by the special business application environment, which will make your product reach and exceed the expectations of the customer. The statement on how certain behaviors can perform certain behaviors or make users take a certain measure is quality attribute, which is a non-functional requirement. Listen to those who describe reasonable features: fast, simple, intuitive, user friendly, robust, reliability, security, and efficiency. You will discuss with users to accurately define their fuzzy and subjective rhetoric, and to assign quality attributes to design constraints for each use case.
9, check the problem report
By checking the currently running system, further improve the problem report and supplemental needs of the needs customers provide a lot of rich improvements and increased features for new systems or new versions. People who provide user support and help can collect demand for collection needs. The process provides extremely valuable information.
10, demand reuse
If the functionality of the customer is similar to the existing system, you can see if the requirements have sufficient flexibility to allow reusability of some existing software components. The best way for business modeling and domain building model demand reuse, like analysis mode and design patterns, requires its own mode.
