Analyse des besoins

En ingénierie des systèmes et en ingénierie logicielle , l'analyse des exigences se concentre sur les tâches qui déterminent les besoins ou les conditions pour répondre au produit ou au projet nouveau ou modifié, en tenant compte des exigences éventuellement contradictoires des différentes parties prenantes , en analysant, en documentant, en validant et en gérant les exigences du logiciel ou du système .

L'analyse des exigences est essentielle au succès ou à l'échec d'un projet de système ou de logiciel . Les exigences doivent être documentées, exploitables, mesurables, testables, traçables, liées aux besoins ou opportunités commerciales identifiés et définies à un niveau de détail suffisant pour la conception du système .

D'un point de vue conceptuel, l'analyse des besoins comprend trois types d'activités :

• Recueil des exigences (par exemple, la charte ou la définition du projet), documentation des processus métier et entretiens avec les parties prenantes. Cette opération est parfois également appelée recueil des exigences ou découverte des exigences.
• Exigences d'enregistrement : les exigences peuvent être documentées sous diverses formes, comprenant généralement une liste récapitulative, et peuvent inclure des documents en langage naturel, des cas d'utilisation , des récits d'utilisateurs , des spécifications de processus et une variété de modèles, y compris des modèles de données.
• Analyse des exigences : déterminer si les exigences énoncées sont claires, complètes, non dupliquées, concises, valides, cohérentes et sans ambiguïté, et résoudre tout conflit apparent. L'analyse peut également inclure le dimensionnement des exigences.

L'analyse des exigences peut être un processus long et fatiguant au cours duquel de nombreuses compétences psychologiques délicates sont impliquées. Les nouveaux systèmes modifient l'environnement et les relations entre les personnes, il est donc important d'identifier toutes les parties prenantes, de prendre en compte tous leurs besoins et de s'assurer qu'elles comprennent les implications des nouveaux systèmes. Les analystes peuvent utiliser plusieurs techniques pour obtenir les exigences du client. Il peut s'agir de l'élaboration de scénarios (représentés sous forme de récits d'utilisateurs dans les méthodes agiles ), de l'identification de cas d'utilisation , de l'observation du lieu de travail ou de l'ethnographie , de la tenue d'entretiens ou de groupes de discussion (plus justement appelés dans ce contexte ateliers sur les exigences ou sessions de révision des exigences) et de la création de listes d'exigences. Le prototypage peut être utilisé pour développer un exemple de système qui peut être présenté aux parties prenantes. Si nécessaire, l'analyste utilisera une combinaison de ces méthodes pour établir les exigences exactes des parties prenantes, afin de produire un système qui répond aux besoins de l'entreprise. La qualité des exigences peut être améliorée grâce à ces méthodes et à d'autres :

• Visualisation. Utilisation d'outils favorisant une meilleure compréhension du produit final souhaité, tels que la visualisation et la simulation.
• Utilisation cohérente de modèles. Production d'un ensemble cohérent de modèles et de gabarits pour documenter les exigences.
• Documenter les dépendances . Documenter les dépendances et les interrelations entre les exigences, ainsi que toutes les hypothèses et congrégations.

Voir Analyse des parties prenantes pour une discussion sur les personnes ou organisations (entités juridiques telles que les entreprises et les organismes de normalisation) qui ont un intérêt légitime dans le système. Elles peuvent être affectées directement ou indirectement.

Dans les années 1990, l'accent a été mis sur l'identification des parties prenantes . Il est de plus en plus reconnu que les parties prenantes ne se limitent pas à l'organisation qui emploie l'analyste. Les autres parties prenantes sont notamment :

• toute personne qui exploite le système (opérateurs normaux et de maintenance)
• toute personne qui bénéficie du système (bénéficiaires fonctionnels, politiques, financiers et sociaux)
• toute personne impliquée dans l'achat ou l'approvisionnement du système. Dans une organisation de produits de grande consommation, la gestion des produits, le marketing et parfois les ventes agissent comme des consommateurs de substitution (clients de grande consommation) pour guider le développement du produit.
• organismes qui réglementent les aspects du système (régulateurs financiers, de sécurité et autres)
• personnes ou organisations opposées au système (parties prenantes négatives ; voir également Cas d'utilisation abusive )
• organismes responsables des systèmes qui interagissent avec le système en cours de conception.
• les organisations qui s’intègrent horizontalement à l’organisation pour laquelle l’analyste conçoit le système.

Les exigences ont souvent des implications interfonctionnelles qui sont inconnues des différentes parties prenantes et qui sont souvent omises ou incomplètement définies lors des entretiens avec les parties prenantes. Ces implications interfonctionnelles peuvent être obtenues en menant des sessions JRD dans un environnement contrôlé, animées par un facilitateur formé (analyste d'entreprise), au cours desquelles les parties prenantes participent aux discussions pour obtenir les exigences, analyser leurs détails et découvrir les implications interfonctionnelles. Un scribe dédié doit être présent pour documenter la discussion, ce qui permet à l'analyste d'entreprise de diriger la discussion dans une direction qui génère des exigences appropriées qui répondent à l'objectif de la session.

Les sessions JRD sont analogues aux sessions de conception d'applications conjointes . Dans les premières, les sessions énoncent les exigences qui guident la conception, tandis que les secondes énoncent les caractéristiques de conception spécifiques à mettre en œuvre pour satisfaire aux exigences suscitées.

Les listes d'exigences sous forme de contrats sont une méthode traditionnelle de documentation des exigences. Dans un système complexe, ces listes d'exigences peuvent s'étendre sur des centaines de pages.

Une métaphore appropriée serait celle d'une liste de courses extrêmement longue. De telles listes sont très mal vues dans l'analyse moderne, car elles se sont révélées lamentablement infructueuses dans la réalisation de leurs objectifs ; mais elles sont encore utilisées aujourd'hui.

• Fournit une liste de contrôle des exigences.
• Fournir un contrat entre le(s) sponsor(s) du projet et les développeurs.
• Pour un grand système, il est possible de fournir une description de haut niveau à partir de laquelle des exigences de niveau inférieur peuvent être dérivées.

• Ces listes peuvent s'étendre sur des centaines de pages. Elles ne sont pas destinées à servir de description conviviale de l'application souhaitée.
• Ces listes d'exigences résument toutes les exigences et le contexte est donc limité. L'analyste métier peut inclure le contexte des exigences dans la documentation de conception qui l'accompagne.
  • Cette abstraction n’a pas pour but de décrire comment les exigences s’adaptent ou fonctionnent ensemble.
  • La liste peut ne pas refléter les relations et les dépendances entre les exigences. Bien qu'une liste facilite la priorisation de chaque élément, la suppression d'un élément hors contexte peut rendre un cas d'utilisation ou une exigence métier entier inutile.
  • La liste ne remplace pas la nécessité d’examiner attentivement les exigences avec les parties prenantes afin d’obtenir une meilleure compréhension partagée des implications pour la conception du système/de l’application souhaité.
• La simple création d'une liste ne garantit pas son exhaustivité. L'analyste d'affaires doit s'efforcer de bonne foi de découvrir et de rassembler une liste substantiellement complète et de compter sur les parties prenantes pour signaler les exigences manquantes.
• Ces listes peuvent créer un faux sentiment de compréhension mutuelle entre les parties prenantes et les développeurs ; les analystes commerciaux sont essentiels au processus de traduction.
• Il est presque impossible de découvrir toutes les exigences fonctionnelles avant le début du processus de développement et de test. Si ces listes sont traitées comme un contrat immuable, les exigences qui émergent au cours du processus de développement peuvent générer une demande de changement controversée.

En alternative aux listes d'exigences, le développement logiciel agile utilise des user stories pour suggérer des exigences dans un langage courant.

Les bonnes pratiques prennent la liste des exigences comme de simples indices et demandent sans cesse « pourquoi ? » jusqu'à ce que les véritables objectifs commerciaux soient découverts. Les parties prenantes et les développeurs peuvent alors concevoir des tests pour mesurer le niveau de réalisation de chaque objectif jusqu'à présent. Ces objectifs évoluent plus lentement que la longue liste d'exigences spécifiques mais non mesurées. Une fois qu'un petit ensemble d'objectifs critiques et mesurés a été établi, des phases de prototypage rapide et de développement itératif courtes peuvent se dérouler pour fournir une valeur réelle aux parties prenantes bien avant que le projet ne soit à moitié terminé.

Un prototype est un programme informatique qui présente une partie des propriétés d'un autre programme informatique, permettant aux utilisateurs de visualiser une application qui n'a pas encore été construite. Une forme populaire de prototype est une maquette , qui aide les futurs utilisateurs et autres parties prenantes à se faire une idée de ce à quoi ressemblera le système. Les prototypes facilitent la prise de décisions de conception, car les aspects de l'application peuvent être vus et partagés avant la construction de l'application. Des améliorations majeures dans la communication entre les utilisateurs et les développeurs ont souvent été observées avec l'introduction des prototypes. Les premières vues des applications ont entraîné moins de modifications ultérieures et ont donc considérablement réduit les coûts globaux.

Les prototypes peuvent être des diagrammes plats (souvent appelés wireframes ) ou des applications fonctionnelles utilisant des fonctionnalités synthétisées. Les wireframes sont réalisés dans une variété de documents de conception graphique et suppriment souvent toute couleur de la conception (c'est-à-dire utilisent une palette de couleurs en niveaux de gris) dans les cas où le logiciel final est censé avoir une conception graphique appliquée. Cela permet d'éviter toute confusion quant à savoir si le prototype représente l'aspect visuel final de l'application.

Un cas d'utilisation est une structure permettant de documenter les exigences fonctionnelles d'un système, impliquant généralement un logiciel, qu'il soit nouveau ou en cours de modification. Chaque cas d'utilisation fournit un ensemble de scénarios qui expliquent comment le système doit interagir avec un utilisateur humain ou un autre système, pour atteindre un objectif commercial spécifique. Les cas d'utilisation évitent généralement le jargon technique, préférant plutôt le langage de l' utilisateur final ou de l'expert du domaine . Les cas d'utilisation sont souvent co-rédigés par des ingénieurs en exigences et des parties prenantes.

Les cas d'utilisation sont des outils d'une simplicité trompeuse permettant de décrire le comportement d'un logiciel ou d'un système. Un cas d'utilisation contient une description textuelle de la manière dont les utilisateurs sont censés travailler avec le logiciel ou le système. Les cas d'utilisation ne doivent pas décrire le fonctionnement interne du système, ni expliquer comment ce système sera mis en œuvre. Au lieu de cela, ils montrent les étapes nécessaires pour effectuer une tâche sans hypothèses séquentielles.

La spécification des exigences est la synthèse des découvertes concernant les besoins actuels de l'entreprise et l'évaluation de ces besoins pour déterminer et spécifier ce qui est nécessaire pour répondre aux besoins dans le cadre de la solution ciblée. La découverte, l'analyse et la spécification font passer la compréhension d'un état actuel à un état futur. La spécification des exigences peut couvrir toute l'étendue et la profondeur de l'état futur à réaliser, ou elle peut cibler des lacunes spécifiques à combler, telles que les bogues prioritaires du système logiciel à corriger et les améliorations à apporter. Étant donné que tout processus d'entreprise de grande envergure utilise presque toujours des logiciels et des systèmes de données et des technologies, la spécification des exigences est souvent associée aux créations de systèmes logiciels, aux achats, aux stratégies de cloud computing, aux logiciels intégrés dans des produits ou des appareils, ou à d'autres technologies. La définition plus large de la spécification des exigences inclut ou se concentre sur toute stratégie ou composant de solution, comme la formation, les guides de documentation, le personnel, les stratégies marketing, l'équipement, les fournitures, etc.

Les exigences sont classées de plusieurs manières. Voici les catégories courantes d'exigences liées à la gestion technique :

Énoncés des objectifs au niveau de l'entreprise, sans référence à des fonctionnalités détaillées. Il s'agit généralement de capacités de haut niveau (logicielles et/ou matérielles) nécessaires pour atteindre un résultat commercial.

Déclarations de faits et hypothèses qui définissent les attentes du système en termes d'objectifs de mission, d'environnement, de contraintes et de mesures d'efficacité et d'adéquation (MOE/MOS). Les clients sont ceux qui exécutent les huit fonctions principales de l'ingénierie des systèmes, l'opérateur étant le client principal. Les exigences opérationnelles définiront le besoin de base et répondront au minimum aux questions posées dans la liste suivante :

• Distribution ou déploiement opérationnel : Où le système sera-t-il utilisé ?
• Profil ou scénario de mission : Comment le système accomplira-t-il son objectif de mission ?
• Performances et paramètres associés : Quels sont les paramètres critiques du système pour accomplir la mission ?
• Environnements d'utilisation : Comment utiliser les différents composants du système ?
• Exigences d’efficacité : Dans quelle mesure le système doit-il être efficace ou efficient dans l’accomplissement de sa mission ?
• Cycle de vie opérationnel : combien de temps le système sera-t-il utilisé par l’utilisateur ?
• Environnement : Dans quels environnements le système sera-t-il censé fonctionner de manière efficace ?

Les exigences architecturales expliquent ce qui doit être fait en identifiant l' architecture système nécessaire d'un système .

Les exigences comportementales expliquent ce qui doit être fait en identifiant le comportement nécessaire d'un système.

Les exigences fonctionnelles expliquent ce qui doit être fait en identifiant la tâche, l'action ou l'activité nécessaire qui doit être accomplie. L'analyse des exigences fonctionnelles sera utilisée comme fonction de niveau supérieur pour l'analyse fonctionnelle.

Les exigences non fonctionnelles sont des exigences qui spécifient des critères pouvant être utilisés pour juger le fonctionnement d’un système, plutôt que des comportements spécifiques.

La mesure dans laquelle une mission ou une fonction doit être exécutée est généralement mesurée en termes de quantité, de qualité, de couverture, de rapidité ou de préparation. Au cours de l'analyse des besoins, les exigences de performance (dans quelle mesure doivent-elles être exécutées) seront développées de manière interactive pour toutes les fonctions identifiées en fonction des facteurs du cycle de vie du système et caractérisées en termes de degré de certitude dans leur estimation, de degré de criticité pour le succès du système et de leur relation avec d'autres exigences.

Les exigences de « construction », de « codage » et d'« achat » pour les produits et les exigences de « mode d'exécution » pour les processus sont exprimées dans des packages de données techniques et des manuels techniques.

Exigences implicites ou transformées à partir d'exigences de niveau supérieur. Par exemple, une exigence de longue portée ou de vitesse élevée peut entraîner une exigence de conception de faible poids.

Une exigence est établie en divisant ou en répartissant d'une autre manière une exigence de haut niveau en plusieurs exigences de niveau inférieur. Exemple : un article de 100 livres composé de deux sous-systèmes peut entraîner des exigences de poids de 70 livres et de 30 livres pour les deux articles de niveau inférieur.

Les modèles de catégorisation des exigences bien connus incluent FURPS et FURPS+, développés chez Hewlett-Packard .

Steve McConnell, dans son livre Rapid Development , détaille un certain nombre de façons dont les utilisateurs peuvent inhiber la collecte des exigences :

• Les utilisateurs ne comprennent pas ce qu’ils veulent ou n’ont pas une idée claire de leurs besoins
• Les utilisateurs ne s’engageront pas à respecter un ensemble d’exigences écrites
• Les utilisateurs insistent sur de nouvelles exigences une fois le coût et le calendrier fixés
• La communication avec les utilisateurs est lente
• Les utilisateurs ne participent souvent pas aux évaluations ou sont incapables de le faire
• Les utilisateurs sont techniquement peu sophistiqués
• Les utilisateurs ne comprennent pas le processus de développement
• Les utilisateurs ne connaissent pas la technologie actuelle

Cela peut conduire à une situation dans laquelle les exigences des utilisateurs continuent de changer même lorsque le développement du système ou du produit a commencé.

Les problèmes possibles causés par les ingénieurs et les développeurs lors de l'analyse des exigences sont les suivants :

• Une inclination naturelle à écrire du code peut conduire à une mise en œuvre commençant avant que l'analyse des exigences ne soit terminée, ce qui peut entraîner des modifications du code pour répondre aux exigences réelles une fois qu'elles sont connues.
• Le personnel technique et les utilisateurs finaux peuvent avoir des vocabulaires différents. Par conséquent, ils peuvent croire à tort qu'ils sont en parfaite harmonie jusqu'à ce que le produit fini soit livré.
• Les ingénieurs et les développeurs peuvent essayer d’adapter les exigences à un système ou à un modèle existant, plutôt que de développer un système spécifique aux besoins du client.

Une solution tentée aux problèmes de communication a été de faire appel à des spécialistes en analyse commerciale ou systémique.

Les techniques introduites dans les années 1990 comme le prototypage , le langage de modélisation unifié (UML), les cas d’utilisation et le développement agile de logiciels sont également destinées à apporter des solutions aux problèmes rencontrés avec les méthodes précédentes.

Une nouvelle catégorie d' outils de simulation ou de définition d'applications a également fait son apparition sur le marché. Ces outils sont conçus pour combler le fossé de communication entre les utilisateurs professionnels et l'organisation informatique, et également pour permettre aux applications d'être « testées sur le marché » avant la production du code. Les meilleurs de ces outils offrent :

• tableaux blancs électroniques pour esquisser les flux d'application et tester les alternatives
• capacité à capturer la logique métier et les besoins en données
• capacité à générer des prototypes haute fidélité qui imitent étroitement l'application finale
• interactivité
• possibilité d'ajouter des exigences contextuelles et d'autres commentaires
• capacité des utilisateurs distants et distribués à exécuter et à interagir avec la simulation