Group items tagged

In my experience use cases are very powerful tools - their purpose is show the view from a *user's point of view*. The presented example is already very technical, and specifies a lot of details.

May I offer alternatives to the example in the article?A) A few brief classic requirements (for business) & a diagram (BPMN or UML activity diagram) (for the engineers)B) A use case with a lot less details (maybe 4-8 steps) & user interface design & a list of business rules (describing the essence of the details)C) No use case. One single sentence describing the goal & rationale ("As a user I want to have a recovery method when I forget the password because ....") & brief description of the important parts, business rules (no flow details!) & user interface design

May I offer other improvements to the "classic" use case in the example?- Instead of a summary, formulate it as a goal (remove redundancy)- Adding how frequently this is done ("Frequency: seldom, max. once per month ... once every few years")- Keep the main flow under 10 points- Remove pre-conditions and post-conditions. Keep it simple.- Integrate the alternative flows into the main flow (if possible, leave away details)

Welkom bij het DREAM Event Atos Origin organiseert op dinsdag 9 maart 2010 voor de tweede keer het Dutch Requirements Engineering and Management event. Het event is open voor de gehele Requirements community; voor iedereen die werkt met specificaties.

Hartelijk welkom op de website van DREAM (Dutch Requirements Engineering And Management). In 2014 is al voor de 5de maal het DREAM event succesvol georganiseerd (zie hier een terugblik op de afgelopen events). We willen ook de komende jaren een bijdrage blijven leveren aan het verder verspreiden van de kennis en het begrip betreffende alles wat te maken heeft met requirements; van business rules tot en met user stories, van functioneel ontwerp tot en met modellen van bedrijfsprocessen.

examined the effectiveness of use cases;

two fundamental observations

Be ambiguous about the scope of your use cases.

Don't be concerned with defining business rules.

Write your first and only use case draft in excruciating detail.