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]
Copyright
© 1987 - 2001 Rational Software Corporation
| |
|