Pourquoi se soucier de différencier les exigences fonctionnelles et non fonctionnelles?

Je comprends la différence entre les deux, mais mes collègues m'interrogent sur l'intérêt des exigences d'étiquetage comme fonctionnelles ou non fonctionnelles (ou transitoires). Pourquoi se donner la peine de le faire? Il a passé ce qu'il a dit être deux jours à parcourir une liste d'exigences pour un projet, et n'y a vu aucun avantage, car le résultat final était de soumettre le document à une autre entité commerciale avec l'édit, "Faites tout".

Ce que je crains, ce sont des exigences regroupées dans un seul document. J'ai essayé d'expliquer l'avantage en termes pratiques, mais je n'ai pas pu le vendre. Comment puis-je vendre l'avantage de documenter les exigences fonctionnelles et celles qui ne le sont pas?

Une séparation explicite des exigences facilitera la conception du bon système.

Avec des exigences non fonctionnelles (je préfère le concept / terme attributs de qualité - devrait fournir de nouvelles perspectives au-delà du fonctionnel par rapport au non fonctionnel), vous êtes plus concerné par les propriétés du logiciel plutôt que par la fonctionnalité. C'est ainsi que le système remplit une fonction, pas simplement ce que fait le système. Les exigences de qualité ont une influence significative sur l'architecture du système d'une manière différente des exigences fonctionnelles et pour cette raison, elles doivent être traitées différemment.

La séparation des attributs de qualité des exigences fonctionnelles vous permet d'analyser, de spécifier et de hiérarchiser différents types d'exigences de différentes manières. Par exemple, les attributs de qualité sont normalement spécifiés à l'aide d'un scénario d'attribut de qualité, tandis que les exigences fonctionnelles peuvent prendre la forme d'histoires, de cas d'utilisation, d'instructions shall ou de tout autre nombre de formats. La plupart des systèmes sur lesquels j'ai travaillé avaient moins d'une douzaine d'attributs de qualité et beaucoup, beaucoup plus d'exigences fonctionnelles.

J'introduirais en fait un autre type d'exigences - les contraintes techniques . Encore une fois, la séparation explicite des exigences dans ces trois compartiments vous donne des indices sur la façon de faire les bons compromis lors de la construction du système. Les exigences fonctionnelles sont souvent assez négociables, les attributs de qualité influencent fortement votre architecture et les structures que vous choisissez, les contraintes techniques ne sont pas négociables.

S'il s'agissait de mon équipe, je leur dirais que les exigences devraient être clairement annotées par type pour nous assurer de ne rien manquer d'important dans l'architecture. Pensez aux pilotes architecturaux, pas seulement à la fonctionnalité.

Anthony Lattanze dans Architecting Software Intensive Systems: A Practitioners Guide donne un aperçu pratique des pilotes architecturaux et pourquoi ils devraient être traités différemment, beaucoup plus complet que mon résumé ici.

Lorsque chaque exigence a une priorité / un poids égal (en particulier «obligatoire»), vous avez probablement plus à vous soucier que de simplement diviser les exigences fonctionnelles et non fonctionnelles.

Néanmoins, il existe plusieurs raisons de séparer les deux catégories d'exigences:

Responsabilité de la mise en œuvre J'ai constaté que de nombreuses exigences non fonctionnelles - en particulier celles axées sur les performances, ne s'appliquent que modérément au développeur. Bien qu'une conception puisse prendre en charge l'évolutivité et la vitesse (et des sections de code spécifiques peuvent être ajustées), la capacité de répondre à toutes les exigences de performances dépend généralement de l'architecture et souvent de la configuration matérielle.

Responsabilité des tests Dans quelle mesure l'utilisateur ou l'équipe AQ ​​est-il habilité à vérifier que les exigences de sécurité, de tolérance aux pannes, de sécurité et de fiabilité sont respectées?

Ne vous répétez pas La documentation doit suivre le même principe SEC que le code. Les exigences communes de style d'interface utilisateur doivent être regroupées. Si la personne responsable des exigences le souhaite vraiment, elle peut référencer les exigences non fonctionnelles (individuellement ou en groupe) dans les exigences fonctionnelles.

Versioning Si vous êtes dans un environnement d'entreprise avec beaucoup de "standards" - vous pouvez écrire des documents spécifiques pour les exigences d'interface utilisateur ou de sécurité (pour n'en nommer que quelques-uns) qui peuvent être versionnés. De cette façon, vous pouvez écrire dans les exigences spécifiques à l'application (principalement les exigences fonctionnelles): "L'application doit respecter la V2.3 des exigences de sécurité définies dans XYZ-Company-SecReq-DocumnentNamingStandard.docx".

Pourquoi se soucier de différencier les exigences fonctionnelles et non fonctionnelles?

L'une des raisons de la différenciation est le niveau d'abstraction entre les deux types. Les exigences non fonctionnelles sont au niveau du système et indiquent comment le système dans son ensemble doit se comporter. Les exigences fonctionnelles se réfèrent à une fonctionnalité spécifique et aux fonctionnalités et fonctionnalités qui doivent être fournies aux clients.

Les exigences non fonctionnelles contraignent également le système, tandis que les exigences fonctionnelles indiquent ce que le système doit faire. Les exigences non fonctionnelles limitent la manière dont les exigences fonctionnelles doivent être conçues et mises en œuvre ultérieurement. En les séparant, il devient possible d'identifier clairement les caractéristiques des contraintes et limitations.

Ce que je crains, ce sont des exigences regroupées dans un seul document. J'ai essayé d'expliquer l'avantage en termes pratiques, mais je n'ai pas pu le vendre. Comment puis-je vendre l'avantage de documenter les exigences fonctionnelles et celles qui ne le sont pas?

D'après mes expériences, les exigences fonctionnelles et non fonctionnelles sont en fait regroupées dans le même document ou suivies dans le même système. Cependant, ils reçoivent leurs propres sections distinctes du document ainsi que les critères de réussite pour chacun d'eux.

Généralement, vous catégorisez les exigences pour aider l'équipe à répondre à ces exigences. S'il existe une exigence spécifiquement ciblée sur un besoin architectural, l'appeler une exigence "Architecture" devrait aider l'équipe lorsqu'elle travaille sur l'architecture.

Un grand document unique de toutes les exigences n'est pas nécessairement une mauvaise chose ... Passer 2 jours à l'examiner n'est pas mauvais non plus. Le problème est généralement qu'une fois qu'une personne a examiné les exigences, elle les comprend, mais il n'est pas plus facile pour quiconque de faire de même. Il peut être très utile de commencer à étiqueter les exigences avec des métadonnées qui aideront les autres personnes qui se joignent au projet.

Essayez peut-être de le décrire comme un problème d'abstraction. Si vous devez travailler dans une base de code héritée, vous ne vous contentez pas de lire toutes les lignes de code existantes, puis vous commencez à travailler. Vous suivez la structure du code pour vous aider. Avoir une certaine structure dans les exigences aide de la même manière.

La séparation présente de multiples avantages.

1. Gagnez du temps sur les tests (c.-à-d. Ne testez que les exigences fonctionnelles)
2. Économise du temps sur les modifications futures des exigences (c.-à-d. Que les exigences non fonctionnelles prendront moins de temps pour examiner / approuver / mettre en œuvre / tester)
3. Dans un monde réglementé (c'est-à-dire la FDA, etc.), les exigences non fonctionnelles nécessitent 1 / 10e de la quantité de paperasse requise par une exigence fonctionnelle.
4. Donne à l'équipe la possibilité de répartir le travail entre les membres de l'équipe senior (fonctionnelle) et junior (non fonctionnelle).

Je pourrais continuer ...

En surface, deux jours semblent être longs, à long terme, cela pourrait économiser des semaines, voire des mois de travail futur.