1 / 24

Software Requirements Specification (SRS)

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?. What is an SRS?. It is a document that you prepare:

kamuzu
Télécharger la présentation

Software Requirements Specification (SRS)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related