Vague and ambiguous use cases Programmers are often frustrated when well-meaning managers or architects attempt to introduce some OOAD [note that the process in my link isn't necessarily the same as the Iconix process Matt alludes to - Ed] into their projects. Often the reason for this frustration is subtle, and has nothing to do with OOAD as such - it's …
I wouldn't dream of giving a developer either of the two examples given to work from. I would expect the use case to evolve from type 1 to type 2 - but for the testers , not the developers. the developers would be working with sequence diagrams, class models and possibly state diagrams specifying with much greater precision the required functionality. The type 1 use case remains though, as a non-technical view of how the system works.
The whole point of implementation-free use cases is to give the implementer a CHOICE of the many ways an implementation can be done. For instance, do you click 'Add' to open an add screen or do you type right into blanks on the view screen. The second example takes away that choice. At the same time, it is full of extremely vague actors like "the system" and "the database", from which lists of classes and responsibilities are quite hard to derive. The second example is no more helpful than the first; it forces some choices, probably for no good reason, while leaving many other choices not explored.
Needs analysis is an art still not well understood even by people proposing solutions. In this case, the analyst needs to decide; is he going to count on the implementors to have a brain and thus give them a general guideline and let them choose an implementation out of the many possible ones, or is he going to draw the UI and write a structured walkthrough that says "The user types into the FOO box, which wakes up class C on event E. Class C then ..." and expects the implementers to only be code monkeys.
The analyst can't have it both ways. He's either doing the needs analysis or he's also doing the design.
Arguably the references to the UI elements are objectionable, however the worst practice is reference to the database activity. The analyst is deciding when to assign an ID, and when to save the claim. This places a lot of assumptions around an operation which can be extremely complex. Are we doing a long running transaction? Do we have multiple data sources that need coordinating? Is there a database at all, or are we talking to an SOA-centric data source, with its own interaction patterns? No matter... the analyst blithely tells us how it's going to work. How nice of him/her!
Your approach is obviously UML-centric; it's my opinion that a common drawback of UML usage is that it forces us to preemptively declare entities before we really know what we're talking about. Your example illustrates this problem nicely.
When a system is first conceptualized, architects should stay far away from listing any details of a system. The specifics of the type and structure of the data storage and UI should not be defined in the initial use cases. Has everyone forgotten about user testing? It shouldn't be an architect, but users who decides where each button should be placed and what data should be stored. By the time the developers get their hands on the use cases, they should have developed far beyond a simple diagram and should be a part of a detailed requirements document.
Thanks for all the feedback. I guess I should point out that the concrete, tangible use cases I've described do make sense (at least to me!) in the context of the overall development process that we described in the "Use Case Driven" book (i.e. the "ICONIX Process").
The reasons it makes sense are that:
a) the team will be working from a higher-level set of functional requirements ("the system shall..."), and the purpose of the use cases is to create a more grounded specification, i.e. it's time to nail down the specifics;
b) in the process of writing the concrete use cases, you would also be delving into preliminary design; so the developers would definitely be involved at that stage. So for example, they would have plenty of opportunity to say "hang on, the system just wouldn't assign an ID there, it would be part of an overall transaction" so the preliminary design, and therefore the use case scenarios, get a serious reality check before the detailed design work begins, and it gets everyone thinking about how (and whether) the system as specced is really going to work; and
c) the analysts can be assured that the developers fully understand the requirements, i.e. that everyone is "on the same page".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
