In
product development
In business and engineering, new product development (NPD) covers the complete process of bringing a new product to market, renewing an existing product or introducing a product in a new market. A central aspect of NPD is product design, along wi ...
and
process optimization
Process optimization is the discipline of adjusting a process so as to optimize (make the best or most effective use of) some specified set of parameters without violating some constraint. The most common goals are minimizing cost and maximizing ...
, 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
The engineering design process is a common series of steps that engineers use in creating functional products and processes. The process is highly iterative - parts of the process often need to be repeated many times before another can be entere ...
, including for example in
systems engineering
Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their enterprise life cycle, life cycles. At its core, systems engineering util ...
,
software engineering
Software engineering is a systematic engineering approach to software development.
A software engineer is a person who applies the principles of software engineering to design, develop, maintain, test, and evaluate computer software. The term '' ...
, or
enterprise engineering Enterprise engineering is the body of knowledge, principles, and practices used to design all or part of an enterprise.R.E. Giachetti (2010). ''Design of Enterprise Systems: Theory, Methods, and Architecture''. CRC Press, Boca Raton, FL. An enterpri ...
. It is a broad concept that could speak to any necessary (or sometimes desired) 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
A specification often refers to a set of documented requirements to be satisfied by a material, design, product, or service. A specification is often a type of technical standard.
There are different types of technical or engineering specificati ...
or requirement "spec" (often imprecisely referred to as "the" spec/specs, but there are actually different sorts of specifications) refers to an explicit, highly objective/clear (and often quantitative) requirement (or sometimes, ''set'' of requirements) to be satisfied by a material, design, product, or service.
A set of requirements is used as inputs into the design stages of
product development
In business and engineering, new product development (NPD) covers the complete process of bringing a new product to market, renewing an existing product or introducing a product in a new market. A central aspect of NPD is product design, along wi ...
. Requirements are also an important input into the verification process, since tests should trace back to specific requirements. Requirements show what elements and functions are necessary for the particular project. When
iterative methods of software development or
agile methods
In software development, agile (sometimes written Agile) practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/ end user(s), ad ...
are used, the system requirements are incrementally developed in parallel with design and implementation. With the
waterfall model
The waterfall model is a breakdown of project activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. ...
requirements are developed before design and implementation.
Origins of term
The term requirement has been in use in the software engineering community since at least the 1960s.
According to the ''Guide to the Business Analysis Body of Knowledge®'' version 2 from IIBA (
BABOK), a requirement is:
# A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
# A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
# A documented representation of a condition or capability as in (1) or (2).
This definition is based on IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.
Product versus process requirements
Requirements can be said to relate to two fields:
* Product requirements prescribe properties of a system or product.
* Process requirements prescribe activities to be performed by the developing organization. For instance, process requirements could specify the methodologies that must be followed, and constraints that the organization must obey.
Product and process requirements are closely linked; a product requirement could be said to specify the automation required to support a process requirement while a process requirement could be said to specify the activities required to support a product requirement. For example, a maximum development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement that the product be maintainable (a product requirement) often is addressed by imposing requirements to follow particular development styles (e.g.,
object-oriented programming
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code. The data is in the form of fields (often known as attributes or ''properties''), and the code is in the form of pr ...
), style-guides, or a review/inspection process (process requirements).
Types of requirements
Requirements are typically classified into types produced at different stages in a development progression, with the taxonomy depending on the overall model being used. For example, the following scheme was devised by the
International Institute of Business Analysis
The International Institute of Business Analysis (IIBA) is a professional association formed in October 2003 with the stated goal of supporting and promoting the discipline of business analysis.
IIBA offers help and information to business analys ...
in their
Business Analysis Body of Knowledge
''A Guide to the Business Analysis Body of Knowledge'' (BABOK) is a guide about business analysis, issued by the International Institute of Business Analysis (''IIBA''), attempting to reflect current best practice and to provide a framework that ...
(see also
FURPS
FURPS is an acronym representing a model for classifying software quality attributes (functional and non-functional requirements):
* Functionality - Capability (Size & Generality of Feature Set), Reusability (Compatibility, Interoperability, P ...
and
Types of requirements).
;
Architectural requirements
: Architectural requirements explain what has to be done by identifying the necessary integration of systems
structure
A structure is an arrangement and organization of interrelated elements in a material object or system, or the object or system so organized. Material structures include man-made objects such as buildings and machines and natural objects such as ...
and systems
behavior
Behavior (American English) or behaviour (British English) is the range of actions and mannerisms made by individuals, organisms, systems or artificial entities in some environment. These systems can include other systems or organisms as wel ...
, i.e.,
systems architecture A system architecture is the conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the ...
of a system.
: In
software engineering
Software engineering is a systematic engineering approach to software development.
A software engineer is a person who applies the principles of software engineering to design, develop, maintain, test, and evaluate computer software. The term '' ...
, they are called
architecturally significant requirements, which is defined as those requirements that have a measurable impact on a software system’s
architecture
Architecture is the art and technique of designing and building, as distinguished from the skills associated with construction. It is both the process and the product of sketching, conceiving, planning, designing, and constructing building ...
.
;
Business requirements
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 w ...
: High-level statements of the goals, objectives, or needs of an organization. They usually describe opportunities that an organization wants to realise or problems that they want to solve. Often stated in a
business case A business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written document, but may also come in the form of a short verbal agreement or presentation. The logic of the business case is that, ...
.
;
User (stakeholder) requirements
: Mid-level statements of the needs of a particular stakeholder or group of stakeholders. They usually describe how someone wants to interact with the intended solution. Often acting as a mid-point between the high-level business requirements and more detailed solution requirements.
;
Functional (solution) requirements
: Usually detailed statements of capabilities, behavior, and information that the solution will need. Examples include formatting text, calculating a number, modulating a signal. They are also sometimes known as ''capabilities''.
;
Quality-of-service (non-functional) requirements
: Usually detailed statements of the conditions under which the solution must remain effective, qualities that the solution must have, or constraints within which it must operate. Examples include: reliability, testability, maintainability, availability. They are also known as ''characteristics'', ''constraints'' or the ''
ilities
In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functi ...
.''
;
Implementation (transition) requirements
: Usually, detailed statements of capabilities or behavior required only to enable the transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required. Examples include recruitment, role changes, education, migration of data from one system to another.
;
Regulatory requirements
: Requirements defined by
laws
Law is a set of rules that are created and are law enforcement, enforceable by social or governmental institutions to regulate behavior,Robertson, ''Crimes against humanity'', 90. with its precise definition a matter of longstanding debate. ...
(Federal, State, Municipal, or Regional),
contracts
A contract is a legally enforceable agreement between two or more parties that creates, defines, and governs mutual rights and obligations between them. A contract typically involves the transfer of goods, services, money, or a promise to tran ...
(terms and conditions), or
policies (company, departmental, or project-level).
Characteristics of good requirements
The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged.
There are many more attributes to consider that contribute to the quality of requirements. If requirements are subject to rules of
data integrity
Data integrity is the maintenance of, and the assurance of, data accuracy and consistency over its entire Information Lifecycle Management, life-cycle and is a critical aspect to the design, implementation, and usage of any system that stores, proc ...
(for example) then accuracy/correctness and validity/authorization are also worthy attributes.
Traceability Traceability is the capability to trace something. In some cases, it is interpreted as the ability to verify the history, location, or application of an item by means of documented recorded identification.
Other common definitions include the capab ...
confirms that the requirement set satisfies the need (no more - and no less than what is required).
To the above some add Externally Observable, that is, the requirement specifies a characteristic of the product that is externally observable or experienced by the user. Such advocates argue that requirements that specify internal architecture, design, implementation, or testing decisions are probably constraints, and should be clearly articulated in the Constraints section of the Requirements document. The contrasting view is that this perspective fails on two points. First, the perspective does not recognize that the user experience may be supported by requirements not perceivable by the user. For example, a requirement to present
geocoded information to the user may be supported by a requirement for an interface with an external third party business partner. The interface will be imperceptible to the user, though the presentation of information obtained through the interface certainly would not. Second, a constraint limits design alternatives, whereas a requirement specifies design characteristics. To continue the example, a requirement selecting a web service interface is different from a constraint limiting design alternatives to methods compatible with a Single Sign-On architecture.
Verification
All requirements should be verifiable. The most common method is by test. If this is not the case, another verification method should be used instead (e.g. analysis, demonstration, inspection, or review of design).
Certain requirements, by their very structure, are not verifiable. These include requirements that say the system must ''never'' or ''always'' exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. As stated above all requirements must be verifiable.
Non-functional requirements, which are unverifiable at the software level, must still be kept as a documentation of customer intent. However, they may be traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from
backdoor
A back door is a door in the rear of a building. Back door may also refer to:
Arts and media
* Back Door (jazz trio), a British group
* Porta dos Fundos (literally “Back Door” in Portuguese) Brazilian comedy YouTube channel.
* Works so title ...
s may be satisfied by replacing it with a process requirement to use
pair programming
Pair programming is an software development technique in which two programmers work together at one workstation. One, the ''driver'', writes code while the other, the ''observer'' or ''navigator'', reviews each line of code as it is typed in. The ...
. Other non-functional requirements will trace to other system components and be verified at that level. For example, system reliability is often verified by analysis at the system level.
Avionics software
Avionics software is embedded software with legally mandated safety and reliability concerns used in avionics. The main difference between avionic software and conventional embedded software is that the development process is ''required by law' ...
with its complicated safety requirements must follow the
DO-178B
DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety-critical software used in certain airborne systems. It was jointly developed by the safety-critical working group RT ...
development process.
Activities that lead to the derivation of the system or software requirements. Requirements engineering may involve a
feasibility study
A feasibility study is an assessment of the practicality of a project or system. A feasibility study aims to objectively and rationally uncover the strengths and weaknesses of an existing business or proposed venture, opportunities and threats pr ...
or a ''conceptual analysis phase'' of the project and
requirements elicitation In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as "requirement gathering".
...
(gathering, understanding, reviewing, and articulating the needs of the
stakeholders) and
requirements analysis
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 ...
,
analysis
Analysis ( : analyses) is the process of breaking a complex topic or substance into smaller parts in order to gain a better understanding of it. The technique has been applied in the study of mathematics and logic since before Aristotle (38 ...
(checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct).
Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous
inspection
An inspection is, most generally, an organized examination or formal evaluation exercise. In engineering activities inspection involves the measurements, tests, and gauges applied to certain characteristics in regard to an object or activity. ...
have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis strives to address these issues.
There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they
#take a long time to produce - sometimes to the point of being obsolete once completed
#limit the implementation options available
#are costly to produce
Agile approaches evolved as a way of overcoming these problems, by baselining requirements at a high-level, and elaborating detail on a
just-in-time or ''last responsible moment'' basis.
Documenting requirements
Requirements are usually written as a means for communication between the different stakeholders. This means that the requirements should be easy to understand both for normal users and for developers. One common way to document a requirement is stating what the system must do. Example: 'The contractor must deliver the product no later than xyz date.' Other methods include
use cases
In software and systems engineering, the phrase use case is a polyseme with two senses:
# A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
# A potential scenario i ...
and
user stories
In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index ...
.
Changes in requirements
Requirements generally change with time. Once defined and approved, requirements should fall under
change control
Within quality management systems (QMS) and information technology (IT) systems, change control is a process—either formal or informal—used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. I ...
. For many projects, requirements are altered before the system is complete. This is partly due to the complexity of computer software and the fact that users don't know what they want before they see it. This characteristic of requirements has led to
requirements management
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 require ...
studies and practices.
Issues
Competing standards
There are several competing views of what requirements are and how they should be managed and used. Two leading bodies in the industry are the IEEE and the IIBA. Both of these groups have different but similar definitions of what a requirement is.
Disputes regarding the necessity and effects of software requirements
Many projects have succeeded with little or no agreement on requirements. Some evidence furthermore indicates that specifying requirements can decrease
creativity
Creativity is a phenomenon whereby something new and valuable is formed. The created item may be intangible (such as an idea, a scientific theory, a musical composition, or a joke) or a physical object (such as an invention, a printed literary w ...
and design performance Requirements hinder creativity and design because designers become overly preoccupied with provided information. More generally, some research suggests that software requirements are an
illusion
An illusion is a distortion of the senses, which can reveal how the mind normally organizes and interprets sensory stimulation. Although illusions distort the human perception of reality, they are generally shared by most people.
Illusions may o ...
created by misrepresenting design decisions as requirements in situations where no real requirements are evident.
Meanwhile, most
agile software development
In software development, agile (sometimes written Agile) practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/ end user(s), ad ...
methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead,
extreme programming
Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,"Human Centred Technology Workshop 2006 ", 2006, PD ...
for example describes requirements informally using
user stories
In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index ...
(short summaries fitting on an index card explaining one aspect of what the system should do), and considers it the developer's duty to directly ask the customer for clarification. Agile methodologies attempt to capture requirements in a series of automated
acceptance test
In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.
In systems eng ...
s.
Requirements creep
Scope creep
Scope creep (also called requirement creep, or kitchen sink syndrome) in project management refers to changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins. This can occur when the scope of a pr ...
may occur from requirements moving over time. In
Requirements management
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 require ...
the alteration of requirements is allowed but if not adequately tracked or preceding steps (business goals then user requirements) are not throttled by additional oversight or handled as a cost and potential program failure, then requirements changes are easy and likely to happen. It is easy for requirement changes to occur faster than developers are able to produce work, and the effort to go ''backwards'' as a result.
Multiple requirements taxonomies
There are multiple taxonomies for requirements depending on which framework one is operating under. (For example, the stated standards of IEEE, vice IIBA or U.S. DoD approaches). Differing language and processes in different venues or casual speech can cause confusion and deviation from desired process.
Process corruptions
A process being run by humans is subject to human flaws in governance, where convenience or desires or politics may lead to exceptions or outright subversion of the process and deviations from the textbook way the process is supposed to proceed. Examples include:
* Process with no rigor gets no respect - If exceptions or changes are common, such as the organization running it having little independence or power or not being reliable and transparent in records, it may lead to the overall process being ignored.
* New players wanting a do-over - e.g., The natural tendency of new people to want to change their predecessor's work to demonstrate their power or claims of value, such as a new CEO wanting to change the previous CEO's planning, including business goals, of something (such as a software solution) already in development, or a newly created office objects to current development of a project because they did not exist when user requirements were crafted, so they begin an effort to backtrack and re-baseline the project.
* Coloring outside the lines - e.g., Users wanting more control do not just input things that meet the requirements management definition of "user requirement" or priority level, but insert design details or favored vendor characteristic as user requirements or everything their office says as the highest possible priority.
* Showing up late - e.g., Doing little or no effort in requirements elicitation prior to development. This may be due to thinking they will get the same benefit regardless of individual participation, or that there is no point if they can just insert demands at the testing stage and next spin, or the preference to be always right by waiting for post-work critique.
Within the U.S. Department of Defense process, some historical examples of requirements issues are
* the M-2 Bradley issues of casual requirements movement portrayed in
Pentagon Wars
''The Pentagon Wars'' is a 1998 HBO military comedy film directed by Richard Benjamin and based on the book ''The Pentagon Wars: Reformers Challenge the Old Guard'' by Colonel James G. Burton, United States Air Force, about the development of t ...
;
* the F-16 growth from lightweight fighter concept of the
Fighter mafia The Fighter Mafia was a controversial group of U.S. Air Force officers and civilian defense analysts who, in the 1960s and 1970s, advocated for fighter design criteria in opposition to those of the design boards of the time. Their assertions include ...
, attributed to F-15 program attempting to sabotage competition or individual offices putting in local desires eroding the concept of being lightweight and low cost.
* enthusiasm ca. 1998 for 'Net-Ready' led to its mandate as Key Performance Parameter from the Net-Ready office, outside the office defining requirements process and not consistent to that office's previously defined process, their definition of what a KPP was, or that some efforts might not be appropriate or able to define what constituted 'Net-Ready'.
See also
*
Business requirements
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 w ...
*
Software requirements Software requirements 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 ...
*
Requirements engineering
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.
The first use of the term ''requirement ...
*
Requirements analysis
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 ...
*
Requirements elicitation In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as "requirement gathering".
...
*
Requirements management
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 require ...
*
Requirement prioritization Requirement prioritization is used in the Software product management for determining which candidate requirements of a software product should be included in a certain release. Requirements are also prioritized to minimize risk during development ...
*
Requirements traceability 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 whic ...
*
Specification (technical standard)
A specification often refers to a set of documented requirements to be satisfied by a material, design, product, or service. A specification is often a type of technical standard.
There are different types of technical or engineering specificati ...
*
Shall and will
''Shall'' and ''will'' are two of the English modal verbs. They have various uses, including the expression of propositions about the future, in what is usually referred to as the future tense of English.
Historically, prescriptive grammar sta ...
- phrasing
*
MoSCoW Method
The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requireme ...
- prioritisation technique
*
User Story
In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index ...
*
Use Case
In software and systems engineering, the phrase use case is a polyseme with two senses:
# A usage scenario for a piece of software; often used in the plural to suggest situations where a piece of software may be useful.
# A potential scenario ...
References
External links
{{Wiktionary
''Discovering System Requirements''
Software requirements