Editing Software requirements specification

{{broader|Software requirements}}
{{short description|Description of a software system to be developed}}
{{IEEE software documents}}
A '''software requirements specification''' ('''SRS''') is a description of a [[software system]] to be  [[Software development|developed]]. It is modeled after the [[Business requirements|business requirements specification]] [[Concept of operations|(CONOPS)]]. The software requirements specification lays out [[Functional requirement|functional]] and [[non-functional requirements]], and it may include a set of [[use case]]s 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.<ref>{{cite web |url=http://www.computer.org/portal/web/swebok/v3guide |title=Guide to the Software Engineering Body of Knowledge (SWEBOK) |access-date=17 July 2014 |publisher=IEEE Computer Society |date=2014 |first1=P. |last1=Bourque |first2=R.E. |last2=Fairley |archive-date=28 December 2014 |archive-url=https://web.archive.org/web/20141228080106/http://www.computer.org/portal/web/swebok/v3guide |url-status=dead }}</ref> Used appropriately, software  requirements specifications can help prevent software project failure.<ref>{{cite web |url=https://belitsoft.com/php-development-services/software-requirements-specification-helps-protect-it-projects-failure |title=Software requirements specification helps to protect IT projects from failure |access-date=19 December 2016}}</ref>

The software requirements specification document lists sufficient and necessary requirements for the project development.<ref name=Pressman>{{cite book|last=Pressman|first=Roger|title=Software Engineering: A Practitioner's Approach|year=2010|publisher=McGraw Hill|location=Boston|isbn=9780073375977|pages=123}}</ref> 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]]<ref>
{{cite web
 |url        = http://www.everyspec.com/DATA-ITEM-DESC-DIDs/DI-IPSC/DI-IPSC-81433A_3709/
 |title      = DI-IPSC-81433A, DATA ITEM DESCRIPTION SOFTWARE REQUIREMENTS SPECIFICATION (SRS) 
 |date       = 1999-12-15
 |publisher  = everyspec.com
 |access-date = 2013-04-04
}}</ref> or have other forms of organizationally-mandated content.

Typically a SRS is written by a [[technical writer]], a [[systems architect]], or a [[software programmer]].<ref>
Donn Le Vie, Jr.
[https://techwhirl.com/writing-software-requirements-specifications/ "Writing Software Requirements Specifications (SRS)"].
2010.
</ref>

== History ==
Software requirement specifications are already used in software development processes as early as 1975.<ref>{{Cite journal |last=Ramamoorthy |first=C. V. |last2=Ho |first2=S. F. |date=1975-04-01 |title=Testing large software with automated software evaluation systems |url=https://dl.acm.org/doi/10.1145/390016.808461 |journal=SIGPLAN Not. |volume=10 |issue=6 |pages=382–394 |doi=10.1145/390016.808461 |issn=0362-1340}}</ref> 

The purpose and content of software requirement specifications was formalised in 1983 by the [[Institute of Electrical and Electronics Engineers|IEEE]].  The standard was published in 1984 as IEEE-830-1984 and approved by [[American National Standards Institute|ANSI]].<ref>{{Cite web |title=IEEE Standards Association - IEE-830-1984 |url=https://standards.ieee.org/ieee/830/1220/ |access-date=2024-12-30 |website=IEEE Standards Association |language=en}}</ref> It was revised in 1993 and 1998, before being superseded by an international standard.<ref>{{Cite web |title=IEEE Standards Association - IEEE 839-1993 |url=https://standards.ieee.org/ieee/830/1221/ |access-date=2024-12-30 |website=IEEE Standards Association |language=en}}</ref><ref name=":0">{{Cite web |title=IEEE Standards Association IEEE 830-1998 |url=https://standards.ieee.org/ieee/830/1222/ |access-date=2024-12-30 |website=IEEE Standards Association |language=en}}</ref>  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 [[International Organization for Standardization|ISO]]/IEC/IEEE 29148 standard "Systems and software engineering —Life cycle processes — Requirements engineering" superseded IEEE 830 in 2011.<ref name=":0" />  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).<ref name=":1">{{Cite web |title=ISO/IEC/IEEE 29148:2018 |url=https://www.iso.org/standard/72089.html |access-date=2024-12-30 |website=ISO |language=en}}</ref>  It proposes a slightly changed example structure.   

==Structure==
An example organization of an SRS is as follows:<ref name="book1">{{cite book | title=Applied software project management |author1=Stellman, Andrew  |author2=Greene, Jennifer  |name-list-style=amp | year=2005 | publisher=O'Reilly Media, Inc | pages=308 | isbn=978-0596009489}}</ref> 

#Purpose
##[[Definition]]s
##Background 
##System overview
##[[Reference]]s 
#[[High- and low-level|Overall description]]
##[[Product requirements document|Product perspective]]
###[[Interface (computing)|System Interfaces]]
###[[User interface]]s
###[[Hardware interfaces]]
###[[Interface (computing)|Software interfaces]]
###Communication Interfaces
###[[Computer memory|Memory constraints]]
##Design constraints
###[[Operations support system |Operations]]
###Site adaptation requirements
##Product functions
##User characteristics 
##Constraints, assumptions and dependencies 
#Specific requirements
##External interface requirements
##[[Performance engineering|Performance requirements]]
##Logical database requirement
##[[#SoftwareSystemAttributes|Software system attributes]]
###[[Reliability engineering|Reliability]]
###[[High availability|Availability]]
###[[Security engineering|Security]]
###[[Serviceability (computer)|Maintainability]]
###Portability
##[[Functional requirements]]
###[[Functional partitioning]]
###[[Functional description]]
###[[Control description]]
##[[Environment characteristics]]
###[[Computer hardware|Hardware]]
###[[Peripherals]]
###[[User (computing)|Users]]
##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.<ref name=":1" />  

==Requirement quality==
Requirements should strictly be about what is needed, independently of the system design, and not how the software should do it.<ref name=":1" /> 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 smell]]s, 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.<ref name="femmer17">{{cite journal|last1=Femmer|first1=Henning|last2=Méndez Fernández|first2=Daniel|last3=Wagner|first3=Stefan|last4=Eder|first4=Sebastian|title=Rapid quality assurance with Requirements Smells|journal=Journal of Systems and Software|date=2017|volume=123|pages=190–213|doi=10.1016/j.jss.2016.02.047|arxiv=1611.08847|s2cid=9602750}}</ref> Examples of requirements smells are ''subjective language'', ''ambiguous adverbs and adjectives'', ''superlatives'' and ''negative statements''.<ref name="femmer17"/> Comparative phrases, non-verifiable terms or terms implying totality should also be avoided.<ref name=":1" /> 

==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==
{{reflist}}

==External links==
* {{Cite book| doi = 10.1109/IEEESTD.1984.119205| year = 1984| isbn = 978-0-7381-4418-4| title = IEEE Guide for Software Requirements Specifications}}
* {{Cite book| doi = 10.1109/IEEESTD.1994.121431| year = 1994| isbn = 978-0-7381-4723-9| title = IEEE Recommended Practice for Software Requirements Specifications}}
* {{Cite book| doi = 10.1109/IEEESTD.1998.88286| year = 1998| isbn = 978-0-7381-0332-7| s2cid = 8674647| title = IEEE Recommended Practice for Software Requirements Specifications}}
* {{cite book | year = 2018 | publisher = Iso/Iec/IEEE 29148:2018(E) | pages = 1–94 | isbn = 978-0-7381-6591-2  | doi = 10.1109/IEEESTD.2011.6146379 | url = https://ieeexplore.ieee.org/document/6146379 | title = Systems and software engineering -- Life cycle processes --Requirements engineering }}("This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 - [https://web.archive.org/web/20120721124049/http://standards.ieee.org/findstds/standard/29148-2011.html]")
* {{cite book|last1=Leffingwell|first1=Dean|last2=Widrig|first2=Don|title=Managing Software Requirements: A Use Case Approach|edition=2nd|year=2003|publisher=Addison-Wesley|isbn=978-0321122476}}
* {{cite book|last=Gottesdiener|first=Ellen|title=The Software Requirements Memory Jogger: A Desktop Guide to Help Business and Technical Teams Develop and Manage Requirements|year=2009|publisher=Addison-Wesley|isbn=978-1576811146}}
* {{cite book|last1=Wiegers|first1=Karl|last2=Beatty|first2=Joy|title=Software Requirements, Third Edition|year=2013|publisher=Microsoft Press|isbn=9780735679665}}
* {{Cite web|url=https://github.com/rick4470/IEEE-SRS-Tempate|title=IEEE SRS Template - rick4470/IEEE-SRS-Tempate|website=[[GitHub]] |access-date=27 Dec 2017}}
*[https://simtechdev.com/blog/how-to-write-a-specification-to-save-costs/ How to Write a Software Requirement Specification to Save Costs?]

{{Software engineering}}
{{IEEE standards}}
<ref name="Requirements Engineering Strategy">{{cite web |last1=Taaffe |first1=Ed |title=Mr |url=http://www.thebridger.co.uk/requirements-engineering-strategy-can-make-or-break-your-project/ |website=thebridger |access-date=2019-02-02 |ref=REQ-ENG1}}</ref>

{{DEFAULTSORT:Software Requirements}}
[[Category:Software requirements]]
[[Category:Software documentation]]
[[Category:IEEE standards]]