User:Robbie404/Software requirements

In software engineering and requirements engineering, software requirements^[a] describe what a software system should do, the service or services that it provides and the constraints on its operation. The ISO/IEC/IEEE Systems and software engineering vocabulary defines a software requirement as:^[1]

A software capability needed by a user to solve a problem or to achieve an objective.
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.

Which of these definitions to use, depends on the context in which the software is developed. While the first definition is appropriate in less constrained environments, the second definition is mainly applicable in environments constrained by existing processes and systems.^[2]

Software requirements can be categorised as functional requirements and non-functional requirements. Functional requirements describe the functionalities or behaviour the system should support, usually in terms of anticipated inputs and expected outputs. Non-functional requirements, also known as quality requirements, describe non-functional qualities of the system, such as security or stability, that can be used to judge the system's performance. Additionally, software requirements can be categorised in terms of the key stakeholder, such as client or user-oriented requirements and developer-oriented requirements^[3].

The aim of software requirements is threefold. First, it enables for discussion and agreement among stakeholders on what the system should include. It should be noted that good communication between stakeholders and frequent reviews are vital for this. Second, it should provide software developers with an understandable description of what the system to be realised should include, as the software developers may not be familiar with the concepts and terminology of the application's domain. Last, the requirements should provide a standard to evaluate the system with^[2].

History

The use of software requirements dates back to the early days of software development. The first systems were built to perform specific tasks and were often developed without a formalized process for specifying requirements, but as the field of software engineering evolved, the importance of requirements began to be recognized, leading to the development of formal methods for specifying and managing requirements.^[4]

One of the earliest approaches to managing software requirements was the waterfall model, which was proposed by Winston W. Royce^[5] as a linear, sequential process for software development. This model emphasized the importance of specifying requirements up front and then using those requirements to guide the design, development, and testing of the software. However, it was soon recognized that the waterfall model was not well-suited to the dynamic nature of software development, and alternative approaches were sought^[4].

In the 1980s and 1990s, a number of approaches were proposed to address the limitations of the waterfall model. One of the most prominent of these was the "iterative and incremental" approach, which emphasized the importance of iteratively refining requirements and incrementally delivering working software^[6]. This approach was seen as more flexible and better suited to the dynamic nature of software development, and it became the basis for many modern software development methodologies, such as agile development.^[7]

With the rise of agile development, there has been an increased focus on requirements management in recent years. Agile requirements management involves constant communication and collaboration between the developers and stakeholders, with frequent inspections and adaptations to requirements. This approach has been widely adopted in the software industry, and it is considered to be one of the most effective ways to manage software requirements ^[4].

System Requirements

Software requirements are a type of system requirement. System requirements describe what should be enforced within an environment, and are described in terms of environmental phenomena. Software requirements, on the other hand, describe what the software should enforce in terms of phenomena shared between the software and the environment.^[3] Following this distinction, software requirements are aimed at developers, whereas system requirements are to be understood by all stakeholders.^[3]

Related disciplines

The disciplines related to software requirements are involved in the process of transforming stakeholders' wishes to specified and validated requirements. The most notable being: requirements elicitation, analysis, specification, validation, and management.

Elicitation

Elicitation is the gathering and discovery of requirements from stakeholders and other sources. It aims to establish what the system should and should not include. A variety of methods can be used, such as joint application design (JAD) sessions, interviews, document analysis, and focus groups. Because of the strengths and weaknesses of each method, and possible varying expertise with the method of the requirement engineer, a combination of methods is often required to effectively do requirement elicitation.^[8] Elicitation is the first step of requirements development.

Analysis

Requirements analysis is the logical breakdown that proceeds from elicitation. The analysis involves reaching a richer and more precise understanding of each requirement and representing sets of requirements in multiple, complementary ways. In addition, requirements analysis often involves exploring and evaluating alternatives to the elicited requirements.^[9]

Requirements Triage or prioritization of requirements is an activity which often follows analysis.^[10] It involves considering the different aspects of the requirements, such as costs, benefits, and risks. Various prioritization methods exist - for example, ranking, numerical assignment, and the 100 dollar test^[11], to name a few. Priorizitation methods vary in complexity and granularity; the choice for a particular prioritization method is often influenced by the context and nature of the project (e.g., its project management structure) and requirements or product/service that is getting build.

Specification

Requirement 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. These models may be structured in a software requirements specification (SPS) document, providing a detailed description of the system to be developed.

Validation

Requirements validation involves techniques to confirm that the correct set of requirements has been specified to build a solution that satisfies the stakeholders' needs. Requirements validation is usually subjective; the specification of requirements is evaluated against informal (i.e., insufficiently documented) requirements. Methods that can be used for requirements validation include inspection, state-based exploration, and scenario-based validation.^[12]

Management

Requirements change during projects and there are often many of them. Management of this change becomes paramount to ensuring that the correct software is built for the stakeholders. Amongst other things, requirements management deals with organizing requirements, tracking their status, tracing their change history, and updating the project plan in accordance to the changed requirements. As requirements may change during development, requirements management is a continuous process.^[13]

Types of software requirements

Software requirements can be categorized in several ways. The following are common categorizations:

Business requirements

Statements of business level goals, without reference to detailed functionality. These are usually high level (software and/or hardware) capabilities that are needed to achieve a business outcome.

Customer requirements

Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:^[14]

Operational distribution or deployment: Where will the system be used?
Mission profile or scenario: How will the system accomplish its mission objective?
Performance and related parameters: What are the critical system parameters to accomplish the mission?
Utilization environments: How are the various system components to be used?
Effectiveness requirements: How effective or efficient must the system be in performing its mission?
Operational life cycle: How long will the system be in use by the user?
Environment: What environments will the system be expected to operate in an effective manner?

Architectural requirements: Architectural requirements explain what has to be done by identifying the necessary systems architecture of a system.
Structural requirements: Structural requirements explain what has to be done by identifying the necessary structure of a system.
Behavioral requirements: Behavioral requirements explain what has to be done by identifying the necessary behavior of a system.
Functional requirements: Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.^[14]
Non-functional requirements: Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.
Performance requirements: The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.^[14]
Design requirements: The "build to", "code to", and "buy to" requirements for products and "how to execute" requirements for processes expressed in technical data packages and technical manuals.^[14]
Derived requirements: Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.^[14]
Allocated requirements: A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.^[14]

Well-known requirements categorization models include FURPS and FURPS+, developed at Hewlett-Packard.

Notes

^ The wording Software requirements is additionally used in software release notes to explain which depending software packages are required for a certain software to be built/installed/used.

References

^ "ISO/IEC/IEEE International Standard - Systems and software engineering--Vocabulary". doi:10.1109/ieeestd.2017.8016712. {{cite journal}}: Cite journal requires |journal= (help)
^ ^a ^b W., Brackett, John (1990). Software requirements : SEI Curriculum, module SEI-CM-19.1.2, Jan. 1990. Carnegie Mellon Univ. OCLC 632654026.{{cite book}}: CS1 maint: multiple names: authors list (link)
^ ^a ^b ^c Lamsweerde, A. van (2009). Requirements engineering : from system goals to UML models to software specifications. Chichester, England: John Wiley. ISBN 0-470-01270-6. OCLC 243941685.
^ ^a ^b ^c Sommerville, Ian (2011). Software engineering (9th ed.). Boston: Pearson. ISBN 978-0-13-703515-1. OCLC 462909026.
^ Royce, Winston W. (2021). "Managing the Development of Large Software Systems (1970)". doi:10.7551/mitpress/12274.003.0035. {{cite journal}}: Cite journal requires |journal= (help)
^ Boehm, B. W. (1988). "A spiral model of software development and enhancement". Computer. 21 (5): 61–72. doi:10.1109/2.59. ISSN 0018-9162.
^ Highsmith, James A. (2002). Agile software development ecosystems. Boston: Addison-Wesley. ISBN 0201760436. OCLC 52349654.
^ Zowghi, Didar; Coulin, Chad (2005), Aurum, Aybüke; Wohlin, Claes (eds.), "Requirements Elicitation: A Survey of Techniques, Approaches, and Tools", Engineering and Managing Software Requirements, Berlin/Heidelberg: Springer-Verlag, pp. 19–46, doi:10.1007/3-540-28244-0_2, ISBN 978-3-540-25043-2, retrieved 2023-01-12
^ Mylopoulos, J.; Chung, L.; Liao, S.; Wang, H.; Yu, E. (2001). "Exploring alternatives during requirements analysis". IEEE Software. 18 (1): 92–96. doi:10.1109/52.903174. ISSN 0740-7459.
^ 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.
^ Berander, Patrik; Andrews, Anneliese (2005), Aurum, Aybüke; Wohlin, Claes (eds.), "Requirements Prioritization", Engineering and Managing Software Requirements, Berlin/Heidelberg: Springer-Verlag, pp. 69–94, doi:10.1007/3-540-28244-0_4, ISBN 978-3-540-25043-2, retrieved 2023-01-13
^ Cheng, Betty H. C.; Atlee, Joanne M. (2009), Lyytinen, Kalle; Loucopoulos, Pericles; Mylopoulos, John; Robinson, Bill (eds.), "Current and Future Research Directions in Requirements Engineering", Design Requirements Engineering: A Ten-Year Perspective, vol. 14, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 11–43, doi:10.1007/978-3-540-92966-6_2, ISBN 978-3-540-92965-9, retrieved 2023-01-13
^ 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.
^ ^a ^b ^c ^d ^e ^f United States. Army (2001). Systems engineering fundamentals. Defense Systems Management College. [Washington D.C.] ISBN 9781484120835. OCLC 1336448886.{{cite book}}: CS1 maint: location missing publisher (link)