The
requirements checklist is a tool to assist in determining whether the
requirements are documented, correct, complete, unambiguous, consistent,
verifiable and approved. The
Requirements Specification template includes examples and can be used to
document the requirements for your product or service, including priority and
approval. Tailor the specification to
suit your project, organizing the applicable sections in a way that works best,
and use this checklist to record decisions about the applicable areas.
Each
deliverable indicated below as applicable must be documented and included in
the requirements review package.
Applicable? (Yes? No?
Comment?)
|
Requirements Deliverable
|
Key questions or issues to consider
|
|
|
Project Description
|
Yes
- Required
|
Project
Overview
|
Does
the package include the name of the project and all requirements
review package contributors, and the name of the work group(s) that will own
the requirements? This may simply be a
reference to the project charter.
|
Yes
- Required
|
Key
Stakeholders
|
Does
the package include a list of the key stakeholders, with their work group and
email addresses? This may simply be a reference to the project charter.
|
Yes
- Required
|
Scope
& Business Reason
|
Does
the package include a brief description of the business reason for this
project, and what is and is not included in the scope of this
project? Is the target audience or primary customer identified? This may
simply be a reference to the project charter.
|
|
Are
the general characteristics or profiles of the intended users defined?
|
|
|
Assumptions
|
Are
assumptions that affect the requirements documented?
|
|
Constraints
and limitations
|
Are
technical, financial or business limitations that could constrain the design
options documented?
|
|
Dependencies
|
Are
the requirements dependent on the release or functionality of other
applications/services? On any organizational changes or resource bottlenecks?
|
|
Common
Language
|
Has
every acronym or specialized term been included in a glossary or data
dictionary?
|
|
|
Requirements
Documentation
|
|
·
Are business rules defined?
·
Are input and output processing actions specified?
·
Is every function supporting an input or output
described?
·
Are validity checks on the inputs defined?
·
Is the exact sequence of operations described?
·
Are specific responses to abnormal situations
needed? (e.g., overflow, communication facilities, error handling/recovery)
·
What about the effect of parameters?
·
Are relationships of outputs to inputs described?
(e.g., input/output sequences, formulas for input to output conversion)
·
Are required user interfaces described? (e.g.,
screen formats or organization, report layouts, menu structures, error and
other messages, or function keys)
·
Are explicitly undesired events/inputs described,
along with their required responses?
|
|
|
·
Are static and dynamic numerical performance
requirements identified?
·
Are all performance requirements measurable?
·
Are explicit latency requirements identified?
·
Are capacity requirements measurable?
·
Are specific and measurable requirements
identified for availability?
·
Are specific and measurable requirements
identified for reliability?
|
|
|
Manageability
& Maintainability
|
·
Are there requirements specific to the management
of the deliverable product or service?
·
Are there requirements for product or service
health monitoring, failure conditions, error detection, logging, and
correction?
·
Are there requirements specifically related to
ease of maintenance?
·
Are normal and special operations specified?
|
|
Are
usability requirements defined?
|
|
|
Interfaces
(Systems, Network, Hardware) and Integration
|
·
Is each required interface with another product or
system described?
·
Is each required interface with a network
component described?
·
Is each required interface with a hardware or equipment
component described?
·
Are all input, output and system conditions and
their interactions described?
·
Are there references to existing interface
documentation?
·
Is there a need for requirements that are specific
to a given site, such as oceanography vessels?
|
|
Are
the data requirements specified?
|
|
|
Are
requirements derived from existing standards, policies, regulations, or laws
described?
|
|
|
Are
security requirements described, including authorization and authentication
factors?
|
|
|
Must
the system be easily ported to other host machines and/or operating
systems? Is environment-independence a
requirement?
|
|
|
Existing
defects to be resolved
|
Are
there any existing defects which must be resolved with this release? Are they
documented?
|
|
|
Requirements Process
|
|
Traceability
|
Are
all requirements numbered or uniquely identifiable?
|
|
Priority
|
Is
every requirement prioritized?
|
|
Have
all requirements been approved and confirmed by the sponsor?
|
|
|
Conciseness
|
Is
every requirement unambiguous, with only one interpretation?
|
|
Consistency
|
Are
the requirements mutually consistent? Do any requirements conflict with or
duplicate other requirements?
|
|
Completeness
|
·
Is every requirement correct and complete?
·
Does the requirements documentation capture all of
the client's stated needs?
·
Are there any unstated client needs which, if not
met, would cause dissatisfaction?
·
Are there any unstated client needs which, if met,
would cause the client to be more than satisfied?
·
Are all identified requirements documented?
·
Do any requirements conflict?
·
Are there any special considerations not covered
in the requirements?
|
|
Business Scenarios / Use Cases
|
Have
business scenarios been constructed to illustrate (or draw out) the
requirements?
|
|
Reviewer
Commitment
|
Have
all requirements reviewers committed to participate in the reviews? Is there a plan to ensure review team
continuity?
|
|
Were
any requirements approved and subsequently deleted? Known to be delayed until
future versions of the product? Are they identified?
|
|
|
Testing
and Testability
|
·
Is every requirement verifiable? Are unverifiable
(and untestable) requirements noted?
·
Can the requirements serve as the basis for defining
product acceptance?
·
What types of testing and testing methodology is
expected?
|
|
Clarity
|
·
Are the requirements described in enough detail
for the implementation team to design a system satisfying the requirements
and to verify that the system satisfies requirements?
·
Are the requirements specifications readable and
understandable?
|
|
Appropriateness
|
·
Do the requirements specify what needs to be done
as opposed to describing how the product or service should be implemented?
·
Do the requirements avoid specifying a particular
design?
|
|
Planning
|
·
Is there a plan to resolve each "To Be
Determined" noted in the requirements?
·
Is there a plan to trace every requirement to an
implementation item (e.g., design diagram or test case)?
·
Are the requirements re-usable after
implementation?
·
Are the requirements compatible with later project
phases?
·
Can the requirements specifications be used as the
basis for proceeding with the project?
|
|
Requirements
Management
|
·
Are all requirements documents kept consistent
with product changes?
·
Is a change management system in place to track
the modifications to the requirements?
Are the requirements under configuration management?
·
Are the requirements documents structured to
accommodate changes?
·
Have the requirements documents been developed
according to documented processes that have been agreed to by the project
team?
·
Do the requirements documents facilitate the
gathering of data about the requirements management process?
|