Software Requirements Specification
Table of Contents
2. Information Description or System Model
3. Functional Description
4. Requirements Validation
5. Ten Tips for Getting Useful Information from Users
6. Characteristics of a Software Requirements Specification 1. Unambiguous
7. Usable during the operation and maintenance phase 7. Rules of Order for Specifying SW Requirements
8. The Seven Sins of the Specifier
1. A Case Study
9. Sample Document Outline
10. A Little Humour!
• 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. The task should not be underestimated, e.g. the requirements document for a ballistic missile defence system (1977) contained over 8000 distinct requirements and support paragraphs and was 2500 pages in length. Six requirements which a software requirements document should satisfy according to Heninger (1980): 1. it should specify only external system behaviour,
2. it should specify constraints on the implementation,
3. it should be easy to change,
4. it should serve as a reference tool for system maintainers, 5. it should record forethought about the life cycle of the system, and 6. it should characterize acceptable responses to undesired events.
Information Description or System Model
This conceptual model is a very high-level view of the system in which the major user services are identified and their relationships documented. It is necessary to establish an explicit, precisely defined system model at an early stage and to use this model to understand the system. The most effective notations for describing the conceptual model of a system are graphical notations - they are usually understandable by users who have no technical background in software engineering.
The functional system requirements are those system services which are expected by the user of the system. The analyst must avoid the introduction of implementation concepts in this section. In principle, the functional requirements should be both complete and consistent. Completeness means that all user-required services are specified. Consistency means that no one requirement definition should contradict any other. There are three ways of expressing the functional requirements of a system: 1. in natural language,
2. in a structured or formatted language which has some rules but no rigorous syntactic or semantic specification, and 3. in a formal specification language with rigorously defined syntax and semantics.
The system requirements should be validated - if they are not, then errors in the requirements definition will be propagated to the system design and implementation and expensive system modifications may be required to correct these errors. There are four separate stages involved in validating requirements: 1. The requirements should be shown to be consistent. Any one requirement should not conflict with any other. 2. The requirements should be shown to be complete. The definition should include all functions and constraints intended by the system user. 3. The requirements should be shown to be realistic. There is no point in specifying requirements which are unrealizable using existing hardware and software technology. It may be acceptable to anticipate some hardware developments, but developments in software...
Please join StudyMode to read the full document