requirement

1 required activity; "the requirements of his work affected his health"; "there were many demands on his time" [syn: demand]

2 anything indispensable; "food and shelter are necessities of life"; "the essentials of the good life"; "allow farmers to buy their requirements under favorable conditions"; "a place where the requisites of water fuel and fodder can be obtained" [syn: necessity, essential, requisite, necessary] [ant: inessential]

3 something that is required in advance; "Latin was a prerequisite for admission" [syn: prerequisite]

English

Etymology

Noun

1. A necessity or prerequisite; something required or obligatory.
2. Something asked.
3. (engineering) A statement (in domain specific terms) which specifies a verifiable constraint on an implementation that it shall undeniably meet or (a) be deemed unacceptable, or (b) result in implementation failure, or (c) result in system failure.

Derived terms

• functional requirement
• requirements engineering
• requirements analysis

Translations

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.

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).

Product versus process requirements

Projects are subject to three sorts of requirements. Business Requirements describe in business terms what must be delivered or accomplished to provide value. Product Requirements describe the system or product which is one of several possible ways to accomplish the business requirements. Process Requirements describe the processes the developing organization must follow and the constraints that they must obey.

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). Both user along with system requirements are vital for every system to develop(Surafel)

Requirements show what elements and function are necessary for the particular project.

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 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.

Some factors in developing requirements

Classification

Requirements are typically placed into these categories:

• Functional requirements describe the functions that the system is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities.
• Non-functional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.

They 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.

Good requirements

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.

Testability

Most requirements should be testable. If this is not the case, another verification method should be used instead (e.g. analysis, inspection or review of design). Testable requirements are an important component of validation.

Certain requirements, by their very structure, are not testable. 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 are often rewritten to state a more practical time period.

Un-testable non-functional requirements may still be kept as a documentation of customer intent; however they are usually 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. Avionics software with its complicated safety requirements must follow the DO-178B development process.

Testability is essentially a form of clarity, which indeed is necessary but can divert attention from other important issues. A requirement can be testable yet incorrect; and assessing testability often will not detect incorrect requirements. Moreover, testability 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 are more than 21 more powerful ways to test or evaluate requirements adequacy and more than 15 ways to strengthen testing or evaluation of design adequacy.

Requirements analysis

seemain Requirements analysis 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
2. begin to limit the implementation options available
3. 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 shall do. Example: "The contractor shall 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 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.

Disputes regarding the necessity of rigour in software requirements

Some modern software engineering methodologies like extreme programming question the need for rigorously describing software requirements, which they consider a moving target. Instead, they describe requirements informally using user stories (short summaries fitting on an index card explaining one aspect of what the system should do), and compose a series of acceptance test cases for this user story.

See also

• Furps - acronym of key requirement categories
• Requirements analysis
• Requirements management
• Requirements Traceability
• Use case

References

External links

• Discovering System Requirements

bare necessities, blackmail, call, call for, claim, condition, contribution, demand, demand for, desideration, desideratum, draft, drain, duty, essential, essentials, exaction, extortion, extortionate demand, heavy demand, imposition, impost, indent, indispensable, insistent demand, levy, must, must item, necessaries, necessities, necessity, need, need for, nonnegotiable demand, notice, occasion, order, precondition, prerequirement, prerequisite, provision, proviso, qualification, requisite, requisition, rush, rush order, sine qua non, stipulation, tax, taxing, the necessary, the needful, tribute, ultimatum, want, warning