Objet
  • Obtenir un consensus sur le problème à résoudre.
  • Identifier les parties prenantes concernées par le système.
  • Définir les limites du système.
  • Décrire les principales caractéristiques du système.
Rôle :  Analyste système 
Fréquence : Selon les besoins. Généralement une fois pour chaque itération dans les phases Création et Elaboration, puis selon les besoins lors des phases ultérieures.
Etapes
Artefacts d'entrée :    Artefacts de sortie :   
Guides d'utilisation de l'outil :   

Détails sur l'enchaînement des activités :   


Obtenir un consensus sur le problème à résoudre Haut de la page

Une façon simple d'obtenir un consensus sur la définition du problème consiste à le mettre par écrit pour voir si tout le monde est d'accord.

Demandez au groupe : Quel est le problème ?

  • Très souvent, on s'attelle immédiatement à la recherche d'une solution, sans avoir d'abord pris le temps de bien comprendre le problème. Mettez le problème par écrit et voyez si tout le monde est d'accord avec votre définition.

Ensuite, redemandez au groupe : Quel est le problème réel ?

  • Recherchez les causes, ou le "problème à l'origine du problème". Le vrai problème se cache souvent derrière un problème de façade.

N'acceptez pas la première formulation du problème. Continuez à demander "pourquoi ?" pour identifier la "véritable nature" du problème.

Parfois, le groupe est tellement convaincu de la solution à mettre en place qu'il est difficile de mettre en évidence le problème sous-jacent. Dans ce cas, il peut être intéressant de répertorier les avantages de la solution envisagée, puis de chercher à identifier les problèmes résolus par ces avantages. Vous pourrez alors déterminer si ces problèmes sont de "réels" problèmes auxquels l'organisation est confrontée. Parmi les techniques couramment utilisées pour identifier le problème derrière le problème, nous citerons le ../workguid/wg_brnst.htm -- This hyperlink in not present in this generated websitebrainstorming, les ../workguid/wg_fish.htm -- This hyperlink in not present in this generated websitediagrammes causes-effets et les ../workguid/wg_paret.htm -- This hyperlink in not present in this generated websitediagrammes de Pareto.

Identifier les parties prenantes Haut de la page

Selon le niveau de compétence de l'équipe de développement, l'identification des parties prenantes peut être une étape simple ou complexe. Souvent, il suffit d'interroger les décisionnaires, les utilisateurs potentiels et autres parties concernées. Les questions suivantes vous seront utiles :

  • Qui sont les utilisateurs du système ?
  • Qui est l'acheteur du système ?
  • Qui d'autre sera affecté par les résultats obtenus via le système ?
  • Qui sera chargé d'évaluer et de valider le système lorsqu'il sera livré et déployé ?
  • Existe-t-il d'autres utilisateurs internes et externes dont les besoins doivent être pris en compte ?
  • Qui va gérer le nouveau système ?
  • Avons-nous oublié quelqu'un ?
  • OK, avons-nous oublié quelqu'un d'autre ?

Commencez à définir les profils des utilisateurs potentiels (ou réels) du système.  Ils seront mis en correspondance avec les rôles des acteurs humains du système en cours de développement.  Les premières informations sur les principaux utilisateurs et leur environnement doivent être incluses dans le document Vision

Définir les limites du système Haut de la page

Les limites du système définissent la frontière entre la solution et le monde réel autour de cette solution. En d'autres termes, les limites du système définissent une enveloppe dans laquelle se trouve la solution. Sous forme d'entrées et de sorties, des informations sont échangées entre le système et les utilisateurs qui se trouvent en dehors du système. Toutes les interactions avec le système ont lieu via des interfaces entre le système et le monde extérieur.

Souvent, les limites du système sont évidentes. Par exemple, les limites d'un gestionnaire de contacts shrink-wrap mono-utilisateur qui s'exécute sous Microsoft Windows® sont relativement claires. Il n'y a qu'un seul utilisateur et une seule plate-forme. Les interfaces entre l'utilisateur et l'application se résument aux boîtes de dialogue via lesquelles l'utilisateur peut entrer des informations dans le système, et aux rapports de sortie et chemins de communication utilisés par le système pour documenter et transmettre ses réponses.

Il est souvent efficace d'utiliser les acteurs pour définir et décrire les limites du système. Voir Activité : Identifier les acteurs et les cas d'utilisation

Identifier les contraintes applicables au système Haut de la page

Il existe un certain nombre de contraintes à prendre en compte. La plupart de ces informations sont consignées dans l'artefact Spécifications supplémentaires . Vous trouverez ci-dessous une liste des sources de contraintes potentielles et des questions à poser :

  • Politique : Existe-t-il des problèmes politiques internes ou externes susceptibles d'affecter les solutions potentielles ? Entre départements ?
  • Economie : Quelles sont les contraintes financières ou budgétaires applicables ? Existe-t-il des considérations relatives au coût des marchandises vendues ou à la tarification des produits ? Certains problèmes de licence doivent-ils être pris en compte ?
  • Environnement : Existe-t-il des contraintes environnementales ou réglementaires ? Légales ? D'autres standards qui nous limitent ?
  • Technique : Sommes-nous limités dans nos choix technologiques ? Sommes-nous contraints de travailler avec les plates-formes et technologies existantes ? Existe-t-il des technologies nouvelles qu'il nous est impossible d'envisager ?
  • Faisabilité : Le planning est-il défini ? Sommes-nous limités aux ressources existantes ? Pouvons-nous utiliser de la main d'oeuvre extérieure ? Pouvons-nous accroître les ressources ? Temporairement ? De façon définitive ?
  • Système : La solution doit-elle être mise en oeuvre sur nos systèmes existants ? Devons-nous assurer la compatibilité avec les solutions existantes ? Quels sont les systèmes d'exploitation et environnements à prendre en charge ?

Les informations recueillies ici serviront à rédiger les contraintes de conception définies dans l'artefact Spécifications supplémentaires.

Formuler le problème Haut de la page

Avec l'ensemble du groupe, travaillez sur un chevalet et décrivez chaque problème identifié à l'aide du canevas suivant :

Le problème de <décrire le problème>
affecte <parties prenantes affectées par le problème>.
Les conséquences de ce problème sont : <répercussions du problème>.
Une solution adaptée permettrait de <répertorier les principales caractéristiques d'une solution adaptée>.

Ce canevas a pour but de vous aider à distinguer les solutions/réponses des problèmes/questions.

Exemple :

Le problème de : résolution insatisfaisante et tardive des problèmes de service après-vente
affecte : nos clients, notre personnel du service après-vente et nos techniciens de maintenance.
Les conséquences de ce problème sont : clients mécontents, niveau de qualité insuffisant, employés insatisfaits et perte de chiffre d'affaires.
Une solution adaptée permettrait de :
fournir un accès en temps réel à une base de données de dépannage pour le personnel de support et de faciliter l'affectation immédiate de techniciens de maintenance sur les sites nécessitant réellement leur intervention.

Définir les caractéristiques du système Haut de la page

A partir de la liste d'avantages établie, définissez une liste des caractéristiques souhaitées pour le système. Décrivez-les brièvement et affectez-leur des attributs afin de définir leur état général et leur niveau de priorité au sein du projet .

Evaluer vos résultats Haut de la page

Vous devez évaluer votre vision à ce stade afin de vous assurer que votre travail semble correct, mais il est inutile de faire un contrôle détaillé. Voir les points de contrôle applicables à la vision dans Activité : Revoir les exigences.



RUP (Rational Unified Process)   2003.06.15