A tool for managing use cases / requirements

23 Mar 2007 - 4:27pm
7 years ago
13 replies
1531 reads
Jeff Axup
2006

Hi everyone,

I'm working on a project where we're entering into a large requirements
analysis stage. This will involve a large number of use cases (often called
scenarios). The use cases need to be directly tied to corresponding
requirements. There will be high and low level use cases, with some as
subsets of others. Additionally, they need to be tied to user roles (and
personas at times), and there will often be a many-to-one pairing between
roles and uses cases, and requirements and use cases. So a static tree model
probably won't work.

This points to the need for a tool to organize this and present it in a
dynamic manner (via a web page with an underlying database comes to mind.)
I've been thinking about using Excel, MS project, Word outlines, or a
hand-coded DB with a web front end, but all seem to fall short in terms of
effectiveness and ease of use.

Has anyone found a good tool (either specifically for use case organization,
or for more general management of data in cross-referenced trees) which
they've used for this in the past? Any thoughts on usability of these
(potential) products?

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
____________________________________________________________________________

Comments

23 Mar 2007 - 6:15pm
Petteri Hiisilä
2004

Jeff Axup kirjoitti 24.3.2007 kello 0:27:

> Hi everyone,
>
> I'm working on a project where we're entering into a large
> requirements
> analysis stage. This will involve a large number of use cases
> (often called
> scenarios). The use cases need to be directly tied to corresponding
> requirements. There will be high and low level use cases, with some as
> subsets of others. Additionally, they need to be tied to user roles
> (and
> personas at times), and there will often be a many-to-one pairing
> between
> roles and uses cases, and requirements and use cases. So a static
> tree model
> probably won't work.

Hi,

There aren't many good solutions for this. Many of them understand
poorly about top-level scenarios, human goals and organization's
intentions.

http://www.telelogic.com/products/doors/index.cfm

Check out DOORS by Telelogic. It can input use cases and requirements
of different abstraction levels and link them together. I haven't
used it myself yet, but our next project will use it. I feel pretty
OK with it so far, after checking it one.

At a quick glance it seemed to do what it promises, but it isn't
pretty and it's not a design tool. It's a development and project
management tool. Your developers and project managers should
appreciate the hierarchical presentation style that DOORS offers.

You input the scenarios and requirements and order them in
hierarchical trees. Cross-referencing is trivial to do. And it can
print out documents.

Still, we will make User & Domain Analysis and Form & Behavior specs
as separate documents because managers and stakeholders need to read
them too. DOORS can't fill this void. U&DA is there for tackling
organizational issues and human motivations (user goals).

Petteri

--
Petteri Hiisilä
Senior Interaction Designer
iXDesign / +358505050123 /
petteri.hiisila at ixdesign.fi

"Simple is better than complex.
Complex is better than complicated."
- Tim Peters

23 Mar 2007 - 8:57pm
Todd Moy
2007

Hi Jeff - I think I understand what you're asking, but not well enough
to propose a solution. I have a few in mind, but I'd like a bit more
information.

My questions:
You mentioned subsets of use cases. Can a use case appear as a child
of many different, higher level use cases...or will it have one parent
only?

What is the difference between a user role and a persona, with regard
to how they relate to use cases and to one another? Is there a
relationship between a user role and a persona?

Would there be a primary means of organizing or accessing this
information? For example, could you use a tree as a primary structure,
but annotate the cases and requirements with metadata to provide an
auxilliary method of navigation?

Is there a requirement to version the documents throughout
time--either the use cases, the scenarios, or the requirements?

--

Altogether, it doesn't seem that your dilemma is that unique. I
immediately think of source code versioning systems (like Subversion),
content management systems (like Ellington), Wikis (like Trac), etc. I
use Serena Dimensions for managing artifacts and requirements, but I
hesitate to force that solution on you without more info.

You might also redefine your requirements by thinking broadly about
what you're trying to accomplish. Once you strip away terms like
"personas", "use cases", and "requirements", it appears that you're
just organizing text and images that can be described by different
attributes. Maybe a basic document management system that provides
both a structured hierarchy and the ability to tag assets would be
useful.

-Todd

On 3/23/07, Jeff Axup <axup at userdesign.com> wrote:
> Hi everyone,
>
> I'm working on a project where we're entering into a large requirements
> analysis stage. This will involve a large number of use cases (often called
> scenarios). The use cases need to be directly tied to corresponding
> requirements. There will be high and low level use cases, with some as
> subsets of others. Additionally, they need to be tied to user roles (and
> personas at times), and there will often be a many-to-one pairing between
> roles and uses cases, and requirements and use cases. So a static tree model
> probably won't work.
>
> This points to the need for a tool to organize this and present it in a
> dynamic manner (via a web page with an underlying database comes to mind.)
> I've been thinking about using Excel, MS project, Word outlines, or a
> hand-coded DB with a web front end, but all seem to fall short in terms of
> effectiveness and ease of use.
>
> Has anyone found a good tool (either specifically for use case organization,
> or for more general management of data in cross-referenced trees) which
> they've used for this in the past? Any thoughts on usability of these
> (potential) products?
>
> 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
> ____________________________________________________________________________
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
____________________________
oombrella | User Experience Design
http://www.oombrella.com
oombrella at gmail.com

24 Mar 2007 - 6:30am
Petteri Hiisilä
2004

Hi,

> There are critically important differences between use
> cases and scenarios.

This is true and may be the reason why the original poster asked for
a way to link them together so that these different levels of
granularity of the problem and its solution can be tracked back to
their origins.

In a "project manager's dream tool" all this can be tracked: human
goals <--> context scenarios <--> key path scenarios (~ use cases) <--
> design requirements <--> ui framework <--> ui design <-->
technical requirements <--> technical design <--> technical
implementation <--> test cases.

In real world it of course isn't as straightforward as this. And
there's much more to technical design than in the above
simplification. Finally, lots of this can be parallelized to save
calendar time.

In projects the managers tend to want this linkage more than they
actually need it. Often, after they have read the User & Domain
Analysis they have the links they need in their head, and they can
contaminate other managers by letting them read the U&DA too. Almost
everybody from marketing to even HR have found it useful in their
regular work too. When you put human motivations on the table it all
starts to make sense.

As a little disclaimer: I'm using terms in a way that About Face
uses. Many of our IxD terms need to be (re)defined before using,
because different groups have already defined them before and after
us. The namespace is limited.

Thanks,

Petteri

Katie Albers kirjoitti 24.3.2007 kello 4:34:

> There are critically important differences between use
> cases and scenarios.
>
> Use cases are at the system/requirement level, e.g.
> "Users will be able to order items. The steps in
> ordering an item are...."and then you go into the
> press this, type that, display this message
> enumeration.
>
> Scenarios put use cases into human context "Jane wants
> to find an item requested by a friend so she goes to
> [our site]and then..."
>
> The two are about interaction from different angles
> and that difference is at a level where you can go
> merrily down the pure use case path...which will tend
> to lead to system-oriented development, or enhance the
> user-centeredness of the product by doing both.
>
> Katie
> another IxD who came to it from usability
>
>
> --- Petteri Hiisilä <petteri.hiisila at ixdesign.fi>
> wrote:
>
>>
>> Jeff Axup kirjoitti 24.3.2007 kello 0:27:
>>
>>> Hi everyone,
>>>
>>> I'm working on a project where we're entering into
>> a large
>>> requirements
>>> analysis stage. This will involve a large number
>> of use cases
>>> (often called
>>> scenarios). The use cases need to be directly tied
>> to corresponding
>>> requirements. There will be high and low level use
>> cases, with some as
>>> subsets of others. Additionally, they need to be
>> tied to user roles
>>> (and
>>> personas at times), and there will often be a
>> many-to-one pairing
>>> between
>>> roles and uses cases, and requirements and use
>> cases. So a static
>>> tree model
>>> probably won't work.
>
>
>
>
>
>
> ______________________________________________________________________
> ______________
> TV dinner still cooling?
> Check out "Tonight's Picks" on Yahoo! TV.
> http://tv.yahoo.com/

--
Petteri Hiisilä
Senior Interaction Designer
iXDesign / +358505050123 /
petteri.hiisila at ixdesign.fi

"Simple is better than complex.
Complex is better than complicated."
- Tim Peters

24 Mar 2007 - 3:23pm
Jeff Axup
2006

Thanks to all who have replied. I think this is a great issue to be talking
about as it is often glossed over in many "user-centered" processes and yet
is absolutely critical to good UCD. Part of the issue here is terminology.
Software engineering uses the term 'use case' to refer to very detailed
technical interactions between network components, and occasionally a user.
They rarely focus on user task flow, user roles or discrete steps in UIs
encountered. However, increasingly use cases have been adapted for HCI
purposes.

In "Understanding Your Users: A Practical Guide to User Requirements
Methods, Tools, and Techniques" if I'm not mistaken the authors say
"Scenarios (sometimes called use cases)". I personally think they're
different things. Scenarios are much more specific. They are used to
evaluate specific user roles (or possibly personas) in a given specific
situation, and to look at what would likely happen. UCD Use cases are
higher-level, process oriented, and include alternate sub-use-cases, and
possibly scenarios as way to explore implications of the use case (but they
are more user-centric than SE use cases). Use cases should be (as much as
possible) complete. Trying to document every possible scenario is an
exercise in futility.

Todd, replies to questions inline below. We are still exploring what the
process should be for this project, but I'll take some educated guesses.

On 3/23/07, Todd Moy <oombrella at gmail.com> wrote:
>
> Hi Jeff - I think I understand what you're asking, but not well enough
> to propose a solution. I have a few in mind, but I'd like a bit more
> information.
>
> My questions:
> You mentioned subsets of use cases. Can a use case appear as a child
> of many different, higher level use cases...or will it have one parent
> only?

JA: My immediate answer would be that unlike many of the rest of the links,
this would seem to be one to many. But I wouldn't be surprised if we end up
with some cases where a task flow is a part of multiple higher-level task
flows, so actually this is probably many-many relationship.

What is the difference between a user role and a persona, with regard
> to how they relate to use cases and to one another? Is there a
> relationship between a user role and a persona?

JA: I'm still figuring out how personas fit in to tell you the truth. Anyone
have ideas on that? We are developing them, more as a common language and
shorthand within the team. I think we could develop a few scenarios around
them since they are more flushed out user characters. However, I'm currently
basing most the use cases and requirements around user roles. I've assigned
one example persona per user role, just so we have a reminder of a human
behind the role. I expect that there will be a many-many relationship
between roles and top-level use cases (Roles will have many top-level use
cases supporting them, and a top-level use case will support various roles).
I also would like to link Requirements to Roles and Use Cases (the
requirement justifies the use case and explains who has the requirement),
which is many>many.

Would there be a primary means of organizing or accessing this
> information? For example, could you use a tree as a primary structure,
> but annotate the cases and requirements with metadata to provide an
> auxilliary method of navigation?

JA: A definite possibility. I could do a role > 1st level use case mapping
chart. But it would require updating, and the connection to lower levels
wouldn't be clear, and I'm wasting a lot of time on updating diagrams with
change iterations anyway. (if only we had a digital tool where we could
electronically post a mockup to a group, have everyone add comments
digitally and visually, everyone see the collective comments digitally, and
then get a digital copy of it sent to you to revise changes, but I digress.)

Is there a requirement to version the documents throughout
> time--either the use cases, the scenarios, or the requirements?

JA: That would be nice. I thoroughly expect many many changes to occur in
these documents as a) we determine what is important b) we add more detail
to the use cases c) we learn more about user behavior d) the market and
usage environment change. It would be great to be able to annotate why some
requirements were demoted in priority, or why use cases were altered based
on site visit results etc.

--
>
> Altogether, it doesn't seem that your dilemma is that unique. I
> immediately think of source code versioning systems (like Subversion),
> content management systems (like Ellington), Wikis (like Trac), etc. I
> use Serena Dimensions for managing artifacts and requirements, but I
> hesitate to force that solution on you without more info.

JA: Thanks. Yes, I expect that some SE tools might be adapted for this
purpose. The main thing that would be a problem is automatic graph
generation showing social-network or tree style graphs, and the ability to
differentiate between requirements, use cases, sub use-cases, etc. And
probably a method of importing an initial spreadsheet of the main data set
would be good.

You might also redefine your requirements by thinking broadly about
> what you're trying to accomplish. Once you strip away terms like
> "personas", "use cases", and "requirements", it appears that you're
> just organizing text and images that can be described by different
> attributes. Maybe a basic document management system that provides
> both a structured hierarchy and the ability to tag assets would be
> useful.

JA: An excellent idea! A requirement, a use case, a scenario, and a role
description are all just text documents (or short lists)(personas would have
images). Each could be viewed as a separate document and perhaps should be.
However in that scenario we have easily hundreds if not a thousand documents
to manage. That could be fine in a document control system, but it would be
a necessity to be able to categorize the documents into the various types
(req, UC, scenario, role) and be able to create ties between items, and be
able to graph those relationships in a reasonable manner.

Several books have mentioned card sorts for doing this task. Are they
insane?! It might be useful for initial organization, but manually writing
out cards, manual updating, scaling to a large project, getting distributed
group review? Doesn't seem feasible.

Any more tool suggests after knowing the above?

-Jeff

-Todd
>
>
>
>
> On 3/23/07, Jeff Axup <axup at userdesign.com> wrote:
> > Hi everyone,
> >
> > I'm working on a project where we're entering into a large requirements
> > analysis stage. This will involve a large number of use cases (often
> called
> > scenarios). The use cases need to be directly tied to corresponding
> > requirements. There will be high and low level use cases, with some as
> > subsets of others. Additionally, they need to be tied to user roles (and
> > personas at times), and there will often be a many-to-one pairing
> between
> > roles and uses cases, and requirements and use cases. So a static tree
> model
> > probably won't work.
> >
> > This points to the need for a tool to organize this and present it in a
> > dynamic manner (via a web page with an underlying database comes to
> mind.)
> > I've been thinking about using Excel, MS project, Word outlines, or a
> > hand-coded DB with a web front end, but all seem to fall short in terms
> of
> > effectiveness and ease of use.
> >
> > Has anyone found a good tool (either specifically for use case
> organization,
> > or for more general management of data in cross-referenced trees) which
> > they've used for this in the past? Any thoughts on usability of these
> > (potential) products?
> >
> > 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
> >
> ____________________________________________________________________________
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
>
>
> --
> ____________________________
> oombrella | User Experience Design
> http://www.oombrella.com
> oombrella at gmail.com
>

--
Best Regards,
Jeff
____________________________________________________________________________
Jeff Axup 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
____________________________________________________________________________

25 Mar 2007 - 10:16am
Todd Roberts
2005

Depending on how much you want to use the tool for project management,
you could look at Rally (www.rallydev.com). It would probably hit a
lot of what you need, but my be a little heavy if you are just going
to be tracking use cases and requirements.

25 Mar 2007 - 1:00pm
Juan Lanus
2005

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

25 Mar 2007 - 1:43pm
Jeff Axup
2006

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
____________________________________________________________________________

26 Mar 2007 - 12:55pm
jrrogan
2005

We use Clear Case with WIKI linking screens and relevant user views.

IT's not perfect, but Clear Case handles the UC/Req side, and linking them
up in a WIKI environment allows ease of access to linked info.

With accurate archiving of WKI pgs this ca n be very effective with
versioning.

Note we link UC's to prototypes/ annotated diagrams, then the
prototypes/annoted diagrams go to req level for that UC.

Rich

On 3/23/07, Jeff Axup <axup at userdesign.com> wrote:
>
> Hi everyone,
>
> I'm working on a project where we're entering into a large requirements
> analysis stage. This will involve a large number of use cases (often
> called
> scenarios). The use cases need to be directly tied to corresponding
> requirements. There will be high and low level use cases, with some as
> subsets of others. Additionally, they need to be tied to user roles (and
> personas at times), and there will often be a many-to-one pairing between
> roles and uses cases, and requirements and use cases. So a static tree
> model
> probably won't work.
>
> This points to the need for a tool to organize this and present it in a
> dynamic manner (via a web page with an underlying database comes to mind.)
> I've been thinking about using Excel, MS project, Word outlines, or a
> hand-coded DB with a web front end, but all seem to fall short in terms of
> effectiveness and ease of use.
>
> Has anyone found a good tool (either specifically for use case
> organization,
> or for more general management of data in cross-referenced trees) which
> they've used for this in the past? Any thoughts on usability of these
> (potential) products?
>
> 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
>
> ____________________________________________________________________________
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

26 Mar 2007 - 3:02pm
Juan Lanus
2005

On 3/25/07, Jeff Axup <axup at userdesign.com> wrote:
>
> Hi Juan, can you tell us more about how you use Amaya? My guess is that
> you're manually creating each new page

Yes. I use a template and then manually edit it. It's good for small things,
unpractical for the bigger.
The template is in http://www.tecnosol.com.ar/uc/

Amaya is just an HTML editor, not a use case tool.
__
Juan Lanus

26 Mar 2007 - 5:24pm
Jeff Axup
2006

Has anyone tried:

*Rational RequisitePro*
http://www-306.ibm.com/software/awdtools/reqpro/

The demos here are useful:
http://www-306.ibm.com/software/awdtools/resources/reqpro.html?S_CMP=rnav

It doesn't appear to do graphs, but they have some table-style
visualizations of dependencies.
and it's only $2k! ;)

-Jeff

On 3/26/07, Juan Lanus <juan.lanus at gmail.com> wrote:
>
>
> On 3/25/07, Jeff Axup <axup at userdesign.com> wrote:
> >
> > Hi Juan, can you tell us more about how you use Amaya? My guess is that
> > you're manually creating each new page
>
> Yes. I use a template and then manually edit it. It's good for small
> things, unpractical for the bigger.
> The template is in http://www.tecnosol.com.ar/uc/
>
> Amaya is just an HTML editor, not a use case tool.
> __
> 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
____________________________________________________________________________

27 Mar 2007 - 5:31am
Al Selvin
2006

Jeff,

Check out Compendium. It is a free-form hypermedia tool, not
specifically for use cases and requirements, but it has unlimited
ability to create pairings and cross-referencing, in a graphical
environment that supports tagging, stencils, templates, multiuser
sharing, and web/xml/outline exports. It is free and open source,
win/mac/linux. http://www.compendiuminstitute.org

Al

On 3/23/07, Jeff Axup <axup at userdesign.com> wrote:
> scenarios). The use cases need to be directly tied to corresponding
> requirements. There will be high and low level use cases, with some as
> subsets of others. Additionally, they need to be tied to user roles (and
> personas at times), and there will often be a many-to-one pairing between
> roles and uses cases, and requirements and use cases. So a static tree
> model
> probably won't work.
>
> This points to the need for a tool to organize this and present it in a
> dynamic manner (via a web page with an underlying database comes to mind.)
> I've been thinking about using Excel, MS project, Word outlines, or a
> hand-coded DB with a web front end, but all seem to fall short in terms of
> effectiveness and ease of use.
>
> Has anyone found a good tool (either specifically for use case
> organization,
> or for more general management of data in cross-referenced trees) which
> they've used for this in the past? Any thoughts on usability of these
> (potential) products?

27 Mar 2007 - 7:14am
jrrogan
2005

No, we haven't gotten to this level yet.

It wouldn't be too difficult given the linkage can easily be derived,
possibly output to Visio. A clever intern could maybe get this going in a
couple of weeks ;)

On 3/26/07, Jeff Axup <axup at userdesign.com> wrote:
>
> Sounds intriguing. Any way to automatically produce a chart of site
> structure by any chance?
> -Jeff
>
>
> On 3/26/07, Rich Rogan <jrrogan at gmail.com> wrote:
> >
> > We use Clear Case with WIKI linking screens and relevant user views.
> >
> > IT's not perfect, but Clear Case handles the UC/Req side, and linking
> > them
> > up in a WIKI environment allows ease of access to linked info.
> >
> > With accurate archiving of WKI pgs this ca n be very effective with
> > versioning.
> >
> > Note we link UC's to prototypes/ annotated diagrams, then the
> > prototypes/annoted diagrams go to req level for that UC.
> >
> > Rich
> >
>

27 Mar 2007 - 4:15pm
Gordon, Richard E.
2006

I saw a demo recently that showed how requirements could be linked to UI
prototypes in iRise (http://www.irise.com/ ) and it supposedly
integrates with Rational. That is a very cool but very expensive
solution. Someday maybe...

The Rational products are pretty good at what they do, but there is a
lot of "big project" overhead with the cost and configuration issues. On
one of my larger projects we use ReqPro, ClearCase and ClearQuest and
have had some success with linking and integrating although I have to
admit we don't use those features as much as we should. Having a
dedicated QA test team keeps us honest as they have to translate from
use case to requirement to test case. One advantage to using the
Rational Suite is that it sorta kinda "forces" you to follow a RUP-like
SDLC process if you are really using the product suite as designed. That
is obviously not going to be the best solution for every project. Using
any one of the products alone doesn't really buy you much and you really
need a dedicated "Rational Guru" to configure and maintain it.

I have used "Enterprise Architect" (http://www.sparxsystems.com.au/ ) in
the past and it did have some linkage between use cases and
requirements, although I don't remember the management aspect being all
that great. It has been a while so it might be a decent option.

I came across this "storyboard-based" application the other day from
STPSoft (http://www.stpsoft.co.uk/stpbadeveloper3.html ). I haven't
tried it yet, but it looks interesting and the price is much better.
Might be worth a look.

Rick Gordon
UI Technical Analyst, SAIC

Syndicate content Get the feed