Requirement
Encyclopedia
In engineering
, a requirement is a singular documented physical and functional need that a particular product or service must be or perform. It is most commonly used in a formal sense in systems engineering
, software engineering
, or enterprise engineering
. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a user.
In the classical engineering approach, sets of requirements are used as inputs into the design stages of product development
. 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. This is reflected in the waterfall model
of the software life-cycle. However, when iterative methods of software development
or agile methods
are used, the system requirements are incrementally developed in parallel with design and implementation.
Requirements engineering
is the set of activities that lead to the derivation of the system or software requirements. Requirements engineering may involve a feasibility study
, or a conceptual analysis phase of the project and requirements elicitation
(gathering, understanding, reviewing, and articulating the needs of the stakeholders) and requirements analysis
, analysis
(checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct).
Product and process requirements are closely linked. Process requirements often specify the activities that will be performed to satisfy 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
), style-guides, or a review/inspection process (process requirements).
. This type of requirement specifies something that the delivered system must be able to do. Another type of requirement specifies something about the system itself, and how well it performs its functions. Such requirements are often called Non-functional requirements
, or 'performance requirements' or 'quality of service requirements.' Examples of such requirements include usability, availability, reliability, supportability, testability and maintainability.
A collection of requirements define the characteristics or features of the desired system. A 'good' list of requirements as far as possible avoids saying how the system should implement the requirements, leaving such decisions to the system designer. Specifying how the system should be implemented is called "implementation bias" or "solution engineering". However, implementation constraints on the solution may validly be expressed by the future owner, for example for required interfaces to external systems; for interoperability with other systems; and for commonality (e.g. of user interfaces) with other owned products.
In software engineering, the same meanings of requirements apply, except that the focus of interest is the software itself.
Non-functional requirements can be further classified according to whether they are usability requirements, look and feel requirements, humanity requirements, performance requirements, maintainability requirements, operational requirements, safety requirements, reliability requirements, or one of many other types of requirements.
In software engineering
this categorization is useful because only functional requirements can be directly implemented in software. The non-functional requirements are controlled by other aspects of the system. For example, in a computer system reliability is related to hardware failure rates, and performance is controlled by CPU and memory. Non-functional requirements can in some cases be decomposed into functional requirements for software. For example, a system level non-functional safety requirement can be decomposed into one or more functional requirements. See FURPS
. In addition, a non-functional requirement may be converted into a process requirement when the requirement is not easily measurable. For example, a system level maintainability requirement may be decomposed into restrictions on software constructs or limits on lines or code.
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.
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 backdoors may be satisfied by replacing it with a process requirement to use pair programming
. 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
with its complicated safety requirements must follow the DO-178B
development process.
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
. 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
studies and practices.
methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead, extreme programming
for example describes requirements informally using user stories
(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 also typically capture requirements in a series of automated acceptance test
s.
Engineering
Engineering is the discipline, art, skill and profession of acquiring and applying scientific, mathematical, economic, social, and practical knowledge, in order to design and build structures, machines, devices, systems, materials and processes that safely realize improvements to the lives of...
, a requirement is a singular documented physical and functional need that a particular product or service must be or perform. It is most commonly used in a formal sense in systems engineering
Systems engineering
Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed over the life cycle of the project. Issues such as logistics, the coordination of different teams, and automatic control of machinery become more...
, software engineering
Software engineering
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...
, or enterprise engineering
Enterprise engineering
Enterprise engineering is a subdiscipline of systems engineering, which applies the knowledge and methods of systems engineering to the design of businesses. The discipline examines each aspect of the enterprise, including business processes, information flows, and organizational structure...
. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a user.
In the classical engineering approach, sets of requirements are used as inputs into the design stages of product development
New product development
In business and engineering, new product development is the term used to describe the complete process of bringing a new product to market. A product is a set of benefits offered for exchange and can be tangible or intangible...
. 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. This is reflected in the waterfall model
Waterfall model
The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.The waterfall...
of the software life-cycle. However, when iterative methods of software development
Iterative and incremental development
Iterative and Incremental development is at the liver of a cyclic software development process developed in response to the weaknesses of the waterfall model...
or agile methods
Agile software development
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams...
are used, the system requirements are incrementally developed in parallel with design and implementation.
Requirements engineering
Requirements engineering
Requirements engineering is a systems and software engineering process which covers all of the activities involved in discovering, documenting and maintaining a set of requirements for a computer-based system...
is the set of activities that lead to the derivation of the system or software requirements. Requirements engineering may involve a feasibility study
Feasibility study
Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of the existing business or proposed venture, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success. In its simplest...
, or a conceptual analysis phase of the project and requirements elicitation
Requirements elicitation
In requirements engineering, requirements elicitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders...
(gathering, understanding, reviewing, and articulating the needs of the stakeholders) and requirements analysis
Requirements analysis
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users...
, analysis
Requirements analysis
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users...
(checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct).
Product versus process requirements
Projects are subject to three sorts of requirements:- Business requirementsBusiness requirementsBusiness requirements is about creating structured representations of business activities, used to communicate how a new or existing business process should work. In IT projects business requirements is often a precursor to designing and building a new business application/system, or changing an...
describe in business terms what must be delivered or accomplished to provide value. - Product requirements describe properties of a system or product (which could be one of several ways to accomplish a set of business requirements.)
- Process requirements describe activities performed by the developing organization. For instance, process requirements could specify specific methodologies that must be followed, and constraints that the organization must obey.
Product and process requirements are closely linked. Process requirements often specify the activities that will be performed to satisfy 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
Object-oriented programming is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction,...
), style-guides, or a review/inspection process (process requirements).
Requirements in systems and software engineering
In systems engineering, a requirement can be a description of what a system must do, referred to as a Functional RequirementFunctional requirements
In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs ....
. This type of requirement specifies something that the delivered system must be able to do. Another type of requirement specifies something about the system itself, and how well it performs its functions. Such requirements are often called Non-functional requirements
Non-functional requirements
In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or...
, or 'performance requirements' or 'quality of service requirements.' Examples of such requirements include usability, availability, reliability, supportability, testability and maintainability.
A collection of requirements define the characteristics or features of the desired system. A 'good' list of requirements as far as possible avoids saying how the system should implement the requirements, leaving such decisions to the system designer. Specifying how the system should be implemented is called "implementation bias" or "solution engineering". However, implementation constraints on the solution may validly be expressed by the future owner, for example for required interfaces to external systems; for interoperability with other systems; and for commonality (e.g. of user interfaces) with other owned products.
In software engineering, the same meanings of requirements apply, except that the focus of interest is the software itself.
Types of product requirements
Requirements are typically placed into these categories:- Architectural requirementsSystems architectureA system architecture or systems 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 structure of the system...
describe what must be done by identifying the necessary system architecture of a systemSystemSystem is a set of interacting or interdependent components forming an integrated whole....
, - Functional requirementsFunctional requirementsIn software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs ....
describe the functionality that the system is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities. - Non-functional requirementsNon-functional requirementsIn systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or...
describe characteristics of the system that the user cannot affect or (immediately) perceive. Nonfunctional requirements are sometimes known as quality requirements or ilitiesIlitiesWithin systems engineering, quality attributes are non-functional requirements used to evaluate the performance of a system. These are sometimes named "ilities" after the suffix many of the words share...
. - Constraint requirements impose limits upon the design alternatives or project/process operations. No matter how the problem is solved the constraint requirements must be adhered to.
Non-functional requirements can be further classified according to whether they are usability requirements, look and feel requirements, humanity requirements, performance requirements, maintainability requirements, operational requirements, safety requirements, reliability requirements, or one of many other types of requirements.
In software engineering
Software engineering
Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software...
this categorization is useful because only functional requirements can be directly implemented in software. The non-functional requirements are controlled by other aspects of the system. For example, in a computer system reliability is related to hardware failure rates, and performance is controlled by CPU and memory. Non-functional requirements can in some cases be decomposed into functional requirements for software. For example, a system level non-functional safety requirement can be decomposed into one or more functional requirements. See FURPS
FURPS
FURPS is an acronym representing a model for classifying software quality attributes :* Functionality - Feature set, Capabilities, Generality, Security...
. In addition, a non-functional requirement may be converted into a process requirement when the requirement is not easily measurable. For example, a system level maintainability requirement may be decomposed into restrictions on software constructs or limits on lines or code.
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.| Characteristic | Explanation |
|---|---|
| Unitary (Cohesive) | The requirement addresses one and only one thing. |
| Complete | The requirement is fully stated in one place with no missing information. |
| Consistent | The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation. |
| Non-Conjugated (Atomic) | The requirement is atomic, i.e., it does not contain conjunctions. E.g., "The postal code field must validate American and Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate American postal codes" and (2) "The postal code field must validate Canadian postal codes". |
| Traceable | The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented. |
| Current | The requirement has not been made obsolete by the passage of time. |
| Feasible | The requirement can be implemented within the constraints of the project. |
| Unambiguous | The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are prohibited. |
| Mandatory | The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated. An optional requirement is a contradiction in terms. |
| Verifiable | The implementation of the requirement can be determined through one of four possible methods: inspection, demonstration, test or analysis. |
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
Geocoding
Geocoding is the process of finding associated geographic coordinates from other geographic data, such as street addresses, or zip codes...
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 or 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 backdoors may be satisfied by replacing it with a process requirement to use pair programming
Pair programming
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, types in code while the other, the observer , reviews each line of code as it is typed in...
. 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
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 and is optimized for safety.It is claimed that the...
with its complicated safety requirements must follow the DO-178B
DO-178B
DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a document dealing with the safety of software used in airborne systems....
development process.
Requirements analysis or requirements engineering
Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous inspectionSoftware inspection
Inspection in software engineering, refers to peer review of any work product by trained individuals who look for defects using a well defined process...
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
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 ways include use cases and user stories.Changes in requirements
Requirements generally change with time. Once defined and approved, requirements should fall under change controlChange Control
Change control within Quality management systems and Information Technology systems is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner...
. 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
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...
studies and practices.
Disputes regarding the necessity of rigour in software requirements
Most agile software developmentAgile software development
Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams...
methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead, extreme programming
Extreme Programming
Extreme programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements...
for example describes requirements informally using user stories
User story
In computer programming a user story is one or more sentences in the everyday or business language of the end user that captures what the user wants to achieve. User stories are used with Agile software development methodologies for the basis of what features that can be implemented...
(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 also typically capture requirements in a series of automated acceptance test
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...
s.
See also
- Business requirementsBusiness requirementsBusiness requirements is about creating structured representations of business activities, used to communicate how a new or existing business process should work. In IT projects business requirements is often a precursor to designing and building a new business application/system, or changing an...
- Software requirementsSoftware requirementsSoftware Requirements is a sub-field of Software engineering that deals with the elicitation, analysis, specification, and validation of requirements for software....
- Requirements analysisRequirements analysisRequirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users...
- Requirements elicitationRequirements elicitationIn requirements engineering, requirements elicitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders...
- Requirements managementRequirements managementRequirements 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...
- Requirement prioritization
- Requirements traceabilityRequirements traceabilityRequirements traceability is a sub-discipline of requirements management within software development and systems engineering. Requirements traceability is concerned with documenting the life of a requirement and to provide bi-directional traceability between various associated requirements...
- Specification (technical standard)Specification (technical standard)A specification is an explicit set of requirements to be satisfied by a material, product, or service. Should a material, product or service fail to meet one or more of the applicable specifications, it may be referred to as being out of specification;the abbreviation OOS may also be used...
- MoSCoW MethodMoSCoW MethodMoSCoW is a prioritisation technique used in business analysis and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement - also known as MoSCoW prioritisation or MoSCoW analysis.According to A Guide to the Business...
- prioritisation technique