Chapitre 1: Le problème des exigences

Les erreurs d'exigences sont la catégorie d'erreur les plus communes et les plus dispendieuses à corriger. On prédit près de 70% des coûts de correction (rework). Les coûts de correction (rework) sont de l'ordre de 30 à 50% des projets logiciels.

Si nous ne faisons pas d'erreur dans les exigences, on peut:

• sauver de l'argent
• augmenter la productivité
• sauver du temps sur la planification (calendrier) du projet
• construire et un logiciel de meilleur qualité à notre client
• éviter l'épuisement de l'équipe logiciel (wear and tear)

Chapitre 2: Introduction à la gestion des exigences

Divisé en deux domaines: domaine Problème (les besoins) et le domaine Solution (fonctionnalité et exigences logiciels).

Un besoin s'exprime souvent par un souhait et plus souvent par la demande de résolution d'un problème complexe. Je veux faire plus d'argent. Je veux enregistrer mes données pour m'en souvenir dans 10 ans...

Une fonctionnalité est une tâche plus ou moins complexe que doit effectuer/accomplir le logiciel. (on peut aussi parler de comportement). Il devrait seulement y en avoir de 25 à 99. On peut ajouter des attributs pour caractériser les fonctionnalité (feature).

Une exigence est une contrainte sur un logiciel.

Besoin: je veux me souvenir de mes données dans 10 ans.
Fonctionnalité: Enregistrement et entreposage de données sur un support matériel.
Exigence: le support matériel doit durer au moins 10 ans, 
          le système (programme, ordinateur, accès) de lecture/écriture doit fonctionner pendant au moins 10 ans.

Chapitre 8: Le défi de la récolte d'information

Nous devons utiliser une série de techniques pour bien comprendre les besoins et les exigences des usagers et des parties-prenantes.

Le monde de la programmation est souvent à des années-lumières du domaine d'expertise du client. On peut avoir comme syndrôme: "Oui, mais...", "Ruines non découvertes" et "Utilisateur et Développeur". Si les programmeurs viennent de mars, les utilisateurs viennent de vénus.

Techniques:

• Interview
• Questionnaire
• Rencontre de travail pour les exigences
• Remue-méninges (brainstorming session) et ébranchage d'idées?
• Storyboards

Chapitre 9: Les fonctionnalités d'un produit ou d'un système

Les fonctionnalités sont faciles à trouver, documenter et maintenir. Elles sont aussi facile à comprendre et sans jargon technique inconcis. Il devrait y avoir que de 25 à 50 fonctionnalités.

Chapitre 10: Interview

Chapitre 11: Atelier de cueillete des exigences

Encourager les concensus. Obtenir un arrangement rapide sur les actions à suivre dans un temps très court. Une ou deux journées. Un aidant expérimenté et neutre (experienced outside facilitator) est souvent exigé.