In engineering, a requirement is a singular documented need of what a particular product or service should be or do. It is most commonly used in a formal sense in systems engineering or software engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order 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 show what elements and functions are necessary for the particular project.
The requirements development phase may have been preceded by a feasibility study, or a conceptual analysis phase of the project. The requirements phase may be broken down into requirements elicitation (gathering the requirements from stakeholders), analysis (checking for consistency and completeness), specification (documenting the requirements) and verification (making sure the specified requirements are correct).
The Product and Process requirements are closely linked. Process requirements are often imposed as a way of achieving some higher-level 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 for the product to be maintainable (a Product requirement) often is traced to by requirements to follow particular development styles (e.g., object-oriented programming), style-guides, or a review/inspection process (Process requirements).
In systems engineering, a requirement can be a description of what a system must do, referred to as a Functional Requirement. 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 availability, testability, maintainability, and ease-of-use.
A collection of requirements define the characteristics or features of the desired system. A 'good' list of requirements generally avoids saying how the system should implement the requirements, leaving such decisions to the system designer. Describing how the system should be implemented is known as implementation bias or "solutioneering".
In software engineering, the same meaning of requirements apply, except that the focus of interest is the software itself.
Requirements are typically placed into these categories:
Non-functional requirements can be further classified according to whether they are performance requirements, maintainability 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, performance 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.
The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to his general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged.
|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.|
|Correct||The requirement meets all or part of a business need as authoritatively stated by stakeholders.|
|Current||The requirement has not been made obsolete by the passage of time.|
|Externally Observable||The requirement specifies a characteristic of the product that is externally observable or experienced by the user. "Requirements" that specify internal architecture, design, implementation, or testing decisions are properly constraints, and should be clearly articulated in the Constraints section of the Requirements document.|
|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.|
|Verifiable||The implementation of the requirement can be determined through one of four possible methods: inspection, analysis, demonstration, or test.|
Certain requirements, by their very structure, are not verifiable. These include requirements that say the system shall 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 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 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.
Verifiability is necessary for a requirement but there're other important issues. A requirement can be verifiable yet incorrect; and assessing verifiability alone will not detect incorrect requirements. Moreover, verification is totally irrelevant with regard to a requirement which has been overlooked. Mere analysis, inspection, or review alone will find some of these issues but generally is far weaker than usually is realized.
There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they