[Sigia-l] Use cases and user centric design (was sitepath dia gramming)

[Lord, Ralph]

I have also been inspired by Larry and Lucy's work and agree with Laura's
observation that use-cases are often too system-centric and don't provide a
readily understandable conceptual view.  They're fine for documenting or
making a list of functionality, but to give the client/users/PM a real
understanding of the solution, one usually has to provide something
clickable or at least visual.  Of course, good old prose is also useful for
describing what the application does for the client!

Ralph Lord
System Analyst
Northrop Grumman Mission Systems
Centers for Disease Control and Prevention
404.639.7382



> -----Original Message-----
> From: Laura Scheirer Quinn [mailto:Laura.Quinn at IntraSphere.com] 
> Sent: Monday, January 06, 2003 10:38 AM
> To: sigia-l at asis.org
> Subject: RE: [Sigia-l] Use cases and user centric design (was 
> sitepath diagramming)
> 
> 
> Prady wrote:
> > I am
> >inspired by the Use Case theory of 'Larry L. Constantine, Lucy 
> >Lockwood' and there's a good paper by them called - 'Structure and 
> >Style in Use Cases for User Interface Design'. Find it at - 
> >http://www.foruse.com/articles/structurestyle2.htm
> 
> I've been spending a lot of time recently, in a fairly 
> traditional technology consulting firm, struggling to build a 
> process that uses both user-centric design techniques and use 
> cases (as if we have to chose one, it's not likely to be the 
> use cases that goes away).  I have to admit that even after 
> reading about and using use cases (almost entirely in a 
> Rational Rose and UML context) for a number of years, I 
> wasn't aware that Constantine and Lockwood's work was out 
> there framing use cases in a more user-centered way than 
> other works.  This is a great article, Prady, thank you. 
> 
> Though that certainly says something about how use cases are 
> being used much of the time out in the world.
> 
> Prady, you also seem to find use cases very useful in 
> requirements definition.  
> > At the end I would also say, if you have ever suffered (or 
> suffering) 
> >by the politics of Requirements Vs. Technical Design (or Product 
> >Management Vs Engineering), use cases are the best to make 
> things black 
> >and white during the Requirement or Task analysis Phase.
> 
> I find use cases invaluable as a functionality documentation 
> method.   However, although I know that they're frequently 
> used specifically to define requirements, I see several 
> drawbacks when trying to use them to define a system in a 
> user centered way.   
> 
> The biggest is use case's undeniable focus on users in 
> system-centric roles.  Even if you call them "roles" rather 
> than "actors", it's very difficult to try to frame your 
> "roles" to be anything else than people who perform 
> significantly different system functions, and/or have 
> different levels of system security.  While this is of course 
> necessary to system design, I find it counter to a 
> user-centered definition of a product.  At the very beginning 
> of a project, you want to think through user groups based on 
> actual user needs.  As you gather data (or at least do a 
> conceptual exercise), it may turn out that there's no 
> difference in the features needed to support a novice desk 
> clerk and a experienced desk clerk, and they may be the same 
> system actor-- but I wouldn't want to assume this going in. 
> Use case methodology encourages you to guess what your system 
> roles-- and often even your feature set-- should be without 
> thinking through the user needs.
> 
> Secondly, use cases are difficult to use to solidify an 
> overall concept of what you're building.  Although they can 
> effectively document what's been arrived at, I feel strongly 
> that those that are using them as a tool to identify, 
> iterate, and work through features and requirements are 
> asking for trouble.  They're simply too hard to read and to 
> process as a whole by anyone except those hired (like us!) to 
> be able to visualize systems from diagrams.  While tech savvy 
> clients and users will review them, have comments on them, 
> etc., you get the same kind of effect that user-centered 
> design tries to avoid, where people will "change their mind" 
> and turn out to have forgotten critical aspects and generally 
> show signs downstream of not having really conceptualized 
> what they were asked to sign off. This effect is more 
> pronounced the less tech savvy your client and user base is.
> 
> Where I've gotten to with a lot of thought about this for my 
> company is to use use cases as a documentation technique, and 
> to use other user centered techniques (probably in our case 
> user profiles, task analysis, and a conceptualization step 
> through prototyping, diagramming or the like) to actually 
> define requirements.
> 
> Laura S. Quinn
> ------------
> When replying, please *trim your post* as much as possible. 
> *Plain text, please; NO Attachments
> 
> ASIST SIG IA website: http://www.asis.org/SIG/SIGIA/index.html
> 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
>