3.1. Expression et analyse du besoin

Objectifs

• Être capable de rédiger le cahier des charges de votre projet

• Savoir exprimer et analyser le besoin

Le cycle en « V » est un grand classique du cycle de développement d’un produit (cycle en V wikipedia). Il va de l’expression du besoin à la livraison d’un produit. Le réalisation d’un cahier des charges est la première étape de ce cycle.

3.1.1. Concepts

3.1.1.1. Les acteurs du projet

Indication

Maître d’ouvrage:

• Définition : client qui demande la réalisation

• Synonyme : client, product owner

Indication

Maître d’œuvre:

• Définition : fournisseur qui réalise le projet

• Synonyme: Développeur, fournisseur, prestataire, concepteur

3.1.1.2. Le besoin

La réussite d’un projet passe impérativement par la définition écrite, détaillée, précise, exhaustive et évaluable du besoin et des contraintes. Les phases d’expression et d’analyse du besoin permettent de décrire les fonctionnalités du logiciel et les contraintes sous lesquelles celui-ci doit être réalisé.

Indication

Expression du besoin

Les besoins sont exprimés par le maître d’ouvrage dans le cahier des charges et rédigés en langage naturel. L’expression du besoin est souvent associée à la description d’un contexte et de contraintes.

Indication

Analyse du besoin

L’analyse du besoin est réalisée par le maître d’œuvre en collaboration avec le maître d’ouvrage. Il s’agit d’identifier les fonctionnalités du produit à réaliser, sa faisabilité et sont coût. Pour être réellement utilisable, l’analyse doit également fournir des critères de validation et de qualité.

3.1.1.3. Différence entre le besoin et la fonction

Le besoin est à diférencier de la fonction d’un produit. La fonction doit répondre à un besoin.

Indication

Besoin

• Définiton : Situation de manque ou prise de conscience d’un manque.

• Format : langage naturel, dessin, schéma…

Indication

Fonctions

• Définition : Éléments de rendu de service de l’application qui permettent de répondre au besoin exprimé.

• Synonyme : fonctionnalités

• Format : phrases à l’infinitif, sujet=système, compléments=acteurs en interaction avec le système.

Le point de vue utilisateur: Il ne faut surtout pas décrire COMMENT le logiciel remplira ses fonctions.

exemples

• Crayon

  • Fonction : déposer de l’encre sur un papier

  • Besoin : communiquer

• Tondeuse

  • Besoin : entretenir le jardin

  • Fonction : diminuer la hauteur de l’herbe

• Projet de IPI

  • Besoin : Vous avez le concept d’un nouveau jeu et vous voulez permettre au prof et à vos amis d’y jouer.

  • Fonction : permettre à l’utilisateur de jouer à ce jeu.

3.1.1.4. Cahier de charges

En IPI, le cahier des charges comportera l’expression et l’analyse du besoin. Dans une relation client / prestataire, le cahier des charges est un document contractuel. C’est en s’appuyant sur le cahier des charges qu’on pourra déterminer si les objectifs ont étés remplis.

Il existe des normes pour réaliser un cahier des charges en contexte industriel:

• Cahier des Charges Fonctionnel : AFNOR

• Use Cases : UML

• Récits d’utilisation : méthodes agiles

• …

Il faut s’adapter au sujet traité et au contexte dans lequel on travail. Ici

3.1.2. Le cahier des charges de IPI

Projet Morpion

Voici un exemple sur lequel vous pouvez vous baser MorpionS2-CdC.pdf et MorpionS2-CdC.odt.

Le cahier des charges constitue les fondations du projet. Tout repose sur ce document! Vous devrez vous mettre dans la peau d’un client qui précise de manière univoque, cohérente et exhaustive ce qu’il attend comme produit.

Par exemple, vous pouvez imaginer qu’un autre binôme utilise votre cahier des charges pour produire le jeu auquel vous pensez. Dans ce cas, ce qui n’est pas décrit dans le cahier des charges ne sera probablement pas réalisé. Ce qui sera équivoque sera toujours interprété de la manière qui provoque le moins de développement.

Le Cahier des charges vous engage. Il permet d’évaluer la quantité de travail à réaliser. Veillez donc à être exhaustif : Si la description détaillée de votre projet vous paraît déjà insurmontable, imaginez le codage! C’est en allant au bout de cette description qu’on est capable de détecter un projet trop ambitieux. Si vous avez des doutes, afin de limiter le risque de ne pas achever le projet, certaines fonctionnalités peuvent être optionnelles. Les objectifs du projet pourront alors être considérés comme atteint même si ces dernières n’ont pas étés réalisées.

3.1.2.1. Plan imposé en 4 parties:

• Objectifs

• Expression du besoin

• Analyse du besoin

• Livrables

3.1.2.1.1. Page de garde

Mettre un titre, le logo de l’ENIB et une illustration. Utiliser un cartouche normalisé pour tous les documents du projet : type du document, nom du projet, commentaire, auteur, version, date.

3.1.2.1.2. Objectifs

Description générale: 1 à 2 phrases maximum disant ce qu’est le document et le projet. Contexte : précise le but et le contexte du projet. Cela apporte un éclairage qui permet de mieux comprendre le besoin qui sera exprimée

3.1.2.1.3. Expression du besoin

• Règles du jeu: Règles complètes, précises et exhaustives

• L’interface utilisateur: Proposition de vues et description des moyens d’action.

• Manuel utilisateur: Première version du manuel

• Contraintes techniques: Au moins celles énoncées pour IPI

• Scenario d’utilisation:

  • schéma (non formalisé); éventuellement plusieurs.

  • enchaînement d’actions.

  • phrases à l’infinitif, le sujet est l’utilisateur (sauf exception explicitée)

3.1.2.1.4. Analyse du besoin

• Fonctionnalités: c’est le plus important!

• Critère de validité et de qualité: essentiel dans la relation client/prestataire

• Livrables : Description de ce qu’on va livrer, quel contenu, quel format.

• Échéancier: Calendrier indiquant quand seront livrées les livrables.

• Documents: Brève description de chaque documents.

• Prototypes: Description des prototypes et des fonctionnalités qu’ils devront posséder