Why Implement Use Cases?
There are several ways to answer this question, but there are 4 main considerations.
1. Use Cases as a better form of documentation
Instead of one monolithic Software Requirement Specification (SRS) in a single document, using Use Cases
encourages us to split up our SRS into more focused smaller documents which together cover all of the requirements
a traditional SRS would contain. Each Use Case has a Use Case Specification document which focuses exclusively on
the functional requirements for that particular Use Case. If we need to change a particular piece of functionality,
we only need to change the Use Case that functionality is expressed in, and won't need to go through the documentation for the entire project!
Similarly, by separating out the non-functional requirements into a Supplementary Specification document, we have a single point of reference and control for all non-functional requirements in our project.
As a consequence, change control and configuration management are made easier. Instead of having to distribute one massive document to everyone on the project every time a minor change is made, we can now version control each individual Use Case Specification and the Supplementary Specification, each of which can have a smaller distribution list of only those people who need to know about changes to a particular Use Case Specification.
2. Use Cases as a tool for communication
Since a good Use Case Specification is one that is written from the user's perspective, it serves as a useful
document for discussing the functional requirements of the system being developed with everyone involved on the project.
It should be something that the end-user (customer) is able to read and understand relatively easily, while still giving the
analysts, designers, developers and tester’s sufficient understanding for doing their jobs. A Use Case Specification is not
intended as a highly technical document, but rather as a document that all parties involved on the project can use to agree the
scope and functionality of the project.
Since it's written from the user's perspective, it is much easier to involve the user throughout the project, and it is easier to get agreement on what will be developed. Traditionally, projects often fail because there is a gap between the user expectations and the project team's understanding of the user's requirements. A major aim of Use Cases is to have a common document that covers all functional aspects of the software being developed and that serves as a facilitator for discussions about the system being developed and allows for common understanding and agreement on what is being developed.
3. Use Cases as a tool for Project Management
Having your Software Requirement Specification captured in the form of Use Case Specifications and a Supplementary Specification,
we are effectively breaking down the system into smaller parts in terms of functional decomposition. While this does not mean that all
functionality will be exclusive to a particular Use Case (some functionality, or rather some implementations of functionality, might be
shared across Use Cases), it certain lends itself to parallel development for disparate pieces of functionality. This is especially true
if we refrain from thinking of development as the same thing as coding! For example, it's possible for our systems analysts and test writers
to work on the same Use Case simultaneously. It is also possible that while designers are evolving the results of analysis for a particular Use
Case, the analysts could be working on another one. And while the designers are coming up with the designs for one Use Case, programmers could be
implementing another one that has already been through the design phase. Essentially, the very act of decomposing the project into smaller parts
based on functionality lends itself to exploiting opportunities for parallel development.
Another interesting side effect of this functional decomposition aspect to Use Cases as far as Project Management is concerned is that we immediately have some potential for monitoring project progress. If we can identify a few key variables for each Use Case such as risk, complexity, size, and available resources, we should be in a better position to gauge not only how long a Use Case will take to develop in its entirety, but also to gauge how far through the project we are. Naturally, as with any estimation technique, learning to accurately predict how long any part of a software project will take is somewhat more of an art than a skill, but being given a good starting point by considering each individual Use Case makes the job of the Project Manager that little bit easier than it would be having to estimate off the traditional single SRS.
There is a tendency to associate Use Cases with iterative development processes. It is worth noting at this stage that using Use Cases to capture functional requirements does not imply that you will be using UML, or that you will be using an iterative development process (for example, the Unified Process). However, having said that, both UML and Iterative processes leverage the power of Use Cases very effectively, and so are often used in tandem. In a typical iterative approach, the first phase of any project involves identifying all of the Use Cases for the project, and doing some initial analysis on them with the aim to identify those Use Cases that pose the greatest risk to the projects overall chance of success or failure. The idea would then be to tackle the high-risk Use Cases in early iterations in the project to eliminate project risk. If the risk cannot be eliminated early on then the project will still fail, but with as little amount of wasted effort and expenditure as possible. When used in conjunction with an iterative process, Use Cases give us an excellent way of managing project risk.
4. Use Case Driven Development
Using UML is not a requirement for using Use Cases to capture functional requirements for a system. However, you will often find that project teams that employ Use Cases also use UML to model the system being developed. There are established techniques for using the flow of events in a Use Case Specification to define analysis versions of Sequence and Communication Diagrams, which in turn are used in identifying analysis classes, the results of which directly feed into the design process wherein design classes are identified and fleshed out. Those design classes are then used by the programmers to implement the system. The whole procedure forms part of what is known as "Use Case Driven Development", where Use Cases are used to drive the development process. Through each of the stages in the process, the Use Case Specification is constantly referred back to (and if necessary, discussed and updated) to ensure that the decisions made in analysis, design and implementation are consistent with the functional requirements expressed in the Use Case Specification.
Getting Started with Use Cases
If you aren't using Use Cases on your projects, now that you know just how useful they can be, why not give them a try? Adopting Use
Cases as your method of documentation does not imply having to adopt UML, RUP, or any other process which deals with Use Cases - even on
their own, Use Cases are an effective method of documentation that any project can benefit from.
Dunstan Thomas recommends the use of Sparx Systems Enterprise Architect as your UML development tool. To understand more about the Unified Modelling Language, visit our What is UML resources page.
To learn how to produce Use Cases in Enterprise Architect, look at our UML with Enterprise Architect for Business Analysts Training Course and to gain a practical understanding of UML, examine the detail of our UML Essentials Training Course.