Requirements Review

Perform a technical review of the Requirements Document for the product of Components 2 of the indicated group, and submit your Requirements Review Report.

A review is intended to detect deficiencies and risks as early as possible. It does not concern the actual diagnosis and elimination of problems. It focuses on the artifact, not its creators; it is certainly not the goal to find out who can be blamed.

In this assignment, you do a limited review only.

Process

The review is carried out by 3 to 5 persons (larger groups need to be split; a group of 2 is possible, but less desirable). The review process follows these steps:

Distribution: Each reviewer receives a copy of the artifact to be reviewed. The reviewing group allocates a subset (possibly the entire set) of the review checklist items (see below) to each reviewer. This allocation is written down in the review report. Each checklist item should be covered by at least one reviewer, and preferably by at least 2.
Preparation: The reviewers individually inspect the artifact on the basis of the pre-agreed checklist. They write down their observations, keeping in mind the details that are needed for the review report.
Meeting: All reviewers meet face-to-face to discuss and consolidate their findings. At the beginning, they designate a moderator and a recorder. Maximum duration of the meeting is 2 hours. The creators of the artifact-under-review are not present. In this meeting, the contents of the review report are determined.
Reporting: As output of the review, a review report is delivered. See below for requirements on the form and content of the report.

Review Focus

It is specifically not the intention that this review concerns language and layout mistakes. (The authors naturally should see to it that language and layout are fine, but the evaluation of these aspects is done by the teachers, not the reviewers.)

The checklist below contain a number of critical questions. Some of these questions are more related to form (e.g. w.r.t. identifiers), others more to content. It is recommended that each reviewer handles some questions of both kinds.

The severity of a deficiency or risk is assessed at one of two levels:

Major: May lead to failure of the product, or to some other observable deviation from the specification.
Minor: Not `major'.

Requirements Review Checklist

Does the (software) product have a succinct name, and a clearly described purpose?
Are the characteristics of users and of typical usage mentioned? (No user categories missing.)
Are all external interfaces of the software explicitly mentioned? (No interfaces missing.)
Does each specific requirement have a unique identifier?
Is each requirement atomic and simply formulated? (Typically a single sentence. Composite requirements must be split.)
Are requirements organized into coherent groups? (If necessary, hierarchical; not more than about ten per group.)
Is each requirement prioritized? (Is the meaning of the priority levels clear?)
Are all unstable requirements marked as such? (TBC=`To Be Confirmed', TBD=`To Be Defined')
Is each requirement verifiable (in a provisional acceptance test)? (Measurable: where possible, quantify; capacity, performance, accuracy)
Are the requirements consistent? (Non-conflicting.)
Are the requirements sufficiently precise and unambiguous? (Which interfaces are involved, who has the initiative, who supplies what data no passive voice.)
Are the requirements complete? Can everything not explicitly constrained indeed be viewed as developer freedom? Is a product that satisfies every requirement indeed acceptable? (No requirements missing.)
Are the requirements understandable to those who will need to work with them later?
Are the requirements realizable within budget?
Do the requirements express actual customer needs (in the language of the problem domain), rather than solutions (in developer jargon)?

Requirements Review Report

The Requirements Review Report includes the following:

Title and version of the reviewed artifact
The names of the reviewers and their allocated checklist items
The date/begin-time/end-time of the meeting, the names of those present, role allocation (moderator, recorder)
The following metrics:
1. The number of user categories and the number of external interfaces of the product.
2. The total number of (elementary, identified) specific requirements, also split by capability (functional) requirements and constraint (extra-functional) requirements. If applicable, count systeem requirements, that do not concern the software, separately.
3. The number of priority levels, and for each level the number of requirements on that level.
4. The number of requirements that have been marked as unstable/incomplete/to-be-confirmed/to-be-defined by the authors of the requirements document.

An overview of all detected deficiencies and risks

For each detected deficiency/risk:
1. a sequence number (possibly grouped by checklist item)
2. precise identification within artifact (e.g. requirement identifier, or page/line number; in case of unnumbered pages, number them from 1),
3. the actual finding (this could also be a question about something that is not clear)
4. the severity (minor versus major).
Group the findings in a section per checklist item.
Start the section (if possible) with a motivated answer to the question(s) in the checklist, even if no deficiencies were detected.
E.g., for item 4 of the Requirements Review Checklist, you can support the answer 'Yes', by explaining how specific requirements are identified.

Optional further remarks/findings (with sequence number)

Total number of findings, also split by minor versus major

See also the general guidelines for details on the file format.