[Sigia-l] RE: Use cases and user centric design (was sitepath diagramming)

[Anne Hjortshoj]

I forgot to mention that I use workflow models to bridge the gap between the
use case document and the wireframes. I don't think the wireframes would
make as much sense without workflow diagrams (I have them refer to each
other).

In the workflows, each use case is broken into screens and diagrammed as a
linear flow. I either keep the workflows strictly linear, with references as
to where things branch off into other workflows, or do a site-map-style
diagram. (I prefer the former, but sometimes the site-map-style model is
easier for non-IAs - clients, notably, as well as some project managers - to
grasp.)

Re: use cases enforcing usability - I agree that they don't. They're more of
a device to clarify scope and analyze tasks, and they do that very well.

-Anne

----- Original Message -----
From: "Katherine Marshak" <katherine.marshak at iconmedialab.us>
To: "Doug Howell (IT)" <DHOWELL at bordersgroupinc.com>; <sigia-l at asis.org>
Sent: Thursday, January 23, 2003 8:24 PM
Subject: RE: [Sigia-l] RE: Use cases and user centric design (was sitepath
diagramming)


> Hi everyone.
> I've fallen behind on this interesting thread so please forgive me while
> I respond to multiple posts.
>
> I strongly advocate developing a business process model or business
> workflow model very early in a project. This model can often be sketched
> on a white board in an hour (or you can devote lots of energy, depending
> on the project). These models give the team has a common reference
> point. It also reminds us that the application or site we're building is
> a small part of users' lives.
>
> Several people (Doug Howell, Pradyot Rai, etc.) mentioned that they have
> moved to diagrams to overcome problems associated with use cases. I've
> seen some projects use this approach successfully when they keep the
> notation simple (basic flow charting or UML activity diagrams without
> lots of esoteric notation). If you use diagrams such as these, are you
> still creating a use case model to show the overall scope?
>
> Several posts raised questions about the level of detail in use cases.
> While there's no one answer that's right for every project, I think a
> few rules of thumb can help.
>
> -- Keep user interface information such as page names, link & button
> names, tab order, widget selection out of the use case.
>
> -- Specify the interaction between the actors and the system under
> development.
>
> -- Specify the expected attributes/fields. Anne Hjortshoj said she uses
> bullet lists of this info. This has been a very effective technique for
> us, too.
>
> -- If you have business rules that apply to multiple use cases or
> multiple projects, keep them in a business rule specification so the use
> cases can all refer to a single (and hopefully correct) set.
>
> -- Keep design decisions such as "The xyz field has a max length of 19
> characters (alpha only)" out of the use cases. There are better places
> to keep this info.
>
> Someone on this list also said that use cases don't ensure usability. I
> agree. But let's say thanks to Ivar Jacobson because use cases are a
> huge improvement over the system-centered way of stating requirements.
> The fact that use cases can change "The system shall support..." into
> "The <role name> <does something useful>" is wonderful!
>
> thanks,
> Kathy Marshak, Senior Consultant
> IconMedialab | www.iconmedialab.com
>
> ------------
> When replying, please *trim your post* as much as possible.
> *Plain text, please; NO Attachments
>
> ASIST IA 03 Summit: Making Connections
> http://www.asist-events.org/IASummit2003/
>
> Searchable list archive:   http://www.info-arch.org/lists/sigia-l/
> ________________________________________
> Sigia-l mailing list -- post to: Sigia-l at asis.org
> Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
>
>