Software requirement engineering
Download as PPTX, PDF2 likes1,187 views
The document discusses key aspects of software requirement engineering including requirement elicitation, analysis, specification, and validation. It describes the purpose of a Software Requirement Specification (SRS) document as a contract between developers and customers. Various techniques are covered for specifying requirements such as informal, semi-formal, and formal specifications. The document also outlines best practices for writing requirements and standards for SRS documents.
Software requirement engineering
- 2. Requirements Engineering Activities Requirements Elicitation Requirements Analysis and Negotiation Requirements Specification Requirements Validation User Needs, Domain Information, Existing System Information, Regulations, Standards, Etc. Requirements Document Agreed Requirements
- 3. 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)
- 4. Mapping Requirements to Specifications
- 5. 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
- 6. 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
- 7. Activities of SRS •Adopt SRS template •Identify sources of requirements •Uniquely label each requirement •Record business rules •Specify functional requirements •Specify quality attributes
- 8. 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
- 9. Specification Techniques • Informal Specifications •Semi-formal ( graphical, tabular) •Formal Specifications •Algebraic approach •Model-based approach
- 10. 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
- 11. Semi-Formal Specifications •Most of the semiformal specifications are based on UML •The specifications based on UML are supported by different tools
- 12. Formal Specifications •Formal specification is part of a more general collection of techniques that are known as formal methods •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
- 13. 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
- 14. Algebraic approach The system is specified in terms of its operations and their relationships
- 15. 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
- 16. 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
- 17. 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
- 18. 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