Since IEEE was interested by requirements engineering and publish the following definition in its IEEE Std 610.12.-1990 : “A requirement is: (1) A condition or capability needed by a user to solve a problem or achieve an objective (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).

RUP and other software development approach use this definition.

IIBA in its BABOK 2.0 take a short circuit and make the following definition : a requirement (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 system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).

(1) is Business and organisational requirements while (2) is solution requirement.

For BABOK 2.0 (1) is splitted in Business requirements which categorize project goals within an organisation and stakeholder requirements  which categorize particular stakeholder needs. (2) are splitted in functional and non functional requirements.

It is astonishing how IIBA has ignored Enterprise Architecture initiative which aims at renewing how to manage requirements lifecycle in an enterprise transformation.

But, otherwise, requirements remains collected by all models we know since time immemorial : IDEF0, SADT, UML, BPMN,… with some refinements on non functional requirements.

Then what have we got on the play mat ?
[…]