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 ?

BABOK 2.0 regarding Requirements management process. Enterprise Architecture regarding whole requirements lifecycle and models management, BISL for business requirements organisation.

Requirements management is today a big challenge for companies agility since, as long as they change, their requirements even more. Then, they need to management these changes to make their major endeavours successful.

I wonder who will start to work on an integrated view, not only to specify a new framework, but to fuel software tools to support a whole entreprise requirements lifecycle and a true Model Driven Enterprise Transformation.

Indeed, Requirements management softwares for Business or Enterprise are poorly integrated with Design software. This does not close the gap between enterprise architects and solution architected for governing programs and large projects.

Another point which need to be covered by softwares, is how to get and maintain links between gaps, target, as-is, to build roadmaps and projects, allowing muliple business scenarios, and versionning.

All these would improve greatly enterprise capability to transform. So, when software editor will decide take these points ?

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *