Architecture Design Practice II: Demand Analysis

1.1 of three questions

To master the demand analysis, we need to master three problem solving methods.

• How are requirements obtained? Demand development = Vision Analysis + Demand analysis
• How to judge the demand is not complete? Functions, quality, constraints three types of requirements
• How do I convert from requirements to design? functionality, quality, and constraints have different effects on the architecture.

1.2 General diagram of software development and delivery process

In general, the conceptualization phase is to complete the vision analysis, risk assessment, feasibility analysis and rough estimation of project schedule and cost, output "vision and scope document", the requirement analysis phase is completed requirements capture, demand analysis, get "Software Requirements Specification", A key idea is that demand capture and demand analysis is iterative, and the idea that the demand analysis is completed after the requirement capture is not credible; The architecture design phase is completed through key requirements determination, conceptual architecture design, refinement of the architecture design and architecture validation, to obtain the architectural design specification.

1.3 Vision Analysis (brief)

The objective of the vision analysis is to define the vision of the system, the scope of the function, the main characteristics and success factors, and so on to conceive and agree. Output for the "vision and scope of documents", some product-based companies will be called "Market demand Document" MRD, some product-based companies are called "Product requirements Document" PRD, project-based companies may be called "Project proposal book."

Vision = Business Goal + Range + feature + context diagram.

• Business goals are the goals that customers need to organize their applications, such as improving some of the organization's capabilities and simplifying some of the organization's processes.
• The scope is the surface characterization of the requirements, indicating which major functional blocks the system needs to provide in order to achieve the business objectives.
• The feature is a point-like characterization of the requirements, enumerating which functional groups the system roughly supports (smaller than the range of functional blocks), highlighting certain features that feature items, highlighting the more detailed advantages of the features, technical features, and other features.
• The context diagram is used to depict the boundary of the system, put the system in the center, surround all the external things related to the system, pay attention to the system and external factors related to the system, but do not pay attention to the internal system, keep the system as black box, its main purpose is to ensure the comprehensive requirements discovery process.

1.4 Demand Analysis (brief)

The process of demand analysis is the iterative process of demand capture and demand analysis, rather than the linear process of demand analysis, demand capture.

Demand capture is the process of acquiring knowledge, requiring understanding of what users are doing, and understanding what users and customers want software systems to do to help them. Demand capture output is a series of "demand Acquisition card", record requirements type, demand description, demand for Beijing, demand and other information.

Demand analysis is the process of excavating and collating knowledge, which is based on the knowledge acquired by the demand capture, which makes the demand more systematic, comprehensive and orderly. The output of the requirements analysis is the software Requirements specification, which accurately describes the functions that a system must provide, the quality attributes that must be achieved, and the constraints that must be observed. General use case technology to carry out requirements analysis, for the important requirements, in addition to the use case diagram, but also to give a detailed use case specification.

1.5 How to determine whether demand is comprehensive 1.5.1 demand level-aspect matrix

Use a two-dimensional demand matrix to determine whether the requirements are comprehensive. This is the most operable method I have seen at the moment.

On the one hand, demand is hierarchical, according to the different stakeholders can be divided into three customer-level requirements (also called organizational level requirements), user-level requirements and development-level requirements, on the other hand, the requirements can be divided into functional, quality and constraints three aspects. By examining the two-dimensional matrix of hierarchy-aspect, we can judge whether the demand is comprehensive.

	Function	Quality	Constraints
Customer needs	Business objectives	Fast, good, provincial	Technical constraints Standard constraints Regulatory constraints Legacy system Integration Technology trends Batch Implementation Competitive factors and competitors
User Requirements	Implement a function of XXX	Run-time Quality	User Group Features User Level Multi-lingual Use environment
Development Requirements	Behavioral needs (this is not a good idea)	Quality of development period	Development team Skill Level Development team running-in degree Distribution of development teams Development team Business Knowledge Confidentiality Requirements for Management Installation Maintenance

1.5.2 Classification of software quality

Software quality involves many, but it is divided into the quality of the running period and the quality of the development period from the perspective of the followers, which can be clearly divided.

The so-called run-time quality refers to the quality attributes that end users can feel during the system's operation, including performance, ease of use, security, robustness, reliability, availability, scalability, and interoperability.

Development period quality refers to the system development, maintenance, migration process reflected in the properties, is the development of software, construction, deployment of people concerned about the quality attributes, including:

• Developer Focus: Easy to understand (this is easy to ignore), scalability, reusability, maintainability, portability
• Testers ' concerns: testability
• Deployer's focus: Ease of deployment

Key Quality Attribute Description

• Performance : Performance includes speed, throughput, and continuous high speed, measured using average response time, throughput is measured in units of time transactions, and continuous high speed refers to the ability of the system to maintain a continuous high speed processing speed, which is related to real-time systems, and real-time systems have stringent requirements for each system response time. It is important to note that the speed generally means high throughput, but slow speed is not necessarily low throughput, which is similar to the network latency and bandwidth.
• Security : The ability to provide services to legitimate users and to prevent illegal users from using them. High security means "simultaneous consideration".
• availability and Reliability : Reliability refers to the ability of the system to operate without fault in a given time, generally measured by mean time-out, while high availability refers to the "ability of the system to provide the user with a service for a long time" (the original book is "The ability of the system to operate without fault for a long time" and should be less accurate). Often use clustering to improve the high availability of the system, but obviously, if the whole cluster as a whole, any one machine down, the whole system can not be judged as "trouble-free operation", so its reliability compared to the single machine is reduced, but as long as the cluster of enough machines to work properly, the system " The ability to provide available services to users is unaffected, so the cluster improves system availability.

1.5.3 constraints

From the customer, the user, the development of three levels to decompose constraints, to ensure the integrity of the constraints. Another angle, constraint = business environment factor (from customer) + use of environmental factors (from users) + build environmental factors (from development, maintenance personnel) + technical environmental factors (industry technical constraints).

1.6 How to transition from demand to design

• Use function to divide subsystem and module: function is the basis of discovering responsibility, each function is completed by a chain of responsibility, by planning responsibility chain for function, dividing responsibility into subsystem, developing interface for subsystem, determining interface-based interaction mechanism to promote architecture design.
• Using quality to improve the architecture: it is necessary to further consider the quality requirements based on the current intermediate architecture and to adjust and refine the intermediate architecture.
• Constraints: A subset of constraints directly restrict design decisions, such as the ability of team members to master only Java-related development techniques; Some of the constraints can be converted to functions, such as the "system execution current interest rate" in the banking system, which leads to the function of "interest rate adjustment"; part of the constraint is converted to mass properties, such Elicit ease-of-use requirements.

Architecture Design Practice II: Demand Analysis