[IxDA Discuss] A tool for managing use cases / requirements

[Jeff Axup]

Hi Juan, can you tell us more about how you use Amaya? My guess is that
you're manually creating each new page (to represent requirements, use
cases, scenarios) and creating links between pages to show relationships?
How does that scale?

-Jeff

On 3/25/07, Juan Lanus <juan.lanus at gmail.com> wrote:
>
> Hi Jeff,
> I want to share some information about use cases and scenarios:
> ------------------------------
> Diferences:
> A scenario is the narrative of a specific interaction shot, for example
> "Lucy stops her car be the ATM after leaving her daughter in school because
> early in the morning she doesn't have to wait in the queue, introduces the
> debit card ..."
> A use case can be called "the mother of all scenarios" because it's
> generic and inclusive. It describes the intercation steps for the "main
> success scenario" (the "normal" sequence) and (ideally) all possible
> alternative paths from start to end, both ending with failure and with
> success. For example including the scenario that swallows Lucy's card after
> so many wrong PINs because her little daughter is crying aloud in the back
> seat of her <brand concealed> car.
> Designing interation is turning scenarios into usable use cases (UCs.)
> ------------------------------
> Use cases and UCD:
> Use cases were born for UCD in the writings of the UCD creators, Larry
> Constantine and Ivar Jacobson more than 20 years ago.
> Over time they are becoming the leading technique for capturing user
> behaviour facinf the system.
> ------------------------------
> Use cases and UML:
> Real use cases are textual. Their great advantage is that they can be read
> by both the IT geeks and normal people like users and managers.
> In UML, a graphical language, UCs are ovals surrounded by straw figures.
> A real UC looks like a page of text with numbered paragraphs that cannot
> be depicted insice a 2" oval.
> ------------------------------
> UC levels and sub-UCs:
> In a shape similar to that of modular programs, some interaction sequences
> that repeat in several contexts (comes to mind a login for embeded in many
> pages of a web application) are given a name, described once, and rferences
> where appropriate. This is an inclusion relationship.
> There is another relationsship type, by level. For example you can depict
> the whole application as a single high level UC, and more detailed UCs to
> describe the actual interactions.
> In a sloppy banking example, one can describe the whole banking operation
> as a process with steps:
> 1- borrow money
> 2- lend money
> 3- collect more money
> 4- repeat till bankrupcy
> This gives a view from the sky. Another view describes for example the
> debit card business, still from the heights. The UCs we are more interested
> in describe the user interactiong with the system in detail. Both the bank
> clients and the bank employees.
> Notice that when a user is entering her name in a text input gizmo, she is
> playing a use case the operating system provides, in that she can write,
> select, edit, click with the mouse, and the like. All these micro
> interactions we take for granted are a lowe level ineraction design. Those
> who designed the gizmo relied in still lower level interaction contects,
> etc, etc. Fortunately we don't have to deal with this since many years ago.
> ------------------------------
> Tools:
> I'm working since long time ago in the inception of a tool to handle UCs,
> after an article I read about the lack of a suitable one. It won't be ready
> for Jeff to look at it.
> In the meanwhile I write use cases with Amaya, a web browser by the W3C
> that permits writing in the page you are reading. I built a complate
> template and after I simplified it a lot. The briefer, the better.
> Other people who might also have read the article I mentioned above, are
> offering lofty tools for this task. IMO those tools are not contemplating
> the need for simplicity and ubiquity that's inherent to UCs.
> I look briefly at each new one, enough to notice that they look
> geek-oriented, i.e.: need a lot of commitment from the user for their
> outcome to be valuable. But it might be mi own impression ...
> ------------------------------
> Juan Lanus
>
>


-- 
Best Regards,
Jeff
____________________________________________________________________________
Jeff Axup, Ph.D.
Principal Consultant, Mobile Community Design Consulting, San Diego

Research:    Mobile Group Research Methods, Social Networks, Group Usability
E-mail:        axup <at> userdesign.com
Blog:           http://mobilecommunitydesign.com
Moblog:       http://memeaddict.blogspot.com
Academic:   http://www.infenv.itee.uq.edu.au
____________________________________________________________________________