- to review and give feedback on the requirements before they were implemented.
A suggested approach is:
- Create a good checklist to use for reviewing requirements for completeness.
- Have business analysts, designers, and developers use requirements checklists throughout the project to help prevent requirements issues.
- Involve testers and end-users in reviews of requirements and designs throughout the project. Although this takes time, it prevents multiplication of errors by catching them before they are developed and also builds test team members' knowledge of the system, making them effective when they need to start building test cases--not playing catch-up and asking basic questions about the requirements at that stage.
- Add system specifics to the requirements-content-review checklists as they become known (e.g., specifics of overnight processing, your functionality), so they can be used in maintenance and regression testing for future versions.
Curing Requirements Issues
What should you do if you're in a situation where you've already got requirements issues? Suggested steps are:
- Use a requirements content checklist to identify requirements issues as soon as you get the requirements. It takes time and effort to do this, but repays later.
- Raise defects or queries (whatever your project process is) against the issues as soon as possible.
- Collect specific examples of the issues you have and metrics on the effort involved in resolving them.
- Try to predict the impact of the issues on the project timescales. You probably won't be allowed to extend the timescales for a project, but it's important to communicate the likely impacts to appropriate stakeholders.
- Identify a central place where requirements clarifications will be stored, so effort is not duplicated in later phases of the project. This could be a change-control system, a folder on a shared server, a public email box, or a wiki.
- Share requirements clarifications with later phases of the project, new starter training, support/maintenance, and regression test efforts.
What do You Put in Your Requirements Content Checklist?
No single requirements checklist can be used for all systems. The following checklist contains some starting points which can be used as a basis for content review, although it is not exhaustive. The best checklists also contain technology platform and system specifics.
Have requirements been specified for the following areas?:
All Front End User Functions such as menu options, screens and processes which implement the main functional requirements for the system.
- Confirm that front end user functions cover all the tasks that the user must perform
- Compare the against a model of the user process, such as a business process description
- If different types of user role are involved, do the functions fully cover all roles e.g.) shopper, finance, customer services, IT support
- Do the requirements specify whether data insert, update, delete and find actions are valid for each function and user role?
Administration Functions which allow management of system settings, to assist the system's primary functions. For example, a screen to set up user permissions.
- Typical areas for administration functions include:
- User permissions, passwords and other security settings
- Picklist content maintenance and user visible options.
- System parameters including processing settings, paths and locations, size limits
- Settings for audit trail, backups
- For each administration function, are the following specified?:
- Default values for settings
- Valid combinations of setting value
- Assumed initial live values
- Some administration functions may not be implemented in the system - some will be carried out manually by an experienced system administrator:
- Which administration functions will not be implemented?
- Are assumptions about how any manual administration functions will take place stated?
Housekeeping Functions which check or maintain the integrity of the data processing, to assist with system support. For