Software requirements

Last updated

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]

Contents

  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 software packages are required for a certain software to be built/installed/used. [1]

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. Elicitation is the first step of requirements development.

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. [4] This relates to Agile software development in planning phase, e.g. by Planning poker, however it might not be the same depending on the context and nature of project and requirements or product/service that is getting build.

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.

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.

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; [5] 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. [6] 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

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 to trace 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

Related Research Articles

Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not necessarily limited to:

In software engineering, software configuration management is the task of tracking and controlling changes in the software, part of the larger cross-disciplinary field of configuration management. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine the "what, when, why and who" of the change. If a configuration is working well, SCM can determine how to replicate it across many hosts.

Software development is the process used to conceive, specify, design, program, document, test, and bug fix in order to create and maintain applications, frameworks, or other software components. Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through the final manifestation, typically in a planned and structured process often overlapping with software engineering. Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.

In software and systems engineering, the phrase use case is a polyseme with two senses:

  1. A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
  2. A potential scenario in which a system receives an external request and responds to it.
<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

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 prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome should conform.

Software assurance (SwA) is a critical process in software development that ensures the reliability, safety, and security of software products. It involves a variety of activities, including requirements analysis, design reviews, code inspections, testing, and formal verification. One crucial component of software assurance is secure coding practices, which follow industry-accepted standards and best practices, such as those outlined by the Software Engineering Institute (SEI) in their CERT Secure Coding Standards (SCS).

Software project management is the process of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

<span class="mw-page-title-main">Systems modeling language</span> General-purpose modeling language

The systems modeling language (SysML) is a general-purpose modeling language for systems engineering applications. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems.

Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary as (1) the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or primary-subordinate relationship to one another; (2) the identification and documentation of derivation paths (upward) and allocation or flowdown paths (downward) of work products in the work product hierarchy; (3) the degree to which each element in a software development product establishes its reason for existing; and (4) discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks.

Verification and validation are independent procedures that are used together for checking that a product, service, or system meets requirements and specifications and that it fulfills its intended purpose. These are critical components of a quality management system such as ISO 9000. The words "verification" and "validation" are sometimes preceded with "independent", indicating that the verification and validation is to be performed by a disinterested third party. "Integration verification and validation" can be abbreviated as "IV&V".

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system's end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems.

References

  1. 1 2 "Linux kernel release 5.x — The Linux Kernel documentation". www.kernel.org. Retrieved 2021-03-25.
  2. IEEE Computer Society (1990). "IEEE Standard Glossary of Software Engineering Terminology". IEEE Standard. Archived from the original on 2018-06-15. Retrieved 2013-01-11.
  3. "Guide to the Software Engineering Body of Knowledge". IEEE Computer Society. Archived from the original on 7 December 2014. Retrieved 11 January 2013.
  4. 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.
  5. "7 Tools to Gather Better Software Requirements". 22 July 2015.
  6. Laplante, Phillip A. (2009). "Requirements Engineering for Software and Systems". CRC Press.{{cite web}}: Missing or empty |url= (help)

Further reading