• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What Is Use Case-Based Requirements?

 
Ranch Hand
Posts: 1309
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is use case-based requirements? Are use cases dependent on having at least partial understanding of the requirements of the system?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Use cases are one way of documenting what the system under development should do once it's finished. The information stays the same, no matter which requirements gathering method you employ -- only the media and pace with which this information is communicated between you and the customer varies.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also, remember that a "use case" can mean many things. There's a Use Case diagram in the UML, but there's also a concept of verbal use case description where the feature/requirement is expressed as a small scenario or story.
 
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Use case describe the system from the viewpoint of the different stakeholders who are going to use the system.
Like in amazon app:
- employee of amazon enters book in catalog
- customer buys a book
- customer browses catalog
- customer clicks on "was review useful" button to keep Thomas Paul in top 1000 reviewers.
You get to use cases in meetings with stakeholders of the system.
A use case should give the actor an "observable result of value".
Authentificate on amazon with email adress and password is not a use case (gives user no overvable result of value), but is part of a lot of use cases like buying book.
Use case describe the functional requirements of the system.
There are non-functional requirements also, like functionality, usability, reliability, performance, supportability and lot more.
Use cases are an instrument to gather the functional requirements of the system. Use case is egg. And (functional) requirements of the system is chicken.
[ January 30, 2004: Message edited by: Axel Janssen ]
 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How much information should a use case contain?
From my previous experience, a use case consists of many sub-flows. Each sub-flow answers the question of what the user do and what the system should do in return. Should the sub-flow also contain information on how the system is processing the information? One example is registration of new member. The sub-flow would be like.
1. User SELECTS register option.
2. System returns a registration screen with Name, Email, etc.
3. User ENTERS information and PRESS submit.
4. System processed information and return confirmation page.
For this sub-flow, there would be a data validation table for the screen elements (like what is the format and length) and a processing section containing things like how the email would be validated, etc.
Then, there are also alternative sub-flow for this sub-flow, like invalid email address, etc.
Is this too detailed? I have use case documentation of 80 over pages for just one use case.
[ January 30, 2004: Message edited by: Hu Chong ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Hu Chong:
How much information should a use case contain?


Whom are you doing the use cases for? How much information will they need? What other information sources will they have?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are a couple interesting views of use cases and the activities involved in writing them.
Our team views creation of the use case as an exploratory process. We sit with the customers and talk about what people need to do and how a new system or feature could help them. The use case is the outcome of much discussion and give and take with the experts. We use Rational tools that let us extract a database of requirements from the use case documents.
I've seen other teams that gather a traditional System Requirements Specification as a numbered list of individual requirements, perhaps with a hierarchical or outline organization. They use another tool that extracts related requirements from their database and generates use cases.
I frankly saw much less value in the second approach. Writing use cases gives us a structured way to interview the customer and share the results. We then mine the use case (interview notes) for requirements.
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Hu Chong:
Is this too detailed? I have use case documentation of 80 over pages for just one use case.
[ January 30, 2004: Message edited by: Hu Chong ]


80 pages for one use case is a bit extensive. If your document is going over 10 pages it's probably time to consider if the particular task can be broken down into subtasks.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael D. Brown:
80 pages for one use case is a bit extensive. If your document is going over 10 pages it's probably time to consider if the particular task can be broken down into subtasks.


Not only that - you should also ask yourself wether all that information really needs to be written down now, needs to be written down in the form of a use case, or needs to be written down at all.
For example, early in the project you probably need to do a rough release plan to get an idea of how long the project will take and what features will be implemented when. For that it might actually suffice to have some words per use case written on an index card as a planning token.
And even when it comes to implementing the feature, it might be well more effective to have tight collaboration with the domain expert(s) and a suite of executable acceptance tests instead of a 80 page use case document.
 
Hu Chong
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


of executable acceptance tests instead of a 80 page use case document.


What are acceptance tests? you mean test cases?
At which stage of the project, should we come up with test cases? My experience is during development.
[ February 03, 2004: Message edited by: Hu Chong ]
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Hu Chong:
What are acceptance tests? you mean test cases?


In some organizations, "acceptance test" means that the customer sits down, monkeys around with the software for a while, and says "I'm ok with this, here's the dough". In some organizations, acceptance tests are a way of documenting requirements. Some organizations write acceptance tests as executable scripts (a bunch of FitNesse test scripts, for example), and some organizations write acceptance tests as Word documents (the traditional "test case"). It really depends...
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Hu Chong:
What are acceptance tests? you mean test cases?


I was referring to executable test scripts, defined by the domain experts, which define what the system is supposed to do. They can serve as an unambigous specification.


At which stage of the project, should we come up with test cases? My experience is during development.


In my humble opinion, you should have at least two layers of tests.
First the above mentioned acceptance tests. A test for a feature should be ready to run when the developers finished implementating the feature - otherwise, how do you know that you are finished? Having the test ready just *before* implementation starts can't hurt, either.
Second, the programmers should write unit tests for their code which helps them make sure that the code does what they think it does. They also can help in designing and refactoring the system in ways the acceptance tests don't. I prefer to write those tests in concert with the implementation, in very tiny increments (using the Test Driven Development practice).
Does that help?
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
IMHO, a use case should only be a couple of pages long at most and frankly I've seen some very effective ones that were only half a page. A previous poster discussed an 80-page use case -- this likely contained definitions of business rules, user interfaces, data definitions, ... This, IMHO, is a serious mistake, likely driven by the "use-case driven" marketing rhetoric in the IT marketplace. My advice is "normalize" your artifacts and store information once and once only in their own separate artifacts. Therefore the business rules belong in a business rule spec, the screens in some form of UI spec or prototype, and so on. This info doesn't belong in your use cases.
In general beware the term "use case driven X", generally what you really want is "requirements driven X".

There are several types of use cases:
1. Essential use cases: http://www.agilemodeling.com/artifacts/essentialUseCase.htm, which describe a technology independent view.
2. Business use cases, which focus on high-level business processes. This is a RUP concept for business process modeling, although frankly I'd rather use process model based on either a data flow diagram (http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm) or perhaps an activity diagram (http://www.agilemodeling.com/artifacts/activityDiagram.htm) as they're better suited.
3. System use cases, http://www.agilemodeling.com/artifacts/systemUseCase.htm, which take technology issues into account. These are really analysis or even design artifacts in my mind, although the RUP seems to think that they're requirements artifacts. Probably because they don't have the concept of essential use cases.
4. Use case diagrams, http://www.agilemodeling.com/artifacts/useCaseDiagram.htm, for overviewing the use cases. The real value is in the use cases.

- Scott
reply
    Bookmark Topic Watch Topic
  • New Topic