- Living with use cases
-
«The hardest single part of building a software system is deciding precisely what to build»
from - Frederick Brooks, «No Silver Bullet: Essence and Accidents of Software Engineering»
- Use case approach
-
If I consider the time spent and number of pages dedicated to use cases I get a feeling that something is intrinsically wrong. As they are supposed to be the most simple thing in the area of software requirements I start to ponder that it must be that «simple» that makes it an obstacle. We hate things simple and we find much fun in getting them entangled, complicated, incoherent, even contradictory all just to find that ultimate and final pleasure is to be lost in a mess of everything. That’s why I adhere, as a firm proponent, to the Use Case approach enjoying it’s simplicity that leads to solid requirements capture, specifications definition and test case preparation. All this in that most stimulating process of software development. Creativity is liberated through the structuring that is not too much reinforced. Anyway a solid framework to assure the control of the requirements capture through use cases is necessary.
- System context
-
Beware: writing a good use case is a very difficult task. The requirements universe is flooded with as many poorly written use cases as the number of projects that failed.
Throughout the article by «system» we mean everything that encompasses the final result with all it’s interactions with the outer world. I would be tempted to say that «System» is what we would indicate by saying just «It». If I look a little bit further to refine on «It» notion, I use Leffingwell’s operational definition that places the notion of the system in the center of the requirements management process. To cut it short five steps define that process:
1. Understand the user’s needs.
2. Define the system.
3. Manage the scope and manage its change.
4. Refine the system definition.
5. Build the right system.
«System» is what’s dealt with through these five steps.
- Levels
-
«Needs» is what starts the process. It’s the first and the highest level with lowest detail. It could be a Vision Document that states what, why and when is necessary to make our living better.
The second level is «Features». They provide a shorthand on the future system that is going to be delivered. It’s more detailed than «Needs Document» but less than its detailed description. I suggest the definition proposed by Rational (RUP) as a very good guide to avoid any upcoming ambiguities:
Feature is a service that the system provides to fulfill one or more stakeholders needs. They (features) are derived from the needs and provide the initial bounds of a particular system solution (detailed solution). They are expressed in the natural language. Any stakeholder may read it and gain immediate basic understanding of what the system is about.
The third level is a detailed description of the system through the use cases. Use cases describe a series of user and system interactions that help users accomplish something they wanted to achieve. They describe the HOW users and the system work to realize the identified features. Each use case encapsulates a set of requirements i.e. all the obvious features the users will expect in the system.
Software development being my domain of consulting, I adopted the following definition proposed by Dorfman [1990]:
Software requirements are capabilities that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documentation. What’s needed to be stressed is the contract driven approach. Just don’t forget that it’s stakeholders money that’s behind the scene.
- Advantages
-
There are some advantages of using the use case approach in requirements capture:
[1] Use case live in a semiformal framework for structuring the «stories» that describe what’s going on in the system. These stories (use cases) must have a purpose: «yield a result of measurable value to an individual actor of the system» as Ivar Jacobson put it. A set of use cases should capture the fundamental value-added services that users and stakeholders need from the system. It is the stakeholders money that makes the things move on.
[2] Use cases describe the system for the error situations. Managing the defects is essential for quality assurance process. Winners know what defects and how many of them they produce.
[3] In the object oriented world objects are created based on use case path that implement the behavior defined by them. The importance of this aspect is what makes use cases unexpected and phenomenal ally and a starting point for approaches defined by Unified Modeling Language (UML) and Rational Unified Process (RUP).
[4] Use cases provide brick and mortar for my project management estimates, schedule release, traceability and the processes like change management, software development and quality assurance.
[5] Use cases drive their force from various established patterns. Nevertheless this trend of using patterns might lose its steaming power by the simple reason of its increasing number and the fact that new developments in software industry with its exponential creation process can’t wait for a new pattern to appear. Some patterns simply get useless and outdated as well.
- What are they for
-
Turning use cases into system requirements is a way of seeing the same goal through a better adapted approach then just writing a prose through «classic» requirements definition.
Use cases describe functionality from the user’s point of view. To evaluate the importance of each of them they are to be rated against three factors. «Status» is a supplementary attribute for project management purposes:
1. customer needs
2. complexity
3. risk
4. status
The combined weighted value of these three factors allow for scoring and classification thus establishing and evaluating the development cycle. The implementation order of requirements maps directly into the iterative development process.
The primary advantages and the role of the use case in the software development process are:
1. They serve as foundation of design review using the status notion (e.g.: initiated, advanced, accomplished).
2. They are converted into objects in design phase using techniques like UML.
3. They form the basic system test plan.
4. They are the backbone for acceptance testing.
5. They form the initial user manual.
- Sources of inspiration
-
I keep track of the use cases using data management system. Despite of a «story» like approach they are dealt with like entities (objects) with attributes and services that they deliver. Solid name convention applied to them, to their attributes and services make of them the best candidates for a data management system. This last phase with the formalism imposed closes the formal institutionalization of the use cases. Now they (use case) live in a formal framework and constitute the foundation for the implementation, evolution and future reengineering of the system.
[1] «What is a Quality Use Case» from Pattern for Effective Use Cases by Paul Bramble, Alistair Cockburn, Andy Pols, Steve Adolph
[2] «Features, Use Cases, Requirements, Oh My» by Dean Leffingwell
[3] «Capturing Requirements with Use Cases» by Todd Wyder
[4] «Applying Requirements Management with Use Cases» by Roger Oberg, Leslee Probasco, Maria Ericsson
[5] «Top ten Use Cases Mistakes» by Dough Rosenberg, Kendall Scott
[6] «Adopting use cases Part I: Understanding types of use cases and artifacts» by Pan-Wei NG
[7] «Adopting use cases Part I: Putting learning into practice» by Pan-Wei NG
[8] «Use cases – Yesterday, Today, and Tomorrow» by Ivar Jacobson
[9] «Writing Effective Use cases» by Alistair Cockburn