Software Requirement specification of software project requirement development process Practice

Who is the software requirement specification written for? It is very meaningful to make the problem clear.

Tell me a story first.

At the beginning of the software project, the requirements and architecture designers spoke to the developers about the requirements and architecture, and the developers were still designing "his car". Requirements and architecture designers then, after writing some of the column documents, the developers are still designing a little bit to adjust the "his car", communication problems have arisen? After the project was completed, the final result was the "his car", which the developer had designed, which had been deformed.

The source of the problem, of course, is in demand, and how can the demand and research results be shared with the "relevant people" without prejudice? Other reasons, such as project team learning, are not analyzed in this article.

First, we review the requirements classification and requirements hierarchy in software engineering.

Classification of requirements

• Software requirements are what the system must accomplish, and the qualities it must have. Specifically, the requirements of the software include functional requirements, non-functional requirements and design constraints three aspects of the content;
• Business requirement is to reflect the organization or customer to the system, product high-level goal requirements, usually the problem definition itself is the business requirements;
• User demand is to describe what the user needs to complete the task of using the product, how to complete the requirements, usually on the basis of the problem definition of user interviews, surveys, the user's use of the scene to organize, and then set up from the user perspective of the needs;
• The system requirement is to explain the requirements of the software from the role of the system, which includes the functional requirements, quality attributes and other non-functional requirements, as well as design constraints.

Level of demand

Requirements include three different tiers: business requirements, user requirements, and functional requirements, as well as non-functional requirements.

In demand research, demand analysis, the preparation of demand specifications, the above requirements classification and level should be involved, otherwise, will be missing, so that people can not understand the overall. As shown in table 1, "Business process Requirements", the user hierarchy and roles are at least 8 levels, and their needs and perspectives are different.

Table 1

In the demand survey, table 1, it is difficult to interview the leadership, the other layers are difficult to cover, and the written requirements of the specification, these people are not seen, or can not be seen, is the project team of developers also rarely read. In this way, the demand story of the software industry continues to unfold.

Figure 1

How to solve these problems?

First, the requirement specification must be written, and the relevant user level can be written to see their own content, meet the existing business needs, and higher than the existing business, that is, the business modeling. Only in this way will changes in demand revert to their original appearance, rather than understanding the changes that have arisen from deviations.

The following list is the early written requirements directory content interception, demand content is very much. For example: The user has many to build the process, if one by one to write to the document, first not to say the work of writing, who still look!

After adjusting the thinking, the Requirement Specification catalogue has changed greatly, not the pattern description requirement of the past points and polygons, but the three-dimensional model to describe the requirements and requirements modeling. Demand modeling requires a lot of developer capabilities, such as experts in the business or management of the program.

Demand analysis really needs a lot of experience with domain experts. What about business management? Do you need a business boss? Who is the expert in enterprise management? Who can point out the process ability, execution, efficiency, effectiveness ... Therefore, it is necessary to follow the process from various perspectives, and to embody these, it needs to be written in the requirement specification.

The software Requirements Specification Reference template is shown in the following table.

In short, the software needs only in accordance with the user needs of the literal interpretation of the way to understand and develop, which will be a nightmare is just beginning. The real need is to pseudo-truth, the real demand is not by ordinary users (business interface person) can provide all, level enough, coverage is not enough, really originates from the business domain knowledge, national policy and Regulation, enterprise rules and regulations, as well as the society and its information development direction. The content is reflected in the requirements of the specification, it is convenient for each layer of leadership to read, but also provide common staff and developers of the level of understanding. Through the sub-requirements manual, developers know and understand what to do, reduce, it is best to prevent "1000 people in the heart of 1000 Hamlet" situation occurs.

Project experience sharing, limited energy, inevitably wrong, for reference only, welcome to discuss, and then complement the perfect.

Software Requirement specification of software project requirement development process Practice