Meilleure pratique pour l'utilisation de doit et doit lors de la rédaction des exigences


22

J'ai envoyé un e-mail plus tôt pour rappeler à nos développeurs que l'utilisation du mot «Shall» dans vos exigences dérivées ne devait pas correspondre à vos exigences fonctionnelles. Lors de la rédaction des exigences fonctionnelles, le mot «doit» est utilisé pour décrire la fonction qu'une exigence dérivée doit remplir.
Dérivé = le système doit être une exigence
fonctionnelle = le système doit répondre à une exigence

Il a été renvoyé par l'un de nos aînés qui, c'était faux et qui devrait être utilisé dans toutes les exigences.

Ai-je tort ici et doit être utilisé dans toutes les exigences. Je n'ai rien trouvé pour étayer cela.


Nous utilisons «doit» dans chaque exigence obligatoire. Mais "doit" et "doit" signifier plus ou moins la même chose. Voir aussi tynerblain.com/blog/2009/04/22/dont-use-shall
Robert Harvey

4
Pensez-vous peut-être au MUSTvs SHOULDdans les RFC? ietf.org/rfc/rfc2119.txt
user10326


Euh, pas pour faire la fête, mais que gagnez-vous quand tout le monde utilise le bon mot dans la bonne situation?
Peter

Réponses:


43

La RFC 2119 "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence" va dans les détails de ce que signifient les différents mots sur les exigences.

Les mots clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DOIT", "NE DOIT PAS", "DEVRAIT", "NE DEVRAIENT PAS", "RECOMMANDÉ", "MAI" et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la RFC 2119.

De ce document:

  • MUSTest équivalent REQUIREDet SHALLindique que la définition est une exigence absolue.
  • MUST NOTest équivalent à SHALL NOTet indique qu'il s'agit d'une interdiction absolue des spécifications.
  • SHOULDéquivaut à RECOMMENDEDsignifie qu'il existe des raisons valables d'ignorer une exigence particulière, mais les implications doivent être évaluées.
  • SHOULD NOTet NOT RECOMMENDEDsignifie qu'un comportement particulier peut être acceptable ou utile, mais encore une fois, les implications doivent être pesées.
  • MAYsignifie OPTIONALque l'exigence est vraiment facultative. L'interopérabilité avec différents systèmes qui peuvent ou non implémenter une exigence facultative doit être effectuée.

Suivre cette RFC SHOULDpour aider à assurer la cohérence de la communication entre ses documents internes et le monde des normes dans son ensemble.


1
réponse solide; accessoires pour déterrer la RFC

1
@ GlenH7 Je le savais (j'aime lire les RFC du 1er avril et une partie de l'humour est dans le `` devrait '' et `` doit '', et 2119 son même sur la page wikipedia ) Je l'ai recherché, trouvé, puis lu le commentaire que j'allais faire - deux ci-dessus c'était à nouveau le RFC. Ce ne sont donc pas des accessoires entièrement énormes pour le déterrer.

Ma pensée était que les exigences de Must / les exigences fonctionnelles devraient exiger toutes les fonctionnalités d'un objet dérivé qui doit exister. Mais étant donné les définitions de devoir et de devoir et comment tout le monde les utilise, j'avais tout simplement tort
Tim Lieberman

6

Je ne sais pas d'où vous êtes arrivé à la conclusion shallet mustappartenez à des niveaux de documentation distincts. C'est une distinction assez arbitraire qui n'est appuyée par aucune source que je connaisse.

Shallet mustsont lexicalement équivalents. C'est une action qui est requise.

Que vous utilisiez shallou que mustcela dépend vraiment du reste du document dans lequel vous écrivez et de ce qui a un sens grammatical pour cette phrase particulière.

Alors oui, vous vous trompez. Mais vous avez également tort de toujours utiliser shallau lieu de must. Ils représentent le même degré d'obligation.


3
Shouldet mayne sont pas tout à fait équivalents. Ils dénotent tous deux des fonctionnalités optionnelles, mais should, contrairement à may, cela implique que vous devez avoir une bonne raison de ne pas l'implémenter. Cependant, je suis d'accord avec vous sur shallvs. must
Keith Thompson

@KeithThompson - c'est un bon point, et vous avez raison. J'ai tiré cette ligne de la réponse.

1
Ma pensée est devenue que les exigences fonctionnelles devraient utiliser doit parce que, si un objet dérivé doit exister toutes ses fonctionnalités doivent fonctionner.
Tim Lieberman

Je suppose qu'à un moment donné, je devrais être intégré comme nouvel objet dans ma tête et devrais fonctionner.
Tim Lieberman

@TimLieberman - ce n'est pas une mauvaise façon de voir les choses, d'autant plus qu'il relie les deux couches de spécifications. Un peu utile, en fait, car certains gens sont confus par la sémantique des termes. D'autant plus que j'ai corrigé les documents de processus où "doit" était le plus souvent utilisé comme substitut de "devrait". Cependant, ce n'est pas assez utile pour exiger cela en tant que norme particulière.

2

S'il vous arrive de travailler dans le cadre des directives DO-178 ou DO-254 , celles-ci ont leurs propres définitions des exigences en général et des exigences dérivées . Ces lignes directrices ne précisent cependant pas quel mot, par exemple doit, doit, doit , être utilisé pour spécifier les exigences.

Si vos outils de gestion des exigences ne signalent pas automatiquement les exigences dérivées pour vous, il peut être avantageux de les distinguer des exigences fonctionnelles par l'utilisation d'un must au lieu de doit , par exemple pour démontrer que les objectifs de vérification des exigences dérivées ont également été atteints. Cela pourrait être une raison possible de l'exigence de documentation apparemment arbitraire.

Notez que dans DO-178 et DO-254, une exigence dérivée signifie en fait une exigence qui n'a pas été dérivée d'une exigence de niveau supérieur. Une exigence dérivée initie donc essentiellement une nouvelle chaîne de traçabilité.

Le DO-178 et le DO-254 sont des documents de référence commerciaux utilisés pour le développement de logiciels et d'électronique avionique, et uniquement disponibles moyennant des frais sur www.rtca.org .

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.