my dog learned polymorphism*
The moose likes Agile and Other Processes and the fly likes What Is Use Case-Based Requirements? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "What Is Use Case-Based Requirements?" Watch "What Is Use Case-Based Requirements?" New topic
Author

What Is Use Case-Based Requirements?

JiaPei Jen
Ranch Hand

Joined: Nov 19, 2000
Posts: 1309
What is use case-based requirements? Are use cases dependent on having at least partial understanding of the requirements of the system?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.
Axel Janssen
Ranch Hand

Joined: Jan 08, 2001
Posts: 2164
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 ]
Hu Chong
Greenhorn

Joined: Jun 30, 2003
Posts: 17
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 ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Michael D. Brown
Greenhorn

Joined: Nov 22, 2003
Posts: 29
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Jun 30, 2003
Posts: 17

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
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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?
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
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


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: What Is Use Case-Based Requirements?