Tag: IIBA

Quelles sont les nouvelles de la ligne de front des exigences ?

Posted on by admin

Lorsque l’IEEE s’est intéressée à l’ingénierie des exigences, elle a publié la définition suivante dans son standard IEEE Std 610.12.-1990: «Une exigence est : (1) Une condition ou une aptitude nécessaire à un utilisateur pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées.(3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).

RUP et les autres approches de développement de logiciels utilisent cette définition.

l’IIBA dans le BABOK 2,0 prend un court-circuit et élargit le périmètre de la définition de l’IEEE grâce au mot partie-prenante : “une exigence est (1) Une condition ou une aptitude nécessaire à une partie prenante pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées. (3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).

(1) concerne les exigences organisationnelles et métier tandis que (2) concerne les exigences de solution.

Pour le BABOK 2.0 (1) est découpé entre exigences d’entreprises classifient les objectifs globaux d’une organisation et les exigences des parties prenantes qui classifient les besoins des intervenants en particulier. (2) concerne les exigences fonctionnelles et non fonctionnelles.

Il est étonnant de voir comment l’IIBA a ignoré les initiatives d’Architecture d’Entreprise qui visent à renouveler la gestion des exigences au sein du cycle de vie de la transformation de l’entreprise.

Malgré tout, les exigences continuent à être collectées au travers des modèles que nous connaissons depuis les temps immémoriaux: IDEF0 , SADT , UML , BPMN , … avec quelques améliorations sur les exigences non fonctionnelles.

Alors qu’il y -t-il à la table de jeu?
[…]

Are there some news of requirements frontline ?

Posted on by admin

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 ?
[…]