User:Gerardnoordhuis/Software requirements specification
A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after a 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 specification establishes the basis for an agreement between acquirers (customers) and suppliers (contractors) on how the software product should function.
The software requirements specification document lists sufficient and necessary requirements for the project development.[1] To derive the requirements, the developer needs to have clear and thorough understanding of the products under development. This is achieved through detailed and continuous communications with the project team and acquirer throughout the software development process.
The SRS may be one of a contract's deliverable data item descriptions[2] or have other forms of organizationally-mandated content.
Typically an SRS is written by a technical writer, a systems architect, or a software programmer.[3]
Purpose
[edit]A software requirements specification is defined as a requirements specification pertaining to a software system.[4] A software requirements specification contributes to the 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.[5] Used appropriately, software requirements specifications can help prevent software project failure.[6][7]
Requirements engineering (RE) involves effectively communicating the requirements among various stakeholders. The manner in which requirements are documented is crucial for ensuring they can be "read, analysed, (re-)written, and validated". [8]
Readers
[edit]The requirements document may be used for reference by a number of different stakeholders[9]:
| Stakeholders | Stakeholder' Responsibility | SRS use |
|---|---|---|
| Software Customers | Ensure that the requirements are properly specified. | Check if their needs are expressed in an acceptable way and specify changes. |
| Managers | Planning, costing and scheduling the software development. | Input for the project planning process. |
| Software Engineers | Designing and implementing the software. | Understand what is to be developed. |
| Software Test Engineers | Validate that the developed software meets the requirements. | Derive tests from the document and perform software verification and validation. |
| Software Maintenance Engineers | Maintain and modify the software after it has gone into use. | Understand the initial software characteristics and the relationships between different parts of the software. |
Writing an SRS
[edit]A requirements specification is typically written by the supplier,[4] but the authors of the SRS can also include individuals representing the acquirer[10]. It is recommended that the acquirer and the supplier work together to produce a well-written and completely understood SRS.[11]
Several sources include an outline for structuring an SRS.[12][13][10] SRS documentation usually includes at least those sections:
- an introduction,
- an overall description
- specific requirements
Structure
[edit]One standardised outline that can be used is the following:[10]
1. Introduction
[edit]- Purpose
- Scope
- Product overview
- Product perspective
- Product functions
- User characteristics
- Limitations
- Definitions
2. References
[edit]3. Specific requirements
[edit]- External interfaces
- Functions
- Usability requirements
- Performance requirements
- Logical database requirements
- Design constraints
- Software system attributes
- Supporting information
4. Verification
[edit]This section should elaborate on verification approaches and methods that can be applied to qualify the software.[10]
5. Appendices
- Assumptions and dependencies
- Acronyms and abbreviations
Specific requirements
[edit]This section is usually the heart of the document and should generally be the largest section. This part of the SRS should be structured in a way that is most helpful for all stakeholders. There is no single optimal structure that is appropriate for all systems[10], but the SRS should always include Functional requirements and Non-functional requirements.
EEE standard 830 offers templates for organising the requirements based on eight approaches: by mode, user class, object, feature, stimulus, functional hierarchy, or a combination of these. There isn't a one-size-fits-all approach, so it might be advisable for organisations and project teams to adjust the templates to their specific needs.[11]
IEEE standards
[edit]The importance of engineering requirements for software systems has been recognised since the early days of software engineering, and as a result several standards have been established. These standards provide guidelines on the content and format of an SRS document.
The Institute of Electrical and Electronics Engineers (IEEE) has published several software engineering standards, including IEEE Std 830-1998, "IEEE Recommended Practice for Software Requirements Specifications". Standard 830, last revised in 1998, has been replaced by ISO/IEC/IEEE 29148:2011, which received an update in 2018.
Characteristics of a good SRS
[edit]Research indicates that there is a positive correlation between high-quality SRSs and project success.[14][15] According to IEEE 830 a proper SRS should be correct, unambiguous, complete, consistent, ranked, verifiable, modifiable and traceable.[11] However, it is difficult for specifications to actually meet those criteria.[16]
| Correct | The SRS should accurately reflect the software's functionality and specification at any point in time. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is not correct. |
| Unambiguous | Confusion about the interpretation of requirements is prevented.[11] Requirement ambiguities can be divided into the following four categories: lexical ambiguity, syntactic ambiguity, semantic ambiguity and pragmatic ambiguity.[17][18] |
| Complete | Contains all requested features. |
| Consistent | An internally consistent SRS should follow the same abbreviations and conventions throughout the document. Three types of likely conflicts in an SRS are:
|
| Ranked for importance and/or stability | IEEE suggests requirements are classified according to importance and/or stability.[11]
There are various specific requirement prioritization techniques, including value-cost comparison.[19] |
| Verifiable | A requirement is deemed verifiable if there is a way to quantifiably measure if the final software satisfies it. |
| Modifiable | Requirements are clearly identified in a systematic manner. It allows for changes to a specific requirement and the dependent ones, without impacting others. |
| Traceable | The origin of each requirement is clear and requirements can be easily referenced later on. |
Detecting requirement defects
[edit]It is difficult to automatically detect defects in requirements artifacts, as industry requirements are primarily written in natural language [20] which has no formal semantics. To face this challenge, 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 [21], following the idea of code smells. Requirement (bad) smells are "concrete symptoms for a requirement artifact’s quality defect for which we enable rapid feedback through automatic smell detection".[21]
Examples of requirements smells are subjective language, ambiguous adverbs and adjectives, superlatives and negative statements.[21]
Revising/updating the SRS
[edit]Requirements management is an important aspect of Requirements engineering. The SRS may need revision as the development of the software product progresses, as some details may be unknown at the start of the project and new issues may arise as the project progresses. According mentions two major considerations if additional changes are made[11]:
- As could be read in the Characteristics of a good SRS the requirements should be as complete as possible at any time. If a requirement is incomplete and later revision is deemed inevitable, this should be mentioned in the SRS.
- Changes should be documented for traceability and previous, superseded parts of the SRS should stay available for review.
Visualisations
[edit]Prototype
[edit]A prototype can be used to demonstrate how the intended product will work, allowing stakeholders to visualize and interact with the features and functionality of the system. It can help improve communication between stakeholders by providing a common understanding.[13]
Agile development
[edit]The development community still appears to be a bit unfamiliar with the role of requirements engineering practices in Agile software development methods and might need further research.[22][23] Agile is incremental and iterative and practitioners could argue that a requirements document might have become obsolete as soon as it has been written, due to the ever-changing needs of the project. Therefore, the effort of creating specific requirements may not always seem of much use. Rather than a formal SRS document, methodologies like Scrum sometimes add requirements incrementally or write user stories instead.[24] Rather than laying out requirements, Agile teams can us the user stories to illustrate the expected behaviour. These function as acceptance tests for developers, because they can check if they have implemented every user story.[24]
- ^ Pressman, Roger (2010). Software Engineering: A Practitioner's Approach. Boston: McGraw Hill. p. 123. ISBN 9780073375977.
- ^ "DI-IPSC-81433A, DATA ITEM DESCRIPTION SOFTWARE REQUIREMENTS SPECIFICATION (SRS)". everyspec.com. 1999-12-15. Retrieved 2013-04-04.
- ^ Donn Le Vie, Jr. "Writing Software Requirements Specifications (SRS)". 2010.
- ^ a b Glinz, M. (2011). A glossary of requirements engineering terminology. Standard Glossary of the Certified Professional for Requirements Engineering (CPRE) Studies and Exam, Version, 1, 56.
- ^ Bourque, P.; Fairley, R.E. (2014). "Guide to the Software Engineering Body of Knowledge (SWEBOK)". IEEE Computer Society. Retrieved 17 July 2014.
- ^ "Software requirements specification helps to protect IT projects from failure". Retrieved 19 December 2016.
- ^ European Software Institute, "European User Survey Analysis", Report USV_EUR 2.1, ESPITI Project, January 1996.
- ^ Nuseibeh, Bashar; Easterbrook, Steve (2000-05-01). "Requirements engineering: a roadmap". Proceedings of the Conference on The Future of Software Engineering. ICSE '00. New York, NY, USA: Association for Computing Machinery: 35–46. doi:10.1145/336512.336523. ISBN 978-1-58113-253-3.
- ^ Kotonya, Gerald; Sommerville, Ian (1998). Requirements Engineering: Processes and Techniques (1st ed.). Wiley Publishing. doi:10.5555/552009. ISBN 978-0-471-97208-2.
{{cite book}}: Check|doi=value (help) - ^ a b c d e * 29148-2018 - Systems and software engineering — Life cycle processes — Requirements engineering. 2018. pp. 1–94. doi:10.1109/IEEESTD.2011.6146379. ISBN 978-0-7381-6591-2.
{{cite book}}:|journal=ignored (help)("This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 - http://standards.ieee.org/findstds/standard/29148-2011.html") - ^ a b c d e f g * 830-1998 — IEEE Recommended Practice for Software Requirements Specifications. 1998. doi:10.1109/IEEESTD.1998.88286. ISBN 978-0-7381-0332-7. S2CID 8674647.
- ^ Stellman, Andrew (2006). Applied software project management. Jennifer Greene. Sebastopol, CA: O'Reilly. ISBN 0-596-00948-8. OCLC 61425297.
- ^ a b Wiegers, Karl Eugene (2013). Software requirements. Joy Beatty (Third edition ed.). Redmond, Washington. ISBN 978-0-7356-7962-7. OCLC 857497823.
{{cite book}}:|edition=has extra text (help)CS1 maint: location missing publisher (link) - ^ Kamata, Mayumi Itakura; Tamai, Tetsuo (2007-10). "How Does Requirements Quality Relate to Project Success or Failure?". 15th IEEE International Requirements Engineering Conference (RE 2007). IEEE. doi:10.1109/re.2007.31.
{{cite journal}}: Check date values in:|date=(help) - ^ Thayer, Richard H.; Dorfman, Merlin (2011). "Software Requirements Engineering". doi:10.1109/9781118156674.
{{cite journal}}: Cite journal requires|journal=(help) - ^ Glinz, M. (2000, September). Improving the quality of requirements with scenarios. In Proceedings of the second world congress on software quality (Vol. 9, pp. 55-60).
- ^ Berry, Daniel M.; Kamsties, Erik (2004), "Ambiguity in Requirements Specification", Perspectives on Software Requirements, Boston, MA: Springer US, pp. 7–44, ISBN 978-1-4613-5090-3, retrieved 2023-01-23
- ^ Berry, D. M., Kamsties, E., & Krieger, M. M. (2003). From contract drafting to software specification: Linguistic sources of ambiguity. Univ. of Waterloo, Tech. Rep.
- ^ Karlsson, J.; Ryan, K. (1997). "A cost-value approach for prioritizing requirements". IEEE Software. 14 (5): 67–74. doi:10.1109/52.605933. ISSN 0740-7459.
- ^ Mich, Luisa; Franch, Mariangela; Novi Inverardi, Pier Luigi (2004-05-01). "Market research for requirements analysis using linguistic tools". Requirements Engineering. 9 (2): 151–151. doi:10.1007/s00766-004-0195-3. ISSN 1432-010X.
- ^ a b c 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. arXiv:1611.08847. doi:10.1016/j.jss.2016.02.047. S2CID 9602750.
- ^ Inayat, Irum; Salim, Siti Salwah; Marczak, Sabrina; Daneva, Maya; Shamshirband, Shahaboddin (2015-10). "A systematic literature review on agile requirements engineering practices and challenges". Computers in Human Behavior. 51: 915–929. doi:10.1016/j.chb.2014.10.046. ISSN 0747-5632.
{{cite journal}}: Check date values in:|date=(help) - ^ Curcio, Karina; Navarro, Tiago; Malucelli, Andreia; Reinehr, Sheila (2018-05). "Requirements engineering: A systematic mapping study in agile software development". Journal of Systems and Software. 139: 32–50. doi:10.1016/j.jss.2018.01.036. ISSN 0164-1212.
{{cite journal}}: Check date values in:|date=(help) - ^ a b Cohn, Mike (2004). User stories applied : for agile software development. Boston: Addison-Wesley. ISBN 978-0-13-270264-5. OCLC 57365091.