Software Requirements Specification (SRS)

1. Software Requirements Specification(SRS) • What is an SRS? • What is the purpose of an SRS? • Who reads the SRS? • Who writes the SRS? • What information is put into an SRS? • What do you need to do for phase 1?

2. What is an SRS? • It is a document that you prepare: • after customer gives you their system specifications • before you design the system

3. What is the purpose of an SRS? • “The SRS precisely defines the software product that will be built.” [readyset.tigris.org/nonav/templates/srs.html] • The SRS is your “response to the customer’s System Specification ... and tells a potential customer how you intend to solve their problem.” [CSE442 project description] • “The [SRS] specifies the requirements … and the methods to be used to ensure that each requirement has been met.” [source?]

4. Purpose (continued) • “An SRS is basically an organization’s understanding (in writing) or a customer or potential client’s system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work.” [www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html] • “It’s a two-way insurance policy that assures that both the client and the organization understand the other’s requirements from that perspective at a given point in time” [www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html]

5. Purpose (continued) • “It provides feedback to the customer.” • “It decomposes the problem into component parts.” • “It serves as an input to the design specification.” • “It serves as a product validation check.” [www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html]

6. Who reads the SRS? The purpose of an SRS is to communicate with the customer: • The SRS must make clear to the customer whether you have understood their system specification correctly and completely. SRS is written in plain language (not a formal language).

7. Who reads (continued) The purpose of an SRS is to communicate with the designers: • The SRS must be detailed enough that the designers can construct a design for the system from this document.

8. Who writes the SRS? • Developers • Architects • Programmers • Technical writers • Customer may be involved

9. Basis for User Manual • The SRS can serve as the basis for a User Manual for the software: • Use case descriptions in SRS describe required functionality of the system, from the perspective of a user. • This can be extended to become a description of how to carry out these required tasks with the finished system.

10. What information is put into an SRS? • Varies between • organizations • customers • projects

11. Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable IEEE Std 830-1998Characteristics of a good SRS

12. Correct: every requirement given in SRS is a requirement of the software • Unambiguous: every requirement has exactly one interpretation • Complete: includes all functional, performance, design, external interface requirements; definition of the response of the software to all inputs (valid and invalid) • Consistent: internal consistency

13. Ranked importance: essential vs. desirable • Verifiable: for each requirement there must be a “finite cost-effective” method to verify process with which a person or machine can check that the software product meets the requirement.” • Modifiable: SRS must be structured to permit effective modifications (e.g. don’t be redundant, keep requirements separate) • Traceable: origin of each requirement is clear.

14. IEEE Std 830-1998: Parts of an SRS • Introduction • Purpose • deliniate purpose of SRS • intended audience for SRS • Scope • identify software to be produced by name • explain what sw will (not) do • describe application of sw (benefits, objectives)

15. IEEE Std 830-1998: Parts of an SRS • Introduction (continued) • Definitions/acronyms/abbreviations • References • list documents referenced by name and source • Overview • brief description of rest of SRS • organization of SRS

16. IEEE Std 830-1998: Parts of an SRS • Overall description • Product perspective (related products?) • block diagram • contraints • system interfaces • identify functionality that fulfills each system requirement • user interfaces • hardware interfaces • software interfaces • how sw interacts with supporting software (purpose, message content and format) • required versions

17. IEEE Std 830-1998: Parts of an SRS • Overall description (continued) • Product perspective • contraints • communications interfaces • network protocols • memory • requirements/limits on primary and secondary memory • operations • modes of operation • interactive vs. unattended operation • backup & recovery • site adaptation requirement

18. IEEE Std 830-1998: Parts of an SRS • Overall description (continued) • Product functions • summary of major functions sw will perform • Intended user characteristics • educational level • experience • technical expertise

19. IEEE Std 830-1998: Parts of an SRS • Overall description (continued) • Constraints (limitations of developer options) • regulatory policies • hardware limitations (e.g. signal timing requirements) • interfaces to other applications • parallel operation • audit functions • control functions • higher-order language requirements • reliability requirements • criticality of the application • safety and security considertations

20. IEEE Std 830-1998: Parts of an SRS • Overall description (continued) • Assumptions and dependencies • e.g. specific OS available on HW • Apportioning of requirements • requirements that may be delayed to future versions

21. IEEE Std 830-1998: Parts of an SRS • Specific requirements • External interfaces • Functions • Performance requirements • Logical database requirements • Design constraints • Standards compliance

22. IEEE Std 830-1998: Parts of an SRS • Specific requirements (continued) • Software system attributes • Reliability • Availability • Security • Maintainability • Portability

23. IEEE Std 830-1998: Parts of an SRS • Specific requirements (continued) • Organizing the specific requirements • System mode • User class • Objects • Feature • Stimulus • Response • Functional hierarchy • Additional comments

24. IEEE Std 830-1998: Parts of an SRS • Supporting Information • Table of contents • Index • Appendixes