Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

use case  RSS feed

 
kri shan
Ranch Hand
Posts: 1489
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How can i validate the particular use case?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
User Acceptance Testing?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Validate for what?
 
kri shan
Ranch Hand
Posts: 1489
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Validation : Whether my use cases are satisfied the requirements?
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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). In companies where the software is written to order for a client, the Use Cases become legally binding, and are signed off by the client. The "review and sign off" part is your validation.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Jayesh Lalwani
Ranch Hand
Posts: 502
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

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
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Scott Ambler
author
Ranch Hand
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fundamentally the only thing that you can say once your requirements have been signed off is that your requirements have been signed off. Your project can still fail, your designers can still misunderstand the requirements, your programmers can still build something else, and your users can still realize that that wasn't what they really wanted anyway.

Sign offs are one of the great lies about traditional software development.

- Scott
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Jayesh Lalwani
Ranch Hand
Posts: 502
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Many contracts are based on much less precise documents. I gues that's why there are courts.

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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I used to say that everyone on the team should have a use case in one hand at all times. Without it, what they heck are they working on?

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.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!