XP pretty much banned use cases, replacing them with the similar sounding “user stories”
Google Insights - UML tools - 0 views
Alistair.Cockburn.us | Why I still use use cases - 1 views
-
-
Scrum did similar, using the “product backlog” instead of user stories
-
Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems
- ...15 more annotations...
List of Unified Modeling Language tools - Wikipedia, the free encyclopedia - 0 views
-
Papyrus
-
Atos Origin
Alistair.Cockburn.us | A user story is the title of one scenario whereas a use case is ... - 0 views
-
As a … I want… so that…” is a new-fangled user story format. The original XP user story format had no rules, so you could simply highlight any phrase in a use case and call it a user story. Personally, I feel sorry for anyone who has to write “As a… I want… so that…” for 200 user stories. Kind of like being kept after school and having to write “I will not write silly user stories in class” 100 times
-
A use case pretty much by definition contains multiple stories. A use case is a collection of scenarios related to the primary actor’s goal – some scenarios show the actor interacting with the system and the system interacting with other systems so that they succeed with the goal, some show failure. That’s all in the nature of a use case. see Structuring use cases with goals (discussion: Re: Structuring use cases with goals) from 1995. A use case written for this will occupy between half a page for a shortish one to 2 pages for a long one. A user story is a nickname for a single scenario – it contains neither the information content of the scenario nor failure or alternate paths. A user story typically occupies 1/2 to one sentence no matter its size.
-
(p.s. Agile was supposed to reduce bureaucracy and overhead, not add to it. :) Alistair
Alistair.Cockburn.us | A user story is to a use case as a gazelle is to a gazebo - 0 views
Use Cases for Business Analysts - The New School - 0 views
-
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)
1 - 7 of 7
Showing 20▼ items per page