Histoires d'utilisateurs pour les exigences fonctionnelles [fermé]

Question

Comme nous sommes une petite entreprise, je travaille à la fois comme un chef de projet et développeur. Le cahier des charges que je crée pour les clients contiennent un certain nombre d'éléments utilisés pour décrire et définir le projet, y compris des histoires d'utilisateur à côté d'autres éléments me semblent devoir être inclus pour définir le projet (par exemple wireframes, userflows, sitemaps, etc.) au client.

Si une spécification fonctionnelle « décrit comment un produit fonctionnera entièrement du point de vue de l'utilisateur. Il ne se soucie pas comment la chose est mis en œuvre. Il parle de fonctionnalités. « . Ensuite, personne ne voit aucun problème avec l'utilisation de User Stories pour définir une spécification fonctionnelle pour un site Web? Est-ce que quelqu'un fait faire des spécifications fonctionnelles de cette façon?

Vraiment, je suis en train de mon jeu un peu, et je me demandais si cela approche fonctionnerait pour les clients plus importants qui ont peut-être des idées plus strictes sur ce que les spécifications fonctionnelles doit contenir, dans lequel une approche formelle peut être nécessaire. Sans aucun doute à l'heure actuelle nos clients répondent bien à notre méthode de production de documents.

Je suis intéressé à entendre ce que les gens qui font la gestion de projet pensent des professionnels à ce sujet.

Answer 1

Je suis en désaccord avec ce que deux autres personnes ont dit.

Tout d'abord le peu que je suis d'accord avec - histoires sont une excellente façon d'énoncer les exigences fonctionnelles. Pour mon argent, ils sont l'une des meilleures façons de communiquer les exigences en fait dans un utilisateur final façon prendront vraiment. J'ai vu trop de spécifications qui se signé sans avoir jamais lu.

La seule chose que je dirais que vous pouvez ajouter à eux est des exigences non fonctionnelles - couvrant la performance, la sécurité, les volumes de données, l'audit, l'archivage et ainsi de suite. Bien qu'ils puissent être traités dans des histoires, parfois, ils sont mieux couvertes d'une manière qui traverse toutes les histoires.

Quant à savoir s'il est adapté aux grandes entreprises c'est là que je suis en désaccord. Dans mon expérience (et je l'ai fait des projets pour Shell, American Express, deux banques multinationales et autres) ils sont souvent plus formelle que les petites entreprises pour qu'ils soient très bien avec des histoires. La réalité est qu'un utilisateur dans une grande entreprise est pas mieux équipé (ou intéressés) à la lecture des diagrammes de classes et la séquence qu'ils ne le sont ailleurs.

La taille et la complexité du projet peuvent nécessiter des exigences plus détaillées, mais il est la taille du projet, pas la taille de l'entreprise qui compte quand vous déterminer comment vous documenter les exigences.

Pour moi, la meilleure exigences documentation est la documentation qui est adaptée à son public, et pour moi des histoires d'utilisateurs ont frappé l'ongle sur la tête la plupart du temps - ils sont assez courts et assez clair que quand ils les signent qu'ils veulent dire quelque chose parce qu'ils ont lu et compris les (par opposition au signe hors d'une spécification de 100 pages qui se lisent signifie invariablement, ils ont pas vraiment), mais assez bon pour les développeurs de travailler de trop.

Answer 2

Oui, vous pouvez utiliser des histoires d'utilisateur pour votre fonctionnelle nécessite. Je le fais tout le temps, et ont été pendant des années. À mon avis, cela fonctionne très bien, et mieux que d'autres systèmes que je l'ai utilisé.

Est-ce que ce travail d'approche pour les clients plus importants? Pour faire une généralisation grossière, non. Ils vont avoir un système qui utilisent pour définir les besoins, et probablement ses pas des histoires d'utilisateurs. Si vous venez avec des histoires d'utilisateurs, il va y avoir une rupture avec les pratiques actuelles, que vous aurez à travailler à travers.

J'ai réussi à l'aide des témoignages d'utilisateurs avec des organisations plus grandes, mais il faudra un effort concerté, que les deux parties doivent être engagés à.

Answer 3

Qu'est-ce que vous décrivez sont les scénarios de cas d'utilisation qui définissent les caractéristiques, voici ce qui est nécessaire du point de vue de la facilité d'utilisation et est exactement ce que le client comprendra et accepter. maquettes et diagrammes de flux écran sans aucun doute aider à la fois le client et les développeurs.

Une spécification de mise en œuvre peut alors être nécessaire pour instruire les développeurs sur ce qui doit être inclus dans la construction proprement dite, la profondeur de ce montant sera déterminé par vos capacités de développeurs qui comprennent leurs connaissances de l'architecture maison / cadre et des méthodes / conventions et peuvent inclure des détails sur les impacts que les différentes parties de l'application.

Nous travaillons aussi dans les petites équipes (parfois un ou deux développeurs) et nous croyons que ce qui précède est tout ce qu'il faut dans ce cas.

Les grandes entreprises avec des équipes beaucoup plus grandes peuvent utiliser la modélisation du logiciel, des diagrammes UML et d'autres spécifications plus détaillées. Dans le cas où vous le développeur principal, vous devriez toujours passer le temps à concevoir votre application, mais si personne ne va examiner les dessins et insister sur toutes les formalités, votre temps est mieux mise en œuvre du logiciel passent.