Eight notes on software requirements Design Review

First, pay attention to the correctness of the Requirements Specification review

The correctness of requirements specifications can often be reflected in the following aspects:

Are there conflicting or overlapping needs with other requirements? Usually a hundreds of-page requirement specification will not be done overnight, and it may be a few nights of system analyst effort. It is precisely because of the continuity of the writing process that may result in inconsistent definitions of terminology in the same document, overlapping or differences in perspective, which requires us to first develop a unified concept of ideas before writing the report, which will allow the glossary to run through the entire document to sketchy.

Do you express each requirement clearly, concisely, and without ambiguity? "Clear" is to enable people to read, "Concise" is to let people willing to read, "No ambiguity" decision "read" effect, is to let the understanding of the requirements description can be agreed. Demand statement is "triple door", these three door whether open determines the requirements of the quality of specifications. In particular, we reject the emergence of the term "ambiguity", a plausible conceptual definition that should be avoided by the demand book. In other words, if a demand specification fails to give a clear, concise, and unambiguous exposition, the demand review is not necessary and cannot proceed. The prerequisite for the requirements review is that the user understands the requirements, and the user understands the content that the analyst describes.

Does each requirement pass the demo, test, review, and analysis is validated? The requirements should be testable and usually tested to verify that it is correct. For example, we completed the "Sales Customer commission royalty rule" requirements of the writing, if the demand book failed to pass the prototype test, then the requirements review can not be passed. In the face of rather complex business needs, testing or demonstrating is a necessary process for users to trust. Imagine, if even the demand can not be well recognized, the development of the implementation phase is not grasp control.

Is every requirement within the scope of the project? Dividing the scope of the project and differentiating the system boundaries is also a task of the requirements manual, do not make the requirements of the book beyond the scope of the exposition and extension, to know that the demand book is not an analyst showing off the concept, show the fashion place, it is an important link in software engineering.

Are there no content and grammatical errors in every requirement? According to the traditional demand list, requirements are listed as menus, and the main fields that make up the requirement items include: Requirement ID, requirement description, priority, source, and status. Typically, the requirements go through a "spell check" to ensure there are no spelling problems, and then you can modify the needs of the content or the wording by line-by-row browsing.

Is it possible to achieve all of the requirements within existing resources? Requirements specifications to consider the feasibility of the issue. In fact, the focus of analysts is on value-driven and cost-driven aspects. Analysts should understand that not all requirements are to be met, and that some of the thankless needs that seem obvious to conflict with users should be decisively discarded. There are experts in the country, the need to talk about "harmony" that is the reason.

are each specific error messages unique and meaningful? Do not overlook the definition of an error message, it must be unique. If you define an error message too loosely, it is the same as if it is not defined.

Second, pay attention to the requirements of the specification of the Practice of evaluation

Practicality refers to whether the demand itself originates from the relevant business rules and file systems of the current enterprise, rather than from the empirical conjecture of analysts. Practicality is to judge whether the requirement specification is a key indicator of theoretical connection practice, close and user contact. If the requirements specification and user practices are detached, even if it appears to be written more hype, it will make the requirements as a tree, source, will greatly reduce the user's trust in the requirements report itself.

Experienced systems analysts often believe in their own experience and graft the previous experience into the current enterprise requirements analysis. Perhaps because the industry is the same nature, but if not through the current practice and research to give demand, still can not reflect the characteristics of the enterprise itself. Therefore can not bring real value for the enterprise, also can cause the gap with the user demand.

I also once "light practice to abstract", I think the system analyst's job is to stand on the specific case of the depth of abstraction, the premise is that the enterprise must obtain a specific business background, processes and rules.

When we analyze systems such as "task tracking", because the abstract model of the system is known (through the analysis of a large number of similar software), it is still necessary for the analyst to deduce the abstract model to the current business situation of the enterprise. Such demand analysis will be "honest" effect, can trigger the resonance of reviewers. Otherwise, it is difficult for reviewers to read your intentions in the requirements review,

Nature will not immediately pass your requirements report, resulting in the need to rework the write requirement report.

Third, pay attention to the requirements of the integrity of specifications to review

We often review the list of issues below to see if the requirement specification is "complete".

1 are all requirements prepared in a consistent and appropriate level of detail?

2 does the requirement provide a sufficient basis for the design?

3 are all internal references to other requirements correct?

Does 4 include the implementation priority for each requirement?

Does 5 define the intrinsic algorithm for the function description?

6 Does it include all known customer requirements or system requirements?

7 have you omitted the necessary information? If there are omissions, mark them as questions to be identified (TBD)?

8 Do you document the system behavior that results from all expected error conditions?

The completeness of the requirement specification is mainly reflected in the detailed level of the requirement specification, how do we judge the description of the requirement in detail? I think that needs to be refined, not just to put forward the refinement function, the object to consider stakeholder participants, what to do, what data information, what business rules and constraints, what the system will respond to, and so on.