- a set of precisely stated properties or constraints which a software system must satisfy.
- a software requirements document establishes boundaries on the solution space of the problem of developing a useful software system.
A software requirements document allows a design to be validated - if the constraints and properties specified in the document are satisfied by the software design, then that design is an acceptable solution to the problem.
Six requirements which a software requirements document should satisfy
- it should specify only external system behaviour,
- it should specify constraints on the implementation,
- it should be easy to change,
- it should serve as a reference tool for system maintainers,
- it should record forethought about the life cycle of the system, and
- it should characterize acceptable responses to undesired events
Characteristics of a Software Requirements Specification
A good SRS is
- unambiguous,
- complete,
- verifiable,
- consistent,
- modifiable,
- traceable, and
- usable during the operation and maintenance phase.
Unambiguous
- Every requirement has only one interpretation.
- Each characteristic of the final product is described using a single unique term.
- A glossary should be used when a term used in a particular context could have multiple meanings.
Complete
- A complete SRS must possess the following qualities:
- inclusion of all significant requirements,
- definition of the responses of the software to all realizable classes of input,
- conformity to any standard that applies to it,
- full labelling and referencing of all tables and diagrams and the definition of all terms.
Verifiable
- Every requirement must be verifiable.
- There must exist some finite cost-effective process with which a person or machine can check that the software meets the requirement.
Consistent
- No set of individual requirements described in the SRS can be in conflict.
- Types of likely conflicts:
- Two or more requirements describe the same real world object in different terms.
- The specified characteristics of real world objects might conflict.
- There may be a logical or temporal conflict between two specified actions.
Modifiable
- The structure and style of the SRS are such that any necessary changes to the requirements can be made easily, completely and consistently.
- Requirements:
- a coherent and easy-to-use organization (including a table of contents, index and cross-referencing),
- not be redundant - this can lead to errors.
Traceable
- The origin of each requirement must be clear.
- The SRS should facilitate the referencing of each requirement in future development or enhancement documentation.
- Types:
- Backward traceability
- Each requirement must explicitly reference its source in previous documents.
- Forward traceability
- Each requirement must have an unique name or reference number.
- Backward traceability
Usable during the operation and maintenance phase
- The SRS must address the needs of the operation and maintenance phase, including the eventual replacement of the software.
No comments:
Post a Comment