usable requirements and use cases

5 Jun 2005 - 9:23am
9 years ago
4 replies
790 reads
mtumi
2004

Anyone like to share info on usable use case and requirements docs?
At a prior job we created some very in-depth requirements docs, so
much so that the engineers never got through them. Hoping to arrive
at a measured approach and provide just enough information to be
useful in requirements and use cases, and no more. Plan to supplement
with interactive prototypes where possible, which I think are clearer
to understand.

Also, anyone read this book? If so, I'd be interested in
opinions. can't seem to find any reviews, amazon aside.

Understanding Your Users : A Practical Guide to User Requirements
Methods, Tools, and Techniques
by Catherine Courage, Kathy Baxter

http://www.amazon.com/exec/obidos/tg/detail/-/1558609350/ref=wl_it_dp/
102-6704155-7041711?%
5Fencoding=UTF8&coliid=I1MNMAQGRJW0BE&v=glance&colid=2WWY0X9QVEW3N

thanks -

Michael

Comments

5 Jun 2005 - 3:42pm
Peter Boersma
2003

Michael Tuminello asked:
> Anyone like to share info on usable use case and requirements docs?

And then suggested:
> At a prior job we created some very in-depth requirements docs, so
> much so that the engineers never got through them. Hoping to arrive
> at a measured approach and provide just enough information to be
> useful in requirements and use cases, and no more.

The trouble with "just enough information to be useful" is that requirements
have many audiences and each has a different need. For example:
- The client needs assurance that you'll build all that's required, maybe
some more but definitely nothing less.
- Your project manager needs a high-level estimate of the work with
indications of complexity, to ease planning.
- The front-end designers need insight into what functionality is crucial to
end-users, what the relationships are between all functions, plus examples
of content for the wireframes.
- The developers need indications of common functionality and exact
specifications of validation rules.
- Testers need to know when requirements have changed, so they can update
their test plans.

So you'll probably need to keep capturing in-depth requirements, but
document them in a way that allows for target-group specific views on the
information.
Rational's ReqPro (http://www-306.ibm.com/software/awdtools/reqpro/) allows
for the capturing of all sorts of requirements plus the specification of
specific reports to meet audience needs. But it does come at a price, and
I'm sure other software allows you to do similar things (anyone?).

> Plan to supplement
> with interactive prototypes where possible, which I think are clearer
> to understand.

For some types of requirements, interactive prototypes can help understand
the requirements better, so "supplement" is the right word. I wouldn't trust
a prototype to deal with all edge cases of the requirement that a date is a
valid date, for example. A requirement like "the user has to get a clear
overview of the status of her child benefit application" can be expressed
through a wireframe or series of linked screens much better than a 6-page
specification of all the fields on the screens with the validation rules for
each included.

Peter
--
Peter Boersma | Consultant User Experience
Koggestraat 10A | 1012 TA | Amsterdam | The Netherlands
phone: +31(0)206245641 | mobile: +31(0)615072747
mailto:peter at peterboersma.com | http://www.peterboersma.com

5 Jun 2005 - 5:35pm
Juan Lanus
2005

Michael:

Sorry I didn't read the book you mention. But I read this:
You might want to see
"Writing Effective Use Cases" by Alistair Cockburn
It's both a backgrounder and a detailed how-to quide. Tha author
addresses your issue thru the use of different templates according to
each company's culture.

I've set a template sample here:
http://ar.geocities.com/juanmlanus/ui/uc01.html
Sorry about the yellow: I'm testing the programs that output it. It's
a saved dynamic page, part of a tool I'm building. Those yellow
backgrounds are the roon where to write

You have to be able to turn off any element like for example
"Sub-variations" or "superordinate use case" and sveral other to make
it simpler.
Keep in mind that for a UC to be useful it must be readable by the
blue-collar end user (who should see his wishes reflected there) and
most notably by the managers too.
In this mood, having elements like "channel to primary actor" is less
than not having it. Also, new elements can be added as needed, the
keyword is "flexibility."

HTH
--
Juan Lanus
TECNOSOL
Argentina

6 Jun 2005 - 9:25am
Tom V
2005

>
> You might want to see
> "Writing Effective Use Cases" by Alistair Cockburn
> It's both a backgrounder and a detailed how-to quide. Tha author
> addresses your issue thru the use of different templates according to
> each company's culture.

We too have been using the Cockburn book to write use cases for a very large
project, an entire re-write of a social networking platform. Developers,
project managers, and IA's have collaboratively written over 300 use cases.
We use a wiki (MoinMoin) as a use-case/requirements CMS. This is extrememly
helpful in creating quick links between use cases and datafield entries.
This is the template we follow:

*Goal in Context:* <a longer statement of the goal, if needed, its normal
occurrence conditions>
*Stakeholders and interests:* <list of stakeholders and key interests in the
use case>
*Precondition:* <what we expect is already the state of the world>
***Success Guarantees:* <the state of the world if goal succeeds>
*Trigger:* <what starts the use case, may be time event>
*Main Success Scenario:*

1.

...

*Extensions:*

1.

None.
2.

Extensions:
1.

...
1.

...

*Open Issues:* <list unresolved questions about this use case; remove
section if no open issues!>
*Related Information:* <whatever your project needs for additional
information; remove section if no related information!>

6 Jun 2005 - 9:42am
Adrian Howard
2005

On 5 Jun 2005, at 23:35, Juan Lanus wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Michael:
>
> Sorry I didn't read the book you mention. But I read this:
> You might want to see
> "Writing Effective Use Cases" by Alistair Cockburn
> It's both a backgrounder and a detailed how-to quide. Tha author
> addresses your issue thru the use of different templates according to
> each company's culture.
[snip]

Seconded. It's the best book on use cases I've read.

Adrian

Syndicate content Get the feed