Spécifications

1. Formulations

Nous parlerons abondamment de besoins. Ceux-ci sont de natures très variées, mais il convient de les exprimer dans un langage clair, l’objectif étant de garantir non seulement une communication constante entre toutes les parties prenantes du projet (nécessité ô combien critique), mais aussi de permettre un travail efficace avec les sous-traitants.

L’expression des besoins d’un produit ou d’une entreprise est protéiforme. La connaissance d’un produit est diluée dans de nombreux documents voire même dans la culture de l’entreprise ou bien cachée dans le cerveau de certains employés. Sa projection sur un document consultable par les parties prenantes du projet est nécessaire si on ne peut se permettre de perdre de l’information ou pour faciliter le transfert de compétences sur le produit.

Où trouve-t-on cette information ?

1. Capture

L’objectif de l’activité de capture est d’identifier les exigences ainsi que le périmètre du système à l’étude. Pour rédiger une spécification ou un document de vision, il est nécessaire de faire surgir les exigences de là où elles se terrent. Il existe un certain nombre de méthodes qui permettent de capturer les besoins auprès des parties prenantes du produit.

Parmi les méthodes classiques de capture, il y a la rédaction de cas d’utilisation (qui fera l’objet d’un chapitre à part entière). On peut aussi procéder à l’élaboration de prototypes qui aident à lever les ambiguïtés d’ergonomie et d’usage (bon complément aux cas d’utilisation).

On peut aussi se prêter à des séries d’entretiens, ou réunions avec les parties prenantes du produit pour leur soumettre des questions, travailler sur des maquettes pour faire apparaître leurs...

1. Exigences d’entreprise

Cette partie du document se concentre sur les exigences de l’entreprise qui constituent le fondement et la référence pour toutes les exigences de développement du produit associé. On peut recueillir les exigences de l’entreprise auprès d’un des clients, de la haute direction, d’un sponsor exécutif, d’un projet majeur et visionnaire, du département marketing, ou d’autres personnes qui ont une idée claire des raisons pour lesquelles le projet est en cours.

1. Introduction

2. Description générale

1. Modèle fonctionnel

Un modèle fonctionnel contient l’ensemble des exigences que le système doit satisfaire. Lorsqu’on modélise une architecture d’intégration, on s’attend à y trouver aussi des workflows de processus métier. L’intérêt d’un tel modèle est de pouvoir centraliser l’ensemble des artefacts fonctionnels du système.

a. Exigences

Dans un logiciel CASE (Computer Aided Software Engineering), on peut en général caractériser une exigence comme un artefact UML. Parmi les propriétés standard, nous avons la description courte qui identifie l’exigence en la préfixant par un numéro unique :

Figure 4.1 : Définition d’une exigence