UML Weekend Crash Course™ - To Parent Directory

82
Saturday Morning
a way that the Use Case alone could not. This closer look will, as you’ll see in subsequent sessions,
open doors to further analysis of the system and ultimately to the design.
Probably the key lesson to learn here is the necessity of tackling the important questions
and issues early, when you have the best chance to come up with the best possible solution.
All too often, developers leave these questions until they’re working on the code, when
many of the big issues are easily lost in the mountain of details and the requirements are
expressed in a form that is alien to most users.
Why you should care about Use Case scenarios
In some situations, a Use Case is simple enough that the narrative is more than ample to
explain all the issues that define its proper execution. But in many other Use Cases, the
logic can become troublesome. Many of the applications we work on are complex and require
significant scrutiny. That is one reason why the UML provides a whole set of tools rather
than just one.
In addition to addressing complexity, you need some way to test the accuracy and completeness
of the Use Cases. Unfortunately, for many projects, developers often hold off testing
until the end of the project, when they’re short on time and focused on the solution
rather than the requirements. Or worse yet, there is no time for testing at all, so final
tweaking happens in production.
Speaking of requirements, did you know that the overwhelming majority of litigation
regarding software projects is based on misunderstandings over requirements In a recent
abstract regarding his participation in litigation over software projects, Capers Jones of
Software Productivity Research had this to say:
“The clients charge that the development group has failed to meet the terms of the contract
and failed to deliver the software on time, fully operational, or with acceptable quality.
The vendors charge that the clients have changed the terms of the agreement and
expanded the original work requirements.”
Furthermore, the problems that Mr. Jones refers to here are on projects where there is a
contract. Consider how much worse the situation can become where the requirements
process is less formal!
If you’ve ever worked in a quality-assurance group, or even worked with one, you know
how frustrating the tester’s role can be. Think about how the tester’s challenge changes
when she’s able to create a test plan at the beginning of the project instead of waiting until
the end. Then testing can take place in small increments throughout the project, instead of
in a massive, difficult, and frustrating process at the end (if there is time to test at all).
This is why scenarios have taken on an increasingly important role in the requirements
phase. But what happened to other tools like screen layouts and prototypes They are still
valuable, and in some cases provide a great way for users to visualize what you are trying to
express in words and diagrams. The challenge is that the layouts themselves don’t explain
how they’ll be used and why.
Another liability with prototypes is that they give the false impression that the application
is nearly complete. This makes sense because the user only works with the interface. To
users, the interface is the application. But you know that there is a lot more to it, including