Élaborer un plan de gestion des exigences, définir les lignes de base des exigences, obtenir la compréhension et l'engagement envers les exigences, gérer les modifications des exigences, maintenir un suivi bidirectionnel des exigences et identifier les incohérences entre le travail du projet et les exigences.

Suivi bidirectionnel des exigences : dans le suivi avant, dans quel cas d'utilisation l'exigence d'origine est réalisée, si toutes les exigences d'origine sont satisfaites. Dans le suivi inverse, si un cas d'utilisation ne répond à aucune exigence d'origine, il s'agit d'un besoin passionnant.

Informations liées au domaine du problème, informations liées au problème à résoudre, attentes et contraintes des utilisateurs

Parties prenantes, systèmes existants, concurrents, experts du domaine

Réunion commune sur les exigences de discussion (discussion multipartite), entretiens avec les utilisateurs (les utilisateurs clés préparent les questions), enquêtes écrites (lorsqu'il y a de nombreuses personnes), observations sur site, lecture de documents historiques et participation aux pratiques commerciales

Outils graphiques : schéma fonctionnel hiérarchique, diagramme de cas d'utilisation, diagramme IPO, diagramme Warnier

Le développement des exigences est un processus évolutif itératif sans cascade qui décompose le problème de haut en bas, couche par couche, et fournit une vue logique et une vue physique du système.

Dessiner un diagramme de portée de la relation entre le système et les entités externes, créer un prototype d'interface utilisateur, analyser la faisabilité des exigences, déterminer la priorité des exigences, établir un modèle d'analyse des exigences (modèle de cas d'utilisation, diagramme ER, diagramme de flux de données) , créez un dictionnaire de données et utilisez les fonctions de qualité pour allouer

méthodes d'analyse structurées

Méthode d'analyse orientée objet

Méthode d'analyse du domaine du problème de zone

Vue logique (réponse aux exigences fonctionnelles), vue processus (problèmes de concurrence), vue composants (problèmes de mise en œuvre), vue déploiement (problèmes de distribution)

Convertir les exigences logicielles en structures de données et en structures de systèmes logiciels, en complétant principalement la conception globale, y compris en divisant les fonctions en modules, en déterminant les fonctions des modules et les relations d'appel et de composition entre les modules.

Descendant, raffinement progressif, masquage des informations (interface de fonctionnement), modules indépendants (forte cohésion, faible couplage)

Concevoir la structure des données et l'algorithme pour chaque module, les performances, le délai d'exécution, le temps de réponse, le débit, la précision, etc.

Module entrant, module sortant, module de transformation, module de coordination

Transformation, Transaction, Mixte

Concevoir des cas de tests selon les spécifications fonctionnelles et vérifier si les fonctions répondent aux exigences, quels que soient la structure et le traitement du programme.

Division des classes d'équivalence

analyse des valeurs limites

erreur de deviner

diagramme de cause à effet

Tester le contenu

Méthodes d'essai

Combinez les tests en boîte noire et en boîte blanche

Réalisés pendant la phase de codage, tests généraux en boîte blanche, tels que les tests de fonction d'interface de module, les tests de structure de données locales, les tests de chemin, les tests de gestion des erreurs et les tests de conditions limites.

Des erreurs au cours de la phase de conception sont découvertes. Une fois les modules assemblés, l'interface et la communication entre les modules sont testées, généralement en boîte noire.

Vérifier si les fonctions et les performances du logiciel sont cohérentes avec les besoins de l'utilisateur, sur la base des spécifications de la demande, des tests de validité, de la revue de la configuration du logiciel et des tests d'acceptation (rapport d'analyse, manuel d'utilisation, rapport de synthèse de développement) dans un environnement simulé.

Tests de l'environnement de production, tests en boîte noire basés sur les spécifications des exigences, couvrant tous les composants communs et évaluant la qualité des produits logiciels

Y compris les logiciels, le matériel, les périphériques, les données, les logiciels de support, etc., en particulier les tests de récupération, les tests de sécurité, les tests de résistance, les tests de performances, les tests de fiabilité et les tests d'installation.

Pour les logiciels de type produit, le développeur @ est présent et le client implémente le test, et le développeur b n'est pas présent.

Objectif (évaluer les capacités du système, identifier les faiblesses, régler le système, vérifier la stabilité et la fiabilité), type (test de charge, test de résistance, test de capacité)

Analyse des exigences logicielles, préparation du plan de tests d'acceptation et des critères d'acceptation du projet, conception des tests et conception des scénarios de tests, construction de l'environnement de test, mise en œuvre des tests, analyse des résultats, rapport de test

Intermédiaire--Centre d'évaluation de logiciels de Pékin

Analyse des besoins – Les améliorations et modifications possibles sont expliquées

Phase de conception : solution facile à étendre, portable et réutilisable, orientée objet

Phase de codage - annotation, qualité, orienté objet

Phase de test : si le test est bon, alors la maintenance est bonne ; tous les documents relatifs au test sont disponibles ;

Phase de maintenance - bonne gestion de la configuration et documents synchronisés

Nombre de boucles (complexité du code source), taille du logiciel, autres facteurs