Documentation détaillée sur les cas d'utilisation [fermé]

Question

Je fais de gros efforts pour discipliner mes projets et créer un document Vision / Scope dès le début. Inclus dans ceci sont les diagrammes de cas d'utilisation. Le simple fait d’énumérer les cas d’utilisation m’a vraiment aidé à avoir une vue complète de toutes les exigences demandées par le client, et le dialogue s’est ouvert.

Je me demande à quel point le cas d'utilisation devrait être détaillé. Si je crée une application Web et que l'utilisateur se connecte pour voir un rapport, est-ce que je liste toutes les colonnes du rapport dans la description du cas d'utilisation?

Si non, alors quand devrais-je documenter ces détails?

Answer 1

l'avantage des diagrammes de cas d'utilisation est qu'ils sont simples et que les utilisateurs finaux peuvent les lire et les comprendre

les colonnes à utiliser dans un rapport font partie d'une spécification de conception ou d'exigences (détails d'une fonctionnalité, en termes agiles) et ne n'appartiennent pas à un diagramme de cas d'utilisation

tout ce qui encombre le diagramme de cas d'utilisation appartient ailleurs

où? peu importe, tant que c'est un endroit cohérent et que vous savez où le trouver; -)

pour rappeler aux utilisateurs à quoi ressemble un diagramme de cas d'utilisation - et pourquoi il n'y a pas de place pour des détails parasites -
_{(source: agilemodeling.com )}

Answer 2

Un cas d'utilisation dans lequel je travaille est une description de l'application du point de vue de l'utilisateur. A ce niveau, c'est très détaillé. Ainsi, dans votre exemple de rapport, le cas d'utilisation décrirait la présentation du rapport, les données affichées, dans quel ordre, etc. Ce que le cas d'utilisation ne vous dit pas, c'est comment ces données sont acquises ou d'où elles viennent.

Une autre façon de voir les choses est de penser à confier le cas d'utilisation à un testeur. Ils peuvent tester n'importe quoi dans le document (test de la boîte noire) et l'enregistrer comme un défaut. Donc, si certaines données sont supposées être affichées dans certaines conditions, vous devez spécifier ce cas dans votre cas d'utilisation afin de pouvoir le tester.

D'autres documents que vous pouvez créer pour compléter le tableau sont ce que nous appelons le SAD (document d'architecture logicielle) et le NFR (exigences non fonctionnelles). Le SAD décrirait, du point de vue de la conception logicielle, comment vous allez programmer la solution, quelles technologies vous allez utiliser et quels algorithmes sont nécessaires. Le NFR comprendra des éléments tels que la reprise après une panne logicielle ou matérielle, les temps de réponse, etc.

.

Answer 3

Si vous savez quelles colonnes doivent être incluses, alors oui, mettez-les dans le document. Si vous devez y réfléchir un peu en premier, faites-le ensuite et documentez-le. Cela évitera au programmeur d’avoir à réfléchir ou à poser des questions plus tard, ce qui rend le processus plus efficace.

Cependant, si vous ne savez vraiment pas quelles colonnes doivent encore être incluses, car vous ne savez pas assez comment le système tout entier fonctionnera une fois le développement en cours, ne le faites pas. inquiétez-vous et dites simplement "Colonnes spécifiques à déterminer"

Vous ne pouvez pas tout connaître à l'avance, mais documentez définitivement ce que vous savez.

Answer 4

La description du cas d'utilisation doit être comprise entre:

• Petits détails: pour que cet utilisateur le comprend et pense: " Comment est-ce facile de faire "
• Détails élevés: Pas de possibilités ouvertes (Description détaillée de ce se passe après chaque étape)

Answer 5

La création de diagrammes de cas d'utilisation avec des notations UML nous aide à comprendre & amp; spécifier rapidement les exigences. Généralement, des diagrammes de cas d’utilisation peuvent être dessinés devant une équipe d’ingénieurs logiciels pour comprendre rapidement la situation.

En fait, un cas d'utilisation doit être écrit. Il a trois formats.

1. Brief
2. Occasionnel
3. Entièrement habillé

Dans le cas d'un rapport, Format du rapport & amp; La spécification doit être jointe au document SRS afin que les tests puissent être effectués en conséquence.

Pour plus de détails ... Voir "Application de modèles UML et de modèles: introduction à l'analyse orientée objet, à la conception et au développement itératif par Craig Larman"

.