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. Activities of SRS Adopt SRS template Identify sources of requirements Uniquely label each requirement Record business rules Specify functional requirements Specify quality attributes

5. 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

6. Appropriate Specification Consider two different projects: – A) Tiny project, 1 programmer, 2 months work – programmer talks to customer, then writes up a 2-page memo – B) Large project, 50 programmers, 2 years work – team of analysts model the requirements, then document them in a 500-page SRS Project AProject B Purpose of spec Crystallizes programmer’s understanding; feedback to customer Build-to document; must contain enough detail for all the programmers Management view Spec is irrelevant; have already allocated resources Will use the spec to estimate resource needs and plan the development

7. 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 e.g. estimates of cost and time, resource scheduling Usable during maintenance phase

8. 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

9. Specification Techniques Informal Specifications Semi-formal ( graphical, tabular) Formal Specifications Algebraic approach –The system is specified in terms of its operations and their relationships 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

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 They do not provide information on high level concepts such as intent, usability and consequences

12. Formal Specifications Formal specification is part of a more general collection of techniques that are known as formal methods Formal specification forces an very details 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. Z (“zed”) Notation Formal specification language –most successful one -> easy to find faults, can prove correctness Requires set theory, functions, & discrete math – difficult to learn because of special symbols Z specifications consists of 4 sections –given sets, data types, and constants sets that get defined in detail –state definition variable declarations & predicates that constrain values –initial state –operations

15. Specification in Z Scenario: We maintain a membership list and an associated phone database. [Person, Phone] |----PhoneDB----------------------------------- |members: P Person (‘set of’ person) |phones : Person  Phone (relation) |------------------------------------------------------- |dom phones ⊆ members (invariant) |---------------------------------------------------

16. Example members  {jim, sue} phones {(jim, 1231), (sue, 3956)} Assign(alice, 1231)

17. Specification in the software process

18. Development costs with formal specification

19. Requirements document structure Preface Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index

20. Requirement Specification Checklist – Do stated goals and objectives for software remain consistent with system goals and objectives? – Have important interfaces to all system elements been described? – Have all data objects been described? Have all attributes been identified? – Do major functions remain within scope and has each been adequately described? – Have functions been refined (elaborated) to an appropriate level of detail? – Is information flow adequately defined for the problem domain? – Are diagrams clear; can each stand alone without supplementary text? – Is the behavior of the software consistent with the information it must process and the functions it must perform?

21. Requirement Specification Checklist – Have events and states been identified? – Are design constraints realistic? – Have technological risks been fully defined? – Have alternative software requirements been considered? – Have validation criteria been stated in detail; are they adequate to describe a successful system? – Have inconsistencies, omissions or redundancy been identified and corrected? – Is the customer contact complete? – Has the user reviewed the Preliminary User's Manual or prototype? – How are the Software Project Plan estimates affected?

22. 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

23. 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