Requirements Analysis and review

A. Classification of requirements

is to group requirements in a manageable way. Can be divided into the following:

(a) original demand (customer demand): The original requirements can be seen as the customer's needs, and the customer is not aware of software development technology, the proposed demand is no way directly for development, output document: Market demand document (requirement DOCUMENT,MRD)

(b) Product requirements: Product designers or demand analysts according to the original requirements, combined with the software can achieve the needs of the formation of the requirements, I personally understand that should be said business needs, this is to be discussed. Output Documentation: Product requirements documentation (products requirement document, PRD)

(c) Software requirements: Software developers based on the principle of software to further detailed product requirements, output documents: Software Requirements Specification (software Requirements specification), referred to as SRS

(iv) Testing requirements: Developers do not know how to test the software, can not detail the requirements to be directly used for testing, so testers also need to translate software requirements into test requirements

Customer demand, product demand (business requirements), software requirements, test requirements, can be seen as requirements from a simple to detailed process, for each requirement type to define the priority, workload and risk of demand implementation

A classic example:

Xiao Ming said, he wants to eat pork bone hotpot (customer demand), 80, but did not expect to meet the grant.

Grant: "Really want to eat?" ”

Xiao Ming: "Want to eat!" ”

Grant: "Why?" ”

Xiaoming: "I'm hungry ..." (found the Essence)

Grant: "Oh, here is two steamed bread (product demand), please eat, only 1 dollars"

......

Tip: The difference between a customer and a user

A customer is a person who pays for a product or service.

The user is the person who uses the product or service, and the product or service produces a direct interaction process.

A customer is a person or entity that forms a service request for a product or service and a business relationship. It can also be said that the purchase of products or services have the right to decision-makers, which includes technical decision-makers and business decision-makers and other series of people.

Customers are generally concerned about the price and effect, the effect of the product after the use of productivity improvement, but also implied the leadership performance improvement. Sometimes the customer neither cares about the price nor cares about the effect, he cares about his personal interests. So finding the real intention of the customer is the key to taking the order.

User focus on the product is easy to use, simple, improve efficiency, bring convenience. The product is ultimately for the user Service, even if the product is the customer pays, but the end user does not use up, then this is also a failure of the product.

Therefore, the product is recognized by the user, the use can improve work efficiency, at the same time to bring benefits to customers, this is a win situation.

B. Testing Requirements

What is the test requirements, see the name of the understanding, what to test? In short, it is the verification point in the design test case, the test basis, which includes functional testing requirements, but also includes non-functional performance testing requirements. To do the test to learn from the requirements of the specification of the test points to be tested, the use case design.

Example: Obtaining test requirements from the software Requirements specification

(for example, to get a novice to understand that writing use cases is not a direct copy of the content in the requirements specification, but rather to mine test points)

Suppose the requirements specification has the following functional requirements

Function Description:

Feature name	Quick Search
Function description	You can search by person or article, title content
Users and Roles	Registered users
Additional Information	No

Input item: Slightly

Processing flow: Slightly

Output item: Slightly

We can also dig and test the requirements for a functional description, even if it is only described:

1. Does the input support Chinese? Digital? English? Space?

2. Can I enter a longer search character?

3. Does the input support fuzzy search?

......

To determine the above problems as test requirements, they can be used as the verification point of use case design.

c. needs assessment

1 . Roles and responsibilities of the requirements Phase review

In a word, according to the specific circumstances of the selection of relevant personnel, as the relevant role, to perform related duties, we also do not spit groove me, the reality is this, do not remember these rules of death

2 . The characteristics of good demand

Completeness: Each requirement must have a clear description of all the features to be implemented so that developers have all the necessary information needed to design and implement these features.

Correctness: Each requirement must accurately state its capabilities to be developed.

Consistency: not contradictory to other software requirements or high-level requirements

Feasibility: Each requirement must be a system and environment of competence and limits can be implemented.

No ambiguity: All the needs of the reader can only have a clear and unified interpretation, because natural language is very easy to lead to two of the semantic, so as far as possible to each needs concise user-specific language expression.

Robustness: The description of the requirements provides an analysis of possible exceptions and fault-tolerant handling of these exceptions.

Necessity: It can be understood that each requirement is used to empower you to write the "root cause" of the document, so that each requirement can be traced back to the input of a customer.

Testability: Each requirement can be tested by designing test cases or other validation methods.

Modifiable: Each requirement should only appear once in the SRS. This change is easy to maintain consistency. In addition, the use of directory lists, indexes, and cross-reference list methods makes it easier to modify the software Requirements specification.

Traceability: A link chain should be established between each software requirement and its root cause and design element, source code, test case, which requires each requirement to be written in a structured, granular (f i n e-g r a i n e d) format, rather than as a large paragraph narrative.

Assign priority: All requirements should be assigned a priority level. If all requirements are considered equally important, project managers lose control of freedom in developing or saving budgets or scheduling

The above features are also the main points of the requirements review, before the review can be specified according to the actual needs of the review checklist to help review.

The requirements can be reviewed according to the above characteristics

3 . Software Requirements Review Output

Or a sentence, according to the specific circumstances appropriate review records, the form of unlimited, the output of the document name is also unlimited, whatever you take, ^^ content is the focus

4 . Organizational Requirements Review Principles

Or a sentence, organize their own, suitable for good, efficiency priority ^^, do not spit groove, do not deceive you, do not believe you Baidu, you can Baidu out of different answers

5. Requirements Review Form

In general, it can be divided into formal review and informal review. Formal review refers to the form of a review, the organization of a number of experts, the needs involved in the collection of people together, and define the role and responsibilities of the reviewer to participate in the formal meeting of the requirements of the review. The informal review does not have this kind of strict organization form, generally does not need to assemble the personnel to review together, but through the e-mail, the document remit the sign and even is the network chats and so on various forms to the request appraisal. Each of the 2 forms has pros and cons, and in the review, the flexibility to use these 2 ways.

Carefully speaking, can be divided into the following:

(1) Mutual review, cross-review (Pear-to-pear Review), A and B in a project team, in a field, but the work content is different, a work results to B review, B's work results to a review, mutual review is the most informal form of a review, but the application is convenient and effective, is commonly used

(2) round-check (Pass-round), also known as allocation Review method, is an asynchronous evaluation mode. The author sends the content of the review to the reviewers and collects their feedback. is a kind of informal peer review.

(3) Walk-through (walkthrough), the product of the author of the product in the field to a group of colleagues, describe the product to have what kind of function, structure, go through to the beginning, to collect everyone's opinion. Other colleagues who wish to participate in the review can find errors in the product and can conduct on-site discussions that form between formal and informal, and their application is common. is a kind of informal peer review

(4) Panel review (group Review), through a formal group meeting to complete the review work, is a planned and structured review form. The review defines the various roles and responsibilities in the review meeting, and all participants receive the review material and independently study the material a few days before the review meeting.

(5) Review (inspection). The review is similar to the panel review, but is more rigorous and is the most systematic and rigorous form of review, encompassing the planning, preparation and organization of meetings, tracking and analysis of the results of the review.

6. Requirements Review Strategy

(1) sub-level review

Generally, it can be divided into the following levels:

* Target demand refers to the business objectives that the whole system needs to achieve, is the highest level, the basic demand, is the enterprise's senior management personnel's concern. If the specific operators to review the target demand, it is easy to lead to "Penny Wise, lost watermelon" phenomenon.

* Functional requirement refers to the function and task that the whole system needs to realize, is the second level requirement under the target, and is the concern of the middle management of the enterprise.

* Operational requirements refers to the completion of each task of the specific human-computer interaction (ui needs, is the specific operator of the enterprise concerned.

(2) Phased Review

Should be in the process of the formation of demand in a phased review, rather than after the final formation of the requirements of the only one review of the phased review can be carried out by the large-scale review of small-scale review, which reduces the need to analyze the risk of rework, improve the quality of the review.

This is especially effective for agile development models. Requirements are divided by version, according to the version of the requirements review (determine what to do, is not done), through the development of the requirements for this version of the development, testing according to the requirements of use case writing and maintenance, and then in this mode of iteration.

7. Precautions

Carefully selected reviewers, customized normalization review process, ready for review materials, good results tracking work, etc.

Requirements Analysis and review