Review Checklist for Software Requirements Document
This checklist is NOT intended as a starting point to write a document.|
It does NOT necessarily cover all aspects relevant for this type of document.
This checklist is intended only as an aid in checking a completed document.
- Does each software requirement have a unique identifier?
- Is each software requirement verifiable?
(If possible, formalize, quantify.)
- Is each software requirement prioritized?
- Are all unstable software requirements marked as such?
(TBC=`To Be Confirmed')
- Is each software requirement traced back to the URD,
and, where relevant, is an explanation included?
- Are the software requirements complete?
(All user requirements are covered;
all relevant input situations are accounted for.)
- Are the software requirements consistent?
- Is overlap among software requirements pointed out explicitly?
- Is the intial system state clearly specified?
- Do the software requirements express a logical model,
rather than implementation?
(Unless this is a user requirement.)
- Are the software requirements expressed in a structured way,
as a hierarchy of abstractions?
- Is it sufficiently clear that
the structure (partitioning into parts) of the logical model
is intended only to improve the understanding and
is not intended to restrict the implementation by requiring that
this structure is maintained?
(Unless stated to the contrary because of the user requirements.)
- Are the software requirements sufficiently formalized?
- Are critical properties of the software requirements proved?
- Is all formalized and diagrammatic material accompanied by
sufficient explanatory text in natural language?
- Are design decisions that restrict developer freedom
(w.r.t. the user requirements), documented explicitly and motivated?
- If applicable, is a user interface prototype described in detail?
Is this prototype explicitly linked to
the logical model or the specific software requirements?
Is the version of this prototype stated, and can this prototype
be recovered for later experimentation?
- Are exploratory prototypes described for those areas
where the project team lacks experience?
- Are backward and forward traceability matrices
between user requirements and software requirements included?
Were these matrices inspected for completeness
(every UR is fully covered by one or more SRs) and
minimality (every SR is fully justified by one or more URs)?
©2001, Tom Verhoeff (TUE)
Feedback about this page is welcome