The Coad Letter: Modeling and Design Edition, Issue 115, Gathering Requirements: Use Cases by Granville Miller

By: Coad Letter Modeling Editor

Abstract: This edition of the Coad Letter takes a look at the dynamics of use cases.

Understanding the requirements for a software project is paramount to a successful completion. There are many ways to capture requirements for software projects. Perhaps some of the most widely used methods are the shall statements, use cases, user stories, and features. Each method has its pros and cons.

In this edition of the Coad Letter, we take another look at use cases. In an earlier edition, we discussed the most common mistakes of use case modeling. This Coad Letter looks at the reasons for choosing use cases instead of the other requirement types. Often this reason is dictated by the dynamics of the project although experience may play a key role as well.

A History of Use Cases

The use case appeared in the object-oriented community in 1992, as a result of pioneered work by Ivar Jacobson. The story goes that the use case should really be called a usage case but that Ivars Swenglish (Swedish accented English) caused it to be so named. Regardless of the origin of the name, Ivar is credited with inventing the use case and had been developing the concepts behind them for many years prior to the release of his first book.

Use case diagrams, a pictorial roadmap of the use case functionality, became part of the Unified Method in 1995, and remain a part of the Unified Modeling Language to this day. The use case diagram provides an overview of the systems functionality while a use case description describes each of the goals of the system. While use case diagrams have been standardized, there is still a great deal of variation in the format used for use case descriptions.

The Use Case Descriptions

Use case diagrams are interesting from a ten thousand foot view of the system. However, the use case descriptions hold the majority of the system information. As their name implies, a use case description holds a description of the way the system is utilized. These uses are formulated as goals and the use case description captures all of the ways that the system can achieve or fail as its users attempt to achieve that goal. For example, the use case description for Rent Video would contain something about paying late fees.

Use case descriptions are great for capturing requirements for outsourcing. Use cases are one of the few requirements vehicles that capture the functional stripes all the way through the system. As a result, they are open to less interpretation than many other requirements methods. They are arguably the best mechanism for capturing requirements when a customer cannot work directly with the team.

One of the drawbacks of the use case is that it is a very large chunk of functionality. Typical systems may contain a dozen or more use cases. In an age of iterative development, it may preferable to use a single functional stripe or scenario as a basis for your current increment. Using scenarios or single steps gives the finer granularity needed to deliver small amounts of functionality quickly, but becomes difficult to put into a project management tool.

Finally, the use case description is functional. As a result, it may foster functional programming. As a result, it is wise to balance use cases with UML class diagrams to promote object-oriented design. Classes create a structure or form while the use cases fill in the functionality. The two models and ensuing code combine to create a system that is both extensible as well as maintainable.

Advanced Use Case Modeling

Building use case models for simple systems with a small number of simple goals is relatively easy once you learn how. However, we often encounter more complex systems that represent entire business processes or have a large number of goals. In these cases, we may have to describe use cases in various forms and levels of abstraction. There are many models that can be employed along with use cases on these types of projects.

For larger systems, a complete use case model is not built in a single step. Instead, the model is built progressively and iteratively, as a natural result of the process of analyzing and discovering system functionality. As more knowledge is gathered, the model is elaborated. There should be representations that capture this progress as it occurs.

The use case model may have varied audiences who will wish to view the use cases in different ways. Different stakeholders of the system have different viewpoints from which they view and validate the use case model. Multiple representations help facilitate their understanding and their validation of the model. The use case model may have a diverse audience, ranging from customers who wish to view the functionality, at a high level, to users who to need to validate the detailed functionality of a specific use case, to the object designers whom need enough information to map the use cases into an object model.

A use case model must be complete and robust enough to represent these views. For example, the CIO or customer of the system may wish to primarily review the use case diagrams and conceptual descriptions of the use cases in order to understand the system concept. However, the system designer may wish to focus on reviewing the use cases at their lowest level of detail to understand the implications of their object design.

Multiple representations also allow the use cases to be more easily partitioned for development. A model containing only high level and base use cases descriptions can be created for a system concept or concept of operation document. The elaborated use cases descriptions and a comprehensive set of extends and includes use cases can be developed during a more extensive analysis activity.

Some of these more complex systems have as many as four hundred use cases. Use case modeling may be used as an organizational technique to add order and understandability to a large use case model. These types of systems require this more disciplined and organized approach.

Conclusion

Use case modeling is one the most popular and effective requirements gathering techniques. We have discussed some of the pros and cons of use case modeling in a variety of environments. Writing your first use case can be difficult, but like most things, it improves with practice. Of course, large-scale, enterprise efforts will require a more advanced approach.

It is important to remember that use case modeling is not a linear process. Use cases will be discovered, then elaborated with detail, rethought, reworked, and revised as the use case modeling effort progresses. In many domains, new use cases will also be discovered throughout the use case modeling process. Remember, there is always the next iteration or the next release.

Bibliography

Frank Armour and Granville Miller. Advanced Use Case Modeling, Addison Wesley, 2000.

Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard. Object-Oriented Software Engineering: A Use Case Driven Approach, Addison Wesley, 1992.

Divider line

For more information on Agile Management, visit http://www.agilemanagement.net/

For the latest up-to-date techniques in the Unified Modeling Language and Agile Software Development Processes, subscribe to The Coad Letter. Visit The Borland Developer Network for all of the latest information on how to deliver better software faster.


Server Response from: ETNASC04