Demand and business model innovation - demand 4- overview of demand acquisition

Book4- Requirements acquisition Overview

1. introduction

1. Requirements acquisition is an activity of requirements collection , It starts with people 、 Data and environment to get the relevant information selected for system development .

2. Common difficulties in requirements acquisition ( Extraordinary )

1. Default background ： user / The customer is separated from the development team
2. Users and developers have different backgrounds , Different positions
   1. The difficulty of understanding knowledge ： Developers try to study the background of the application , Understand the state of the organization , Form a rough knowledge framework for effective communication with users
   2. Default (Tacit) Knowledge phenomenon ： Use effective acquisition methods and techniques ( Role play 、 Observation, etc ) To discover and acquire default knowledge , In most cases, it is wrong to find a user who knows the computer well .
3. The average user lacks generality 、 Comprehensive expression ability
   1. The knowledge structure of ordinary users is relatively limited For some specific Business details ： Be good at expressing the details of specific business
   2. The knowledge structure of expert users is characterized by its profundity Generality and universality ： Able to answer general and comprehensive questions
   3. The developer determines the acquired before contacting the user Content subject , Then design the specific application environment and scenario conditions , The user describes the problem according to the execution of the detailed business 、 Express expectations .
4. Users have cognitive dilemmas
   1. potential (Latency) knowledge ： Have a method but don't know it , It is necessary to utilize various effective requirements acquisition methods and techniques
      1. Ethnographic methods , Analyze user environment and behavior , Tap into potential knowledge .
      2. Design the initial prototype on the basis of limited understanding .
      3. Take the initiative " create " demand , The essence is still the prototype method .
5. The user is acting on his behalf
   1. It's not a requirement that users put forward , It's the solution ： Pay attention to maintaining the distinction between business areas and solutions , For example, the original problem is to improve disaster tolerance , The proposed requirement is dual machine hot standby ( Solution )
   2. Users stubbornly adhere to certain features and functions ： Analyze the user's deep purpose , Find hidden in The need behind
6. Lack of user participation
   1. Too many users , Difficult choice
   2. Users don't know enough , Unwilling to participate in ： Think that the software product is the result of paying .
   3. User emotional resistance , Passive participation ： The new system infringes on them , Or do not see respect for them .
   4. There is no specific user ( Market driven )
      1. To the users of the system and the alternative sources of users Stakeholders Analyze
      2. User portrait (Persona)

3. Activity process of requirement acquisition

3.1. Sub activities of requirements acquisition

1. Research application background , Build an initial knowledge framework
2. According to the need to obtain , Use the necessary acquisition methods and skills
   1. Determine the content and subject of the acquisition first , Set the scene
   2. Analyze the user's high ( deep ) Layer target , Understand the user's intention
3. Do stakeholder analysis , Work on the characteristics of stakeholders

3.2. Activity process of requirement acquisition

1. Collect and apply relevant background information $\to$ Understand the general situation of the application and organization , Build an initial knowledge framework $\to$ Analyze high-level issues of stakeholders in combination with background resources , Understand stakeholders' expectations for the resolution of these high-level issues , Summarize the business requirements of the system
2. In complex acquisition activities , The essential steps are as follows ：
   1. Determine the content of the information to be obtained
   2. Identify the source of the information to be obtained
   3. Determine the acquisition method to be used
   4. Execute get
   5. Record the results

4. Key points of requirements acquisition activities

4.1. Acquired content

1. Within the scope of the project
2. All the information necessary to create and solve the system for users
   1. demand ( draft )： It is the desired goal of the system , Usually reflected in the user's point of view 、 view 、 Goals or problems
   2. Problem domain characteristics ： It should be noted that the system environment and constraints should not be ignored
   3. Environment and constraints ： It mainly comes from the description of stakeholders and the observation of the application environment
3. The content obtained is not obtained at one time , But gradually accumulated

4.2. The source of information

1. Stakeholders
   1. user ： Most important
   2. Customer
   3. Domain expert
   4. Marketing people 、 Other user alternative sources such as sales personnel
2. Hard data
   1. Registration form 、 bill 、 Reports and other quantitative documents
   2. Memorandum 、 Qualitative documents such as logs
3. Related products
   1. The original system
   2. Competitive products
   3. Collaborative products ( Reconcile other software systems that have interfaces with the system )
4. Important documents
   1. Specification of original system
   2. Specifications of competitive products
   3. Specifications for collaborative products
   4. Customer requirements document ( Specification of commissioned development 、 Tender )
5. Relevant technical standards and regulations
   1. Relevant laws 、 Laws and regulations
   2. Industry norms 、 Industry standard 、 Domain reference model
6. There are two main types of inductive acquisition sources ：
   1. Knowledge in the human brain
   2. Knowledge outside the human brain

4.3. How to get information

1. traditional method ： The questionnaire survey 、 Interview 、 Hard data analysis 、 Document checking 、 Demand stripping, etc
2. Collective access methods ： Brainstorming (Brainstorming)、 Symposium (Workshop)、JAD(Joint Application Development, Joint requirements development )、JRP(Joint Requirements Planning, Joint demand planning ) etc.
3. Prototype And model driven ： Especially for Fuzzy and uncertain The situation of .
4. Model driven approach ： The model defines the information type of the mobile phone , The process of model establishment and improvement is the method of requirement acquisition
   1. A goal oriented approach
   2. Scenario Oriented Approach
   3. Use case based approach
5. Cognitive approach ： Task analysis (Task Analysis)、 Protocol analysis (Protocol Analysis) etc. – Rigorous and meticulous extraction of domain knowledge
6. Context based approach ： Observe 、 Ethnography (Ethnography) And discourse analysis (Conversation Analysis) - Go deep into users , Observe it ( third party )

4.4. The process of obtaining information

4.4.1. matters needing attention

1. Formulate the organization plan as a whole ： Determine the boundary of the system ,( best ) establish Context diagram or system use case diagram
2. Maintain the prospect and scope of the project
   1. Guide and control the acquisition process
   2. Correct the inaccurate foreground and scope properly
3. Accept the instability of demand ： The world changes at any time , Users change with the world , Need to accept
4. Control exploratory work ( Examples are simulations and prototypes )： There is a risk of delay and overspending , Additional project approval or incremental development may be considered

4.4.2. Prevent requirements from missing

1. Make sure that all Stakeholders All express their opinions .
2. Don't end with abstract and vague requirements . Yes Abstract and vague The needs of , To carry out elaboration , Let the real needs be revealed .
3. Use many-ways Express demand information . Use different analysis techniques to model the same requirements , By analyzing different concerns , Check whether the requirements are complete .
4. Pay attention to inspection The boundary value ( Degree of ) and Boolean logic ( Good or bad , Yes or no ).

4.4.3. The judgment condition for ending the acquisition activity

1. The user can't think of more The use case ;
2. The new use cases that users come up with are Export use cases ( The use case can be deduced through the combination of other use cases );
3. Users are just Repeat what has been discussed The problem of ;
4. New features 、 The demand is waiting Project scope outside ;
5. New requirements Low priority ;
6. The new functions proposed by users belong to Subsequent versions , Not the current version

4.5. Results obtained

1. There must be acquisition record (Elicitation Notes)
   1. The user needs 、 Problem domain knowledge and constraints
   2. May have Poor organization 、 redundancy 、 missing 、 stultify oneself And so on
   3. Can include A written record 、 sound recording 、 Video shooting And so on
2. There may be two well-defined formal documents ( Combined with demand analysis )
   1. Project prospects and scope file
   2. Use cases file

5. Practical investigation of demand acquisition

5.1. The requirements acquisition activities in practice mainly focus on several issues ：

1. Project objectives ： One of the top ten factors influencing the success of the project [Standish Group], Target model and target oriented method .
2. Project scope ： It contains complete functions , Function is necessary ; Best cost benefit ratio ; To control effectively .
3. User participation
4. Communication issues
5. Get the use of the method

5.2. Common project wide errors

1. Project boundary definition blurring , Or there is no project boundary defined at all ;
2. Defined project boundaries error , Make the final requirements incomplete or redundant ;
3. There is no control Established project boundaries , Make the project scope out of control ： Especially the problem of abandoning requirements and developers because of time pressure " gold-plated " The problem is very common

5.3. Insufficient user participation

1. No one can It works Select the users who will participate in the project ： The ideal user is the most unlikely user
2. Lack of understanding
   1. developer ： The user doesn't understand / Not interested in / don't have time
   2. user ： Not aware of its main role ( Give me the product directly ！)
3. Users resist ： Affecting some groups Interests or values / Refuse to change / Conflict
4. There is no specific user ： Internet enterprises / thinking ： Huge user base ( Traffic )+ New things ( innovation ), Take advantage of the user's alternate sources
5. Management barriers ： please There's authority Employee involvement ： Requirements acquisition will take up its own working time

5.4. Communication issues

1. The biggest problem is Understanding bias
2. Common communication methods ： Informal telephone conversation 、 A formal telephone conversation ( For example, customer hotline or teleconference )、 mail 、web Feedback form 、 Documentation and some face-to-face communication ( for example JAD meeting 、 Prototypes, etc )
   1. Personal contact and informal communication are more popular
   2. The number of communication channels should be moderate (4-7)
3. Face to face communication is the most effective , It's also the most popular
4. Direct communication is better than indirect communication

5.5. Get the use of the method

1. It has not been fully applied in practice ： Did not select the correct acquisition method
2. The basis for selection of acquisition methods in five aspects ( Whether the user has the ability to accurately and comprehensively express the requirements for the system )
   1. The purpose of the demand ( Detailed SRS Or overall demand plan ): Create specifications for existing systems , Or establish a requirement scheme for a project .
   2. The type of knowledge ( static state / dynamic , abstract / detailed )
   3. The characteristic requirements of knowledge internalization ( New knowledge 、 Potential knowledge 、 Scene knowledge 、 Inertia knowledge 、 Obvious knowledge )
   4. Observable phenomena
   5. constraint ( Meeting required 、 Get ready / collection / Time limits for obtaining requirements 、 The engineer / Number of stakeholders 、 Level of stakeholder support 、 Leading technical requirements )