software requirements specification srs l.
Download
Skip this Video
Download Presentation
Software Requirements Specification (SRS)

Loading in 2 Seconds...

play fullscreen
1 / 24

Software Requirements Specification (SRS) - PowerPoint PPT Presentation


  • 499 Views
  • Uploaded on

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:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Requirements Specification (SRS)' - kamuzu


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
What is an SRS?
  • It is a document that you prepare:
    • after customer gives you their system specifications
    • before you design the system
what is the purpose of an srs
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?]
purpose continued
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]
purpose continued5
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]

who reads the srs
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).
who reads continued
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.
who writes the srs
Who writes the SRS?
  • Developers
    • Architects
    • Programmers
  • Technical writers
  • Customer may be involved
basis for user manual
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.
what information is put into an srs
What information is put into an SRS?
  • Varies between
    • organizations
    • customers
    • projects
ieee std 830 1998 characteristics of a good srs
Correct

Unambiguous

Complete

Consistent

Ranked for importance and/or stability

Verifiable

Modifiable

Traceable

IEEE Std 830-1998Characteristics of a good SRS
slide12
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
slide13
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.
ieee std 830 1998 parts of an srs
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)
ieee std 830 1998 parts of an srs15
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
ieee std 830 1998 parts of an srs16
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
ieee std 830 1998 parts of an srs17
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
ieee std 830 1998 parts of an srs18
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
ieee std 830 1998 parts of an srs19
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
ieee std 830 1998 parts of an srs20
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
ieee std 830 1998 parts of an srs21
IEEE Std 830-1998: Parts of an SRS
  • Specific requirements
    • External interfaces
    • Functions
    • Performance requirements
    • Logical database requirements
    • Design constraints
      • Standards compliance
ieee std 830 1998 parts of an srs22
IEEE Std 830-1998: Parts of an SRS
  • Specific requirements (continued)
    • Software system attributes
      • Reliability
      • Availability
      • Security
      • Maintainability
      • Portability
ieee std 830 1998 parts of an srs23
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
ieee std 830 1998 parts of an srs24
IEEE Std 830-1998: Parts of an SRS
  • Supporting Information
    • Table of contents
    • Index
    • Appendixes