3.4.1.1 Requirements Review
As described by (Saqi, 2008), requirements review represents a techniques where a group of people comes together to validate requirements. The formal process includes readers from both client and developer sides and helps them to resolve problems at the early stages of SDLC. Shown below are the steps that will be undertaken during the review of the requirements that have been specified.
For the actual review itself, there will be five focus groups to go through in order to review the requirements that have been specified. These groups are; The owners Sue and Tom, experienced drivers who have worked with the company for a period of at least 1 year, experienced telephone operators who have also worked for the same period of time, customers who frequently order from the company and lastly the staff from restaurants who handle the orders sent by the company to them. The relevant requirements will be presented to them and reviewed for verifiability, comprehensibility, traceability and adaptability.
3.4.2 Requirements Inspection and Checklist
3.4.2.1 Inspection
According to (T.Y. Chen, 2006), formal inspection was made an integral part of the development process thanks to Michael E Fagan of IBM. Based on his designs, inspections are conducted as team activities, which aims to have one or more reviewers formally inspect the items, which is typically done in a meeting after individual preparations. Normally, members of the inspection team will include the producer of the item to be inspected as well as a moderator to facilitate the inspection process.
For this project, the authors of this documentation which is Alexander and Enson, along with the owners and a selected group of staff will be gathered together to inspect the requirements based on several methods.
3.4.2.2 Entry criteria
Before the inspection can begin, the requirements must satisfy the following prerequisites:
The document conforms to the standard template.
The document has been spell-checked.
The author has visually examined the document for any layout errors.
Any predecessor or reference documents that the inspectors will require to examine the document are available.
Line numbers are printed on the document to facilitate referring to specific locations during the inspection meeting.
All open issues are marked as TBD (to be determined).
The moderator didn't find more than three major defects in a ten-minute examination of a representative sample of the document.
3.4.2.3 Inspection Stages
An inspection is a multistep process, as illustrated below. The purpose of each inspection process stage is summarized briefly in the rest of this section.
3.4.2.4 Planning
The authors of this document will plan the inspection together. The participants deemed to be suitable for the inspections have been narrowed down to the owners and experienced staff who are familiar with the company’s operations. A total of 5 inspection meetings will be held to cover the amount of material which consists of 26 requirements. Two hours is determined as the most suitable amount of time to assess the requirements for defects.
3.4.2.5 Overview meeting
During the meeting, the background of the material will be explained to the inspecting team along with any assumptions that has been made and stated in the project documentation.
During later meetings, this stage will be omitted as the team will have already been familiar with them.
3.4.2.6 Preparation
Prior to the meeting, each inspector will examine the requirements and highlight any issues or defects by using a checklist which is described below.
Do requirements exhibit a clear distinction between functions and data?
Do requirements define all the information to be displayed to users?
Do requirements address system and user response to error conditions?
Is each requirement stated clearly, concisely and unambiguously?
Is each requirement testable?
Are there ambiguous or implied requirements?
Are there conflicting requirements?
Are there areas not addressed in the SRS that need to be?
Are performance requirements (Such as response time, data storage requirements) stated?
If the requirements involve complex decision chains, are they expressed in a form that facilitates comprehension (i.e. decision tables, decision trees, etc.)?
Have requirements for performing software upgrades been specified?
Are there requirements that contain an unnecessary level of design detail?
Have the real-time constraints been specified in sufficient detail?
Has the precision and accuracy of calculations been specified?
Is it possible to develop a thorough set of tests based on the information contained in the SRS? If not, what information is missing?
Have Assumptions and Dependencies been clearly stated?
Does the document contain all the information called out in the outline for the SRS?
3.4.2.7 Inspection meeting
In this stage, a reader will be appointed to read to other inspectors in the team to describe the requirements in their own words. As defects and issues are brought up, they are noted down by an inspector who will be assigned the role of a recorder. At the end of this stage, the team will decide whether to accept the requirements as a whole, or indicate that minor or major changes will be needed to the requirements themselves.
3.4.2.8 Follow-up
In this final stage, the moderator will work with the authors to try and ensure all open issues are resolves and errors have been corrected properly to bring closure to the inspection process.
3.4.2.9 Exit Criteria
After all the stages of the inspection have been completed, the moderator then determines whether the inspection is formally complete based on the following criteria:
All issues raised during the inspection have been addressed.
Any changes made in the document and related work products were made correctly.
The revised document has been spell-checked.
All TBDs have been resolved, or each TBD's resolution process, target date, and owner has been documented.
The document has been checked into the project's configuration management system.