use case
-
-
Number of slices to send:Optional 'thank-you' note:
-
-
-
- Number of slices to send:Optional 'thank-you' note:
-
-
-
- Number of slices to send:Optional 'thank-you' note:
-
-
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
-
- Number of slices to send:Optional 'thank-you' note:
-
-
-
- Number of slices to send:Optional 'thank-you' note:
-
-
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Originally posted by Paul Sturrock:
Strictly, your Use Cases are the requirements. However, if you mean to validate whether the requirements match user expectation, then typically once the Use Cases have been written they are reviewed and signed off by a domain expert (i.e. a non-technical person who knows the business process they represent).
That's still risky, though - sign off isn't a guarantee that user expectations will be met in any meaningful way. It's more of a promise along the lines of "I won't complain if I get what I think you've written down about what you think I will need." (as Robert C. Martin puts it, as far as I remember.) And often it doesn't work out very well if it's the only measure of success for the development team.
The only *real* way to know wether your system meets user expectations is to show the system to the users. Ways to do that early and often include prototyping and highly incremental development (such as implementing the most important features for a week and showing the result to the users before continuing with development of the next important features).
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
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Without Use cases, incremental development becomes an ad-hoc process. If you have Use cases in front of you, you can start using the list of Use cases to track the progress of your project
-
- Number of slices to send:Optional 'thank-you' note:
-
-
That's still risky, though - sign off isn't a guarantee that user expectations will be met in any meaningful way
Absolutely. Its the difference between "best case" and "realistic case" - whichever wins is usually down to project time constraints. If this were a question for a college course I'd say your answer is certainly more appropriate than mine, and if I worked in an environment where I had no customers/project managers/sales staff etc. breathing down my neck its the way I'd suggest to go - it depends really on context.
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Sign offs are one of the great lies about traditional software development.
- 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>
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Originally posted by Jayesh Lalwani:
Even if you are doing incremental development, Use Cases are useful in defining the incremental deliverables. So, say you got the requirements from the user, who is not sure about the requirements. You take the set of not-so-complete requirements, hammer out some Use Cases, and ask client to prioritize them. Client and you decide on which use cases should be developed first. Then you design/implement the first use case, deliver it the client, client gives feedback, you hammer out more usecases; lather, rinse and repeat
Full agreement! I didn't want to imply that use cases aren't helpfull - they are!
It's just important to understand that they aren't the definitive description of the system the user needs. Instead, they are more of a snapshot of your current understanding, and therefore need to be reassessed throughout the project, just as everything else.
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
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Originally posted by Paul Sturrock:
Absolutely. Its the difference between "best case" and "realistic case" - whichever wins is usually down to project time constraints. If this were a question for a college course I'd say your answer is certainly more appropriate than mine, and if I worked in an environment where I had no customers/project managers/sales staff etc. breathing down my neck its the way I'd suggest to go - it depends really on context.
I'm not sure I follow you. Are you saying that my suggestion is unrealistic for professional software development?
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
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Originally posted by Ilja Preuss:
Full agreement! I didn't want to imply that use cases aren't helpfull - they are!
It's just important to understand that they aren't the definitive description of the system the user needs. Instead, they are more of a snapshot of your current understanding, and therefore need to be reassessed throughout the project, just as everything else.
Right!!! And it's quite risky using an Use Case document as a sign-off. Most non-technical people don't and won't understand Use Case diagrams.
BTW, this made me think. What is the legal standing of an Use case document? Say, Acme Corp comes up with some requirements, and asks my company to implement it. I come up with use cases, get a sign-off from Acme. Some months down the line, I finish implemnting the product that 100% confirms to Use Case doc and give the product to Acme. Acme is'nt happy with it, and refuses to pay. Can I take Acme to court based on the Use Case document?
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Our customers don't sue us but we do disagree on what is a defect and what is an enhancement sometimes. The distinction is important with SLAs and budgeting, which is totally non-agile and silly to me, but there ya go. Anyhow, if it's not in the use case the customer signed off (or another lower level doc we attach to it), it's an enhancement.
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
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Originally posted by Jayesh Lalwani:
Some months down the line, I finish implemnting the product that 100% confirms to Use Case doc and give the product to Acme. Acme is'nt happy with it, and refuses to pay. Can I take Acme to court based on the Use Case document?
Not sure.
What I'm sure about is that both sides already lost in that case: the customer didn't get what he needed - if nothing else, he lost an important advantage to his competition. And the development company lost a potential long term customer and some good reputation.
So being able to go to court really doesn't buy you much, as far as I can tell.
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
-
- Number of slices to send:Optional 'thank-you' note:
-
-
The use case is validated by everyone who touches it. Does it communicate to the project manager, the designer, the coder, the QA tester, the customer tester, the deployer? As any of those roles (they might all be you) work with a use case they may find holes or inconsistencies. It's folly to think you can write perfect use cases, lock them down and wait for perfect software. Be sure you have a process for discussion, growth, modification over time.
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
-
- Number of slices to send:Optional 'thank-you' note:
-
-
Are you saying that my suggestion is unrealistic for professional software development?
Reading what I wrote back I see that it could be taken that way, though that's not how I intended it to come across. Its not unrealistic, its just (in my experience anyway) not the norm. And this is largely down to commercial pressures. Perhaps your experience is different?
| The airline is called "Virgin"? Don't you want a plane to go all the way? This tiny ad will go all the way: Paul Wheaton's 16th Kickstarter: Gardening playing cards for gardeners and homesteaders https://coderanch.com/t/889615/Paul-Wheaton-Kickstarter-Gardening-playing |