Un meilleur mot pour les exigences facultatives? [fermé]

Quel meilleur mot pour une exigence facultative en génie logiciel? La phrase est contradictoire. J'ai utilisé des «exigences non essentielles» dans des projets précédents.

Le terme "exigence hors champ" peut éventuellement être utilisé. Cela signifie que l'exigence a été capturée dans votre processus et est traçable, mais il a été déterminé que l'exigence est quelque chose qui dépasse la portée actuelle du système, pour un certain nombre de raisons, telles que le budget, le calendrier, le temps, ou faisabilité.

Cependant, l'expression "exigence facultative" est couramment utilisée pour désigner quelque chose qui est dans la portée, mais pas nécessairement requis par le système. Il s'agit d'une mesure de la priorité de l'exigence. D'après mon expérience, les exigences sont souvent classées par ordre de priorité comme obligatoires, souhaitables ou facultatives (bien qu'il existe également d'autres régimes). Pour qu'un projet soit considéré comme complet et pleinement fonctionnel, toutes les exigences obligatoires doivent être satisfaites. Si les ressources sont suffisantes, les exigences souhaitables seront ensuite mises en œuvre. Enfin, tout ce qui serait considéré comme facultatif serait inclus.

Je crois que la confusion vient du terme "exigence". Dans la langue anglaise, une exigence est "une chose qui est nécessaire" ou "une condition obligatoire, obligatoire ou nécessaire". Cependant, en génie logiciel, le terme exigence est simplement une caractéristique documentée d'un système logiciel. Le concept de facultatif et obligatoire décrit la priorité de la caractéristique documentée du système logiciel.

Nous les appelons des fonctionnalités «agréables à avoir» par opposition aux exigences.

Pour la documentation des exigences logicielles, le libellé des exigences facultatives est parfaitement correct, tant que vous utilisez ce terme conformément aux mots clés RFC 2119 pour indiquer les niveaux d'exigence - c'est-à-dire pour indiquer les éléments qui sont vraiment facultatifs.

Lorsque votre texte de spécification implique un verbe au lieu d'un adjectif, utilisez "MAI" au lieu de "FACULTATIF".

Puisqu'il est petit et facile à lire, le texte RFC est entièrement cité ci-dessous:

    Groupe de travail réseau S. Bradner
    Demande de commentaires: 2119 Harvard University
    BCP: 14 mars 1997
    Catégorie: Meilleures pratiques actuelles


            Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence

    Statut de ce mémo

       Ce document spécifie les meilleures pratiques Internet actuelles pour
       Internet Community, et demande des discussions et des suggestions pour
       améliorations. La distribution de ce mémo est illimitée.

    Abstrait

       Dans de nombreux documents de suivi des normes, plusieurs mots sont utilisés pour signifier
       les exigences de la spécification. Ces mots sont souvent
       capitalisé. Ce document définit ces mots tels qu'ils devraient être
       interprété dans les documents de l'IETF. Auteurs qui suivent ces directives
       devraient incorporer cette phrase vers le début de leur document:

          Les mots clés "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DOIT", "DOIT
          PAS "," DEVRAIT "," NE DEVRAIT PAS "," RECOMMANDÉ "," MAI ", et
          "FACULTATIF" dans ce document doit être interprété comme décrit dans
          RFC 2119.

       Notez que la force de ces mots est modifiée par l'exigence
       niveau du document dans lequel ils sont utilisés.

    1. DOIT Ce mot, ou les termes "OBLIGATOIRE" ou "DOIT", signifie que le
       la définition est une exigence absolue de la spécification.

    2. NE DOIT PAS Cette phrase, ou la phrase "NE DOIT PAS", signifie que le
       la définition est une interdiction absolue de la spécification.

    3. DEVRAIT que ce mot, ou l'adjectif "RECOMMANDÉ", signifie qu'il
       peut exister des raisons valables dans des circonstances particulières d'ignorer
       particulier, mais toutes les implications doivent être comprises et
       soigneusement pesé avant de choisir un cours différent.

    4. NE DEVRAIT PAS que cette phrase ou la phrase "NON RECOMMANDÉ" signifie que
       il peut exister des raisons valables dans des circonstances particulières lorsque
       un comportement particulier est acceptable, voire utile, mais le
       les implications doivent être comprises et le cas soigneusement pesé
       avant d'implémenter tout comportement décrit avec cette étiquette.

    5. MAI Ce mot, ou l'adjectif "FACULTATIF", signifie qu'un élément est
       vraiment facultatif. Un fournisseur peut choisir d'inclure l'article car un
       marché particulier l'exige ou parce que le vendeur estime que
       il améliore le produit tandis qu'un autre fournisseur peut omettre le même article.
       Une implémentation qui n'inclut pas d'option particulière DOIT être
       prêt à interagir avec une autre mise en œuvre qui ne
       inclure l'option, mais peut-être avec des fonctionnalités réduites. dans le
       même veine une mise en œuvre qui comprend une option particulière
       DOIT être prêt à interagir avec une autre mise en œuvre qui
       n'inclut pas l'option (sauf, bien sûr, pour la fonction
       offre.)

    6. Orientation dans l'utilisation de ces impératifs

       Les impératifs du type défini dans cette note doivent être utilisés avec précaution
       et avec parcimonie. En particulier, ils NE DOIVENT être utilisés que
       effectivement nécessaire pour l'interopérabilité ou pour limiter le comportement qui a
       potentiel de causer des dommages (par exemple, limiter les retransmissions)
       par exemple, ils ne doivent pas être utilisés pour essayer d'imposer une méthode particulière
       sur les implémenteurs où la méthode n'est pas requise pour l'interopérabilité.

    7. Considérations de sécurité

       Ces termes sont fréquemment utilisés pour spécifier un comportement avec sécurité
       implications. Les effets sur la sécurité de la non-mise en œuvre d'un MUST ou
       DEVRAIT, ou faire quelque chose que la spécification dit NE DOIT PAS ou DEVRAIT
       NE PAS faire peut être très subtil. Les auteurs de documents doivent prendre le temps
       d'élaborer les implications de sécurité de ne pas suivre
       recommandations ou exigences car la plupart des exécutants n'auront pas
       ont profité de l’expérience et de la discussion qui ont produit le
       spécification.

    8. Remerciements

       Les définitions de ces termes sont un amalgame de définitions prises
       à partir d'un certain nombre de RFC. En outre, des suggestions ont été
       constituée d'un certain nombre de personnes, dont Robert Ullmann, Thomas
       Narten, Neal McBurnett et Robert Elz.

Cela ne ferait pas de mal si votre documentation se réfère à RFC comme source de définitions:

Ce document utilise des définitions basées sur celles spécifiées dans la RFC 2119 .

J'apprécie que ce n'est pas une réponse à votre question, mais dans mon monde, c'est toujours une exigence, même si pour une raison quelconque vous n'allez pas y répondre.

J'aime l' approche MoSCoW (doit avoir, devrait avoir, pourrait avoir, n'aura pas cette fois) pour catégoriser les exigences avec les utilisateurs, ainsi que d'autres facteurs (dans mon monde réglementé, les exigences peuvent être critiques ou non critiques, et bien d'autres argument éclate sur des exigences facultatives mais critiques.)

Un meilleur mot pour une exigence facultative est « Recommandation »

Que diriez-vous de l'identifier comme une fonctionnalité facultative ou des tâches facultatives. Cela ne sera fait que si, à un certain moment du projet, il a été déterminé qu'il y a du temps et de l'argent disponibles pour compléter ces fonctionnalités.

Ils peuvent également être déclenchés si un événement externe se produit. Si les clients passent à Windows 8, les tâches suivantes devront être effectuées ...

La description de la fonctionnalité doit inclure une date limite pour déterminer si elles seront effectuées.

Les exigences sont classées en 4 domaines en génie logiciel:

1. Exigences opérationnelles : se concentre sur les buts et objectifs commerciaux globaux du système
2. Exigences de l'utilisateur : se concentre sur les objectifs de l'utilisateur et sur ce que les utilisateurs doivent faire pour utiliser le système afin d'atteindre les objectifs de l'entreprise
3. Exigences fonctionnelles : quelles fonctionnalités et tâches le système doit effectuer pour atteindre les objectifs commerciaux
4. Exigences non fonctionnelles : quelles sont les exigences autres que fonctionnelles. Cela inclut l'environnement, les contraintes, l'interface, les problèmes de maintenance, etc.

Maintenant, les exigences peuvent être facultatives ou obligatoires , selon les 4 catégories ci-dessus, que j'ai décrites ci-dessus. Les exigences facultatives peuvent également entrer dans le champ d'application du système considéré ou en sortir. Les exigences facultatives sont un bon moyen d'éviter Scope Creep et de définir votre étendue en termes précis.

Les exigences facultatives feront toujours partie de l'ingénierie logicielle car elles nous aident à identifier la portée et sont un bon moyen d'éviter Scope Creep. Vous ne pouvez jamais dire qu'ils contredisent les pratiques d'ingénierie de SDLC. Cependant, les exigences doivent être hiérarchisées et bien définies.

Dans le modèle Volere, le terme "salle d'attente" est utilisé.

... Ce modèle est destiné à être utilisé comme base pour vos spécifications d'exigences. Le modèle fournit pour chacun des types d'exigences appropriés pour les systèmes commerciaux, scientifiques et logiciels d'aujourd'hui. Il fournit une liste de contrôle, une structure et une traçabilité pour vos besoins ... Le modèle est indépendant de l'outil et a été utilisé avec succès avec Yonix, Requisite, DOORS, Calibre RM, IRqA et d'autres outils populaires ...

Les techniques Volere sont décrites dans le livre Mastering the Requirements Process de Suzanne Robertson et James Robertson ...

Dans mon entreprise (vaisseau spatial), ils sont appelés «objectifs», ce qui indique qu'ils sont documentés et que des efforts seront déployés pour les atteindre, mais le système sera toujours considéré comme réussi s'il n'est pas atteint; «désirs» (pas un vrai mot, mais vous y êtes), indiquant que quelqu'un les veut et qu'ils essaient d'atteindre le statut d'objectifs mais ne sont pas encore acceptés ou documentés; ou "exigences rampantes", qui est une version plus désobligeante des exigences indiquant des choses qui essaient de consommer des ressources mais qui n'en valent pas la peine dans un projet essayant de réaliser "assez bien" où elles compromettront ou menaceront d'atteindre les exigences réelles.

Si vos besoins sont prioritaires , vous pouvez les considérer comme des besoins de faible priorité .

Je suis assez surpris que personne n'ait mentionné que ces objectifs sont appelés "objectifs". Chaque entreprise pour laquelle j'ai travaillé les a appelés ainsi. Ils sont dénotés par l'utilisation des mots "sera" ou "devrait" au lieu de "doit". Parfois, ils sont inclus dans les accolades lorsque l'on parle de chiffres. Par exemple, le système doit fonctionner en continu sans nécessiter l'attention de l'opérateur pendant 100 {250} heures. Cela signifie que l'exigence qui doit être satisfaite est de 100 heures, mais l'objectif est de 250 heures.

En passant, il est très rare que quiconque conçoive réellement pour répondre à l'exigence objective, à moins qu'il n'y ait une sorte d'incitation.

Le terme «désir» est parfois utilisé pour des exigences facultatives. Cependant, il peut ne pas être approprié pour un document officiel.

Je suis surpris que toutes les réponses concernent le suivi des exigences dans le développement de projet. Bien que développeur, je ne me suis jamais trop inquiété de cette terminologie dans ce contexte. Lorsque j'ai lu la question pour la première fois, j'ai supposé qu'elle concernait les spécifications des produits des utilisateurs et non le développement des produits. Par exemple, une encyclopédie peut répertorier une imprimante couleur comme exigence facultative. Son requis si vous voulez profiter pleinement de l'application, mais facultatif si vous voulez afficher l'écran. Et si vous aviez par exemple une imprimante monochrome? Comment savoir si votre application fonctionne avec la restriction évidente que certaines photos peuvent ne pas sembler si bonnes? Ou ne pas imprimer du tout? Comme un autre exemple, comment dois-je vérifier un examen de l'imprimante pour vérifier si l'encre est une exigence ou une exigence facultative dans une imprimante multifonction? En d'autres termes, puis-je toujours numériser? Quelques conseils sur la terminologie et les éléments à rechercher seraient les bienvenus en tant que développeur / vendeur de produits et en tant que consommateur.

Je les appellerais des "fonctionnalités optionnelles", pas des exigences optionnelles. Les exigences sonnent comme quelque chose que vous devez avoir , tandis que les fonctionnalités sonnent comme un complément au produit d'origine.