|
Use Cases And The User Interface
I want to raise a question here regarding the use or misuse
of use cases in the industry. Please - don't respond if you
don't have REAL experience with this issue.
My company is using the use-case modeling technique for
modeling a large application (telecommunications field).
The idea was to have these use-cases developed by our system analysts - then handed to a separate group that specializes in user interfaces. This group was supposed
to develop the various screens for the application.
The only thing is that this method does'nt work ...
As I see it - there are several problems here:
1. When developing use-cases - every developer needs to
have some picture of the final user interface in order to
have his part "integrate" into the final system. When
developing screens (pictures) - it's easy to see how each
new screen integrates into the system. When
developing use-cases - it's easy to get lost in the details
and fail to see the global picture. This makes it very hard
to maintain consistency between the few hundreds of
use-cases in the system.
2. We can't really get any meaningful feedback on these
use-cases from our clients. I suppose that for a non-
technical client it is much easier to comment on a visual
representation of the program than on thick use-case
documents.
3. There is no "WOW" effect when writing tons of use-case
documents. It's a lot of text, some of it tends to adapt
a repetitive (and boring) style like "create equipment",
"remove equipment" etc.
In the past - I never used the use-case modeling technique.
I've always started out with the screens - then created the
architecture and detailed design documents based on the
insights I got from the screens. This simple way worked
well for me.
I wanted to know what do you think on this issue ? did you
encounter these problems also ? did you manage to find
a solution that uses use-cases and works ?
Liron Levy
Thursday, October 23, 2003
Dude, I agree with you, it's not easy. Definitely a customer works best from what they can touch and feel. Look at what architects do. I worked on a project that had "use cases" (about 150 of them) although I don't know if they would have validated, but I found them a waste of time. The screen shots were gold. My mantra is data-model and screen shots. I rarely get either, seriously.
Me
Thursday, October 23, 2003
I am in the middle of a project where we have defined use cases and UI together. It is a pain to keep the screenshots and use cases synchonized. I don't have any suggestions either.
I am not even going to attempt to get customer input based on the use case/UI docs. I have been able to get some of the technical sales folks to review it and recieved a small amount of good feedback. I am tempted to try paper prototyping of the UI with a real customer next time.
The main value that I found with the documentation is that I am pretty sure we haven't left out any major pieces of the UI or the app. The value isn't in the design itself, it's in the process of building the design.
pdq
Thursday, October 23, 2003
Other than the intent of the UI in a particular case I have never found Use Cases relevant for designing the UI.
Certainly in defining the Use Case I've attached a ton of fields or attributes that it will require or affect but whether its one form or a series ow whatever I can't see any mapping between them.
Its the intent that matters in the Use Case.
Simon Lucy
Thursday, October 23, 2003
1. Use cases are not intuitive to the non-technical people who are defining the requirements, and the large amount of writing & funny little diagrams turn them off. In order to write an effective use case, you really need someone who (a) understands use cases, (b) can communicate effectively with the business, and (c) can really walk the business through the use cases without relying on the use case itself... Sort of act as a translator.
2. As useful as use cases are for determining workflows, and what buttons need to appear on the screen (i.e. alternate flow "Use Hits Cancel") I don't see that a use case should really be used to design the screen and that the programmer should then work from the screen. In that case it really seems like an extra layer: use case -> screen -> programmer. Shouldn't the programmer also have access to the use cases and not just be working to the screen?
In other words, if you're only using the use case to design the screen, why bother with the use case and why not just design the screen?
3. Use Cases are really effective when the project sponsors come to you and say "Why does this do this, this isn't what we wanted?" You can then go back to the Use Case and say "Well you signed off on this, and according to this... this is what you want."
So when they come back and ask why clicking "Next" on a multi-page input form doesn't directly update the database instead of waiting for the last screen when the user clicks "Finish" you can use the Use Case to show that the workflow for "Next" didn't include updating the database.
www.MarkTAW.com
Thursday, October 23, 2003
"So when they come back and ask why clicking "Next" on a multi-page input form doesn't directly update the database instead of waiting for the last screen when the user clicks "Finish" you can use the Use Case to show that the workflow for "Next" didn't include updating the database."
Don't be so smug. This is a 100% failure on your part. It's the developer's job to determine if the client wants updates page by page or only for the entire transaction.
Philo
Philo
Thursday, October 23, 2003
"Don't be so smug. This is a 100% failure on your part. It's the developer's job to determine if the client wants updates page by page or only for the entire transaction."
Hmmm. Okay, maybe that was a bad example.
www.MarkTAW.com
Thursday, October 23, 2003
I haven't found use cases useful for program design, though I have used them to add a couple of wizards to do tasks commonly performed by a certain subset of users.
I have found the big picture gleaned from coming up with the use cases to be useful in creating marketing materials, in particular defining the sort of presentation you want to make to a subgroup of users, showing that you do understand their workflow.
Dennis Atkins
Thursday, October 23, 2003
Use cases are just a different way of expressing functional requirements for a project. They are supposed to be easier for the non-software person to understand. In my opinion they are a good first step for systems that are mostly for moving a set of humans real world workflows into the software world. They probably aren't very good for other sorts of system, such a phone switches, which work internally with little human interaction.
Either way, I have never found use cases to translate into screens. I think this sort of design will doom you to a stove pipe system. Read the use cases while creating your object model. Read the use cases while designing your GUI. Change all three as needed as you proceed.
Name withheld out of cowardice
Friday, October 24, 2003
We have close to 10 years invested in our development process, applied to six different products. Although our development process has changed in many ways through the years, one result we have always been able to attain (according to our clients), are products that are exceptionally easy to use.
I would credit this to the fact that the design process *always* involves mock-ups of screens in Paint very early on in the process. During early development of a new product idea, we've found the most important component at that time is visualization of how the user will interact with the product.
We have only recently introduced use case modeling (about 1.5 years ago) to help our process (which it has). However, we feel that the initial process of mocking up the screens and "storyboarding" the application is the most important part of the process to get to an end result that we--and our clients--want. For us, this is especially important because our number one focus is ease-of-use.
We consider the UI spec and use cases two separate, but equally important components of the overall requirements specification. In our company, we have decided to informally break it down like this:
Note: Our "rules" outlined below are sometimes broken here and there to achieve better clarity and understanding of what the product look and behavior is supposed to be.
UI Specification
- Layout of controls
- Types of controls used (We have defined "standard controls" as part of our UI specification. For example, a "State Text Box" includes rules such as the text being forced to all uppercase as it's typed, and a character limit of 5.)
- Minimum/maximum size of resizable dialogs
- Domain model object/property that corresponds to each control.
Use Cases = "Dynamic requirements"
- What happens both on-screen as well as "behind the screens." I.e., when the user clicks the XYZ button, what, exactly, it supposed to happen?
To get back to the original poster, I believe that there is no "right" answer to "what comes first, the use cases or the screen mock-ups?" I believe that they need to be done hand-in-hand. What I envision as the ideal process (again--based upon our particular circumstances, developing rich Windows client applications) would be:
Phase I - Brainstorming
1. Identify core use cases. (Not hundreds, tens. Ivar Jacobson gives a target of 20 "core" use cases for any size system (not counting included and extending use cases). The idea here would be, "OK, what does the user want to do with this system?")
2. Brainstorm how the user will interact with the system to attain these goals. Create general outlines for the use case flows.
3. Mock up the screens that allow the user to perform the use case actions.
Phase II - Validation & Revision
1. Review the screens with focus group members, verbally walking them through the outline of what happens first, second, third.
2. Continue to flesh out more details in the use cases, expanding the outlines and adding alternative flows as more, "what ifs" are discovered.
3. Revise the mock-ups as more feedback is obtained from the target audience.
I've skipped development of the glossary and domain model, but those kind of fall out of what, again for us, are the core pieces--the screens and the blow-by-blow description of what happens (i.e., the use cases.)
As always, this is all based upon our particular experience. Hopefully some of this information will at least be somewhat helpful.
I've personally found the following book extremely helpful. It's the one that Jacobson recommends. I figured if the inventor of use cases recommends it, it's probably pretty good. It was.
Use Case Modeling (Bittner/Spence)
http://www.amazon.com/exec/obidos/tg/detail/-/0201709139/qid=1067213578/sr=8-1/ref=sr_8_1/102-3264620-9029722?v=glance&n=507846
Here's the Jacobson article where he discusses both the "20 use case rule of thumb" as well as the book recommendation:
Use Cases--Yesterday, Today, and Tomorrow
http://www.therationaledge.com/content/mar_03/f_useCases_ij.jsp
Liron, if you want to hear more how we dealt with the same issues you're now dealing with, feel free to e-mail me.
- Dave
Dave
Sunday, October 26, 2003
Hmm. Anyone know why those links didn't, well, turn into links?
- Dave
Dave
Sunday, October 26, 2003
Guys,
We need to remember that screen design and Use Casing are different aspects of the same activity.
The Use Cases describe the functionality and the screen shots describe the composition of controls that furnish that functionality.
The problem manifests itself when development causes changes in either of these aspects, when the functional-modeling causes changes that screen-shots need to express and vice versa.
The best way I know to help this issue is to pay HUGE attention to the level of (relevant) detail in the two branches.
Keeping track of the level of abstraction is not a new concept, checkout "Essential Use Cases" from Constantine & Lockwood. They suggest that you should start with Essential Use Cases and move to Real UseCases later.
This is under discussion in UI circles under "UML-UI".
A Nice article on this is in:
http://www.foruse.com/articles/abstract.pdf
Erez
Erez
Monday, October 27, 2003
 Recent Topics
Fog Creek Home
|
