Checkpoints:
Software Requirements Specification
-
The following basic issues should be addressed:
-
Functionality
: What is the software supposed to
do?
-
External interfaces
: How does the software
interact with people, the system's hardware, other hardware, and other
software?
-
Performance
: What is the speed, availability,
response time, recovery time of various software functions, etc.?
-
Attributes
: What are the portability, correctness,
maintainability, security, etc. considerations?
-
Design constraints imposed on an implementation
:
Are there any required standards in effect, implementation language,
policies for database integrity, resource limits, operating
environments, etc.?
-
Are any requirements specified that are outside the bounds of
the SRS? This means the SRS
-
Should correctly define all of the software requirements,
-
Should not describe any design or implementation details,
-
Should not impose additional constraints on the software.
-
Does the SRS properly limit the range of valid designs without
specifying any particular design?
-
Does the SRS exhibit the following characteristics?
-
Correct
: Is every requirement stated in the SRS
one that the software should meet?
-
Unambiguous
-
Does each requirement have one, and only one, interpretation?
-
Has the customer's language been used?
-
Have diagrams been used to augment the natural language
descriptions?
-
Complete
-
Does the SRS include all significant requirements, whether related
to functionality, performance design constraints, attributes, or
external interfaces?
-
Have the expected ranges of input values in all possible scenarios
been identified and addressed?
-
Have responses been included to both valid and invalid input
values?
-
Do all figures, tables and diagrams include full labels and
references and definitions of all terms and units of measure?
-
Have all TBDs been resolved or addressed?
-
Consistent
-
Does this SRS agree with the Vision document, the use-case model
and the Supplementary Specifications?
-
Does it agree with any other higher level specifications?
-
Is it internally consistent, with no subset of individual
requirements described in it in conflict?
-
Ability to Rank Requirements
-
Has each requirement been tagged with an identifier to indicate
either the importance or stability of that particular requirement?
-
Have other significant attributes for properly determining
priority been identified?
-
Verifiable
-
Is every requirement stated in the SRS verifiable?
-
Does there exist some finite cost-effective process with which a
person or machine can check that the software product meets the
requirement?
-
Modifiable
-
Are the structure and style of the SRS such that any changes to
the requirements can be made easily, completely, and consistently
while retaining the structure and style?
-
Has redundancy been identified, minimized and cross-referenced?
-
Traceable
-
Does each requirement have a clear identifier?
-
Is the origin of each requirement clear?
-
Is backward traceability maintained by explicitly referencing
earlier artifacts?
-
Is a reasonable amount of forward traceability maintained to
artifacts spawned by the SRS?
Reference: [IEEE93]
|