Why Implement Use Cases in Software Design & Development?

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, there are several additional benefits for Project Management. Since we are defining the functional requirements in terms of Use Cases, 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.