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

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 usability, availability, reliability, supportability, testability, maintainability, and (if defined in a way that's verifiably measurable and unambiguous) 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 may be known as implementation bias or "solution engineering". However, implementation constraints (aka solution requirements) on the solution may be validly expressed by the future owner, for example for communality reasons with other owned products.