Req specification
- 1. Requirement Specification • SRS document is a contract between the development team and the customer • How do we communicate the Requirements to others? • Firm foundation and baseline for design phase and latter phases • Support project management and control evolution of system • The SRS document is known as black-box specification • SRS have different audiences(Technical and non-technical)
- 2. Mapping Requirements to Specifications
- 3. Essentials for Writing Requirements • Requirements are read more often than they are written • Readers of requirements come from diverse backgrounds • Writing clearly and concisely is not easy and is time consuming and cost effective • Different organizations write requirements at different levels of abstraction • Writing good requirements requires a lot of analytic thought
- 4. Specification Principles • Separate functionality from implementation • Develop model of desired behavior of the system • Define the environment in which system operates • Create a cognitive model • Content & structure of a specifications should be amenable to change
- 5. Activities of SRS • Adopt SRS template • Identify sources of requirements • Uniquely label each requirement • Record business rules • Specify functional requirements • Specify quality attributes
- 6. Benefits of SRS • Forces the users to consider their specific requirements carefully • Enhances communication between the Purchaser and System developers • Provides a firm foundation for the system design phase • Enables planning of validation, verification, and acceptance procedures • Enables project planning eg. estimates of cost and time, resource scheduling • Usable during maintenance phase
- 7. Components of srs • Functional requirements • Performance requirements • Design constraints • External interface requiremnts
- 8. Specification Techniques • Informal Specifications • Semi-formal ( graphical, tabular) • Formal Specifications • Algebraic approach • Model-based approach
- 9. Informal Specifications • Textual descriptions and informal diagrams are easy for understanding • These specifications are often ambiguous, imprecise and lengthy • They lack support of abstraction and there is minimal or no automated tool support for such specifications • Good for user requirements • Lack of tool support • Possibility of ambiguity
- 10. Semi-Formal Specifications • Most of the semiformal specifications are based on UML • The specifications based on UML are supported by different tools
- 11. Formal Specifications • Formal specification is part of a more general collection of techniques that are known as formal methods • Syntax and semantics defined • Fewer possibility for ambiguity. • Formal specification forces a very detailed analysis of the system requirements at an early stage. Correcting errors at this stage is cheaper. Formal methods include – Formal specification – Specification analysis and proof – Transformational development – Program verification
- 12. Use of Formal Methods • Their principal benefits are in reducing the number of errors in systems so their main area of applicability is critical systems: – Air traffic control information systems, – Railway signalling systems – Spacecraft systems – Medical control systems • In this area, the use of formal methods is most likely to be cost-effective
- 13. Algebraic approach • The system is specified in terms of its operations and their relationships
- 14. Model-based approach • The system is specified in terms of a state model that is constructed using mathematical constructs such as sets and sequences. • Operations are defined by modifications to the system’s state
- 15. SRS Standards • ANSI/IEEE SRS Standard 830-1984 • BS 6719: 1986 • European Space Agency Standards • (ESA PSS-05-0, Jan 1987) • US DoD-Std-7935A • NASA Standard • Canadian Standard(Z242.15.4-1979) • Vlore Standard
- 16. What not to include in SRS • Project development plans • Staffing, Methods, Tools etc. • Product quality assurance plans – Configuration Management, Verification & Validation • Designs information – Requirements and designs have different audiences
- 17. Characteristics of good requirement specification documents • Complete – Description of all major requirements relating to functionality, performance etc. • Consistent – A software requirement specification is consistent if none of the requirements conflict • Traceable – Origin and all references are available • Unambiguous – Having two or more meanings • Verifiable – All requirements are verifiable