Software requirements specification

From Wikipedia, the free encyclopedia
Jump to: navigation, search

A Software requirements specification (SRS), a requirements specification for a software system, is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Non-functional requirements impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints) .

The software requirements specification document enlists all necessary requirements that are required for the project development.[1] To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with the project team and customer.

The SRS may be one of a contract deliverable Data Item Descriptions[2] or have other forms of organizationally-mandated content. An example organization of an SRS is as follows: [3][4]

  • Introduction
    • Purpose
    • Definitions
    • System overview
    • References
  • Overall description
    • Product perspective
      • System Interfaces
      • User Interfaces
      • Hardware interfaces
      • Software interfaces
      • Communication Interfaces
      • Memory Constraints
      • Operations
      • Site Adaptation Requirements
    • Product functions
    • User characteristics
    • Constraints, assumptions and dependencies
  • Specific requirements
    • External interface requirements
    • Functional requirements
    • Performance requirements
    • Design constraints
      • Standards Compliance
    • Logical database requirement
    • Software System attributes
      • Reliability
      • Availability
      • Security
      • Maintainability
      • Portability
    • Other requirements

Write specifications to be readable and reviewable[edit]

One of the main values of writing specifications is to have them reviewed by stakeholders and to allow the stakeholders to provide feedback. Therefore, specifications should be written in such a way that they can easily be read and reviewed.

Some of the questions to ask yourself about readability is:

  • Does the specification contain a high-level description of the scope of the work?
  • Does the formatting allow a reader to easily navigate the specification?
  • Does the formatting allow a reader to easily understand the primary versus secondary cases?
  • Does the specification contain links to related features?
  • Does the specification call out questions which still need to be addressed?

References[edit]

  1. ^ Pressman, Roger (2010). Software Engineering: A Practitioner's Approach. Boston: McGraw Hill. p. 123. ISBN 9780073375977. 
  2. ^ "DI-IPSC-81433A, DATA ITEM DESCRIPTION SOFTWARE REQUIREMENTS SPECIFICATION (SRS)". everyspec.com. 1999-12-15. Retrieved 2013-04-04. 
  3. ^ Stellman, Andrew and Greene, Jennifer (2005). Applied software project management. O'Reilly Media, Inc. p. 308. ISBN 0596009488. 
  4. ^ "SRS format - Scribd". 

External links[edit]