Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Toucher juste. Mars 2012

Transcription

1 Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 RequIREments EngINEERINg Toucher juste

2 TouchER juste L ingénierie des exigences: les bases L ingénierie des exigences sert à élaborer des exigences et à les gérer durant le cycle de vie entier du projet. Dans la pratique, l analyse des exigences ainsi qu un processus itératif se sont avérés particulièrement importants. PAR David Kurmann L ingénierie des exigences (requirements engineering) est une discipline jeune qui devient toujours plus présente. Son importance est actuellement reconnue. Il est évident que des exigences doivent être recensées, consignées et gérées si l on veut éviter les mauvaises surprises en fin de projet. Cependant, dans la pratique, de nombreux défis mettent à l épreuve la cohérence dans l ingénierie des exigences. Celle-ci requiert du temps et des ressources auprès des parties prenantes. La communication doit être garantie au-delà des frontières. Des décisions doivent être prises, ce qui suppose un accord entre les parties prenantes. Au cours du projet, un change management est nécessaire pour actualiser constamment les exigences consignées. Ces défis peuvent être maîtrisés grâce au savoir et à l expérience transmis dans ce numéro d ERNI Experience. Cet article présente tout d abord brièvement les notions les plus importantes, puis se concentre sur deux aspects du requirements engineering qui se sont révélés essentiels dans la pratique: l analyse des exigences et l exécution de plusieurs itérations pour parvenir à des exigences qui constituent une base stable pour le développement. Le requirements engineering se divise en deux sous-disciplines: requirements management et requirements development. Le requirements management concerne la gestion des exigences durant le cycle de vie entier du projet. Il est mené par le responsable de projet. L objectif est de parvenir à un accord entre le commanditaire et le fournisseur d un nouveau produit. Le résultat est une sorte de contrat qui est continuellement revu et examiné. Le requirements management constitue ainsi la base du requirements engineering. La seconde sous-discipline est le requirements development, à savoir l élaboration systématique des exigences. Le requirements engineer en est responsable. Dans le processus s est imposé un déroulement en quatre étapes: recensement, analyse, spécification et validation (voir illustration 1). Des méthodes différentes sont à disposition pour ces quatre phases. Exemple 1 Recensement et analyse des exigences dans une entreprise de services Une entreprise de services doit développer une nouvelle version de son logiciel central. Plusieurs techniques de recensement sont utilisées pour le requirements development. L observation de terrain en fait partie. On suit plusieurs utilisateurs du logiciel dans leur travail quotidien. On recense ainsi par exemple comment ils organisent leurs tâches et les documents qui y sont liés, combien dure quelle phase de travail, ce que le collaborateur effectue lui-même et pour quelles tâches il a besoin de soutien, et beaucoup d autres éléments encore. Des ateliers sont menés avec des représentants de différents départements utilisant tous le système, on aborde l utilisation future du système ainsi que les processus futurs. On recense ainsi autant les processus actuels réels dans la pratique que les attentes des utilisateurs face au nouveau système.

3 requirements engineering 4 5 L ingénierie des exigences se divise en deux sousdisciplines: requirements management et requirements development. Le requirements management concerne la gestion des exigences durant le cycle de vie entier du projet. La seconde sous-discipline est le requirements development, à savoir l élaboration systématique des exigences.

4 Plusieurs techniques de recensement sont utilisées pour le requirements development. L observation de terrain en fait partie. On suit plusieurs utilisateurs du logiciel dans leur travail quotidien. On recense ainsi par exemple comment ils organisent leurs tâches et les documents qui y sont liés, combien dure quelle phase de travail, ce que le collaborateur effectue lui-même et pour quelles tâches il a besoin de soutien, et beaucoup d autres éléments encore. GESTION DES EXIGENCES Listes d'exigences, gestion des modifications, gestion des versions, approbation des clients FORMULATION Analyse des parties prenantes Entretiens/Ateliers Observation sur le terrain Techniques de créativité VALIDATION Prototypes (graphique) Examen Prise de décisions Ill. 1: L ingénierie des exigences Développement des exigences Exigences Business Case BUSINESS ANALYSE Priorisation Niveaux des exigences Modèle de Kano SPÉCIFICATION Description textuelle Cas d utilisation Descriptions types (UML) Processus opérationnels (BPMN) Exigences de l'utilisateur Exigences du système SYSTÈME Exigences liées aux infrastructures Exigences techniques TECHNIQUE Ill 2: Niveaux

5 requirements engineering 6 7 Ces processus sont représentés par le biais de la méthode Use Case et discutés avec les différentes parties prenantes. Ce déroulement est exemplaire. Une tâche essentielle du requirements engineering est d analyser auquel des trois niveaux suivants appartiennent certaines exigences: vente, utilisateurs ou technique. différentes parties prenantes sont concernées et l environnement est également différent (voir illustration 2). Il convient en outre de ne pas prendre de décisions prématurées au niveau technique, ce qui pourrait restreindre la liberté quant aux exigences du système, et ces dernières ne devraient pas non plus être fixées de telle manière qu elles restreignent le choix du business case. Cette catégorisation est nécessaire, car les parties prenantes n en tiennent souvent pas compte. Ainsi, lors d entretiens, les utilisateurs expriment souvent le souhait d un certain outil et donc d une solution, et comprennent cela comme une exigence. Les utilisateurs intéressés par la technique font souvent des propositions qui ne concernent pas le niveau des utilisateurs, mais le niveau du système. Cette confusion est problématique, car des responsables différents sont compétents pour les trois niveaux, La confusion peut être évitée dès le recensement. Lorsque par exemple, lors d entretiens, des interlocuteurs évoquent des solutions, l analyste devrait les interroger sur les raisons de ces propositions jusqu à ce qu il parvienne à l exigence correspondante. Pour poursuivre l analyse, on peut s appuyer sur une représentation des exigences par le biais de modèles tels que des graphiques d activités ou des diagrammes de scénarios. Dans le présent exemple, on

6 Une tâche essentielle du requirements engineering est d analyser auquel des trois niveaux suivants appartiennent certaines exigences: vente, utilisateurs ou technique. Cette catégorisation est nécessaire, car les parties prenantes n en tiennent souvent pas compte. Ainsi, lors d entretiens, les utilisateurs expriment souvent le souhait d un certain outil et donc d une solution, et comprennent cela comme une exigence. Les utilisateurs intéressés par la technique font souvent des propositions qui ne concernent pas le niveau des utilisateurs, mais le niveau du système. Cette confusion est problématique, car des responsables différents sont compétents pour les trois niveaux, différentes parties prenantes sont concernées et l environnement est également différent

7 requirements engineering 8 9 a recouru à des Use Cases, qui présentent l avantage important d être compréhensibles pour tous les utilisateurs. Avec les Use Cases, on peut généralement voir au premier coup d œil si le processus décrit appartient au niveau de la vente, des utilisateurs ou du système. Un autre défi typique réside dans le fait que les parties prenantes ne peuvent souvent pas imaginer les solutions futures. C est pourquoi des itérations sont nécessaires dans le requirements engineering. Mieux l on maîtrise le requirements management, plus il est aisé pour l entreprise d envisager des étapes ultérieures de développement pour se confronter à des projets plus complexes de développement. Les deux articles suivants sont consacrés à deux tels projets: l outsourcing de tâches de développement et le passage à un département informatique orienté vers la vente. Exemple 2 Recours à des prototypes Une entreprise industrielle développe une nouvelle solution pour soutenir son processus central. Ce système soutiendra de nombreux intervenants différents tout au long de la chaîne de création de valeur. Il n est pas facile de consolider les attentes variées et de parvenir à une décision fondée. Dans ce cas, les exigences sont systématiquement recensées, analysées et spécifiées. Sur cette base, un prototype est développé pour la validation. Les parties prenantes peuvent alors s exprimer sur ce prototype. De cette manière, la qualité des exigences peut être nettement améliorée. Le recours à une description d interfaces graphiques d utilisateurs (GUI) comme prototypes a aussi fait ses preuves dans d autres projets. Dans ce cadre, il est important que le caractère provisoire du prototype GUI reste clairement tangible, de façon à ce que les parties prenantes ne critiquent pas des détails, mais prennent position sur l essentiel. ERNI Innovation in process and technology David Kurmann david.kurmann@erni.ch Activité de conseiller: formation et encadrement, amélioration des processus ingénierie des exigences

8 enables & delivers