Software requirements

Short description: Programming concept

Software requirements[1] for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:[2]

1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
3. A documented representation of a condition or capability as in 1 or 2

The activities related to working with software requirements can broadly be broken down into elicitation, analysis, specification, and management.[3]

Note that the wording Software requirements is additionally used in software release notes to explain, which depending on software packages are required for a certain software to be built/installed/used.[1]

## Contents

* 1 Elicitation
* 2 Analysis
* 3 Specification
* 4 Validation
* 5 Management
* 6 Tool support for Requirements Engineering
* 6.1 Tools for Requirements Elicitation, Analysis and Validation
* 6.2 Tools for Requirements Specification
* 6.3 Tools for Requirements Document Verification
* 6.4 Tools for Requirements Comparison
* 6.5 Tools for Requirements Merge and Update
* 6.6 Tools for Requirements Traceability
* 6.7 Tools for Model-Based Software or Systems Requirement Engineering
* 6.8 Tools for general Requirements Engineering
* 7 See also
* 8 References
* 9 Further reading

## Elicitation

Main article: Requirements elicitation

Elicitation is the gathering and discovery of requirements from stakeholders and other sources. A variety of techniques can be used such as joint application design (JAD) sessions, interviews, document analysis, focus groups, etc.[4] Elicitation is the first step of requirements development.

## Analysis

Main article: Requirements analysis

Analysis is the logical breakdown that proceeds from elicitation. Analysis involves reaching a richer and more precise understanding of each requirement and representing sets of requirements in multiple, complementary ways.

Requirements Triage or prioritization of requirements is another activity which often follows analysis.[5] This relates to Agile software development in the planning phase, e.g. by Planning poker, however it might not be the same depending on the context and nature of the project and requirements or product/service that is being built.

## Specification

Main article: Software requirements specification

Specification involves representing and storing the collected requirements knowledge in a persistent and well-organized fashion that facilitates effective communication and change management. Use cases, user stories, functional requirements, and visual analysis models are popular choices for requirements specification.

## Validation

Validation involves techniques to confirm that the correct set of requirements has been specified to build a solution that satisfies the project's business objectives, and to detect and correct errors in the requirements before implementation.[6]

## Management

Main article: Requirements management

Requirements change during projects and there are often many of them.[7] Management of this change becomes paramount to ensuring that the correct software is built for the stakeholders.

## Tool support for Requirements Engineering

### Tools for Requirements Elicitation, Analysis and Validation

Taking into account that these activities may involve some artifacts such as observation reports (user observation), questionnaires (interviews, surveys and polls), use cases, user stories; activities such as requirement workshops (charrettes), brainstorming, mind mapping, role-playing; and even, prototyping;[8] software products providing some or all of these capabilities can be used to help achieve these tasks.

There is at least one author who advocates, explicitly, for mind mapping tools such as FreeMind; and, alternatively, for the use of specification by example tools such as Concordion.[9] Additionally, the ideas and statements resulting from these activities may be gathered and organized with wikis and other collaboration tools such as Trello. The features actually implemented and standards compliance vary from product to product.

### Tools for Requirements Specification

See also: Software requirements specification

A Software requirements specification (SRS) document might be created using general-purpose software like a word processor or one of several specialized tools. Some of these tools can import, edit, export and publish SRS documents. It may help to make SRS documents while following a standardised structure and methodology, such as ISO/IEC/IEEE 29148:2018. Likewise, software may or not use some standard to import or export requirements (such as ReqIF) or not allow these exchanges at all.

### Tools for Requirements Document Verification

Tools of this kind verify if there are any errors in a requirements document according to some expected structure or standard.

### Tools for Requirements Comparison

Tools of this kind compare two requirement sets according to some expected document structure and standard.

### Tools for Requirements Merge and Update

Tools of this kind allow the merging and update of requirement documents.

### Tools for Requirements Traceability

Tools of this kind allow tracing requirements to other artifacts such as models and source code (forward traceability) or, to previous ones such as business rules and constraints (backwards traceability).

### Tools for Model-Based Software or Systems Requirement Engineering

Model-based systems engineering (MBSE) is the formalised application of modelling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases. It is also possible to take a model-based approach for some stages of the requirements engineering and, a more traditional one, for others. Very many combinations might be possible.

The level of formality and complexity depends on the underlying methodology involved (for instance, i* is much more formal than SysML and, even more formal than UML)

### Tools for general Requirements Engineering

Tools in this category may provide some mix of the capabilities mentioned previously and others such as requirement configuration management and collaboration. The features actually implemented and standards compliance vary from product to product.

There are even more capable or general tools that support other stages and activities. They are classified as ALM tools.

## See also

* Requirement
* Requirements engineering
* Software requirements specification (SRS)
* List of requirements engineering tools
* Non-functional requirement
* Performance requirements which are covered by Software performance testing
* Safety requirements
* Security requirements

## References

1. ↑ 1.0 1.1 "Linux kernel release 5.x — The Linux Kernel documentation". https://www.kernel.org/doc/html/latest/admin-guide/README.html.
2. ↑ IEEE Computer Society (1990). "IEEE Standard Glossary of Software Engineering Terminology". IEEE Standard. http://standards.ieee.org/findstds/standard/610.12-1990.html. Retrieved 2013-01-11.
3. ↑ "Guide to the Software Engineering Body of Knowledge". IEEE Computer Society. http://www.computer.org/portal/web/swebok/html/contents. Retrieved 11 January 2013.
4. ↑ Dar, Hafsa; Lali, M. Ikramullah; Ashraf, Humaira; Ramzan, Muhammad; Amjad, Tehmina; Shahzad, Basit (2018). "A Systematic Study on Software Requirements Elicitation Techniques and its Challenges in Mobile Application Development". IEEE Access 6: 63859–63867. doi:10.1109/access.2018.2874981. ISSN 2169-3536. Bibcode: 2018IEEEA...663859D.
5. ↑ Davis, Alan Mark. (2005). Just enough requirements management : where software development meets marketing. New York: Dorset House Pub. ISBN 0-932633-64-1. OCLC 57211148.
6. ↑ Atoum, Issa; Baklizi, Mahmoud Khalid; Alsmadi, Izzat; Otoom, Ahmed Ali; Alhersh, Taha; Ababneh, Jafar; Almalki, Jameel; Alshahrani, Saeed Masoud (2021). "Challenges of Software Requirements Quality Assurance and Validation: A Systematic Literature Review". IEEE Access 9: 137613–137634. doi:10.1109/ACCESS.2021.3117989. Bibcode: 2021IEEEA...9m7613A.
7. ↑ Davis, Alan M.; Nurmuliani, Nur; Park, Sooyong; Zowghi, Didar (2008). "Requirements Change: What's the Alternative?". 2008 32nd Annual IEEE International Computer Software and Applications Conference. pp. 635–638. doi:10.1109/COMPSAC.2008.216. ISBN 978-0-7695-3262-2. Bibcode: 2008cmps.conf..134D.
8. ↑ "7 Tools to Gather Better Software Requirements". 22 July 2015. https://www.liquidplanner.com/blog/7-tools-to-gather-better-software-requirements/.
9. ↑ Laplante, Phillip A. (2009). "Requirements Engineering for Software and Systems". CRC Press.

## Further reading

* Wiegers, Karl; Beatty, Joy (2013). Software Requirements (3rd ed.). Microsoft Press. ISBN 978-0-7356-7966-5.
* Cockburn, Alistair (2001). Writing Effective Use Cases. Pearson Education. ISBN 0-201-70225-8. https://archive.org/details/writingeffective00cock.
* Leffingwell, Dean (2000). Managing Software Requirements: A Unified Approach. Addison-Wesley Professional. ISBN 0-201-61593-2.
* Burek, Paul (2008). Creating clear project requirements differentiating "what" from "how". Conference Paper. Requirements Management, Business Analysis, Scope Management.
* Koopman, Philip (2020). Embedded Software Requirements. Fall Lectures.
* IEEE Xplore Search. "Software Requirements".

* 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

0.00

(0 votes)

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

|

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