Software requirements specification

For broader coverage of this topic, see Software requirements.

Short description: Description of a software system to be developed

IEEE software life cycle

* SQA – Software quality assurance • IEEE 730
* SCM – Software configuration management • IEEE 828
* STD – Software test documentation • IEEE 29119
* SRS – Software requirements specification • IEEE 29148
* V&V – Software verification and validation • IEEE 1012
* SDD – Software design description • IEEE 1016
* SPM – Software project management • IEEE 16326
* SUD – Software user documentation • IEEE 24748

* v
* t
* e

A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after the business requirements specification (CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.

Software requirements specifications establish the basis for an agreement between customers and contractors or suppliers on how the software product should function (in a market-driven project, these roles may be played by the marketing and development divisions). Software requirements specification is a rigorous assessment of requirements before the more specific system design stages, and its goal is to reduce later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules.[1] Used appropriately, software requirements specifications can help prevent software project failure. The software requirements specification document lists sufficient and necessary requirements for the project development.[2] To derive the requirements, the developer needs to have a clear and thorough understanding of the products under development. This is achieved through detailed and continuous communications with the project team and customer throughout the software development process.

The SRS may be one of a contract's deliverable data item descriptions[3] or have other forms of organizationally-mandated content.

Typically a SRS is written by a technical writer, a systems architect, or a software programmer.[4]

## Contents

* 1 History
* 2 Structure
* 3 Requirement quality
* 4 See also
* 5 References
* 6 External links

## History

Software requirement specifications are already used in software development processes as early as 1975.[5]

The purpose and content of software requirement specifications was formalised in 1983 by the IEEE. The standard was published in 1984 as IEEE-830-1984 and approved by ANSI.[6] It was revised in 1993 and 1998, before being superseded by an international standard.[7][8] This standard aimed at providing criteria for a good SRS, and recommendations about its content. It recognised the benefits of prototyping for the requirement engineering. It propose an example of structure and several variants.

The ISO/IEC/IEEE 29148 standard "Systems and software engineering —Life cycle processes — Requirements engineering" superseded IEEE 830 in 2011.[8] The current revision is from 2018. This standard is broader as it covers also requirement quality criteria, requirement management processes, and business requirement specification (BRS), as well as stakeholder requirement specification (StRS).[9] It proposes a slightly changed example structure.

## Structure

An example organization of an SRS is as follows:[10]

1. Purpose
1. Definitions
2. Background
3. System overview
4. References
2. Overall description
1. Product perspective
1. System Interfaces
2. User interfaces
3. Hardware interfaces
4. Software interfaces
5. Communication Interfaces
6. Memory constraints
2. Design constraints
1. Operations
2. Site adaptation requirements
3. Product functions
4. User characteristics
5. Constraints, assumptions and dependencies
3. Specific requirements
1. External interface requirements
2. Performance requirements
3. Logical database requirement
4. Software system attributes
1. Reliability
2. Availability
3. Security
4. Maintainability
5. Portability
5. Functional requirements
1. Functional partitioning
2. Functional description
3. Control description
6. Environment characteristics
1. Hardware
2. Peripherals
3. Users
7. Other

It would be recommended to address also verification approaches planned to qualify the software against the requirements, for example with a specific section with a structure that mirrors the section on specific requirements.[9]

## Requirement quality

Requirements should strictly be about what is needed, independently of the system design, and not how the software should do it.[9] Individual requirements shall hence be necessary, appropriate, and unambiguous. A set of requirements shall moreover be complete, consistent, feasible, and comprehensible.

Following the idea of code smells, the notion of requirements smell has been proposed to describe issues in requirements specification where the requirement is not necessarily wrong but could be problematic.[11] Examples of requirements smells are subjective language, ambiguous adverbs and adjectives, superlatives and negative statements.[11] Comparative phrases, non-verifiable terms or terms implying totality should also be avoided.[9]

## See also

* System requirements specification
* Concept of operations
* Requirements engineering
* Software Engineering Body of Knowledge (SWEBOK)
* Design specification
* Specification (technical standard)
* Formal specification
* Abstract type

## References

1. ↑ Bourque, P.; Fairley, R.E. (2014). "Guide to the Software Engineering Body of Knowledge (SWEBOK)". IEEE Computer Society. http://www.computer.org/portal/web/swebok/v3guide.
2. ↑ Pressman, Roger (2010). Software Engineering: A Practitioner's Approach. Boston: McGraw Hill. pp. 123. ISBN 9780073375977.
3. ↑ "DI-IPSC-81433A, DATA ITEM DESCRIPTION SOFTWARE REQUIREMENTS SPECIFICATION (SRS)". everyspec.com. 1999-12-15. http://www.everyspec.com/DATA-ITEM-DESC-DIDs/DI-IPSC/DI-IPSC-81433A_3709/.
4. ↑ Donn Le Vie, Jr. "Writing Software Requirements Specifications (SRS)". 2010.
5. ↑ Ramamoorthy, C. V.; Ho, S. F. (1975-04-01). "Testing large software with automated software evaluation systems". ACM SIGPLAN Notices 10 (6): 382–394. doi:10.1145/390016.808461. ISSN 0362-1340. https://dl.acm.org/doi/10.1145/390016.808461.
6. ↑ "IEEE Standards Association - IEE-830-1984" (in en). https://standards.ieee.org/ieee/830/1220/.
7. ↑ "IEEE Standards Association - IEEE 839-1993" (in en). https://standards.ieee.org/ieee/830/1221/.
8. ↑ 8.0 8.1 "IEEE Standards Association IEEE 830-1998" (in en). https://standards.ieee.org/ieee/830/1222/.
9. ↑ 9.0 9.1 9.2 9.3 "ISO/IEC/IEEE 29148:2018" (in en). https://www.iso.org/standard/72089.html.
10. ↑ Stellman, Andrew; Greene, Jennifer (2005). Applied software project management. O'Reilly Media, Inc. pp. 308. ISBN 978-0596009489.
11. ↑ 11.0 11.1 Femmer, Henning; Méndez Fernández, Daniel; Wagner, Stefan; Eder, Sebastian (2017). "Rapid quality assurance with Requirements Smells". Journal of Systems and Software 123: 190–213. doi:10.1016/j.jss.2016.02.047.

## External links

* IEEE Guide for Software Requirements Specifications. 1984. doi:10.1109/IEEESTD.1984.119205. ISBN 978-0-7381-4418-4.
* IEEE Recommended Practice for Software Requirements Specifications. 1994. doi:10.1109/IEEESTD.1994.121431. ISBN 978-0-7381-4723-9.
* IEEE Recommended Practice for Software Requirements Specifications. 1998. doi:10.1109/IEEESTD.1998.88286. ISBN 978-0-7381-0332-7.
* Systems and software engineering -- Life cycle processes --Requirements engineering. Iso/Iec/IEEE 29148:2018(E). 2018. pp. 1–94. doi:10.1109/IEEESTD.2011.6146379. ISBN 978-0-7381-6591-2. ("This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 - [1]")
* Leffingwell, Dean; Widrig, Don (2003). Managing Software Requirements: A Use Case Approach (2nd ed.). Addison-Wesley. ISBN 978-0321122476.
* Gottesdiener, Ellen (2009). The Software Requirements Memory Jogger: A Desktop Guide to Help Business and Technical Teams Develop and Manage Requirements. Addison-Wesley. ISBN 978-1576811146.
* Wiegers, Karl; Beatty, Joy (2013). Software Requirements, Third Edition. Microsoft Press. ISBN 9780735679665.
* "IEEE SRS Template - rick4470/IEEE-SRS-Tempate". https://github.com/rick4470/IEEE-SRS-Tempate.
* How to Write a Software Requirement Specification to Save Costs?

* v
* t
* e

Software engineering

Fields|

* Computer programming
* Requirements engineering
* Software deployment
* Software design
* Software maintenance
* Software testing
* Systems analysis
* Formal methods

Concepts|

* Data modeling
* Enterprise architecture
* Functional specification
* Modeling language
* Orthogonality
* Programming paradigm
* Software
* Software archaeology
* Software architecture
* Software configuration management
* Software development methodology
* Software development process
* Software quality
* Software quality assurance
* Software verification and validation
* Structured analysis

Orientations|

* Agile
* Aspect-oriented
* Object orientation
* Ontology
* Service orientation
* SDLC

Models|

| Developmental|

* Agile
* EUP
* Executable UML
* Incremental model
* Iterative model
* Prototype model
* RAD
* UP
* Scrum
* Spiral model
* V-Model
* Waterfall model
* XP

|

Other|

* SPICE
* CMMI
* Data model
* ER model
* Function model
* Information model
* Metamodeling
* Object model
* Systems model
* View model

Languages|

* IDEF
* UML
* USL
* SysML

Software
engineers

* Victor Basili
* Kent Beck
* Grady Booch
* Fred Brooks
* Barry Boehm
* Peter Chen
* Danese Cooper
* Ward Cunningham
* Tom DeMarco
* Edsger W. Dijkstra
* Delores M. Etter
* Martin Fowler
* Adele Goldstine
* Margaret Hamilton
* C. A. R. Hoare
* Lois Haibt
* Mary Jean Harrold
* Grace Hopper
* Watts Humphrey
* Michael A. Jackson
* Ivar Jacobson
* Alan Kay
* Nancy Leveson
* Stephen J. Mellor
* Bertrand Meyer
* David Parnas
* Trygve Reenskaug
* Winston W. Royce
* James Rumbaugh
* Mary Shaw
* Peri Tarr
* Elaine Weyuker
* Niklaus Wirth
* Edward Yourdon

Related fields|

* Computer science
* Computer engineering
* Project management
* Risk management
* Systems engineering

* Category
* Commons

* v
* t
* e

IEEE standards

Current|

* 488
* 730
* 754
* Revision
* 854
* 828
* 829
* 896
* 1003
* 1014
* 1016
* 1076
* 1149.1
* 1154
* 1164
* 1275
* 1278
* 1284
* 1355
* 1394
* 1451
* 1497
* 1516
* 1541
* 1547
* 1584
* 1588
* 1596
* 1603
* 1613
* 1666
* 1667
* 1675
* 1685
* 1722
* 1733
* 1800
* 1801
* 1815
* 1850
* 1900
* 1901
* 1902
* 1904
* 1905
* 2030
* 2050
* 11073
* 12207
* 14764
* 16085
* 16326
* 29148
* 42010

802 series|

| 802.1|

* D
* p
* Q
* Qat
* Qay
* w
* X
* ab
* ad
* AE
* ag
* ah
* ak
* aq
* AS
* ax
* az
* BA

|

802.3|

* -1983
* a
* b
* d
* e
* i
* j
* u
* x
* y
* z
* ab
* ac
* ad
* ae
* af
* ah
* ak
* an
* aq
* at
* av
* az
* ba
* bt
* by

802.11|

* legacy mode
* a
* b
* c
* d
* e
* f
* g
* h
* i
* j
* k
* n
* p
* r
* s
* u
* v
* w
* y
* ac
* ad
* af
* ah
* ai
* ax
* ay

* .2
* .4
* .5
* .6
* .7
* .8
* .9
* .10
* .12
* .14
* .15
* .1
* .4
* .4a
* .6
* .16
* Original · d · e
* .17
* .18
* .20
* .21
* .22

Proposed|

* P1363
* P1619
* P1699
* P1823
* P1906.1

Superseded|

* 754-1985
* 830
* 1219
* 1233
* 1362
* 1364
* 1471

See also
IEEE Standards Association
Category:IEEE standards

[1]

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/Software requirements specification. Read more

|

1. ↑ Taaffe, Ed. "Mr". http://www.thebridger.co.uk/requirements-engineering-strategy-can-make-or-break-your-project/.

Retrieved from "https://handwiki.org/wiki/index.php?title=Software_requirements_specification&oldid=3983713"
*[v]: View this template
*[t]: Discuss this template
*[e]: Edit this template