Modélisation fonctionnelle SJ-meetup à l'aide de cas d'utilisation

En règle générale, la part du lion des exigences pour un produit informatique est le comportement et l'interaction du système avec l'environnement. Le 18 juillet, lors d'une réunion à SuperJob, nos analystes système ont parlé de modélisation fonctionnelle en mettant l'accent sur la technique des cas d'utilisation. L'approche canonique, l'approche non canonique a été discutée, par rapport à d'autres pratiques de modélisation fonctionnelle.

La réunion a été ouverte par Ekaterina Evstifeeva , analyste système chez Superjob, sur le thème «Utiliser un cas en pratique» .

Programme:

1. Définition de l'UC, ses avantages et sa place dans la classification des exigences.
2. Formes UC et leur composition
3. Niveaux de cas d'utilisation et règles de regroupement.
4. Règles pour rédiger un bon cas d'utilisation.
5. Exercices pratiques.

→ Présentation

Sergey Nuzhnenko darkboatman , un analyste de systèmes leader chez Superjob, a parlé des bases de la modélisation fonctionnelle à l'aide de cas d' utilisation .

Programme:

1. Le système, sa structure et ses fonctions. Types de systèmes informatiques.
2. Présentation des techniques de base de la modélisation fonctionnelle des systèmes informatiques.
3. Cas d'utilisation - avantages et applicabilité.
4. Cas d'utilisation et analyse structurelle.
5. Cas d'utilisation pour les activités de modélisation.
6. Cas d'utilisation pour définir les limites et la portée du système.
7. Cas d'utilisation pour une modélisation détaillée du comportement.
8. Autres pratiques de modélisation fonctionnelle versus cas d'utilisation.

→ Présentation

Ksenia Lyutova , analyste de systèmes chez Superjob, a parlé du sujet «Que se passe-t-il lorsque vous essayez de monter un vélo (une histoire de cas d'utilisation basés sur des événements réels)» .

Programme:

1. Comment nous avons appris à décrire le comportement du système: des messages sur Skype aux documents de 600 feuilles.
2. Le client ne comprend pas les exigences: qui est à blâmer et que faire?
3. Pourquoi les développeurs ont-ils préféré me parler plutôt que de lire mes documents?
4. Conclusions et recommandations (comment le faire et comment ne pas le faire).

→ Présentation