Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is the requirement review of Android software testing". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the requirement review of Android software testing".

Demand review

1. Roles and responsibilities of requirements phase review

In a word, choose the relevant personnel according to the specific situation, play the relevant roles and perform the relevant duties, and don't complain about me, the reality is like this, don't remember these dead rules.

2. The characteristics of good demand

Integrity: each requirement must clearly describe all the functions to be implemented so that the developer has all the necessary information to design and implement these functions.

Correctness: each requirement must accurately state the functionality it wants to develop.

Consistency: does not contradict other software requirements or high-level requirements

Feasibility: each requirement must be enforceable by the capabilities and limitations of the system and environment.

Unambiguity: there can only be a clear and unified explanation for all readers of requirements. As natural language can easily lead to ambiguity, try to express each requirement in a concise and user-friendly language.

Robustness: whether possible exceptions are analyzed in the description of the requirements and fault-tolerant handling of these exceptions.

Necessity: it can be understood that each requirement is the "source" that authorizes you to write documentation, so that each requirement can be traced back to a customer's input.

Testability: each requirement can be tested by designing test cases or other verification methods.

Modifiable: each requirement should appear only once in SRS. In this way, it is easy to maintain consistency when changing. In addition, catalog list, index and cross-reference list methods are used to make the software requirements specification easier to modify.

Traceability: should be able to establish a link between each software requirement and its source and design elements, source code, and test cases, this traceability requires each requirement to be written and identified separately in a structured, f i n e-g r an i n e d manner, rather than a large narrative.

Assign priority: priority should be assigned to all requirements. If all requirements are regarded as equally important, then project managers will lose their freedom of control in developing or saving budgets or scheduling

The above characteristics are also the main points of the requirements review. Before the review, you can specify the requirements review checklist according to the actual situation to help the review.

The requirements can be reviewed according to the above characteristics.

3. Software requirements review output

In a word, make the review record appropriately according to the specific situation, the form is not limited, the name of the output document is not limited, whatever you choose, the content is the key point.

4. Principles of organizational requirements review

In a word, organize and decide for yourself, as long as it is suitable, efficiency first, don't complain, don't lie to you, if you don't believe you go to Baidu, you can come up with different answers.

5. The form of demand review

Generally speaking, it can be divided into formal review and informal review. Formal review refers to through the form of a review meeting, organize a number of experts, gather the people involved in the needs together, and define the roles and responsibilities of the reviewers, and conduct a formal meeting review of the requirements. The informal review does not have such a strict organizational form, and generally does not need to review the personnel together, but reviews the requirements through e-mail, document collection and even online chat. Each of the two forms has its own advantages and disadvantages, and these two methods should be used flexibly in the evaluation.

In detail, it can be divided into the following:

(1) Mutual review, cross-review (Pear-to-pear Review). An and B are in the same project team and in the same field, but the work contents are different. A's work results are handed over to B for review, and B's work results are handed over to A for review. Mutual review is the most informal form of review, but it is convenient and effective in application and is widely used.

(2) Pass-round, also known as distribution review method, is an asynchronous review method. The author will send the content that needs to be reviewed to the reviewers and collect their feedback. It's an informal peer review.

(3) Walkthrough, the author of the product introduces the product to a group of colleagues on the site, describes the function and structure of the product, and goes through it from beginning to end to collect everyone's opinions. It is hoped that other colleagues who participate in the review can find errors in the product and have an on-site discussion. This form is between formal and informal, and its application is common. It's an informal peer review.

(4) Group review (Group Review), which completes the review through formal group meetings, is a planned and structured form of review. The review defines the various roles and corresponding responsibilities in the review meeting, and all participants received the review material a few days before the review meeting, and conducted independent research on the material.

(5) Review (Inspection). Review is similar to group review, but more rigorous, and is the most systematic and rigorous form of review, including planning, preparing and organizing meetings, tracking and analyzing review results, and so on.

6. The strategy of requirements review

(1) hierarchical evaluation

In general, it can be divided into the following levels:

* Target requirements refer to the business goals that the whole system needs to achieve, which are the highest-level and basic requirements, and are concerned by the senior management of the enterprise. If specific operators are asked to evaluate the target requirements, it will easily lead to the phenomenon of "picking up sesame seeds and losing watermelons".

* functional requirements refer to the functions and tasks that the whole system needs to achieve, which are the second-tier requirements under the goal and are concerned by the middle managers of the enterprise.

* operational requirements refer to the specific human-computer interaction (UI) requirements for each task, which are concerned by the specific operators of the enterprise.

(2) Review by stages

Multiple reviews should be carried out in stages during the formation of requirements, rather than the only phased review after the final formation of requirements, which can split the large-scale review into small-scale reviews. in this way, the risk of rework of requirements analysis is reduced and the quality of review is improved.

This is particularly effective for agile development models. The requirements are divided into units by version, the requirements are reviewed according to the version (to determine what to do and whether to do that), the post-development is developed for the requirements of this version, and the test is written and maintained according to the requirements. then iterate according to this pattern.

7. Matters needing attention

Carefully select reviewers-> customize standardized review process-> prepare review materials-> do a good job of result tracking, etc.

About requirements Review

1, the traditional software development model, too dependent on documents, there are a variety of documents, requirements specifications, such as market requirements specification, business requirements specification, software summary specification, software detailed design documents, etc., these documents do not seem to be very effective in the pursuit of speed, but often become a burden. How to solve this problem?

Get rid of useless functional definition documents, requirements documents, feasible ways:

The idea is quickly made into a static prototype-> > modify the prototype design according to the "market effect feedback"-> build a dynamic prototype with real data-> remove the burden.

In this way, it is a good way to use the actual interface or prototype to show that you want to build a real product.

From this point, we can shift the focus from "requirements document review" to "Demo review", with prototype review as the center, supplemented by necessary documentation, as a supplement to the prototype.

2. Tripartite cooperation

In other words, the discussion of each functional requirement requires the participation of developers, testers and product personnel. Agreement must be reached before development.

3. At all kinds of review meetings, there must be someone who can make a decision, because during the review, all parties will inevitably have different understandings of the needs, resulting in arguments, fair arguments and reasonable arguments, and no one can convince each other.

Thank you for your reading, the above is the content of "what is the requirements review of Android software testing". After the study of this article, I believe you have a deeper understanding of what the requirements review of Android software testing is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.