Demand and business model innovation - demand 11 - overview of demand analysis

Book11- Overview of requirements analysis

1. The fundamental task of requirements analysis

1.1. Basic task content

1. Build an analytical model , Reach a common understanding between developers and users of demand information
2. According to common understanding , Be creative , Create software system solutions

1.1.1. Build an analytical model , Reach a common understanding between developers and users of demand information

1. Decomposing complex systems into simple parts and the connections between them , determine Essential characteristics
2. Reach a common understanding of the information content with users
3. The analysis activities mainly include distinguish 、 Define and structure , Its purpose is Get information about something that can be transformed into knowledge , This analytical activity is called modeling —— Build a demand analysis model

1.1.2. According to common understanding , Be creative , Create software system solutions

1. Decompose a problem into independent 、 Simpler and easier to manage Of Son Problems to help find solutions
2. The process of creating a solution is creativity Of
3. Help developers to define problems , And determine the logical relationship between the defined things , These logical relations can form information reasoning , Then it can be used to validate the solution correctness .

1.2. Build an analytical model

1.2.1. Model

1. A model is an abstraction of things , Help people have a better understanding before creating a thing
2. Focus on the computational nature of the problem ( data 、 function 、 Rules and so on )
3. It is a way of thinking and reasoning about the system . The goal of modeling is to establish a representation of the system , This representation describes the system in a precise and consistent manner , Make the system easier to use
4. The process of modeling is modeling .
5. Modeling benefits ：
   1. Reduce application complexity through modeling abstraction .
   2. Understand information more deeply in the process of modeling .
   3. It can help people remember details better .
   4. Better communication with other developers .
   5. Better communication with users and other stakeholders .
   6. Provide documentation for future maintenance and upgrades .
6. Modeling methods
   1. abstract
   2. decompose
   3. Projection

1.2.1.1. abstract (Abstraction)

1. On the one hand, it requires people to focus only on important information , Ignore secondary content ： By emphasizing the essential characteristics , It reduces the complexity of the problem
2. On the other hand, it also requires people to keep cognition at an appropriate level , Mask deeper details ： Infer a broader and more general relationship between the elements of the problem , Help people find solutions

1.2.1.2. decompose (Decomposition / Partitioning)

1. “ Divide and rule ”： Decompose a single complex and difficult problem into several relatively easier subproblems , And master the relationship between the sub problems
2. Decomposed solutions can often provide solutions to problems

1.2.1.3. Projection (Projection)

1. Multi view method

1.3. Two worlds and three models

1. Model is the simplification and abstraction of complex system , Focus on specific components and relationships between components , At the same time, ignore the secondary information irrelevant to the component .

1.3.1. Computing world and computing model

1. Use The constituent unit of software As a component of the model
2. Software Build relationships between units As the relationship between model components
3. Calculation model ： The components used and the relationships between components are elements of software , From the software ( Computing world ) Model of .
4. The computing world is based on computing science , Characterized by formalization , The description of information is clear 、 The characteristics of accuracy and certainty
5. The demand analysis stage is not appropriate Establish a formal calculation model
   1. The point is the problem , Lack of technical details related to software implementation
   2. The user cannot understand
   3. The model based on the computing model is the understanding model of the developer , But it is not the common understanding model of users and developers .

1.3.2. Problem world and business model

1. Use Important concepts in the problem domain As a component of the model
2. Use Business linkages between concepts As the relationship between components
3. Used Business description The way , have Informal features
   1. Business model elements ( Business concept and business connection ) Is inaccurate in the selection and definition of 、 Uncertainty and fuzziness
   2. You can extract the most important and essential content from the requirement information
   3. It can reach the common understanding of users and developers
4. Non formal features make it unsuitable for requirement modeling , Not enough to describe an effective software solution
5. The problem world is complex , The elements of the business model are inaccurate in selection and definition 、 Non formal features of uncertainty and fuzziness .

1.3.3. Software analysis model ( Analysis of the view )

1. Be situated between Computing model and business model The model form between the two
2. The analytical model uses the of the computational model Component form , When describing the solution, it has a more rigorous and applicable description than the business model .
3. The analytical model is The performance of components Using the business model on The way of expression
4. The analytical model is semi formal
   1. Not as rigorous as the computational model , No formal features
   2. More stringent than the business model , It has semi formal characteristics .

1.3.4. The difference between the three models

1. There is no business model in the actual production
2. The demanders directly acquire information according to the demand to establish an analysis model
3. The computing model can be seen as a pre implementation build draft , Is the design model of software .

1.4. Description of the model

1. The three elements are interdependent , Each element All for The next element Provides a necessary environment
   1. grammar ： Usage rule —— How to use model elements , And in what way organization 、 Connect or associate These elements
   2. semantics ： What a particular model element has meaning
   3. pragmatics ： Of model elements Context , And the factors that affect the meaning of the model elements Constraints and assumptions
2. The analysis model ： It has high requirements for language and pragmatics , Because the content described by the model is complex
3. Analyze model characteristics ：
   1. Pragmatic complexity
   2. Semantic richness
   3. The grammar is strict but not too complicated
4. Many researchers have tried to build a formal or semi formal model language that can describe various scenarios in software development , But they all failed in the end

1.4.1. Description of the model ： Multi view method

1. Viewpoint analysis requires people to model a complex system , From different perspectives , In a static system, different contents, which are interwoven, coexisted and relatively independent, are disassembled into different parts , Then model each disassembled sub part separately .
2. viewpoint (Viewpoints)
   1. The different contents in the system, which are interwoven, coexisted and relatively independent, are disassembled into different parts
   2. Each viewpoint is an independent model , Describe with independent model language and representation
3. Multi view
   1. Model descriptions of all viewpoints are integrated , It is the model description of the original complex system
   2. According to the relationship between different parts of the system , Establish relationships between elements in different models , Thus, multiple independent model descriptions are semantically connected

1.4.2. Model 、 Model language and representation

1. Software analysis model is the integration of multiple viewpoint models .

1.5. Requirements modeling

1. The key to requirements analysis is to model real-world problems , Problem domain modeling .
2. Common influencing factors
   1. Problem domain model ： Real time applications ( flow )/ Information system application
   2. Skills of demand analysts
   3. Customer's process requirements
   4. Availability of methods and tools
3. The usual way is ：
   1. First, a preliminary model is established according to the obtained problem domain information .
   2. Then analyze user needs , Adjust the model , Get an intermediate model form .
   3. Last , The adjusted model is logically reasoned and verified , If it meets the expected expectations , Then it is the final solution model .

2. Build solutions

1. Building a solution system is difficult , Creative process .
2. The inspiration of the needs analyst is also important .
3. In creative activities , Scientific factors also play an important role .
4. Scientific factors
   1. External cause
      1. Problem domain characteristics
      2. demand
      3. technology 、 Method
   2. Internal cause
      1. Technical background
      2. Knowledge background
      3. Experience / habit

3. Requirements analysis technology

3.1. Model 、 notation 、 technology 、 Methods and tools

1. The model is represented in context as one of the following three
   1. Abstract information body ： Focus on the minimum completeness of knowledge
   2. View
   3. Model language

3.2. Common requirements analysis techniques

3.2.1. Structured Technology

1. Data modeling
   1. Entity relation diagram Entity Relationship Diagram
2. Process modeling
   1. Data flow diagram Data Flow Diagram
   2. Context map Context Diagram
   3. Microspecification Mini-Specification
   4. The data dictionary Data Dictionary
3. Behavior modeling
   1. state ( transformation ) chart / matrix State (Transition) Diagram/Matrix
4. The process / Data relationship modeling
   1. Functional entity matrix Function/Entity Matrix
5. Information engineering methods
   1. Functional breakdown diagram Function Decomposition Diagram
   2. Process dependency diagram Process Dependency Diagram

3.2.2. Object oriented technology

1. UML
   1. Use case diagram Use-Case Diagram
   2. Class diagram Class Diagram
   3. Interaction diagram ( Sequence diagram / Communication diagrams ) Interaction(Sequence / Communication)Diagram
   4. Activity diagrams Activity Diagram
   5. Object constraint language Object Constraint Language
   6. State diagram State Chart Diagram

3.2.3. Simple summary

3.3. Comprehensive application of technology

3.3.1. The need for comprehensive application

1. How to select requirements analysis technology for each perspective ？
   1. Each requirement analysis technology has its own characteristics , It is unique in application
   2. Complex applications require modeling from multiple perspectives
2. How to realize the cooperation between them ？ Only through the organic combination and integration of a variety of requirements analysis technologies can we fully describe complex applications

3.3.2. The development process of demand analysis technology

1. See textbooks for more P263
2. 20 century 50 years ： code 、 Machine centered
3. 20 century 60 years ： Hardware and software are different 、 Personal heroism
4. 20 century 70 years ： Formal method :$\lambda$ Calculus and Turing machines 、DFD、ERD、 Functional entity matrix 、 Entity life history and fact matrix .
5. 20 century 80 years ： Focus on software efficiency 、 State diagram 、 Functional breakdown diagram 、 Process dependency diagram
6. 20 century 90 years ： object-oriented
7. 20 century 90 s ： Workflow challenges 、 Business process reengineering

3.4. Application characteristics of technology

Overview and classification of requirements analysis technology

3.4.1. Wieringa frame

1. Functional description ： Interaction is purposeful ,“ Users can use ATM Withdraw money ”
2. Communication description ： The system communicates information with surrounding entities ,“ The user enters the card number 、 password 、 amount of money ,ATM Withdraw the corresponding cash ”
3. Behavioral description ： Function split , More detailed , Every step of the interaction
4. function - signal communication - Behavior is gradually refined , Gradually expand the system functions .
5. Another route is system decomposition
   1. External interaction of the system ：
      1. Component functions ： Functional description of the interaction of components within the system after decomposition , Such as " Depositors can use ATM Withdraw money "$\to$“ The card reader can read the bank card data ; The touch screen can display … And allow depositors … The keyboard allows the depositor to enter the password and amount ; The remote connection can connect to the bank database for verification … The cash outlet can spit out the corresponding amount of cash ”.
      2. Component communication ：“ After decomposition, the internal components of the system are described interactively , Such as “ The depositor enters the bank card number 、 Password and withdrawal amount ,ATM The system gives the corresponding amount of cash ”$\to$“ The card reader reads the bank card data and provides it to the remote connection ; The keyboard receives the password entered by the depositor and provides it to the remote connection , Get the amount of cash input by the depositor and provide the banknote outlet ; The touch screen displays... To the depositor … The remote connection sends the bank card number to the bank database 、 password , Get the validation result data ; The cash outlet spits out the corresponding amount of cash ”.
      3. Component behavior ： After decomposition, the interaction behavior of components in the system is described , Sequence diagram
   2. System internal interaction
6. Requirements analysis technology
   1. external function
   2. External communication
   3. External behavior
   4. Conceptual components
   5. Component functions
   6. Component communication
   7. Component behavior
7. The external interaction refinement and system decomposition of the system are carried out simultaneously , Sequential cohesion ： External behavior $\to$ External communication $\to$ External behavior .
8. Based on the analysis of 、 When modeling a simple system , After the external interaction refinement and system decomposition of the system are completed , End requirements analysis , Software design .
9. If the system is complex , Further decompose the internal interaction ： Component functions $\to$ Component communication $\to$ Component behavior

3.4.2. Zachman frame

1. Focus on all modeling techniques in software production
2. Describe the distributed network of the software system , People draw topologies of locations
3. Describe the organizational structure of the enterprise , Use a hierarchical model 、 Matrix model and mesh model

3.4.2.1. Zachman The rows of the matrix

1. The goal is / Range ( Planner view )
   1. Care about the cost and benefit of software systems
   2. The scale of the final system 、 form 、 A rough description of the location space and basic objectives
   3. The planner's view defines the prospects and scope of the project .
2. Enterprise model ( Owner view )
   1. Care about how the software system will participate in and help the actual work
   2. For business entities 、 A description of business processes and their interactions with systems
   3. Use business concepts to define the solution of the system —— The analysis model .
3. System model ( Designer view )
   1. Pay attention to the needs of the software system and the selection limitations of the design method
   2. Description of the basic functions and design space of the software system —— Architecture .
4. Technology model ( Builder view )
   1. Focus on the program
   2. Control logic in software system 、 Algorithm 、I/O Description of control and various other specific technical details —— A design model that describes the detailed design
5. Component model ( Integrator view )
   1. Focus on assembly
   2. For the components of the software system 、 Description of interface and coding program
6. Actual operating system ：
   1. Describe the actual status and performance of the system after it is put into use .

3.4.2.2. Zachman The columns of the matrix

1. data ： Things of great significance to the enterprise and the enterprise's understanding of these things
2. function ： The tasks performed by the enterprise in the business and the understanding of the task by the enterprise .
3. Location ： Geographical distribution of organizational activities and software systems , And how they relate to other aspects of the organization .
4. people ： Personnel and organizations involved after the software system is introduced
5. Time ： Events within the system - The time factor between events , It is expressed as business planning and scheduling 、 Event response and control structure of the system .
6. motivation ： This column is for the motivation of the enterprise to establish the target system , It reveals the goal of the enterprise 、 Purpose 、 Business planning 、 Knowledge structure 、 Ideological line and decision-making basis .

4. Demand analysis method

1. Traditional analysis : There is no way (1950’s)
   1. Rely on individual intelligence , According to personal habits
   2. Lack of structure 、 Do not repeat 、 It's not measurable , Lengthy 、 confusion 、 Biased 、 No structure, etc
2. Structural analysis
   1. Traditional structured analysis (late 1960’s), Modern structured analysis (late 1970’s), Focus on data flow , With DFD As the core technology , auxiliary ERD,STD…
   2. Information engineering (late 1980’s), Based on data knowledge structure ,ERD As the core technology , auxiliary DFD,STD, FDD, PD…
3. Object oriented analysis (1990’s)
   1. Focus on the object , With UML( Class diagram ) As the core technology
   2. Take comprehensive ideological innovation as the ideal , Take the inheritance of structured technology as the reality

4.1. Structural analysis

1. The structural analysis method describes the display world as the flow of data in the information system , And the transformation from data to information in the process of data flow .
2. Data flow diagram ： System input 、 Handle 、 Storage and output
3. Entity relation diagram ： Store data information
4. State transition diagram ： Identify all events that the system needs to respond to .
5. Analysis inhibition ： Pay too much attention to the original system

4.2. Information engineering

1. Improvements to the structured approach
2. Develop systems from an information perspective
3. Including functional decomposition diagram and process dependency diagram technology

4.3. Object oriented analysis

5. Modeling and analysis of early demand stage

5.1. Early demand stage and late demand stage

1. Goal oriented analysis (Goal Oriented Analysis)
2. Problem domain oriented analysis (Problem Domain Oriented Analysis)： Early demand stage analysis
3. Demand oriented analysis ： Analysis of later demand stage .
4. Domain analysis (Domain Analysis)
5. Enterprise modeling (Enterprise Modeling)

5.2. Problem domain oriented analysis

1. Problem framework
   1. characteristic
   2. solve
2. Frame decomposition and combination
3. The basic idea
   1. Study all possible problem domains , Find some simple problem types that recur , Such as workpiece system 、 Connect the system .
   2. Analyze the characteristics of each problem framework , Determine the understanding and solution of the problem
   3. Systematize the establishment and classification of the problem framework , Take the simple problem framework as the basic unit , Decompose complex problems

5.3. Domain analysis

1. field ： scope of business 、 A collection of problems 、 A collection of applications 、 A range of knowledge with common terms .
2. Product family ： There are a lot of commonalities 、 Products with a few differences .
3. To discover 、 Analyze and define reusable requirements .

5.4. Sample analysis

1. Not aware of the difficulties of different people in understanding the model at the same time .
2. Object models are used extensively in projects , But there are many problems , Mainly in the following aspects ：
   1. It ignores that objects should have both state and behavior ;
   2. The object has too many responsibilities ;
   3. The relation division of objects is not clear ;
3. Others such as use case models 、 Behavioral models 、 State machine models are commonly used . The improper use of the use case model is mainly the relationship between subsystems , Sometimes I feel that the boundary of each subsystem is not well established . Behavioral models , The main problem of the state machine model is that the demand personnel face a demand , I don't know how to use sequence diagram , Communication diagrams , Activity diagram or state diagram .

6. Requirements analysis activities

6.1. Important activities in the requirements analysis stage

6.2. Demand refinement

1. Define the requirements of users Implication factors
2. Be careful ：
   1. Refinement of user requirements ： Transform the user requirements expressed from the perspective of problem domain and business into the system requirements expressed from the perspective of software and technology
   2. Need to add hidden factors ： Add problem domain information to system level requirements , Like the price 、 Quantity and other details .
   3. Non functional requirements also need to be transformed from high-level expression to a series of more detailed and specific requirements
   4. Requirements refinement will also find new detailed requirements
   5. The requirements are well understood , And the developer can start to stop the refinement process when designing the scheme
3. The detailed requirements should be identified and recorded one by one

4. Record of requirements
   1. identifier (ID), Every requirement should be able to pass ID The only way to identify yourself .
   2. The source of the (Source), Be able to trace back to the source of demand , For example, specific stakeholders .
   3. reason (Rational), The purpose for which the requirement is proposed .
   4. priority (Priority), See the next section for details .
   5. cost (Cost), Estimated realization cost .
   6. risk (Risk), Possible risks in the process of realizing this requirement .
   7. variability (Volatility), The possibility of future changes .

6.3. Prioritize requirements

6.3.1. Situations where requirements need to be prioritized

1. Project resources are limited
2. The project is developed in stages
3. At the beginning of the project , Not all the user requirements can be defined .

6.3.2. The method of prioritizing

6.3.2.1. Cumulative votes

Normal voting , Empowerment

6.3.2.2. Zoning

1. Importance ： The indispensability of demand .
2. Urgency ： The degree of time urgency required .
3. punitive ： The degree of punishment that can result from neglecting requirements .
4. cost ： The cost of achieving the requirements .
5. risk ： The degree of risk that may arise in the implementation of requirements .
6. Not important but urgent ： Does the stored voice of wechat use .

6.3.2.3. Top-N

1. N The value of is not explicitly limited , What is really limited is Top-N The total implementation cost of the requirements
2. Choose the highest priority N A need

6.3.2.4. Data quantification

1. Priority judgment based on time delay cost
   1. Same delay cost , Short task first
   2. The workload is the same , High delay costs are preferred
   3. Weighted shortest task first ( important + The degree of emergency )
   4. All priorities are local and temporary

6.4. Demand negotiation

1. Identify the factors of conflict , Avoid emotional conflict
2. Clarify the conflict resolution space
3. Determine the best solution

7. Summary of this chapter

1. Requirements analysis is the most important and core activity in requirements engineering , Its modeling of information is the key to understanding problems , It is also the key to creating the right solution
2. Requirements analysis involves many technologies and methods , The effective implementation of requirements analysis activities requires analysts to master and determine the selection and use of these methods
3. Many important sub activities will be performed in the requirements analysis process , Their effective integration ensures the success of the whole requirements analysis