Header image
Information Technology In Business
    Checklist - Requirements Specification checklist for Managers
source ITIB chk-req-mgr 23-Feb-2009
RS01 - Have all primary stakeholders been identified?

This question is best asked before the specification is to be written. It must be clear to the author what the intended audience for the specification is. The word primary stresses the necessity of deciding on a concise set of stakeholders that represent at least a) the customer, the party that benefits from the result; b) the designers or suppliers, the party that is responsible for the solution; c) the independent testers, the party that verifies and validates the result; d) the project or program manager, the party that is responsible for the actual content of the project and its priorities.
Ideally, after having reviewed the specification, these primary stakeholders will sign it when they have read, understood and agreed to the requirements in the specification, within the limits of their responsibility. The department or group manager will authorize and release the specification.

RS02 - Have all requirements been given a unique identifier within the scope of the specification?
Not only for enabling the traceability, but this is a precondition for efficient reviews and communication with relevant parties.
RS03 - Is it clear that all the necessary inputs (higher level) were available for the author, that they have been checked with the relevant (higher level) stakeholders, and that the comments have been incorporated into the specification?
To ensure that important stakeholder needs and comments are captured and verified. In case previous versions of the TRS are used: has been verified if the requirements were still relevant and necessary?
Inspection, Process, Compliance
RS04 - Does the author have a good understanding of the top-5 needs of the stakeholders?
To be able to distinguish between the real need of stakeholders and to give direction towards the designers / suppliers, the author must have priorities set. This is also to ensure that the development activities are contributing to those properties of the product that add the most value for its stakeholders. To understand what the stakeholders needs are, will help is analyzing the list of potential requirements into a well-balanced list of stakeholder needs.
RS05 - Have all critical requirements been documented and verified?
To focus all development activities on the right properties.
Process, Compliance
RS06 - Is it clear that the author has verified the completeness and the level of detail with stakeholders that depend on the content of the requirements specification?
If any of the primary Stakeholders does not understand or agree with the requirements, the development of the product/service may be at risk. It is important to understand where author and stakeholder disagree to be able to analyze the risk.
RS07 - Has feasibility been verified? Has testability been verified?
Well-written requirements facilitate the design process. The clearer the problem is described, the more likely it will be to develop the right solution. Also for testing purposes it is crucial that no ambiguity exist in the requirements specifications.
RS08 - Has the author succeeded in writing a clear, unambiguous, concise specification?
Perform random tests, select a few requirements and determine the priority and importance by the location in the specification, the amount of detail and the quantification of requirements.
RS09 - Are guidelines for writing good requirements followed?
If the organization has adopted a specific way-of-working to achieve good quality specifications, this question will remind both the manager and the author of the existence of such a document. Often this process documentation is owned and managed by the process owner, a role that takes care of a particular process. In case the author decided to deviate from the standard way-of-working he/she should be able to justify this.
Standards, Process, Craftsmanship
RS10 - Is it clear in the requirements specification what the important and less important requirements are?
Particularly when there is little time to properly inspect the requirements specification, the author must take care that a minimum amount of time must be spend by the reviewers to understand each requirement. Ideally after reading it once. It does not help to add details to a requirement when its description is unclear.
RS11 - Does the structure (logic, modularity, coherence) of the document help the design and implementation processes (efficiency)?
A glance on the table of contents should reveal that the specification is divided into logical sections that help to be complete.
RS12 - Are the requirements testable and measurable?
In case requirements are not testable or not quantified in any way, any implementation will do. Nothing will guide the developers in their attempts to find the right solution. They would not be able to validate whether the solution is adequate.
RS13 - Did  the author incorporate the lessons learned from the past? Has he/she consulted senior (knowledgeable) engineers or domain experts?
Perhaps the must crucial question, particularly in small informal organizations when processes are fuzzy and where standards are either not known or not followed.

Page updated: 23-Feb-2009