Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Architecture logicielle
  3. Spécifications
Extrait - Architecture logicielle Pour une approche organisationnelle, fonctionnelle et technique (2e édition)
Extraits du livre
Architecture logicielle Pour une approche organisationnelle, fonctionnelle et technique (2e édition) Revenir à la page d'achat du livre

Spécifications

Exigences

Tout est une question de vision. Dès lors qu’une entreprise se projette sur un marché logiciel, elle a une vision à plus ou moins long terme sur la problématique qu’elle cherche à résoudre ou le service rendu à travers les produits qu’elle va mettre sur le marché. L’entreprise devra être visionnaire, anticiper les besoins actuels et futurs du marché et des utilisateurs et prévoir la manière d’y répondre à travers un produit compétitif et adapté. Pour cela, il faut un peu de méthodologie et un zeste de formalisme. Ce chapitre traite précisément de ce sujet. Il va montrer comment formuler une vision d’entreprise à travers un produit et comment rédiger sa spécification en détaillant la nature intrinsèque des différents besoins et en précisant l’usage de ces documents tout au long de la chaîne de production informatique.

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 ?

a. Café

Les informaticiens adorent l’expression « ça fait le café », qui exprime que l’élément ainsi qualifié sait tout faire. Outre le plaisir sonore de l’allitération, cette expression peut revêtir des sens cachés. Nous avons déjà parlé des difficultés de pénétration du télétravail...

Ingénierie

Nous décrirons ici les diverses activités de gestion des exigences comme il est recommandé par les pratiques CMMI des niveaux 2 et 3. Le processus d’ingénierie des exigences comprend donc une phase de capture des besoins, une phase d’analyse et de négociation, une phase de documentation et une autre de gestion.

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...

Vision

Ce qui suit est une proposition de squelette pour un document nommé Scope and Vision. Ce modèle est fourni comme base d’écriture pour un document personnalisé qui suivra un formalisme conforme au processus de développement de l’entreprise.

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.

a. Fondements

Résume la raison d’être du nouveau produit. Fournit une description générale de l’histoire ou de la situation menant à la conclusion que ce produit devrait être développé.

b. Opportunité commerciale

Décrit l’opportunité de marché qui existe, ou le problème métier qui est résolu. Décrit le marché dans lequel un produit commercial sera en compétition ou l’environnement dans lequel un système d’information sera utilisé, incluant une évaluation comparative des produits concurrents et les solutions possibles, en indiquant pourquoi le produit proposé est attractif. Identifie les problèmes qui ne peuvent actuellement pas être résolus sans le produit...

Spécification

Ce qui suit est une proposition de squelette pour un document nommé Software Requirements Specification (SRS). Ce modèle est fourni comme base d’écriture pour un document personnalisé qui suivra un formalisme conforme au processus de développement de l’entreprise. Une SRS est un cahier des charges pour un produit logiciel. Ce document capture dans ses pages les besoins des utilisateurs sous forme d’exigences fonctionnelles ou non.

1. Introduction

a. Intention

Identifie le logiciel spécifié, son nom, sa version et le périmètre du produit couvert par la SRS.

b. Conventions

On décrit ici tous les standards ou conventions typographiques suivies lors de l’écriture de la SRS.

c. Audience

Décrit les différentes catégories de lecteurs à qui s’adresse le document (développeur, chef de projet, analyste…) et suggère un plan de lecture pertinent.

d. Cadre du projet

Fournit une courte description du système spécifié en incluant les objectifs, les bénéfices attendus en fonction des objectifs stratégiques de la société. On référence ici le document Scope and Vision, s’il en existe un.

e. Références

Liste tous les autres documents auxquels se réfère la SRS et auxquels le lecteur doit avoir accès. Ceci peut inclure les standards de codage, les modèles, des chartes graphiques…

2. Description générale

a. Perspective du produit

Décrit le contexte et l’origine du produit. Version spécifique d’une famille de produits, ou bien composant d’un produit plus vaste. On inclura alors un diagramme de...

Modélisation

Nous allons montrer dans cette partie comment travailler avec un modèle d’exigences UML. Il ne s’agit pas ici de tomber dans le formalisme des documents précédents mais plutôt de voir comment on peut gérer les exigences d’un système de manière centralisée.

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 :

images/04DP01.png

Figure 4.1 : Définition d’une exigence

b. Reporting

Voici une liste d’exigences pour la gestion des utilisateurs de notre système, exportée depuis le logiciel CASE via un modèle de document.

REQ011 - Manage User Accounts (Gérer les comptes utilisateur)

«Functional»

Status: Validated

Priority: Medium

Difficulty: Medium

Phase: 1.0

Version: 1.0

The system is required to store and maintain a list of client accounts in a repository (Le système est obligé de stocker et maintenir une liste de comptes client dans un dépôt).

REQ016 - Add Users (Ajouter des utilisateurs)

«Functional»

Status: Validated

Priority: Medium

Difficulty: Medium

Phase: 1.0

Version: 1.0

It must be possible to add new users to the client repository (Il doit être possible d’ajouter de nouveaux utilisateurs à la base de clients).

REQ017 - Remove User (Supprimer un utilisateur)

«Functional»

Status: Validated

Priority: Medium

Difficulty: Medium

Phase: 1.0

Version: 1.0

It is required that users within the repository may be deleted if required. If the user has existing transactions against their account, the delete is a logical delete only (Il est requis que les utilisateurs de la base clients soient supprimés si nécessaire. Si l’utilisateur a des transactions...