Requirement


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.
A set of requirements is 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. When iterative methods of software development or agile methods are used, the system requirements are incrementally developed in parallel with design and implementation. With the waterfall model 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, a requirement is:
  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. 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.
  3. A documented representation of a condition or capability as in or.
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 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 may be imposed to help achieve a maximum sales price requirement ; a requirement that the product be maintainable often is addressed by imposing requirements to follow particular development styles, style-guides, or a review/inspection process.

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 in their Business Analysis Body of Knowledge.
; Architectural requirements
; Business requirements
; User requirements
; Functional requirements
; Quality-of-service requirements
; Implementation requirements
; Requirements bylaws
Which includes all requirements that should be followed by laws that may enforce By;
1- Outer sources such as Federal Requirements, Municipality, IRS, Employees organization, Engineering organization, Environment entities or requirements that enforced by contracts terms and conditions.
2- Organization source: such as your organization laws that should be followed or requirements that comes from the project type, location and project specifications.

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.
CharacteristicExplanation
Unitary The requirement addresses one and only one thing.
CompleteThe requirement is fully stated in one place with no missing information.
ConsistentThe requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.
Non-Conjugated 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: "The postal code field must validate American postal codes" and "The postal code field must validate Canadian postal codes".
TraceableThe requirement meets all or part of a business need as stated by stakeholders and authoritatively documented.
CurrentThe requirement has not been made obsolete by the passage of time.
UnambiguousThe requirement is concisely stated without recourse to technical jargon, acronyms, 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 avoided.
Specify ImportanceMany requirements represent a stakeholder-defined characteristic the absence of which will result in a major or even fatal deficiency. Others represent features that may be implemented if time and budget permits. The requirement must specify a level of importance.
VerifiableThe implementation of the requirement can be determined through basic possible methods: inspection, demonstration, test or analysis.

There are many more attributes to consider that contribute to the quality of requirements. If requirements are subject to rules of data integrity then accuracy/correctness and validity/authorization are also worthy attributes. Traceability confirms that the requirement set satisfies the need.
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.
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.
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 and requirements analysis, analysis, specification and validation.
Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous inspection 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
  1. take a long time to produce - sometimes to the point of being obsolete once completed
  2. limit the implementation options available
  3. 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 and user stories.

Changes in requirements

Requirements generally change with time. Once defined and approved, requirements should fall under change control. 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.

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 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 created by misrepresenting design decisions as requirements in situations where no real requirements are evident.
Meanwhile, most agile software development 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, 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 tests.

Requirements creep

may occur from requirements moving over time. In Requirements management the alteration of requirements is allowed but if not adequately tracked or preceding steps 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. . 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:
Within the U.S. Department of Defense process, some historical examples of requirements issues are