temps de lecture: 9 minutes
des exigences clairement définies sont des signes essentiels sur la route qui mène à un projet réussi. Ils établissent un accord formel entre un client et un fournisseur qu’ils travaillent tous les deux pour atteindre le même objectif. Des exigences détaillées et de haute qualité aident également à atténuer les risques financiers et à respecter le calendrier du projet., Selon la définition du corps D’analyse des connaissances de L’entreprise, les exigences sont une représentation utilisable d’un besoin.
la création d’exigences est une tâche complexe car elle comprend un ensemble de processus tels que l’élicitation, l’analyse, la spécification, la validation et la gestion. Dans cet article, nous allons discuter des principaux types d’exigences pour les produits logiciels et fournir un certain nombre de recommandations pour leur utilisation.
Classification des exigences
avant de discuter de la façon dont les exigences sont créées, différencions leurs types.,
Haut niveau d’exigences en cascade vers le bas pour les détails spécifiques
exigences de l’Entreprise. Ceux-ci comprennent des énoncés de haut niveau de buts, d’objectifs et de besoins.
exigences des parties Prenantes. Les besoins des différents groupes de parties prenantes sont également spécifiés pour définir ce qu’ils attendent d’une solution particulière.
les exigences de la Solution. Les exigences de Solution décrivent les caractéristiques qu’un produit doit avoir pour répondre aux besoins des parties prenantes et de l’entreprise elle-même.,
- Les exigences non fonctionnelles décrivent les caractéristiques générales d’un système. Ils sont également connus sous le nom d’attributs de qualité.
- Les exigences fonctionnelles décrivent comment un produit doit se comporter, quelles sont ses caractéristiques et ses fonctions.
exigences de Transition. Un groupe supplémentaire d’exigences définit ce qui est nécessaire à une organisation pour passer avec succès de son état actuel à son état souhaité avec le nouveau produit.
explorons plus en détail les exigences fonctionnelles et non fonctionnelles.,
exigences fonctionnelles et leurs spécifications
les exigences fonctionnelles sont des caractéristiques du produit ou des fonctions que les développeurs doivent implémenter pour permettre aux utilisateurs d’accomplir leurs tâches. Il est donc important de Les préciser à la fois pour l’équipe de développement et pour les parties prenantes. Généralement, les exigences fonctionnelles décrivent le comportement du système dans des conditions spécifiques. Par exemple:
Une fonction de recherche permet à un utilisateur de rechercher parmi diverses factures s’il souhaite créditer une facture émise.
Voici un autre exemple simple: en tant qu’invité, Je veux un canapé sur lequel je peux dormir toute la nuit.,
Les exigences sont généralement écrites en texte, en particulier pour les projets agiles. Cependant, ils peuvent aussi être des effets visuels. Voici les formats et documents les plus courants:
- Software requirements specification document
- cas D’utilisation
- User stories
- Work Breakdown Structure (WBS) (functional decomposition)
- Prototypes
- modèles et diagrammes
Software requirements specification document
Les exigences fonctionnelles et non fonctionnelles peuvent être formalisées dans le document requirements specification (SRS)., (Pour en savoir plus sur la documentation du logiciel, lisez notre article sur ce sujet.) Le SRS contient des descriptions des fonctions et des capacités que le produit doit fournir. Le document définit également les contraintes et les hypothèses. Le SRS peut être un document unique communiquant les exigences fonctionnelles ou il peut accompagner d’autres documents logiciels tels que des histoires d’utilisateurs et des cas d’utilisation.
Nous ne recommandons pas de composer des SRS pour l’ensemble de la solution avant le lancement du développement, mais vous devez documenter les exigences pour chaque fonctionnalité avant de la construire., Une fois que vous avez reçu les commentaires initiaux des utilisateurs, vous pouvez mettre à jour le document.
SRS doit comprendre les sections suivantes:
But. Définitions, aperçu du système et contexte.
l’Ensemble de la description. Hypothèses, contraintes, règles métier et vision du produit.
exigences Spécifiques. Attributs système, exigences fonctionnelles, exigences de base de données.
il est essentiel de rendre le SRS lisible pour toutes les parties prenantes. Vous devez également utiliser des modèles avec un accent visuel pour structurer l’information et aider à la comprendre., Si vous avez des exigences stockées dans d’autres formats de document, liez-les pour permettre aux lecteurs de trouver les informations nécessaires.
exemple: si vous souhaitez voir un document réel, téléchargez cet exemple SRS créé à L’Université D’État du Michigan, qui comprend tous les points mentionnés ci-dessus en plus de présenter des cas d’utilisation pour illustrer des parties du produit.
de cas d’Utilisation
de cas d’Utilisation décrit l’interaction entre le système et les utilisateurs externes qui mène à atteindre des objectifs particuliers.
Chaque cas d’utilisation comprend trois éléments principaux:
les Acteurs., Ce sont les utilisateurs en dehors du système qui interagissent avec le système.
Système. Le système est décrit par des exigences fonctionnelles qui définissent un comportement prévu du produit.
objectifs. Les objectifs de l’interaction entre les utilisateurs et le système sont décrits comme des objectifs.
Il existe deux formats pour représenter les cas d’utilisation:
- de cas d’Utilisation spécifications structurées dans le format texte
- diagramme de cas d’Utilisation
Un cas d’utilisation de la spécification représente la séquence des événements ainsi que d’autres renseignements qui se rapportent à ce cas d’utilisation., Un modèle de spécification de cas d’utilisation typique comprend les informations suivantes:
- Description
- condition pré et Post – interaction
- chemin d’interaction de base
- chemin alternatif
- chemin D’Exception
exemple:
modèle de spécification de cas d’utilisation
un diagramme de cas d’utilisation ne contient pas beaucoup de détails. Il montre un aperçu de haut niveau des relations entre les acteurs, les différents cas d’utilisation et le système.
Le diagramme de cas d’utilisation comprend les principaux éléments suivants:
de cas d’Utilisation., Généralement dessinés avec des ovales, les cas d’utilisation représentent différents scénarios d’utilisation que les acteurs peuvent avoir avec le système (se connecter, effectuer un achat, Afficher des articles, etc.)
les limites du Système. Les limites sont délimitées par la boîte qui regroupe divers cas d’utilisation dans un système.
acteurs. Ce sont les chiffres qui représentent les utilisateurs externes (personnes ou systèmes) qui interagissent avec le système.
les Associations. Les Associations sont tracées avec des lignes montrant différents types de relations entre les acteurs et les cas d’utilisation.,
Exemple:
diagramme de cas d’Utilisation exemple
articles de l’Utilisateur
Un article de l’utilisateur est une description documentée d’une fonctionnalité logicielle vu de la perspective de l’utilisateur final. L’histoire de l’utilisateur décrit exactement ce que l’utilisateur veut que le système fasse. Dans les projets agiles, les user stories sont organisées dans un backlog, qui est une liste ordonnée de fonctions du produit. Actuellement, les User stories sont considérées comme le meilleur format pour les éléments de backlog.,
Un utilisateur typique histoire est écrite comme ceci:
dans un <type de l’utilisateur>, Je veux <certains objectifs> alors que <quelque raison>.
exemple:
en tant qu’administrateur, je souhaite ajouter des descriptions aux produits afin que les utilisateurs puissent ensuite afficher ces descriptions et comparer les produits.
Les témoignages D’utilisateurs doivent être accompagnés de critères d’acceptation., Ce sont les conditions que le produit doit remplir pour être accepté par un utilisateur, des parties prenantes ou un propriétaire de produit. Chaque user story doit comporter au moins un critère d’acceptation. Les critères d’acceptation efficaces doivent être vérifiables, concis et parfaitement compris par tous les membres de l’équipe et les parties prenantes. Ils peuvent être écrits sous forme de listes de contrôle, de texte brut ou en utilisant le format Given/When/Then.
exemple:
Voici un exemple de liste de contrôle des critères d’acceptation pour une histoire utilisateur décrivant une fonction de recherche:
- Un champ de recherche est disponible dans la barre supérieure.,
- une recherche est lancée lorsque L’utilisateur clique sur Soumettre.
- l’espace réservé par défaut est un texte gris tapez le nom.
- L’espace réservé disparaît lorsque l’utilisateur commence à taper.
- la langue de recherche est l’anglais.
- l’utilisateur ne peut pas taper plus de 200 symboles.
- Il ne prend pas en charge les symboles spéciaux. Si l’Utilisateur a tapé un symbole spécial dans l’entrée de recherche, il affiche l’avertissement massage: L’entrée de recherche ne peut pas contenir de symboles spéciaux.,
Enfin, toutes les histoires d’utilisateur doit correspondre à l’INVESTIR qualité modèle:
- j’ai Indépendant
- N – Négociable
- V – Précieuses
- E – Estimable
- S – Petit
- T – Testable
Indépendant. Cela signifie que vous pouvez planifier et implémenter chaque histoire utilisateur séparément. Ceci est très utile si vous implémentez des processus d’intégration continue.
négociable. Cela signifie que toutes les parties conviennent de donner la priorité aux négociations plutôt qu’aux spécifications. Cela signifie également que les détails seront créés en permanence pendant le développement.
la valeur., Une histoire doit être précieuse pour le client. Vous devriez vous demander du point de vue du client « Pourquoi » vous devez implémenter une fonctionnalité donnée.
Estimatable. Une histoire d’utilisateur de qualité peut être estimée. Cela aidera une équipe à planifier et à hiérarchiser la mise en œuvre. Plus l’histoire est grande, plus il est difficile de l’estimer.
Petite. Les bonnes histoires d’utilisateurs ont tendance à être assez petites pour planifier des versions de production courtes. Les petites histoires permettent des estimations plus précises.
Testable. Si une histoire peut être testée, elle est assez claire et assez bonne., Les histoires testées signifient que les exigences sont remplies et prêtes à l’emploi.
décomposition fonctionnelle ou structures de répartition du travail (WBS)
une décomposition fonctionnelle ou WBS est un document visuel qui illustre comment les processus complexes se décomposent en leurs composants les plus simples. WBS est une approche efficace pour permettre une analyse indépendante de chaque partie. WBS permet également de capturer l’image complète du projet.
Nous suggérons la logique de décomposition fonctionnelle suivante:
- trouver la fonction la plus générale.
- trouvez la sous-fonction la plus proche.,
- trouvez le niveau suivant de la sous-fonction.
- Vérifiez votre diagramme.
Ou le processus de décomposition peut ressembler à ceci:
de Haut Niveau de la Fonction>Sous-fonction -> Processus> Activité
Les caractéristiques doivent être décomposé en le point le plus bas niveau des parties ne peut pas être décomposé plus loin.,
exemple:
un exemple de décomposition fonctionnelle
prototypes de logiciels
prototype de logiciel est un terme générique pour différentes formes de livrables à un stade précoce qui sont construits pour montrer comment les exigences doivent être mises en œuvre. Les Prototypes aident à combler les lacunes de vision et permettent aux parties prenantes et aux équipes de clarifier les domaines compliqués des produits en développement. Traditionnellement, les prototypes représentent le fonctionnement de la solution et donnent des exemples de la façon dont les utilisateurs interagiront avec elle pour accomplir leurs tâches.,
Les Prototypes peuvent être des représentations visuelles peu coûteuses et rapides d’exigences (prototypes jetables) ou plus complexes (prototypes évolutifs). Ce dernier peut même devenir les premières versions du produit qui ont déjà quelques morceaux du code final. Effectivement, les prototypes évolutifs peuvent même se transformer en MVP que nous avons décrits dans un article séparé.
documents de conception et prototypes
les exigences de conception sont généralement collectées et documentées à l’aide de trois formats principaux qui se transforment les uns en les autres:
Wireframes., Les Wireframes sont des structures graphiques de faible fidélité d’un site web ou d’une application. Ils aident à cartographier différentes pages de produits avec des sections et des éléments interactifs.
Maquettes. Une fois que les wireframes sont prêts, ils sont transformés en maquettes, des conceptions visuelles qui transmettent l’apparence du produit final. Finalement, les maquettes peuvent devenir la conception finale du produit.
la Conception de prototypes. Ces documents contiennent des visuels et permettent certaines interactions d’interface, comme faire défiler, cliquer sur des liens ou remplir des formulaires., Les prototypes de conception peuvent être construits à partir de zéro en utilisant HTML et CSS, mais la plupart des équipes UX utilisent des services de prototypage comme InVision.
exemple:
pour en savoir plus sur la façon dont les processus de conception UX sont gérés, consultez notre étude de cas sur la création d’une solution de gestion des voyages pour Cornerstone, un fournisseur SaaS d’entreprise, dans laquelle nous avons utilisé les trois types d’exigences de conception.
exigences non fonctionnelles
les exigences non fonctionnelles décrivent comment un système doit se comporter et établissent des contraintes de sa fonctionnalité. Ce type d’exigences est également connu sous le nom d’attributs de qualité du système.,
examinons de près les exigences non fonctionnelles typiques.
Usability
Usability définit à quel point il sera difficile pour un utilisateur d’apprendre et d’utiliser le système. La convivialité peut être évaluée de différents points de vue:
efficacité d’utilisation: le temps moyen nécessaire pour atteindre les objectifs d’un utilisateur, le nombre de tâches qu’un utilisateur peut effectuer sans aucune aide, le nombre de transactions effectuées sans erreur, etc.
intuitivité: comme il est simple de comprendre l’interface, les boutons, les en-têtes, etc.,
faible charge de travail perçue: combien de tentatives sont nécessaires par les utilisateurs pour accomplir une tâche particulière.
exemple: les exigences D’utilisabilité peuvent tenir compte des barrières linguistiques et des tâches de localisation: les personnes ne comprenant pas le français doivent pouvoir utiliser le produit. Ou vous pouvez définir des exigences d’accessibilité: les utilisateurs de clavier qui naviguent sur un site Web en utilisant <tabdoivent pouvoir accéder au bouton »Ajouter au panier »à partir d’une page de produit en 15 clics<tab>.,
sécurité
exigences de sécurité assurez-vous que le logiciel est protégé contre tout accès non autorisé au système et à ses données stockées. Il prend en compte différents niveaux d’autorisation et d’authentification entre différents rôles d’utilisateurs. Par exemple, la confidentialité des données est une caractéristique de sécurité qui décrit qui peut créer, voir, copier, modifier, ou supprimer des informations. La sécurité comprend également une protection contre les virus et les attaques de logiciels malveillants.
exemple: les autorisations d’accès pour les informations système particulières ne peuvent être modifiées que par l’administrateur des données du système.,
fiabilité
la fiabilité définit la probabilité que le logiciel fonctionne sans défaillance pendant une période de temps donnée. La fiabilité diminue en raison de bogues dans le code, de pannes matérielles ou de problèmes avec d’autres composants système. Pour mesurer la fiabilité du logiciel, vous pouvez compter le pourcentage d’opérations effectuées correctement ou suivre la période moyenne pendant laquelle le système s’exécute avant d’échouer.
exemple: le processus de mise à jour de la base de données doit annuler toutes les mises à jour associées lorsqu’une mise à jour échoue.,
Performance
la Performance est un attribut de qualité qui décrit la réactivité du système aux diverses interactions de l’utilisateur avec lui. De mauvaises performances entraînent une expérience utilisateur négative. Cela compromet également la sécurité du système lorsqu’il est surchargé.
exemple: le temps de chargement de la première page ne doit pas dépasser 2 secondes pour les utilisateurs qui accèdent au site web à l’aide d’une connexion mobile LTE.
disponibilité
La disponibilité est mesurée par la période pendant laquelle les fonctionnalités et les services du système sont disponibles pour toutes les opérations., Ainsi, les périodes de maintenance planifiées influencent directement ce paramètre. Et il est important de définir comment l’impact de la maintenance peut être minimisé. Lors de la rédaction des exigences de disponibilité, l’équipe doit définir les composants les plus critiques du système qui doivent être disponibles à tout moment. Vous devez également préparer des notifications utilisateur au cas où le système ou l’une de ses parties deviendrait indisponible.
exemple: le déploiement d’un nouveau module ne doit pas avoir d’impact sur la page d’accueil, les pages produit et vérifier la disponibilité des pages et ne doit pas prendre plus d’une heure., Le reste des pages qui peuvent rencontrer des problèmes doit afficher une notification avec une minuterie indiquant quand le système va être de nouveau.
évolutivité
les exigences d’évolutivité décrivent comment le système doit se développer sans influence négative sur ses performances. Cela signifie servir plus d’utilisateurs, traiter plus de données et effectuer plus de transactions. L’évolutivité a des implications matérielles et logicielles. Par exemple, vous pouvez augmenter l’évolutivité en ajoutant de la mémoire, des serveurs, ou de l’espace disque. D’autre part, vous pouvez compresser les données, utiliser des algorithmes d’optimisation, etc.,
exemple: la limite de fréquentation du site Web doit être suffisamment évolutive pour prendre en charge 200 000 utilisateurs à la fois.
mots finaux
tous les projets logiciels incluent les limites d’information qui décrivent les objectifs du produit et du projet. Ces limites sont définies dans les exigences et les spécifications du projet. La valeur de la création d’une spécification d’exigence logicielle réside dans l’optimisation du processus de développement. Les spécifications des exigences logicielles répondent à toutes les questions du développeur sur le produit qui sont nécessaires pour démarrer le travail., La spécification fonctionnelle est approuvée par le client et garantit que les développeurs construisent ce que le client veut.