urbanisation-si

urbanisation-si

Le catalogue des exigences de la phase A Vision de TOGAF : étape 4.1 de l’étude de cas

Réalisé par les analystes métier, les experts métier, les responsables métier et les architectes applicatifs et destiné aux architectes métier, aux architectes applicatifs et aux concepteurs logiciels, le catalogue des exigences a pour but d’expliciter les objectifs en besoins détaillés sur les composants de l’architecture d’entreprise et de concevoir le cahier des charges des évolutions du SI et de l'architecture métier.

 

exemple-mise-en-oeuvre-togaf-matrice-exigences-objectifs-strategiques-1.PNG
 

L’identification des exigences et relations avec les objectifs

Elle débute par l’analyse des objectifs stratégiques (le pourquoi et le quoi) et opérationnels (le comment).

 

Les exigences répondent à la question des caractéristiques fonctionnelles (Business Requirements) et non fonctionnelles (IS requirements)  (comme par exemple le RGPD : Règlement Général sur la Protection des Données, très à la mode en ce moment en Europe ou bien encore les aspects portant sur la sécurité). 

 

Voir en annexe à la fin de cet article la liste complète des exigences regroupées en IS requirements et Business Requirements.

 

Le profil UML pour TOGAF créé par Modelio, utilise le stéréotype de dépendance <<Guarantee>> signifiant que la satisfaction des objectifs est obtenue par les exigences qui devront être remplies.

 

Par exemple l’exigence « Trip reservation process automation » garantie l’atteinte de l’objectif « Reduce file processing times ».

 

Un objectif et une exigence ne peuvent pas être confondus. Le premier à une portée générale alors que la seconde est une solution du premier.

 

Deux autres stéréotypes de dépendance :

  • <<Assigned>> signifie qu’un objectif opérationnel est assigné à un acteur ou à une unité organisationnelle ou bien encore à un service métier, mais par contre il ne le sera jamais à un composant de SI.
  • <<Satisfy>> signifie qu’une exigence est satisfaite par un composant du SI.

 

La bonne pratique de rédaction veut qu’une exigence corresponde à une spécification de comportement et non comme un but à atteindre.

On peut utiliser les cas d’utilisation UML qui ont spécialement été inventés pour modéliser l’aspect fonctionnel du système (le système stockera les informations clients de manière persistante).

Voir l’article :

 

Un autre sur l’art de l’interview pour recueillir les exigences :

 

Les Mind Map sont considérés, tant par le monde académique que par le monde industriel, comme de puissants outils pour l’élicitation des exigences :

  

Les règles de vérification des exigences

Pour chaque exigence identifiée, on doit s’assurer qu’elle vérifie les critères suivants :

 

  • Atomique: autonome et pouvant être compris indépendamment des autres exigences ou élément de conception.
     
  • Complète :  elle doit être suffisamment détaillée pour que l’implémentation puisse se faire. Le niveau de complétude requis peut dépendre du point de vue, de la méthodologie, ainsi que l’état dans le cycle de vie, par exemple lorsque l'exigence est en cours d'examen ou de représentation.
     
  • Cohérence : aligné sur les besoins identifiés des parties prenantes et n’entre pas en conflit avec d'autres exigences.
     
  • Concision : ne contient aucun contenu superflu et détail inutile.
     
  • Réalisable : raisonnable et possible dans les limites du risque, du délai de réalisation et du budget alloué, ou considéré comme suffisamment réalisable pour persévérer dans l’analyse à travers d’expériences ou de prototypes (POC).
     
  • Non ambiguë : l'exigence doit être clairement énoncée de manière à préciser si une solution répond ou non aux exigences et si on l’exigence est liée à d’autres besoins.
     
  • Testable : a-t-on la capacité de vérifier que l'exigence a été remplie. Les niveaux acceptables de vérification de l'exécution dépendent du niveau d'abstraction de l'exigence ou de la conception.
     
  • Priorité : classée, groupée ou négociée en termes d'importance et de valeur apportée par rapport à toutes les autres exigences.
     
  • Compréhensible : explicitée avec la terminologie spécifique utilisée par les experts métier.

 

Référentiel d’exigences et leurs propriétés dans Modelio

 

exemple-mise-en-oeuvre-togaf-catalogue-des-exigences-0.PNG
 

  • Nom/Id : permet d’avoir un groupe nominal court résumant l’exigence. L’identifiant, sert à référencer les exigences dans le repository de l’AGL et à éviter les doublons.
     
  • Definition : décrit l’exigence
     
  • Benefit (Critical / Strong / Low) : type de bénéfice obtenu. Il s’agit de caractériser l'avantage qui revient aux parties prenantes à la suite de la mise en œuvre des exigences, mesuré par rapport aux buts et objectifs pour le changement. L'avantage fourni peut faire référence à une fonctionnalité spécifique, qualité souhaitée, ou objectif stratégique ou objectif métier. S'il y a plusieurs parties prenantes, chaque groupe peut percevoir les avantages différemment. Les techniques de résolution de conflit et la négociation peuvent être utilisés pour parvenir à un consensus sur le l’avantage global.
     
  • Cost : l'effort et les ressources nécessaires pour mettre en œuvre l'exigence.
  • Les informations sur les coûts proviennent généralement de l'équipe de mise en œuvre (MOE). On changer la priorité d'une exigence en fonction du coût et du risque. Le coût est souvent utilisé en conjonction avec d'autres critères, tels comme l’analyse coûts-bénéfices.
     
  • Risk (Strong / Medium / Low) : probabilité et impact qu’aura le risque s’il arrive. Il s’agit de la possibilité que l'exigence ne puisse pas fournir la valeur attendue, ou ne pas être réalisée du tout. Cela peut inclure de nombreux facteurs tels que la difficulté de la mise en œuvre d'une exigence ou la possibilité que les parties prenantes n’acceptent pas un composant de solution. S'il y a un risque que la solution ne soit pas techniquement réalisable, l'exigence la plus complexe est à prioriser « Strong » en haut de la liste afin de minimiser les ressources qui seront dépensées, avant d'apprendre qu'une solution proposée ne peut pas être livrée. Un POC (Proof Of Concept), c’est-à-dire un prototype ayant pour but de prouver qu’une solution fonctionne, peut être développé pour établir que les options à haut risque sont possibles.
     
  • Stability (Strong / Medium / Low) : les parties prenantes ne savent pas ce qu’ils veulent, on ne connait pas au début toutes les difficultés pour satisfaire l’exigence. Uune exigence n’est donc pas stable au moment où elle a été identifiée. La stabilité représente la probabilité pour que l'exigence change, soit parce qu'elle nécessite une analyse plus approfondie ou parce que les parties prenantes n'ont pas atteint un consensus à ce sujet. Si une exigence n'est pas stable, elle peut avoir une priorité « Low » afin de minimiser les retouches imprévues et les efforts inutiles.
     
  • Target Release : est ce que l’exigence va être prise en compte dans la version cible. La décision dépend du l’analyse entre le rapport des 3 critères :  Benefit, Cost, et Risk.
     
Par exemple une exigence avec un bénéfice faible pour un coût élevé et un risque fort aura une priorité faible.

 

BABOK (Guide to the Business Analysis Body of Knowledge)

Si vous aimez les cadres verbeux, comme l'est du reste TOGAF, et bien concernant l'analyse métier vous allez être servi avec l’institut IIBA (voir le lien : International Institute of Business Analysis ) qui vous a concocté un petit guide de 514 pages, le « BABOK (Guide to the Business Analysis Body of Knowledge) », qui se veut être une référence pour l’analyse métier.

 

L'objectif principal du Guide BABOK est de définir la profession d’analyste métier et de fournir un ensemble de bonnes pratiques.

BABOK est donc un cadre commun pour toutes les perspectives, décrivant les tâches d'analyse métier qui sont effectuées pour analyser correctement un changement ou évaluer la nécessité d'un changement.

Les six domaines de connaissance du Guide BABOK :

  • Planification et contrôle de l’analyse métier
  • Elicitation et collaboration
  • Gestion du cycle de vie des exigences
  • Analyse de la stratégie
  • Analyse des exigences et Définition de la conception (RADD)
  • Évaluation de la solution

Ces domaines décrivent la pratique de l'analyse métier telle qu'elle est appliquée dans les limites d'un projet ou à travers l'évolution de l'entreprise et de l’amélioration continue.

 

Conclusion

Une exigence spécifie un besoin ou une règle qui doit être satisfaite.

Une exigence peut spécifier une fonction qu'un système doit exécuter ou des critères de performance à atteindre.

 

Avec TOGAF, les exigences peuvent changer tout au long des phases ADM, voir l'article :

 

 

Un nombre important de facteurs externes ou internes peuvent impacter les exigences durant le projet : les lois changent, la concurrence est de plus en plus agressive, les utilisateurs ne savent pas ce qu’ils veulent, des nouvelles technologies apparaissent à des fréquences de plus en plus réduites

La solution est d’itérer le processus et d’intégrer à chaque nouvelle itération, la gestion des exigences et étudier s’il y des changements.

 

La modélisation des exigences est destinée à fournir une passerelle entre des outils de gestion d'exigences traditionnels et les autres modèles.

On pourra ainsi réutiliser des exigences dans d'autres produits ou projets.

Les scénarios typiques sont des exigences réglementaires, statutaires, ou contractuelles applicables à des produits et à des projets.

On doit pouvoir faire référence à une exigence qui peut donc se trouver dans des contextes multiples ou bien mettre à jour l'exigence d'origine et propager les modifications aux exigence réutilisées.

 

Le meilleur moyen, ayant largement fait ses preuves dans les projets même les plus complexes, pour décrire les exigences textuelles de manière graphique, tabulaire, ou arborescente et qui permet de les relier à d'autres éléments de modélisation est le diagramme d'exigences SysML (norme OMG).

Nous verrons cela dans le prochain article.

 

Rhona Maxwel

@rhona_helena

 

"Nous appellerons émotion une chute brusque de la conscience dans le magique."

Jean-Paul Sartre

 

  

Articles conseillés :

 

Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio

 

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation

 

Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)

 

Tutorial, exemple d’étude de cas TOGAF - Analyser les objectifs - étape 3.1 de Comment modéliser la phase A Vision de la méthode ADM 

 

Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst

  

Comment modéliser les objectifs stratégiques et opérationnels en phase A Vision de la méthode ADM TOGAF ? (étape 3.2 de notre étude de cas)

 

Cas complet de mise en œuvre TOGAF : l’artefact « catalogue d’objectifs » (étape 3.3 de notre didacticiel)

 

Annexe : Liste complète des exigences dans Modelio

IS requirements

Accounting ERP connection

The system must be linked to the existing accounting ERP. It must be compatible with stored data.

 

Client memorization

DISCOUNT TRAVEL wishes to retain its clients contact information (title, surname, first name, address, telephone number), and envisages subsequently developing its client follow-up. In particular, accompanying people declared in a file are potential clients for whom an address and telephone number are required.

 

Insurance range extendability

Other types of insurance (repatriation, flight, ?) are also being studied. The system must be able to evolve to take into account several types of insurance for a file.

 

Date of birth targeting evolution

Furthermore, DISCOUNT TRAVEL would like in future to be able to target its range of trips on the basis of the participant's age.

 

File memorization

However, DISCOUNT TRAVEL does not want to keep files once trips have taken place.

 

Business Requirements

IS access via website

The information system must allow the client to place and track his/her orders on the internet at any time and from any location in the world.

 

Client autonomy

The client must be able to place his/her trip orders from start to finish without the intervention of a sales representative.

 

Purchase automation

This activity will be automated in the new website through a direct connection with the "GIE" credit card server.

 

Trip reservation process automation

The order taking and order follow-up processes must be able to be carried out without human intervention.

 

Security

Confidentiality and reliability must be guaranteed. A representative of the company must be able to compensate for possible system dysfunctions at all times.

 

Client relationship management

Client contacts will be retained (greeting, first name, surname, addresse, telephone number, ...), in order to be able to perform client follow-up activities. In particular, people accompanying clients on trips are future potential clients, and contact with them must also be managed.

 

Marketing campaign management

Marketing campaigns will be put in place (e-mailing campaigns), in order to propose new offers. Alongside these campaigns, telephone campaigns will take place. For the most part, client service representatives will be responsible for these operations.

 

Satisfaction poll management

Satisfaction surveys will be set up. These will take place via email, or by completing forms during telephone interviews.  This must take place no later than a few days after the end of client trips. A monthly satisfaction report will constitute part of the overall company performance reporting schedule.

 

Load monitoring and personal satisfaction

An employee workload level indicator and satisfaction index will constitute part of the reporting schedule monitored by the general management team.



01/06/2018
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 221 autres membres