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

[Juan Lanus]

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