👕 🍯 🕗 JIRA: règles pour la préparation en temps opportun de délicieux logiciels. TLDR 2: gestion des exigences 🤶🏽 👰🏻 💡

Plus haut dans l'article « JIRA: les règles pour la préparation en temps opportun de délicieux logiciels. TLDR 1: limites des possibilités »une tentative a été faite d'unifier les exigences générales pour l'utilisation de JIRA dans le cas de la gestion de plusieurs projets pour le développement de logiciels personnalisés dans l'un des départements de notre entreprise . Développant le sujet, cet article sera consacré aux principales caractéristiques de l'enregistrement, de la clarification et du suivi de la mise en œuvre des exigences clients dans le cadre du modèle proposé précédemment . Toute critique est la bienvenue.

La source

Tout produit fini est principalement déterminé par la qualité des ingrédients d'origine, et le logiciel ne fait pas exception ( Garbage In - Garbage Out ). Si les ingrédients d'origine sont légèrement pourris ou que certains d'entre eux sont tout simplement manquants, il est peu probable que vous puissiez sauver la situation à l'aide d'un super-four ou d'une merveilleuse poêle. Dans le cas du logiciel, les composants initiaux sont les bonnes intentions (rêves) du client concernant un avenir radieux (lorsque «les robots travaillent dur, une personne est heureuse »).

L'un des paradoxes des marchés publics modernes est que l'entrepreneur a souvent une faible influence sur le processus de formation des exigences, c'est-à-dire processus d' analyse des besoins réelssur le projet commence après l'approbation de la liste de ces exigences. Le fait que les recommandations de l'équipe de projet concernant le libellé des exigences n'aient pas eu d'effet sur le texte du contrat, le chef de projet apprend généralement auprès du représentant joyeusement excité du service des contrats, qui, avec un sentiment de dette totale, rapporte que l'appel d'offres tant attendu est finalement remporté et l'accord Reste petit. Dans le même temps, d'une part, le client empêche de toutes les manières possibles le changement d'exigences dans le document approuvé (un rêve est sacré), et d'autre part, il peut facilement interpréter la même exigence de différentes manières en fonction de la situation.

Dans ces conditions, il est souhaitable de veiller à ce que toutes les exigences des clients soient stockées dans votre «cuisine numérique» de manière à éviter, au stade de la livraison du projet, une grave frustration de toutes les parties intéressées au projet.

Pour résoudre ce problème, dans le cadre de l'approche proposée précédemment , un type particulier de tâche est conçu - «l'exigence». Une liste de ces exigences de tâche est constituée par ce que l'on appelle le backlog de projet. Dans les versions plus récentes de JIRA, un analogue de ce type de tâche est le type de tâche «épique». Cependant, comme nous le verrons plus loin, le type de tâches «exigence» dans notre projet ne consiste pas seulement à fixer les formes de pensée conceptuelle du client, mais des tâches caractérisant les résultats des activités du chef de projet et des analystes sur la gestion des exigences .

Règles pour les exigences de découpage

Si le client reçoit une liste d'exigences pour l'amélioration du logiciel (par exemple, un mandat approuvé), toutes les activités d'enregistrement et de maintenance de la liste d'exigences dans JIRA peuvent être réduites à deux scénarios frontaliers.

Dans le premier cas, le chef de projet transmet simplement la lettre avec les exigences du client aux analystes avec une note «Enregistrer les exigences concernant la tangente auprès de JIRA et assurer leur mise en œuvre». Après cela, le chef de projet peut «marteler» le projet jusqu'au début des tests préliminaires (la seule chose à faire est de s'assurer que toutes les exigences trouvent leurs exécuteurs responsables dans JIRA). Si votre équipe de projet est composée d'analystes sensés, de programmeurs ingénieux, de testeurs de bourreaux de travail et d'écrivains graphomanes techniques, le résultat de cette approche ne différera pas de la deuxième option, plus gênante.

Dans le second cas, le travail de gestion des exigences est divisé en plusieurs étapes.

Début de la source . Enregistrement du document source pour le développement / modification de logiciels dans JIRA. Les matériaux reçus sont téléchargés dans le référentiel avec le numéro de la tâche correspondante indiqué dans le commentaire du commit.

1. Sur la base du document source enregistré, une réunion est prévue, dont le but est de déterminer les limites de la responsabilité de satisfaire aux exigences, d'identifier les «points blancs» et les exigences «ésotériques». La planification de la réunion s'effectue directement dans JIRA (pour cela, une tâche de type «mise en œuvre» est enregistrée, le responsable de la tâche est le chef de projet, les participants sont enregistrés en tant qu'observateurs, les points de l'ordre du jour sont enregistrés dans la description). Le temps consacré à une analyse préliminaire des besoins est fixé indépendamment par les analystes sous forme de sous-tâches pour la réunion prévue. Si des questions se posent pendant l'analyse, elles sont reflétées dans les commentaires sur l'ordre du jour de la réunion.

Lors de la réunion, des décisions sont prises sur la nomination des responsables des «points blancs». Les risques liés aux exigences «ésotériques» sont évalués et des moyens de les surmonter sont proposés. La première version, encore très approximative, de la «feuille de route» est en cours d'élaboration, selon laquelle le travail sera organisé (en tenant compte des priorités et de l'emploi actuel de l'équipe de projet).

2. Une fois l'analyste nommé responsable de la mise en œuvre des exigences, il enregistre chaque exigence auprès de JIRA en tant que tâche distincte liée au document source (le lien «complète»). Le statut initial de la réclamation est «notation» .

L'une des règles de base - chaque exigence du client doit être enregistrée en tant que tâche distinctechez JIRA. Cette approche, à son tour, permet d'apprécier l'état du projet du point de vue de la mise en œuvre de chacune des exigences du client, et non du point de vue du nombre de tâches effectuées ou de l'investissement en travail. Le libellé de l'exigence est enregistré mot à mot dans le champ "Description" comme dans le document du client.

De plus, l'enregistrement «atomique» des exigences permet par la suite de générer automatiquement la documentation de reporting lors de la publication d'une version ou d'une mise à jour (protocole de composition fonctionnelle et de test).

3. Compte tenu de la feuille de route élaborée pour chacune des exigences au stade initial de sa mise en œuvre, les problèmes suivants devraient être résolus par l'analyste responsable:

clarification du contenu sémantique de l'exigence;
clarification des limites de la mise en œuvre.

Au moment de la clarification, l'exigence peut être transférée au statut «en attente» , en indiquant la raison correspondante.
Tous les documents de clarification (interprétation) des exigences sont joints à la tâche correspondante (téléchargés dans le référentiel de documentation). Le matériel résultant doit provenir du client et doit permettre une réponse claire aux questions ci-dessus. Il est conseillé que ce soit un protocole de la réunion pour clarifier les exigences, au moins un e-mail de la correspondance.
Après élimination des «points blancs», l'exigence peut être transférée au statut «attribué» .

4. Dans le cadre de la mise en œuvre d'un domaine fonctionnel (un cas d'utilisation clé - cas d'utilisation) l'analyste responsable doit formuler des tâches de type «analyse» liées aux exigences pertinentes.

5. Si nécessaire, l'analyste responsable mène une enquête d'information sur l'objet d'automatisation.

6. Après avoir collecté les données initiales nécessaires à la conception, l'analyste responsable prend la décision de conception.

7. Sur la base des résultats de la décision de conception, l'analyste doit former / clarifier la liste des composants susceptibles d'être développés / modifiés.

8. La solution de conception développée est une condition nécessaire et suffisante pour créer des tâches de développement, de test et de documentation et prévoir la complexité de leur mise en œuvre.

C'est souvent là que se situe la principale pierre d'achoppement entre les gestionnaires et les développeurs. Un desLes approches utilisées pour réduire l'incertitude dans la résolution de ce problème consistent à évaluer la tâche proposée par le développeur responsable, à condition que la complexité totale de la tâche individuelle ne dépasse pas 16 heures. Alexei Kataev dans son rapport montre de façon convaincante que si les coûts de main-d'œuvre pour la mise en œuvre de la tâche dépassent 12 heures, la fiabilité de la prévision de la complexité d'une telle tâche s'apparente à la fiabilité de la prévision des gains de jeu. Par conséquent, pour garantir la qualité requise de la planification, il est recommandé de décomposer les tâches.

D'un autre côté, du point de vue de la direction, je souhaiterais obtenir un résultat significatif du point de vue du client lors de l'exécution de la tâche de développement, ce qui n'est pas toujours réalisable en 16 heures de travail.

Dans notre cas, il a été décidé que si la complexité de la tâche dépasse 8 heures, l'auteur de la tâche devrait la diviser en étapes distinctes (ce qui ne signifie pas toujours des sous-tâches). De plus, des listes formelles de résultats particuliers pour chacune de ces étapes ont été établies. De plus, des calculateurs en ligne ont été créés pour augmenter l'objectivité des prévisions basées sur ces listes en utilisant la méthode PERT .détermination de la complexité totale des tâches de différents types (une description plus détaillée du travail avec ces outils est censée être donnée lors de la publication des articles suivants). Mais en même temps, une limitation a été établie selon laquelle la complexité maximale projetée d'une seule tâche JIRA ne devrait pas dépasser 32 heures. Dans le cas où le contractant n'est pas d'accord avec la complexité projetée de sa tâche, comme argument, il doit soumettre son calcul de la complexité, effectué à l'aide des mêmes outils. L'arbitre dans la résolution de ces différends entre l'analyste responsable de la mise en œuvre de l'exigence et les exécuteurs est le chef de projet (chef d'équipe).

9. Immédiatement après l'enregistrement des tâches liées à l'exigence de développement, d'essais et de documentation, le chef de projet devrait spécifier la priorité et le calendrier de mise en œuvre de cette exigence (en tenant compte du coût total de la main-d'œuvre des tâches, des priorités et des délais requis pour la mise en œuvre d'autres tâches du projet). Compte tenu de ces clarifications, à son tour, l'analyste responsable peut ajuster le calendrier des tâches de développement, de test et de documentation.

10. La mise en œuvre de la solution de conception s'effectue dans le cadre de tâches de type «développement».
Une fois que la première tâche liée au besoin pour le développement de logiciels a été exécutée , l'exigence doit être transférée à l'état "en cours de travail" (cela peut être fait à l'aide du plug-in Automation for Jira ).

11. Sur la base des délais de mise en œuvre spécifiés, il est décidé d'inclure la mise en œuvre de l'exigence dans l'une ou l'autre version du logiciel. Le client doit être informé de tout changement dans la composition ou le délai de livraison du communiqué.

12. Parallèlement au processus de développement, une version de la documentation utilisateur est formée sur la base de la décision de conception.

13. Après avoir terminé les tâches de développement, le programmeur doit clarifier la liste des composants qui ont été développés / modifiés.

14. Une nouvelle clarification de la documentation utilisateur doit être effectuée dans le cadre d'un test hors ligne. Le respect de toutes les exigences liées à l'exigence de développement, de documentation et de test est un signal pour traduire cette exigence en statut "terminé" et son inclusion dans la version.

15. La révision est incluse dans la version du logiciel conformément à la décision de livraison prise par le chef de projet.

16. Avant d'effectuer les tests, des tests d'intégration répétés des exigences implémentées incluses dans la version sont effectués.

17. La confirmation de l'exactitude des exigences mises en œuvre peut être effectuée lors des tests du logiciel (préliminaire, opération d'essai, acceptation). Les résultats des tests sont enregistrés dans JIRA dans le cadre des tâches de type "implémentation".
Une fois qu'un document a été reçu du client sur la mise en œuvre correcte de l'exigence, il peut être transféré au statut «fermé» . Dans le cas où des commentaires sont reçus du client concernant l'exigence, celle-ci revient au statut «assigné»(sur scène numéro 8). Dans le même temps, les commentaires eux-mêmes peuvent être corrigés dans JIRA en tant qu'exigences distinctes liées à l'exigence principale en utilisant le type de communication «Relates» .

Permettez-moi de vous rappeler que le schéma décrit ne reflète pas le flux de travail d'une tâche distincte dans JIRA, mais implique la création d'un ensemble de tâches interdépendantes de différents types (qui se reflète dans le schéma avec les couleurs correspondantes). La séquence donnée donne un aperçu de la procédure standard pour la mise en œuvre de nouvelles exigences client. Dans le même temps, ce schéma n'exclut pas la possibilité de dérogations à celui-ci, par exemple, dans le cas d'un prototypage préalable avant la décision de conception. Cependant, dans notre projet, ces exceptions doivent être convenues avec le chef de projet.

Pendant les tests ou l'exploitation commerciale, les commentaires des clients sur le logiciel créé seront inévitablement révélés. Ces remarques peuvent être conditionnellement réparties dans les groupes suivants:

nouvelles exigences;
clarifications sur la mise en œuvre;
défauts;
des erreurs.

Malgré le fait que, conformément à l' approche initialement proposée, les commentaires sont enregistrés dans JIRA ainsi que les exigences de raffinement du logiciel (en tant que tâches de type «exigence»), le processus de leur élimination mérite une considération séparée.

Règles de coloration des cafards

Celui qui ne fait rien ne se trompe pas.
Théodore Roosevelt

Il n'y a pas de logiciel sans erreurs. Absolument. Même s'il n'y a pas d'erreurs dans le code, un utilisateur averti les trouvera dans la documentation ou les proposera. D'une manière ou d'une autre, je n'ai pas vu de projets où il n'y a pas eu d'incidents logiciels. Analyse de maintenance logicielle par l'American Institute of Software Engineering ( SEI) au début des années 90, a montré que le coefficient de corrélation entre le nombre d'erreurs détectées lors des tests de modules individuels et le nombre d'erreurs détectées par les utilisateurs dans le produit fini est de 0,91. Autrement dit, si 10 erreurs ont été détectées lors de la phase de test, 9 autres s'afficheront lors de l'opération d'essai. Atteindre la qualité requise dans le développement de logiciels pour les stations spatiales est obtenu en particulier en raison de la supériorité décuplée du personnel de test par rapport au personnel de développement, sans compter l'utilisation de techniques avancées, par exemple, les tests unitaires ou l' automatisation des tests GUI. À mon avis, la fiabilité d'un tel logiciel est obtenue en raison de l'implication minimale possible des utilisateurs en direct dans son travail. Bien sûr, c'est très cool quand une équipe de contrôle qualité professionnelle travaille sur le projet . Cependant, dans de nombreux projets logiciels, il n'est pas possible de mettre en œuvre toutes ces recommandations pour diverses raisons objectives et subjectives.

Par conséquent, si le chef de projet ne gère pas le flux des incidents entrants, alors très prochainement ce thread gérera un tel manager (s'il ne "s'étouffe" pas dans ce thread).

D’un autre côté, comme l’expérience le montre, une partie importante des commentaires du client qui ont été initialement classés par lui comme une erreur logicielle n’est pas une erreur. L'apparition de commentaires de ce type peut être due à des raisons telles que:

violation des conditions techniques d'exploitation du logiciel («mains tordues» des administrateurs système du client);
restrictions sur les droits d'accès des utilisateurs (les droits d'accès des utilisateurs attribués ne répondent pas à ses attentes);
l'inadéquation des attentes fonctionnelles de l'utilisateur avec les exigences mises en œuvre (si rien n'y fait, peut-être devriez-vous lire les instructions?);
incohérence dans la description de l'implémentation du logiciel (une remarque assez rare, car les utilisateurs et les administrateurs du client, en règle générale, ne lisent pas les manuels après la première connaissance du logiciel).

À cet égard, lors de la correspondance avec le client concernant des commentaires sur le logiciel, il est recommandé d'éviter les mots tels que «erreur» ou «défaut», au moins jusqu'à ce qu'il soit complètement établi sans ambiguïté. Jusqu'à ce point, il est recommandé d'utiliser les mots «remarque» ou «incident».

Le processus unifié de réalisation de travaux pour éliminer les incidents peut être représenté comme une séquence des étapes suivantes.

Début de la source . Enregistrez une application de résolution d'incident auprès de JIRA. Cette étape pour différents projets peut être organisée à sa manière. Vous pouvez, par exemple, enregistrer manuellement les applications reçues du client avec JIRA, ou vous pouvez utiliser une boîte aux lettres spéciale, que JIRA affichera et configurera indépendamment les tâches en fonction des lettres entrantes. Si vous développez une application Web, vous pouvez utiliser le collecteur de tâches JIRA pour collecter les commentaires des utilisateurs . Le champ de la façon dont le commentaire s'est en quelque sorte avéré être enregistré dans JIRA (dans le statut de "classement" ), il est nécessaire de le prétraiter.

1. Clarification des conditions de l'incident. Dans le cadre de cette action, il est nécessaire de collecter les informations les plus complètes sur le commentaire logiciel:

la séquence d'actions au cours de laquelle l'incident se produit, une combinaison de données d'entrée;
les détails et l'autorité de l'utilisateur du commentaire;
emplacement du poste de travail (serveur);
captures d'écran d'écrans utilisateur;
protocoles de surveillance;
exemples de fichiers (rapports) mal générés.

Souvent, une partie importante des incidents met fin à leur parcours de vie à ce stade, car lors de la collecte des artefacts, il s'avère que l '«erreur» détectée est le comportement standard du système. Si le JIRA commence à accumuler des exigences pour résoudre les incidents qui ont été résolus sans créer de tâches de développement, il convient de prêter une attention particulière à la convivialité de l'interface utilisateur et à la pertinence du manuel d'utilisation.

2. Décomposition de l'incident en exigences "atomiques". Souvent, dans une lettre, le représentant du client peut refléter plusieurs commentaires. Par conséquent, si nécessaire, dans la deuxième étape, sur la base de la lettre recommandée du client à JIRA, des tâches d'exigences distinctes sont formées. De plus, chacune de ces tâches est associée à l'exigence parent à l'aide de la relation Cloners . Pour chacune de ces tâches, les documents collectés à l'étape précédente sont joints (en partie concernant). De plus, tout le travail est organisé avec chaque exigence séparément.

3. Définition du cadre contractuel. Après avoir spécifié les défauts identifiés, une détermination est faite à quel type de relation contractuelle le travail pour l'éliminer peut être attribué. Du point de vue de l'organisation future du travail, cette étape peut changer fondamentalement la priorité des tâches futures. Dans de nombreux projets, l'opération d'essai de nouveaux composants développés dans le cadre du développement est réalisée en installant ces composants directement sur la version actuelle après un court test autonome. Cependant, le client corrèle déjà les erreurs qui surviennent dans ces cas avec les contrats d'assistance de base ou de garantie, qui stipulent des délais stricts pour éliminer les défauts. Si, dans le cadre de l'assistance de base, la période contractuelle d'élimination du défaut peut être mesurée en heures, alors si le défaut est identifié par rapport à la nouvelle fonctionnalité,la période d'élimination du même défaut est déterminée par la date de fin de l'opération d'essai (jusqu'à plusieurs mois). Si le chef de projet ne prête pas attention à cette «petite» nuance, la société d'exécution a toutes les chances de commencer à payer une pénalité pour un logiciel simple avant même qu'il ne soit commercialisé.

4. Contrôle des doublons. Dans le cas d'une demande de réassociation pour l'élimination de défauts précédemment détectés, cette exigence est associée à la tâche précédemment déposée via la connexion "Dupliquer" ( Dupliquer ).

Sur la base des résultats de l'analyse préliminaire de l'incident, il est nécessaire d'informer le client de ses résultats, car la vision du client sur le moment de l'élimination de l'incident peut faiblement correspondre aux obligations contractuelles.

5. L'incident doit être répété sur le serveur de test par l'équipe de support avant de soumettre la demande à l'analyste de l'équipe de développement. Le test initial peut être enregistré dans JIRA sous la forme d'une sous-tâche correspondant à l'exigence correspondante.

6. Si l'incident n'a pas été résolu au cours des étapes précédentes, l'exigence est transférée au statut «attribué» et transférée à l'analyste de l'équipe de développement pour identifier les raisons de son occurrence et formuler des tâches pour son élimination.

7. Si nécessaire, l'analyste doit clarifier la portée contractuelle de l'exigence. Si un commentaire est fait concernant la nouvelle fonctionnalité du logiciel, l'analyste doit associer ce défaut aux exigences pertinentes pour le développement / développement / support étendu (le lien «Ajouts»).

8. L'analyse devrait également déterminer la liste des composants qui affectent ce commentaire. De plus, si le commentaire est vraiment un bug logiciel, il doit être généré.typification du défaut détecté.

9. Après avoir identifié les causes du défaut, l'analyste du groupe de développement forme des tâches de développement visant à éliminer l'erreur identifiée. Si nécessaire, des tâches de test et de clarification de la documentation sont formées. Dans le cadre de ces tâches, les coûts de main-d'œuvre prévus sont déterminés. Si la charge de travail d'une tâche particulière dépasse 8 heures, il est nécessaire de justifier la complexité à l'aide des outils spécifiés dans la section précédente. Compte tenu de la priorité et de la charge de travail de l'équipe projet, les dates prévues pour la mise en œuvre de ces tâches sont déterminées.
Après que la première exigence liée au développement du logiciel a été mise en œuvre, l'incident doit être transféré au statut "en cours de travail" .

10. L'apparition de tâches connexes pour le développement, les tests et la documentation d'un besoin est un signal pour le chef de projet pour prendre une décision concernant la version du logiciel que le défaut identifié sera corrigé. Dans le même temps, le chef de projet prévoit un événement pour la mise en œuvre du logiciel en liant les exigences correspondantes à la tâche JIRA de type «mise en œuvre».

11. Si nécessaire, le chef de projet clarifie les dates prévues pour la mise en œuvre des tâches connexes et en informe le client.

12. La correction du défaut s'effectue dans le cadre de tâches de type "développement".

13. Après élimination du défaut, le développeur, si nécessaire, doit clarifier le type du défaut détecté et la composition des composants qui ont été finalisés.

14. Si nécessaire, la documentation est spécifiée.

15. Les spécialistes du groupe de support effectuent des tests autonomes de la fonctionnalité corrigée (dans le cadre de la tâche de test formée par l'analyste du groupe de développement).
De même, comme dans le cas de la mise en œuvre de la nouvelle exigence, la base pour transférer l'incident au statut de «terminé» est l'accomplissement de toutes les tâches créées sur sa base (à l'exception des tâches de type «mise en œuvre»).

16. Après avoir effectué des tests hors ligne, le correctif est inclus dans la mise à jour et dans la version actuelle.

17. Après l'état de préparation de toutes les améliorations prévues pour inclusion dans la publication de la livraison, des tests d'intégration sont effectués. La réalisation des tests d'intégration peut être corrigée dans JIRA sous la forme d'une sous-tâche pour la tâche correspondante de type "implémentation".

18. Les mises à jour du logiciel sont transmises au client de la manière établie. Cependant, le transfert des tâches des exigences pertinentes au statut de «clôturé» n'est possible qu'après avoir reçu du client des preuves documentaires de l'élimination de l'incident.

Source

Tout développeur sait que les plus grandes erreurs sont celles qui n'ont pas été détectées en temps opportun au stade de la formation / spécification des exigences.

Règles pour les exigences de gel

Marcher sur l'eau et développer un logiciel selon les spécifications est très simple lorsque les deux sont gelés.
Edward V. Berard

Il convient de noter que la clarification des exigences a fait ses preuves en créant une situation dans laquelle le client doit donner une réponse simple à la lettre de clarification: «J'accepte». Pour cela, il est nécessaire de formuler plusieurs réponses possibles dans la lettre . L'art de former de telles lettres est que l'option même que le client choisit est la plus préférable pour vous en tant qu'interprète.

La source

Par exemple, l'exigence «simple» de «fournir la possibilité d'échantillonnage par région dans tous les écrans» au stade de la livraison peut poser de nombreux problèmes, car elle ne détermine pas sur quels formulaires d'écran l'échantillonnage doit être fourni, qu'il s'agisse d'un échantillonnage par une valeur de paramètre ou plusieurs. comment l'historicité des changements dans le nom des régions doit être prise en compte. Si vous demandez simplement de clarifier cette exigence, il est peu probable que la réponse résout les problèmes indiqués.

Dans ce cas, une clarification peut être apportée à l'aide d'une lettre du contenu suivant:

. 4.5.6. : « 1, 2 3 «». , , ».

Une copie de la lettre est jointe à la tâche. La tâche est transférée à l'état «en attente» jusqu'à ce qu'une réponse du client soit reçue, qui est ensuite jointe à la tâche. Cette formulation est reflétée dans le champ correspondant de la tâche JIRA (voir ci-dessous, «Clarification»). C'est sur cette base que les décisions de conception, les tâches de développement et les tâches de test sont formées.

Idéalement, ce qui est souvent réalisable comme horizon pour des raisons objectives et subjectives, afin de transférer l'exigence à un développement ultérieur, il est nécessaire de garantir une compréhension de ses limites par tous les membres de l'équipe de projet. Par conséquent, dès qu'une tâche de type «besoin» est associée à des tâches de développement, le chef de projet vérifie qu'il répond aux critères de qualité décrits ci-dessous ( Définition de Prêt) Si le libellé de base de l'exigence ne répond pas à ces critères, le travail de raffinement doit être effectué sans faute. Le résultat du travail de raffinement doit être soit une formulation mise à jour de l'exigence, soit une décision de conception (SCF) approuvée par le client concernant cette exigence.

Critères d'évaluation de la qualité des exigences d'un projet
Caractéristique	Explication
Achèvement	L'exigence est entièrement définie dans la tâche JIRA et toutes les informations nécessaires sont présentes.
Cohérence	L'exigence ne contredit pas d'autres exigences et est conforme à la documentation réglementaire.
Atomicité	L'exigence est «atomique». Autrement dit, il ne peut pas être décomposé en un certain nombre d'exigences plus détaillées sans perte d'exhaustivité.
Pertinence	L'exigence n'est pas devenue obsolète au fil du temps.
Faisabilité	L'exigence peut être mise en œuvre au sein du projet (en tenant compte des ressources disponibles et des délais).
Sans ambiguïté	L'exigence est brièvement définie sans recourir au jargon technique, aux acronymes et autres expressions cachées. Une et une seule interprétation est possible. La définition ne contient pas de phrases ambiguës. Le libellé de l'exigence (clarification) ne contient pas de déclarations négatives et composées.

Lors de la comptabilisation des coûts de main-d'œuvre dans une tâche de type «besoin», seul le temps consacré directement à son affinement est enregistré. Tous les autres coûts de main-d'œuvre sont enregistrés dans les tâches des types correspondants (ou leurs sous-tâches).

En plus des attributs communs décrits dans l' article précédent , un ensemble d'attributs supplémentaires a été défini pour chaque tâche de type «exigence» dans JIRA au cours d'un processus long et douloureux.

«»


*	( ).
	: ( , , .. ); ; — ( , , ); ; ( , ); /; (, , , , , ).
	, (, ).
()	. , , ( ).
	– . . . . , . - .
	, : ; ; ; ; ; .
	( - ). , . «» .

	, ( )
	/ ( PSP IBM): ( , ); ; ( , ); ( , , ); ( , -, ); ( , ); ( ); ( , , , , ); ( , ); , .
— , .
	: ; ; ; ; ; ; ; ; ; ; ; — , ; (e-mail).


	/ ( JIRA , [ ].[ ].[() ])

*	Si la raison du transfert de l'exigence au statut «clôturée» est décrite, ce champ doit indiquer les détails du document confirmant soit la reconnaissance officielle par le client que l'exigence a été satisfaite, soit que l'exigence a été annulée.
Décision
Une version de logiciel	Numéro de version du logiciel dans lequel l'exigence est mise en œuvre

* Caractéristiques attribut de remplissage, commun à tous les types de tâches.

La modification des attributs spécifiques d'une tâche de type «exigence» lors de la transition d'un état à l'autre est décrite dans le tableau suivant, où:

- un changement d'attribut est possible;

- saisie de données requise.

À suivre

De nombreux chefs de projet estiment que si les termes de référence ont été approuvés par le client, alors c'est la vérité ultime, qui n'est sujette à aucun changement. Cela est en partie vrai - le libellé des exigences des spécifications techniques est peu susceptible d'être modifié jusqu'à l'achèvement du projet. Cependant, déjà aux étapes initiales du projet (bien avant l'approbation du programme et de la procédure de test), personne ne prend la peine de clarifier avec le client les limites de chaque exigence et de fixer la procédure proposée pour sa vérification. Si un tel travail n'a pas été effectué, alors très probablement la totalité de la «liste de souhaits» du client exprimée lors de la mise en œuvre, vous déciderez dans le budget et le calendrier du même projet.

N'oubliez pas les lois objectives, qui ont attiré l'attention de Barry Boehm ( Barry W. Boehm ) à la fin des années 80 du siècle dernier. Si le chef de projet ne se soucie pas d'éliminer l'incertitude et les inexactitudes des exigences aux étapes initiales du projet, alors par la phase d'achèvement du projet, il est assuré d'avoir de nombreuses «découvertes» désagréables.

Cependant, l'expérience a montré que la plupart des ambiguïtés ne peuvent pas être résolues en clarifiant simplement les exigences. En outre, il est souvent impossible de considérer les exigences isolément les unes des autres, car les objectifs dans l'intérêt desquels le logiciel est créé ne peuvent être atteints qu'avec la mise en œuvre intégrée des souhaits du client.

Dans le cadre de l'approche décrite, la coordination d'un ensemble d'exigences interconnectées, ainsi qu'une interprétation réaliste des fantasmes clients reflétée dans les termes de référence approuvés, est proposée pour être réalisée lors de la résolution de problèmes de type «analyse», dont les caractéristiques seront présentées dans l'article «JIRA: règles pour la préparation en temps opportun de logiciels savoureux». TLDR 3: Solutions de conception. ”

JIRA: règles pour la préparation en temps opportun de délicieux logiciels. TLDR 2: gestion des exigences

Règles pour les exigences de découpage

Règles de coloration des cafards

Règles pour les exigences de gel

À suivre

More articles: