Design path: How to perform software requirements analysis?

1. The importance of demand analysis

Software requirements refers to the user's expectations of the target software system in terms of function, behavior, performance, design constraints and so on.

Typically, the software lifecycle includes activities such as feasibility analysis and development planning, requirements analysis, design (summary design and detailed design), coding, testing, and maintenance.

Among the three commonly used software lifecycles (waterfall model, iterative model and rapid prototyping model), demand analysis plays an important role, which is the input of system analysis, software programming, software testing and system maintenance.

1.1 Waterfall Model

The waterfall model is well known as a waterfall, first presented by Royce (Waterfall models). In this model, the requirements are first identified and validated by the customer and the SQA team. Then draw up the specification, also through the validation, into the planning stage ... It can be seen that the most important point in the waterfall model is that only when a phase of the document has been prepared and approved by the SQA team to enter the next stage. In this way, the waterfall model provides prescriptive documentation to ensure that each stage is well-done with mandatory requirements. However, it is often difficult to do so because the entire model is almost document-driven, which is difficult for non-professional users to read and understand.

The waterfall model is illustrated below:

As can be seen, the output of demand analysis, "Requirements Specification" (some projects will also produce software prototypes, such as static HTML prototypes, etc.) is the basis for subsequent design, coding, testing and system maintenance.

The "Demand analysis" stage of the waterfall model can be subdivided into two stages of "software concept" and "User Requirement Analysis", the former is used to collect the user's original requirements, including the user's expectation in function, behavior, performance, design constraints and so on, and after the initial analysis, the user requirement specification is formed, and then after further analysis, The user needs to be accurate and complete, the final formation of the requirements specification.

The "System design" in the waterfall model can be subdivided into two stages of "architecture design" and "Detailed design", the former is generally grasped and more concerned with the architecture level, including the overall architecture of the system, and the relationship between each subsystem or each module. The latter more attention to detail, including all aspects of system design should be reflected in the detailed design.

As a system analyst, or system architect, mainly in the "Requirements analysis" and "system design" stage to reflect their own role, the follow-up stages mainly through the communication with the project team members to carry out their own design.

1.2 Iterative Model

An iterative model is a periodic model recommended by RUP (Rational Unified process, unified software development processes, unified software processes). In Rup, iterations are defined as: iterations include all development activities that produce a product release (stable, executable product version) and all other peripheral elements necessary to use the publication.

To some extent, development iterations are a complete process of all workflows: (including at a minimum) requirements workflows, analytical design workflows, implementation workflows (coding processes), and test workflows. In essence, it can be understood as a number of small, waterfall-style projects. Each iteration produces a product that can be released, which is a subset of the final product.

An iterative prototype is shown below:

In each iteration, the "demand analysis" phase, like the waterfall pattern, is the basis for subsequent system analysis, coding, and testing phase dependencies. If the demand analysis has a large deviation, it is bound to cause a large deviation of a subset of products produced during the iterative process.

1.3 Rapid Prototyping Model

The Fast prototyping (Rapid Prototype) model is functionally equivalent to a subset of the product. Note that this is said to be functional. The disadvantage of the waterfall model is that it is not intuitive enough, and the rapid prototyping method solves this problem. In general, according to the needs of customers in a short period of time to solve the most urgent needs of users, to complete a demonstration of the product.

After getting the user's needs, the prototype will be discarded. Because prototype development is fast, design is almost no consideration, if you retain the prototype, in the subsequent development will pay a great price.

In the rapid prototyping model, the most important purpose of a prototype is to determine the real needs of the user. To some extent, rapid prototyping can be understood as a more intuitive way of demand analysis, and it is also a way for the industry to recognize and achieve good results.

2. Target of demand analysis

Through the understanding and analysis of the corresponding problem and its environment, the paper establishes a model for the information, function and system behavior of the problem, makes the user's requirement accurate and complete, and finally forms the requirement specification, which constitutes the requirement analysis stage of the software development life cycle.

Demand analysis is a bridge between the system analysis and the software design phase. On the one hand, the requirement analysis takes the system specification and the project planning as the basic starting point of the analysis activity, and inspects and adjusts them from the software angle. On the other hand, the requirement specification is the main foundation of software design, realization, test and maintenance. Good analysis activities help to avoid or eliminate early errors earlier, thus improving software productivity, reducing development costs, and improving software quality.

3, how to carry out demand analysis 3.1 requirements analysis difficulties

The objective of the demand analysis is to make it more popular, that is, to determine "what to do and what not to do". But demand analysis is not as simple as imagined, mainly because of the following reasons:

3.1.1 Customer demand changes frequently

Everything in this world, only "change" is absolute, from this point of understanding, the requirements of software systems are constantly changing is understandable. Listening to designers and developers complaining that the needs of customers are constantly changing, it should be understood that "demand change" is a normal.

There are many reasons why demand changes, such as:

(1) Because some preconditions are not fulfilled, they are implemented according to the "compromise" scheme, but if these preconditions are satisfied at a certain point in time, they cause the change of demand.

(2) There is no need to go through the approval process before a background operation, but because a customer's internal process changes, the need to go through the approval process, will inevitably lead to the requirements of design------code--

"Countermeasures": As demand changes are unavoidable, system analysts need to be clear when conducting requirements analysis:

(1) As much as possible to analyze what is the stable demand, which is the variable demand. In order to carry out the system design, the core of the software building in a stable demand, or will suffer.

(2) In the contract must say clearly "what to do" and "do not do what." If the contract vague, there will be more things to do in the future. Small changes have little impact and do not affect progress, but there is a need to make a clear statement in the contract about the need for changes that could lead to significant design changes.

3.1.2 Customers say they do not know the need, analysts understand the error

The customer's computer level, the understanding of the demand, the level of expression is uneven. Some customers have only a hazy sense of demand, of course, not clear the specific needs. Some customers are very clear about what they want, but they don't understand. Some customers understand the software development, can make the requirements clear, such a demand analysis will be very easy and enjoyable.

System analysts who have different personalities, different levels, and who are prepared to communicate with the customer before they discuss the requirements will get a very different result.

As a system analyst, can guide the customer, first elaborated the general demand, again by the customer denies does not need, finally determines the customer real demand. A good system analyst, can from the customer's one or two sentences to put forward a lot of their own views or can be expanded, and further explore customer needs, or if the contradiction with previous requirements, can be the correct demand-oriented.

"Countermeasures": if the customer is not clear about the requirements, in order not to cause misunderstanding, the system analyst can use many ways of communication, such as the first time through the customer to understand the requirements, go back to analyze what is reasonable demand, those are contradictory or unreasonable demand, and what needs further clear needs. After refinement, the second exchange can provide PPT or simple Word documents for a second in-depth communication with the customer. The third exchange can be further communicated with the customer by establishing a rapid model for precise requirements. Demand analysis can also refer to "iterative models" to iterate continuously until all of the customer's potential needs are tapped.

3.1.3 Customers have not seen the prototype or complete system, there are some potential requirements have not been excavated

There are even a lot of such customers, to carry out the need to communicate with too much demand, but when you finish the whole system, the potential demand suddenly burst out.

"Countermeasures": in order to avoid the destructive impact of this situation on the project, it is recommended that the relevant personnel establish a rapid prototype for some large functional modules for the customer to confirm, and in the contract must say clearly "what to do" and "Do not do"

3.1. More than 4 related parties need conflicting requirements with two semantics

If the needs of the customer are involved in different departments, if there is disagreement, if the opinion of a party to modify, it is likely to be later involved in another department of the idea of transformation.

"Countermeasures": for this kind of customer internal conflict needs, the needs of the customer side of the relevant departments to discuss, by the customer's higher leadership decide which side of the demand, or adopt a compromise plan. The requirement explanation cannot have two semantics, can not contradict before and after. If there are two semantics or inconsistencies, then you need to re-analyze this requirement.

3.2 Requirements Analysis activities 3.2.1 Requirements acquisition

Develop, capture and revise user requirements by communicating with users, observing existing systems and analyzing tasks.

The common method of obtaining software requirements (in the article "Software Requirements Acquisition Method" is written in detail) is as follows:

Ø Interview

Individuals feel that interviewing is the most useful way to obtain software requirements, and is also a common method of demand analysis. Through multi-party interviews, get the most information, the system we are doing now, with the mobile Group Customer department, Business support department, Network Management Center, system operators, etc. have been interviewed.

What to prepare for the interview: Interview subjects and interview questions.

Interview participants: As far as possible, it is necessary to include participants in the interview with a system-related stakeholder, and to be representative and to ensure that each role is covered. Who pays for the system and buys the system? Who uses the system? Who is affected by the results of the system? Who will supervise the system? Who will maintain the system?

Ø Questionnaire Survey

The questionnaire can not replace the role of interview in the stage of demand acquisition, the questions and answers of the questionnaire have some guidance, which will affect the result in some way.

The results of the questionnaire are directly related to the design of the questionnaire, in doing this project, the operators in the pre-promotion meeting, but also to corporate customers sent questionnaires, but because of many reasons, the effect is not ideal, basically did not for our project needs analysis of how much force.

Ø Panel Discussion

A panel discussion is a gathering of people who are related to a problem in a project to meet and discuss. Advantages: It is easy to obtain the identification of the other side case in the internal, which is advantageous to the project development; at the seminar, each relevant person can make their own comments, ensuring the comprehensiveness of the information obtained. Cons: Not easy to grasp.

This approach is desirable in the case of requirements involving system boundaries, or conflicting requirements.

Ø scenario Concatenation

Due to the abstraction of software products, most of the stakeholders in the brain do not have a clear outline of the product, affecting the understanding of the product stakeholders. Based on this, consider writing a clear, complete scenario description document.

1, the use of PPT and pictures of the way to describe the situation: a good ppt can be more intuitive description of various scenarios;

2, the use of prototype method (the comparison recommended this method).

Ø participation and observation of business processes

Stakeholder-described business processes may omit important information for some reason, and demand analysts can apply to participate in their specific work to observe and experience the business process. When observing the business operation process, the requirement analyst can ask and record detailed information according to the actual situation, record the operation process of the business operator, the difficulties encountered during the operation, obtain the real material and understand the whole business.

Ø Existing product and competitor description document

Reading the existing product documentation facilitates understanding of the current system situation, as well as understanding the business process and a deeper understanding of the system issues that the operator reflects.

3.2.2 Demand Modeling

To effectively collect requirements, the first step you will take is to model, which includes creating a representation of the architecture to capture requirements, communicate about solution methods, and analyze the proposed system design. The goal is to use models to represent key aspects of the system. You can then use these models in formalized analysis, simulation, and prototyping to study expected system behavior, and you can use these models to communicate the performance and appearance of your system when you write documents or summaries.

Ø Domain Modeling

Domain modeling refers to the process of creating a corresponding model of a problem domain and dividing it into several cohesive groups. You can then capture business processes, rules, and data in an abstract model.

The domain model is a tool for understanding problem domains. It is important that you understand this domain from a point of view outside the information system.

Ø use case modeling

The use case model describes the main interactions between the various actors (people and other systems) and the systems to be analyzed. Use cases should explain how the system supports business processes in domain and business process models.

The use case model should put the system into context, display the boundaries between the system and the external actors, and describe the key interactions between the system and the participants. Use case modeling can describe the system behavior seen by stakeholders (for example, users and maintenance personnel).

Ø Component and Service modeling

The component model assigns requirements and responsibilities to the hierarchy of subsystems, modules, and components. Each element acts as a self-contained unit for development, deployment, and execution purposes. The elements of the component model are defined by the interfaces they provide and use. Here, the interior details are not considered.

The service model defines an application as a set of abstract service interfaces between the external boundaries (use cases), the schema layer, and provides a common application and infrastructure (security, logging, configuration, and so on). This set of services that support application requirements can match existing internal and external provided interface specifications. The resulting analysis can determine the preset strategy and divide the project activity into specific types of parts, depending on whether a given service already exists (internal or external, and each of these services has the appropriate activity), exists but needs to be modified (define a new interface and plan its implementation), Or you must build a new service.

Ø Performance Modeling

Performance can be measured in a variety of ways, and the most obvious way is for the application to perform its mission-critical operations. However, as an architect, you must consider several other aspects of the performance modeling process:

What is the speed at which applications are built and deployed?

L How much does it cost to build, maintain, and run?

• To what extent does the application meet its needs?

How much does it cost to the person who must use the application?

How will the application affect other applications and infrastructure?

"description" Requirements modeling is a profound knowledge, when doing this project, the requirement modeling basically only uses the "Use case modelling", carries on the use case modelling to some typical process. Domain modeling, component and service modeling, and performance modeling are basically blank states and hopefully improved in the next project.

3.2.3 Formation of the requirements specification

Generate a precise formal description of the requirements model artifacts as a compact between the user and the developer.

3.2.4 Requirements Verification

The correctness and feasibility of the requirements specification are analyzed by means of symbol execution, simulation, or rapid prototyping, with the requirement specification as input.

3.2.5 Demand Management

Support system requirements evolution, such as demand changes and traceability issues.

In order to update the requirements specification and related documentation in the case of changes in requirements, it is important to know that a correct document is a reference to the different stages of the software system, but a document that does not synchronize updates is disruptive to the software system, and the person concerned will be led incorrectly.

4. Reference documents

1, "The role of demand analysis and how to carry out demand analysis" (Zhang Yusheng):

Http://www.educity.cn/se/requirement/200903310923051492.htm

2, "Software life cycle _ Baidu Encyclopedia": http://baike.baidu.com/view/3110371.htm

3, "The software project needs analysis difficult reason":

Http://developer.51cto.com/art/200512/15979.htm

4. "Demand Modeling": http://blog.csdn.net/weishaofei/article/details/4371584

5, "Software Requirements Acquisition Method": http://blog.sina.com.cn/s/blog_646b84760100s645.html

6, "System Domain Modeling Technology":

Http://wenku.baidu.com/view/8423fb97dd88d0d233d46ace.html

Design path: How to perform software requirements analysis?