Élaboration des exigences pour le développement des fonctionnalités: Cours "Créer un logiciel et gérer son développement"

Bonjour, Habr! Poursuivant la série sur la gestion des produits , nous discutons aujourd'hui des exigences de développement. Dans cet article, nous parlerons de la manière dont un chef de produit interagit avec les développeurs R&D, pourquoi des exigences sont nécessaires, comment les formuler correctement et quelles conclusions devraient être tirées des exigences de développement par divers spécialistes, y compris les développeurs eux-mêmes, les responsables, l'assurance qualité, etc. D'un autre côté, les développeurs futurs et confirmés apprendront ce qu'un chef de produit peut (et devrait réellement) vous offrir. Tous les détails sont sous la coupe.

Table des matières du cours

1.

2.

3.

4.

5.

6.

7. < —

8. - -

9.

—



Parfois, il semble que la tâche du développeur est tout simplement évidente! Mais ne vous fiez pas trop au bon sens pour poser le problème. Pour toute tâche, même la plus simple, des écarts sont possibles, car les gens ont tendance à vivre dans un monde de leurs propres illusions. Par exemple, en République de Cuba, on pense que les murs doivent être clairs et variés, et même si le client demande à les peindre en blanc, les travailleurs peuvent ajouter des taches de couleur, car "c'est plus beau comme ça". Il en va de même pour le développement.







Un document tel que les exigences aide à surmonter le «mur du malentendu». La présence d'exigences vous permet de créer la même idée de ce qui doit être fait dans le produit, de ce que devrait être exactement la fonctionnalité.

Comment les exigences sont construites

Lors de la formulation des exigences de développement, vous devez comprendre pour quel utilisateur nous développons le produit. C'est là que User Persona est utile (nous en avons déjà parlé ici ). User Persona est ce qu'on appelle l'acteur dans le système, et pour chaque acteur, nous définissons un ensemble de règles et de capacités.



Par exemple, les acteurs suivants peuvent être définis dans une application de forum Web:

• L'administrateur peut tout faire, littéralement tout - y compris l'attribution de rôles (personnes) à d'autres utilisateurs.
• Un utilisateur régulier ne peut laisser que des messages.
• Le modérateur peut laisser des messages, supprimer les messages d'autres personnes, bannir les utilisateurs réguliers.

Dans le cas de l'application d'appel taxi, que nous rappelons périodiquement au cours de notre stage, les personnes peuvent être un passager, un chauffeur de taxi et un opérateur.







Pour formuler une exigence adéquate, vous devez rédiger un document que nous appelons Description de la fonctionnalité. Et pour cela, vous devez répondre aux questions suivantes:

• Pourquoi? Quel est le but? Quels sont les avantages commerciaux?
• Pourquoi? Quels sont les risques? Que perdrons-nous si nous ne le faisons pas? Que se passe-t-il si nous le faisons?
• Quoi? Quel problème voulons-nous résoudre? Pour qui?
• Comment? Exigences fonctionnelles et cas d'utilisation (séquence d'actions).

Il est également nécessaire de prévoir la présence d'un vocabulaire des termes du domaine. Cela est particulièrement vrai pour des acronymes spécifiques. Par exemple, le développeur peut ne pas connaître tous les noms de processus et les spécificités de l'industrie sidérurgique ou de la cuisine.



Enfin, le document doit faire une section «Approbations», dans laquelle, d'une part, les clients de la fonctionnalité (parties prenantes, clients, chef de produit) conviennent que la description correspond à ce qu'ils veulent du produit. D'autre part, les développeurs (chefs d'équipe, architectes) confirmeront que la description de la tâche dans les exigences est claire et complète. Ainsi, tous les participants au processus de développement doivent dire: «Oui, nous comprenons le document, maintenant c'est possible».

Métriques auxiliaires

Lorsque vous travaillez avec des exigences, les mesures auxiliaires aident à réaliser une exécution précise de la tâche, ainsi qu'à réduire le temps consacré à la vérification de la conformité.

• La définition de Terminé est une brève description de la façon de savoir si une fonctionnalité fonctionne.
• Exigences non fonctionnelles - exigences relatives aux paramètres techniques tels que la réactivité de l'interface utilisateur, la charge du backend, les limitations du processeur et de la RAM. C'est un point très important, car si vous n'exprimez pas les exigences, vous pouvez obtenir un monstre - Photoshop intégré au lieu de simplement choisir la couleur de la voiture.
• Exigences de sécurité - cryptage, stockage des données personnelles, etc.
• Corner Case - test des cas de bord. Que se passe-t-il si le prix du produit est égal à 0? Combien de voitures de taxi une personne peut-elle commander en même temps?
• — , . , , , , — Visa, MasterCard, , .
• . , , , , . , , . , .
• . , “ ”, “ ”.

Exigences fonctionnelles et non fonctionnelles, cas d'utilisation

Arrêtons-nous un peu sur les exigences fonctionnelles et non fonctionnelles.







Les exigences fonctionnelles expliquent ce qui doit être fait, elles listent les actions de l'application en réaction aux actions de l'acteur. Ces exigences sont implémentées dans les scénarios d'utilisation répertoriés.



Les exigences non fonctionnelles saisissent les conditions dans lesquelles la solution doit rester efficace, ou les qualités que la solution doit posséder. Les exemples les plus courants d'exigences non fonctionnelles sont:

• évolutivité,
• fiabilité, temps d'arrêt minimum,
• méthodes de soutien.

Des cas d'utilisation sont également utilisés pour décrire les exigences. C'est l'élément principal de notre document, que nous préparons lors de la génération d'une demande de fonctionnalité. Les scripts doivent fournir un flux complet, étape par étape, de ce qu'un utilisateur peut faire avec votre application.



Les scripts personnalisés contiennent généralement les sections suivantes:



Section: Contexte

Répond à la question: Quel composant? Quelle est la condition?

Exemple: l'utilisateur n'est pas autorisé.



Section: Acteur

Répond à la question: Quelle personne?

Exemple: utilisateur régulier.



Section: Conditions préalables

Répond à la question: Quelles sont les fonctionnalités?

Exemple: il y a une invitation à recevoir un statut VIP.



Section:Objectif

Répond à la question: qu'est-ce que l'utilisateur a l'intention de faire / d'obtenir?

Exemple: connectez-vous.



Section: Scénario principal

Répond à la question: Quelles mesures doivent être prises pour atteindre le résultat?

Exemple: Entrez votre nom d'utilisateur et votre mot de passe, appuyez sur le bouton "Entrée".



Section: Bad Scripts

Répond à la question: Qu'est-ce qui peut mal tourner, une liste d'erreurs, y compris le texte des messages d'erreur pour l'utilisateur.

Exemple: le bouton n'est pas enfoncé, la langue ne change pas, la connexion ne peut pas être établie via le protocole https, etc.



Section: Layouts

Répond à la question: Layouts ou prototypes possibles de conception d'interface utilisateur.

Exemple: dessiner dans Figma ou Sketch.



Dans une forme simplifiée, les scripts personnalisés peuvent ressembler à ceci:

Comment la description des fonctionnalités est-elle lue?

Chaque catégorie d'utilisateurs peut recueillir des informations utiles pour eux-mêmes à partir des exigences. Et il est donc très important de garder à l'esprit que les exigences seront lues par différentes personnes:

• Développeurs - Il est important pour eux de savoir pourquoi la fonctionnalité est nécessaire, quel problème elle résout. Afin de ne pas perdre de temps sur des correctifs plus tard, les développeurs doivent fournir une liste complète de tous les scénarios, ainsi que faire attention aux cas Corner. Si vous informez le développeur à temps de ce que nous ajouterons plus tard, par exemple, les paiements avec une carte MIR, il pourra prévoir cette possibilité au niveau de l'architecture. Ainsi, les coûts peuvent être considérablement réduits en évitant les retouches.
• , QA — , . Corner Cases. , — , .. ( , , ) . , . .
• DevOps Datacenter Operations— , , , . DevOps , , , .
• — , , . , , .

Si vous écrivez des exigences de développement, assurez-vous de poser la question - qui est votre utilisateur, ce qu'il fait (ou peut faire), dans quelles conditions il se trouve. Créez un diagramme de son comportement, cela aidera à décrire tous les aspects des exigences.



Lors de la rédaction d'un document, il faut être le plus court possible et ne pas laisser de lieux incompréhensibles. Les exigences couvriront de toute façon plusieurs pages. Il doit être lu par de nombreuses personnes et doit être lisible.



Suivez une règle simple: commencez par l'essentiel et ajoutez ensuite des détails. De plus, vous devez obtenir des commentaires du contrôle qualité, des développeurs, des DevOps et d'autres parties prenantes. Très probablement, la description de la fonction acquerra de nouveaux détails après communication avec les parties prenantes.



Essayez de penser à des scénarios non évidents. Il est conseillé de déterminer immédiatement ce que votre application doit faire en cas d'urgence. Pensez aux composants externes qui affectent votre fonctionnalité. Et quand tout est prêt, posez à nouveau la question: "Que pouvez-vous tester d'autre que les étapes décrites dans les scripts personnalisés?"

Conclusion

Dans le prochain article, nous parlerons du business plan et du prix du nouveau produit.



En attendant, partagez dans les commentaires votre expérience de travail avec les exigences, tant du côté du gestionnaire que de l'exécuteur testamentaire. Dites-nous, y avait-il un exemple dans votre pratique où un client fonctionnel voulait une chose, mais au final cela s'est avéré complètement différent à cause d'un malentendu?



→ L'enregistrement vidéo de toutes les conférences du cours est disponible sur YouTube



Lecture sur la feuille de route et les exigences de développement: