Quelle est la différence entre les exigences et les critères d'acceptation?
J'essaie de mieux comprendre la différence car il semble que ce soit la même chose.
J'ai du travail dans des projets sans utilisation des exigences et tout est un critère d'acceptation, et sur des projets qui ont les deux.
Les critères d'acceptation définissent le moment où l'application est terminée. Ou pour le dire autrement, quand vous pouvez l'expédier. Il comprend une liste d'exigences qu'il has to remplir. Cela signifie que certaines exigences (généralement des exigences "Nice to have") peuvent tomber et être implémentées dans la prochaine version.
Pour l'étendre encore plus (extrait de ici ):
Microsoft Press définit les critères d'acceptation comme "les conditions qu'un produit logiciel doit remplir pour être accepté par un utilisateur, un client ou une autre partie prenante". Google les définit comme "des normes ou des exigences préétablies auxquelles un produit ou un projet doit répondre".
et
Les critères d'acceptation sont un ensemble d'énoncés, chacun avec un résultat de réussite/d'échec clair, qui spécifient à la fois les exigences fonctionnelles (par exemple, fonctionnalité commercialisable minimale) et non fonctionnelles (par exemple, qualité minimale) applicables au stade actuel de l'intégration du projet. Ces exigences représentent des "conditions de satisfaction". Il n'y a pas d'acceptation partielle: soit un critère est rempli, soit il ne l'est pas.
Une exigence décrit une certaine fonctionnalité de l'application.
Ou, comme wiki bien indiqué:
une exigence est un besoin physique et fonctionnel singulier documenté qu'une conception, un produit ou un processus particulier doit être en mesure de réaliser.
Quelle est la différence entre les critères d'acceptation et les exigences de candidature?
Avec les définitions ci-dessus, la différence est assez claire.
Les exigences sont ce que vous êtes censé faire.
Les critères d'acceptation sont les mesures convenues pour prouver que vous les avez faites.
Les exigences sont ce que le client/client a demandé.
Les critères d'acceptation, souvent exprimés sous forme de tests, sont utilisés pour illustrer les exigences et pour indiquer, une fois les tests réussis, que les exigences ont été satisfaites.
C'est souvent une question de timing
Les exigences sont en avance. Les critères d'acceptation sont au point de livraison du logiciel.
C'est ce que d'autres ont répondu ...
Il y a cependant un problème plus profond et vous le voyez peut-être:
Dans un monde "idéal", cela correspondrait. Cependant, dans le monde réel, il se passe beaucoup de choses entre ces deux événements, y compris souvent certains des éléments suivants:
- à mesure que le logiciel est développé, les exigences changent.
- le logiciel est construit avec des processus Agiles
- les changements de budget
- les changements d'horaire
- la disponibilité des talents techniques n'est pas à 100% et évolue avec le temps
- la détermination que toutes les fonctionnalités ne sont pas nécessaires pour la mise en service.
- l'entreprise est affectée par des facteurs externes qui modifient les besoins.
C'est souvent une question de `` niveau de détail '', avec des exigences à un niveau élevé, par ex. "un module de traitement des remboursements" et les critères d'acceptation à un niveau plus bas et plus détaillés tels que "un remboursement demandé doit être effectué dans les 3 jours et un avis envoyé par e-mail au client"
Exigences relève de vérification qui répond à la question:
Le produit a-t-il été construit correctement? (de bas en haut selon les exigences)
Critères d'acceptation relèvent validation qui répond à la question:
Le bon produit a-t-il été construit? (de haut en bas comme en témoignent les tests d'acceptation réussis)
Exigences sont souvent pilotées par le client. Dans un schéma de développement en cascade, il s'agit de la liste des résultats attendus de l'achèvement d'un projet. Dans sa description la plus élémentaire, les exigences ne sont rien de plus qu'une tâche à accomplir pour un projet.
Critères d'acceptation sont souvent motivés par la relation entre deux parties. Ils peuvent être indépendants des exigences et/ou liés aux exigences. Cela ne fait pas d'eux la même chose, mais juste liés. Contrairement aux exigences, les critères d'acceptation ne sont pas une liste de tâches. Il s'agit d'une liste de conditions qui doivent être remplies pour que l'accord soit considéré comme terminé.
Certaines réponses ont cité les tests unitaires, la budgétisation et la gestion de projet comme exemples, mais ce ne sont que des exemples de conditions placées sur les accord en tant que critère d'acceptation .
Il est possible pour un développeur de remplir aucune des exigences, et toujours répondre aux critères d'acceptation pour terminer le projet.
Par exemple;
Obligation de mettre à jour le système de point de vente avec les nouvelles modifications de la législation fiscale. Critères d'acceptation entre le développeur et le client déclare que le développeur accepte d'effectuer 40 heures de travail pour effectuer la mise à jour. Si le travail n'est pas terminé dans ce délai, aucune mise à jour du système ne sera publiée car il s'agit de la limite budgétaire des clients.
Le développeur conclut l'accord et, après 40 heures de travail, il signale que le changement est important, ce qui entraîne plus de 40 heures pour terminer. Le client accepte ce résultat, paie au développeur son salaire et son accord est terminé.