The typical situation refers to the common situation of software development, this article chooses the following to analyze:
1. Requirements review under the development of traditional waterfall models
2. Requirements review using IEEE Std. 1028
3. Requirements review under Agile development
The traditional waterfall model has a critical requirement milestone review at the end of the demand phase, which is characterized in section 2.8, Case 1. In the actual operation of the industry, the following situations are often seen:
1, the convening of representatives, including leaders, after 1-2 hours of meetings, review more than 30 pages of demand specifications, the parties signed through the review;
2, the parties to the demand specifications have a variety of views, after 3~n times, see the schedule has been significantly delayed, follow-up development has been followed up, even the development of the completion, and finally get through;
3, through the multi-logistics coordination, before and after time-consuming 4 weeks, called the parties to a resort, after three days to discuss the revision of the review, finally passed the review.
The above situation reflects the former "bureaucratic cumbersome, red tape", the shortcomings of the obvious. In [26] the same is also recognized: Demand review is often a mere formality.
Subject to CMM/CMMI requirements and inspiration, in order for the final milestone review of the demand phase to pass smoothly, the requirement peer review was used [12][13]. Common scenarios include the following:
1, when the requirements are finalized, planning a peer review meeting, focusing on technical aspects, the formation of peer review findings and records. This is a great help in winning through milestone reviews, but often more to cope with cmm/cmmi assessments;
2, the phased arrangement of multiple meetings or non-immediate needs peer review, attention to technical aspects, records review found and resolved. This is Cmm/cmmi more recommended practice, can greatly alleviate the waterfall-type demand stage milestone review of the shortcomings.
The above analysis, in order to facilitate the overall understanding, the following table.
Table 8 Requirements review under Waterfall model
| Standard Review | Requirements Review Framework Analysis Description |
|---|---|
| Requirements Milestone Review | Pre-trial meeting format, milestones, technical and managerial aspects, non-peer requirements document review |
| Requirement finalization Peer review | Have pre-trial meeting form, completion, technical aspects, peer requirements document review |
| Segment Requirement Peer review | Pre-trial meeting form, segmentation, technical aspects, peer requirements document review |
Revelation 1: It is worth carrying on regular two-person instant reviews, each time about 15-30 minutes, suitable for the location of the team companion sitting together. Benefits: Communicate early and learn from each other.
Revelation 2: It is worthwhile to separate the technical aspects of the review and management aspects, first of all types of technical aspects of the review, and then convene a milestone management review. Benefits: After the technical review problem is resolved, the requirements Phase Milestone review focuses on management aspects, such as demand size, schedule, workload, etc., more concerned about the overall success of the project, but also can greatly save the meeting time.
In contrast to the requirements review, the management review, technical review, review, and walk-through in IEEE STD. 1028 can be applied to requirements reviews, which do not fall within the scope of the requirements review discussed in this article.
Management reviewIEEE STD. 1028 Description Management review (Management reviews) is used to monitor progress, to determine the status of plans and schedules, or to assess the effectiveness of management methods in order to achieve the appropriate objectives; Management reviews support decisions about corrective actions, resource allocation changes, or project scope changes Management reviews identify and plan for consistency and variance, or identify the degree of integrity and inadequacy of the management process. In the practice of requirements management Review, the most focused question is whether the scope and scale of requirements match the plan. Some organizations make plans before they are needed, so whether the actual results of demand need to be rescheduled, and some organizations that plan the overall planning of the project after the requirements, then need to determine how the progress of the previous, and how to plan the impact of the later.
The management review has detailed specifications, from roles, pre-meetings, meeting, post, to input and output, etc. It is not illusory to be the type of review first elaborated by the IEEE std.1028, although it has a heavy and cumbersome suspicion, but for prudent multi-stakeholder situations, it is still the preferred or even required type of review for critical milestone reviews. In this five-dimensional requirement review framework, the management review, in most cases, is a non-peer requirement document review of the management aspects of pre-qualified meeting-type milestones, providing the most systematic "pole" of management review.
The purpose of a technical review is for a team of qualified personnel to evaluate a software product to determine suitability for its intended use and to identify discrepancies compared to specifications and standards. It provides management with evidence that confirms the technical status of the project, and may also offer alternative proposals that may require more than one meeting.
As with the management review, technical reviews are detailed and standardized. Technical review is the most well-known type of review, as early as 1996 published in the "Practical Software Engineering" (2nd edition) [9] This is also described in detail. In practice, technical review often serves as a milestone review, and as for management review, its focus is a small part of the technical review, and there is no longer a dedicated management review. In the framework of this five-dimensional requirement review, the technical review, in most cases, is a non-peer requirement document review of technical aspects of a pre-qualified meeting form milestone, providing the most systematic "pole" of technical review.
Revelation 3: Understanding the position of management review and technical review in the five-dimensional requirements review framework, applying these two reviews flexibly in practical work, and tailoring the adaptability to it more confidently, so as to make it play more efficiently and avoid the heavy and tedious malpractice of being criticized.
The review corresponds to the English language inspection, which is designed to detect and identify anomalies in software products. Review is a systematic peer check. The review defines 5 roles, namely review leaders, recorders, readers, authors, examiners. Any member of the review team (including the above 5 roles) is not allowed to participate in the review activities. The review should be planned and documented in the appropriate project plan documentation, before the review begins to confirm that the product being reviewed is complete and meets the format requirements, and that the review will require a record of the size of the review product, pre-meeting time, rework time, etc.
Reviews: The review has been rigorously defined in IEEE Std. 1028 and gives detailed guidance on the specification. In this five-dimensional requirement review framework, the review is a peer review of pre-qualified conference form completion techniques, which is also the most systematic "pole" of peer review. The review requires a complete product and does not identify problems as early as possible.
Revelation 4: It is worth exploring and using lighter-weight, more efficient and more timely peer reviews.
Systematic walk-through is intended to evaluate a software product. Walk-through may also have the purpose of making the training Software PRODUCT audience. The role of walk-through is also the exchange of technology, exchange of different styles of change. Walk-through can not only detect anomalies, but also point out deficiencies (such as the efficiency and readability of software products, the modularity of design or code, or the inability to verify specifications). Participate in the follow-up there are 4 roles, is to walk the team leader, the recorder, the author, walk the member, walk check at least 2 people. Any administrative superiors who are members of the walk-in group are not allowed to take part in the investigation. The most important activity of walk-through is the author or the team leader to show each part of the product of the review, walk the group to identify and put forward the found anomalies and problems. The Standard minimum output of the walk-through is 9 items in total. Walk-through does not require the product has been completed, can be carried out on demand high frequency.
In this five-dimensional requirement review framework, the review is a regular or high-frequency peer-reviewed document that belongs to the pre-trial two-person immediate or meeting form, technical aspects. Double walking is the minimum number of people allowed in the standard. Double walking and meeting the form of walking check in fact there is a big difference: Double walk can use a common display, the use of ordinary can sit down the work of two people, so that can be high-frequency on-demand, conference format often need conference room, and conference room in most organizations is scarce resources, If all project teams carry out requirements and code meeting walks, then every two-week conference room reservation may not be guaranteed, so it is difficult to carry out on demand. Code walk-through is a commonly heard word, but the need to walk in the Chinese world is rarely mentioned, and in Agile software development has shown its effectiveness.
Revelation 5: It is worth exploring and using double high frequency on demand to walk or simplify the needs of the investigation.
The above analysis, in order to facilitate the overall understanding, the following table.
Table 9 Requirements Review of IEEE standards
| Standard Review | Requirements Review Framework Analysis Description |
|---|---|
| Management review | Pre-trial meeting format, milestones, management, non-peer requirements document review |
| Technical review | Review of pre-trial meeting forms, milestones, technical aspects, non-peer requirements documentation |
| Review | Have pre-trial meeting form, completion, technical aspects, peer requirements document review |
| Check it out. | Pre-trial double or conference, regular or high-frequency, technical, peer-level requirements document review |
First of all, in the context of agile development, almost no use of the word "review", commonly used "verification", "acceptance", "feedback" and so on. In this paper, based on the document reading or observation software operation of the timeliness of manual inspection work is defined as a review, the agile practice in line with this definition is considered a review. The following is an analysis of the typical requirements review practice in agile. Since scrum is currently the most adopted agile genre, several practices from scrum have been chosen to analyze and take into account other agile genres.
Optimization of Product Backlog listIn scrum, the product owner (English: Products owner, abbreviated PO) is the only person responsible for managing the product backlog [28]. Although in theory the product owner can create a single person to maintain the entire contents of the product backlog, but in most cases the product owner is to absorb the contributions of others, the product owner then to organize sorting adjustment optimization and so on [21]. Product to-do list optimization in scrum (the English name in Scrum Guide version 2011 in Grooming,scrum Guide2013) refers to the addition of details, estimates, and sorting for list items. This is an ongoing process in which the product owner and the development team collaborate to discuss the details of the product backlog and review and modify the list items. This is the five-dimensional requirement review framework, which is a review of the technical aspects of the peer requirements document for the regular meeting. Because this process even if the product owner is the executive of the team, but also the main author of the review object, rather than the reviewers.
General, product Backlog the results of thinning are used for future iterations (known as sprints in scrum), which serve as a technical aspect of the requirements phase of the waterfall model, but it is intriguing that the scrum guide says that "granular work typically takes up less than 10% of the development team's time." However, the product owner can update the product backlog list at any time according to his or her own judgment. , and for a traditional waterfall model with only one-to-two needs review, the proportion of review meetings for demand discussions is probably not more than 5%.
The question in the first part of the planned meeting in scrum is: What will be included in the incremental delivery of the next sprint (equivalent to iteration)? The development team anticipates the features to be developed in this sprint. The product owner explains the goals of the sprint and the product backlog items that need to be completed to achieve the goal. The entire Scrum team discusses the work of the sprint in order to better understand it. In contrast to the new requirements review framework, this is a peer-to-peer review of the regular meeting focus on management-level requirements, as well as the refinement of the above-backlog list.
Responsible for the needs of the product owner and the team to communicate, listen to deal with a variety of suggestions, in the management review is the object of the review, this is indeed a breakthrough in traditional practices, and the popularity of scrum also illustrates the effectiveness of this new approach. In contrast to the waterfall model, the first part of the planning session in scrum serves as a milestone management review of the requirements phase of the waterfall model. It is worth noting that in the 1-month iteration of the scrum proposal, the first part of the scheduled meeting takes about 4 hours, accounting for about 2.3%, and the entire scheduled meeting takes 8 hours.
The Daily Scrum station is limited to 15 minutes of events, where development team members share their work and plan for the next 24 hours. [28] This requires reviewing the work of the previous daily station and predicting the work to be done before the next daily stop. In general, the scrum team draws a sprint Burndown chart every day, drawing the remainder of the sprint's work in the sprint each day, and this effort is predicted based on user stories or use cases, and user stories and use cases are forms of demand expression. So this is also equivalent to the requirements management review, specific to the new five-dimensional requirements review framework, which is the conference form of high-frequency management of peer requirements document review.
Clarification and confirmation of requirements in the agile development processIn an agile development environment, where there is no requirement to have a complete and detailed requirement specification at the beginning, it is necessary to clarify and confirm requirements such as on-site customers or customer representatives during the development process. This is the practice common to all agile schools. Agile methods encourage face-to-face communication, so the clarification and confirmation of requirements during development is often a form of demand review, in contrast to the new requirements review Framework, which is peer-reviewed for dual-pair real-time high-frequency technology, and is no longer based solely on requirements documentation, It is also possible to determine whether a requirement is satisfied based on the operation of the software, although it may not be fully operational, but can be partially run to show the interface or interface. In scrum, the product owner is responsible for responding to such reviews (clarifying explanations and modifying supplements as needed), in the process, even if the product owner is the executive superior of the team member, and participates as a sibling.
This is also one of the most efficient requirements review types, the most efficient characteristics of the exchange feedback fast, small particle size, strong pertinence, and even can be combined with semi-finished or finished products to check.
Revelation 6: Demand analysts and developers deserve to be in the process of development, in combination with semi-finished or finished products for the needs of the table, can sooner and faster to avoid the defects caused by the need to understand deviations.
Iterative presentation is a common practice in each agile genre, and it is often the practice to show the outcomes of iterations to stakeholders at the end of the iteration, or even directly to the user for trial or use. Scrum has a clear definition of this link, which is its sprint (equivalent to iteration) Review meeting: The Sprint Review Meeting is held at the end of the sprint to view the delivered product increments and to adjust the product backlog on demand; During a sprint review meeting, the Scrum team and stakeholders discuss the work done in the sprint; [28] based on the completion and the changes in the Product backlog list during the sprint, discuss with the attendees what might be done next to optimize the value. It is worth noting that for a typical one-month sprint, the time box for the Sprint review meeting is 4 hours. [21] The Sprint review meeting can be counted as a requirement review and an evolutionary prototype for the customer. Compared to the new five-dimensional requirements review framework, this is a non-pre-qualified meeting format, a regular, management-focused and technical-oriented, software-based peer review.
Such a review is also one of the most efficient requirements assessment types, its high-efficiency features need to be displayed in an intuitive way, customer or customer representatives to participate in the spot to collect feedback, on the spot according to feedback to plan for the future.
Revelation 7: Let the customer or the customer representative periodically unifies the software to carry on the review, more intuitively can discover the improvement, can make the customer more satisfied.
The above analysis, in order to facilitate the overall understanding, the following table.
Table 10 Practice of common requirements review under agile development
| Agile Requirements Review related practices | requirements Review Framework Analysis Description |
|---|---|
| Scrum Middle Product to-do list refinement | non-pre-qualified meetings, periodic, technical, peer-reviewed |
| Scrum Planning meeting Part I | non-pre-trial meetings, regular milestones, management aspects, peers Requirements Document Review |
| scrum daily station and Burndown chart drawing | non-pre-trial meetings, daily high frequency, management, peer requirements document review |
| Agile Development In demand clarification and refinement | double, on-demand high frequency, technology, peer review, software-based operation |
| Iteration Show | non-pre-trial meetings, regular, technical and managerial aspects both, non-peer review, base Run |
It can be seen that agile software development of the common needs of the review did not adopt any kind of standard review, at most can be said to review and follow-up for reference.
Revelation 8: For more efficient and high-quality development software, dare to break through the original Requirements review standards and authoritative guidance, dare to seek more efficient needs assessment methods.
Revelation 9: According to Revelation 8, combined with this new five-dimensional requirements review framework, it is a recommended new way to review periodic requirements documents or software run management reviews. In particular, managers are required to review the status, progress, difficulties, and risks associated with the developer on a per-day or weekly or biweekly basis, using a mentoring system, a master programmer [29], a one-to-one meeting, and so on.
Revelation 10: According to Revelation 8, combined with this new five-dimensional requirements review framework, non-immediate on-demand high-frequency requirements Document technology peer review is also a recommended new review method. In combination with the Requirement Entry management tool, peer review can be achieved on a per-demand basis. A more detailed analysis is provided in chapter 4th below.
Revelation 11: According to Revelation 8, to break through this five-dimensional requirements review framework, it is worth looking for other more efficient and more humane needs assessment methods, such as the game practices, points upgrade, etc. into the review.
Revelation 12:scrum The application of management review is focused on the current and next iterations, missing the attention of the whole longer process. While there have been additions to the release plan and release Burndown charts in scrum, there is no clear definition of how to review or validate, so it is worthwhile to conduct regular management review meetings that focus on the development of the overall product over a longer timeframe.
Requirements Review Five dimension framework analysis and its enlightenment--typical needs review
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
