Risk assessed user requirements management (RUM) Ou management des besoins utilisateurs basé aur les risques
Quand une entreprise veut acheter, un évolutif de logiciel ou nouveau logiciel pour appuyer son activité, il est crucial de savoir quels sont les besoins relatés par les personnes qui vont réellement utiliser l’application ou être en support de celle-ci.
Dans de nombreux projets de développement de logiciel, les analystes ont souvent des difficultés à identifier de manière exhaustive les réels besoins utilisateurs.
Ceci conduit à des mauvaises compréhensions qui vont interrompre la communication entre les utilisateurs, les développeurs et les testeurs.
Le développement d’un logiciel inadapté, l’effort produit dans certains composants du logiciel qui sont moins importantes pour l’activité ou même du code inutile peuvent être le résultat de ce manque de communication, conduisant à un surcroît de développement et de coûts de test voire même, à retarder la mise en exploitation du logiciel.
Utiliser un modèle du style “Risk-Assessed User Requirements Management” (RUM) conduira à une meilleure communication et contribuera dans le développement d’un logiciel de meilleure qualité.
Le modèle principal est basé sur 4 phases.
Dans la phase 1, les Besoins Utilisateurs sont identifiés d’une manière structurée au moyen d’un User Requirements Hierarchy (TRH ou Hiérarchie des besoins utilisateurs)
Dans la phase 2, le modèle identifie le risque/importance des différents composants du logiciel
Dans la phase 3, le résultat de ces deux phases sont comparés et les éléments correspondants sont rapprochés. Par exemple, on pourrait obtenir l’affirmation suivante : “Le besoin utilisateur X est couvert par le Risque décrit dans l’élément Y”
Dans beaucoup de cas, il y aura un écart entre les besoins utilisateurs établis et les risques identifiés.
Ceci signifie que certains besoins utilisateurs ne correspondront à aucun risque, mais le plus important est que certains risques ne correspondront à aucun besoin utilisateur.
En comblant ces manques, la couverture et la qualité des besoins utilisateurs et l’impact et le niveau de risque (incl. solutions possibles) vont être améliorés.
Lorsque ceux-ci sont identifiés tôt dans le processus, la concentration, la coordination et la communication en sont d’autant améliorées.
Dans la phase 4, un critère d’acceptation sera donné aux besoins utilisateurs correspondant à des risques, de manière à vérifier s’ils sont conformes aux besoins de l’entreprise
L’objectif final du modèle RUM est de combiner l’analyse de différents aspects, le développement et les tests, dans une vue d’ensemble très tôt dans le projet, c’est donc un excellent outil pour prendre en compte les aspects suivants :
- Management des besoins
- Mesures du Processus
- Estimation de l’Effort de développement et des phases d’exécution
- Suivi de Projet
- Analyse de risque
- Communication
ps_testware a présenté cette nouvelle approche à la session SPIder “Project driven by requirements”, vous pouvez télécharger la présentation.
Vous pouvez nous contacter si vous le désirez pour en savoir plus sur cette approche ou les possibilités du Management des besoins utilisateurs basé sur les risques (RUM).