Functional requirements specify the needed effects of a system on its environment.(1) Use cases are a simple way to model the functional requirements of a system. By capturing who does what with the system in order to achieve a particular end result, use cases provide the outline for the system from a high level view without delving into the system internals. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system, bounding the scope of the system.(2)
During the requirements analysis stage of system development, the systems analyst sits down with the intended users of the system and makes a thorough analysis of what functions they desire from the system. The analyst then draws use case diagrams to model these functions. A use case is a description of a set of sequences of actions that a system performs that yields an observable result of value to a particular actor.(3)
Use cases find their roots in Object Oriented Systems Analysis and Design (OOSAD). OOSAD is an approach that has numerous advantages over the traditional structured approach of the SDLC. Instead of focusing on data and processes as separate entities with separate models, OOSAD uses the notion of an object to encapsulate data and processes. In the real world, the data aspects of a thing and its behavior or process aspects are not considered separately. George, et al. use the example of a DVD player to illustrate this ontological issue. They claim it is not natural to think of the attributes of a DVD player such as make, model, and price, and its behavior such as play, fast forward, and show subtitles as logically separate items.(4)
The SDLC’s four phase linear approach to identify, analyze, design, and implement information systems limits modifications to the system when it is close to completion. The analyst or designer would have to effectively start over at the beginning of the SDLC to make the changes. Worst of all, the user may discover that the system is a lot different than what they were wanting after considerable time, energy, and expense has already been invested. Using the iterative and incremental methodology of OOSAD mitigates risk by developing the core aspects of the project before moving on to more periphery concerns. This enables the user to experience the product early in the development period and allow for needed changes.
In addition to the high risks caused by changes needed late in the SDLC, there is a lack of fluency from the analysis diagrams and representations of the SDLC to those of design. If the user requirements should change, it is difficult to model that change easily in both the analysis and design areas of the SDLC. The utilization of a Unified Modeling Language (UML) in OOSAD provides transparency from one diagram to the next allowing for changes in one diagram to be easily transposed to the others. The UML embodies a set of nine unique object modeling and diagramming tools that comprehensively define and model an object oriented system. The common element in these nine tools is that they all use exactly the same syntax and nomenclature, thus making it easy for analysts and programmers to learn and use the UML.(5) The foundation for the UML is the use case diagram.
A use case diagram is essentially a picture showing system behavior along with the key actors that interact with the system. Typically, a use case is initiated by an actor, but a use case can also interact with actors other than the one that initiated it. The use case represents complete functionality. Individual actions that are part of overall functions should not be represented as a use case. This keeps use class diagrams high level and focused on user interactions with the system rather than on the individual tasks required for the user to interact with the system to accomplish a specific goal. Although the systems analyst is ultimately drawing the use case diagram, it is important to remember that the use case diagram is predominantly the user’s perspective on the things that take place. The use case diagram is not meant to lead directly to design, but rather to provide a flexible blueprint of what the design will need to include. Further decomposition by the systems analyst into other UML diagrams like the collaborative and sequence diagrams will show these interactions at a more granular level by which to transition to design.(6)
Drawn according to UML standards, the use case diagram is a square (representing the system boundary) with actors depicted as stick figures outside of it. Inside the square are ovals with descriptions of specific use cases such as “Place Order”. Multiple use cases can be depicted inside the diagram with lines connecting them to other use cases or to the actors outside the system. Lines connecting actors to the use cases within the system do not require arrows to show the direction of the relationship. However, lines between use cases within the diagram should denote the nature of the relationship between the use cases.
UML provides two additional relationships that can be used to structure use cases: include and extends. An include relationship depicts a necessary subroutine for the use case goal to be completed. It is depicted as a dotted line pointing from the primary use case outward to the includes use case.
The extends relationship is more peripheral, as it is not always required to complete the use case but is under certain circumstances necessary. To register for a special class requires the same process as registering for a class does, but it also requires the intervention of a professor to occur. The extends relationship is denoted by a dotted line from the extended case toward the primary use case.
Use case diagrams have relatively few symbols, so they are easy to draw by hand or by using Visio. They can be quickly referenced and understood by analysts and could even be shown to users without substantial difficulty to verify understanding of the domain. Changes to use case diagrams can be made easily and then quickly transposed to the other UML diagrams to reflect the necessary changes to the system.
Jacobson et al. suggest that the analyst asks simply:
Constantine and Lockwood (1999) suggest one way to identify use cases, or simply to identify use cases, is to identify potential services by asking your stakeholders the following questions from the point of view of the actors:
An example from the website www.agilemodeling.com suggests that from the point-of-view of the Student actor, you may discover that students:
Rosenberg and Scott suggest writing a user manual first in order to determine if the set of use cases is complete.(10) A user manual, even though the system has not been built yet, should list every function that the user would want to perform. From the lists of how to do things that typically fill user manuals, one can generate a reasonable set of use cases.
The power of the use case diagram consists in its ability to convey interactions between the users and the system at a sufficiently high level that it can be easily modeled in subsequent diagrams. However, the various potential scenarios by which users can interact with the system can abound to such a degree that use case diagrams become so numerous as to undermine their simplicity. Part of the reason for this multiplicity and confusion is that there is no established theory of how to write use cases.(11) Deciding upon the appropriate level of abstraction for the use case diagram can be a challenge.
Cockburn suggests five different levels of detail:
System extensibility can also be limited by driving component identification too closely off of use cases, thus causing system analysts to revert to functional decomposition.(13) The system components should be relevant enough to the use cases to fulfill their completion, but not specific to the point that they limit the system performance exclusively to the use case tasks. When use cases drive a model’s shape, the model effectively becomes a slave of the current functionality being addressed and no longer is a true representation of the business.(14) Modeling implies a change of the user’s activities in performing tasks, the change of which needs to be confirmed by the user.(15)
Changes in user requirements at later stages of product development require flexibility that must be allowed for in the diagrams derived from the use cases. It is very easy for use case modeling to become un-agile. To prevent this from happening, one needs to focus on creating artifacts that are just barely good enough, they don’t need to be perfect.(16)
Common functionality and identity in use cases across product lines allows for the development of platform architecture. By utilizing a set of reusable assets across a family of products, system analysts can save time and money. Rather than developing a product from scratch, system developers can customize a product within the product family to address the specific needs of an organization. The same iterative and incremental process use in OOSAD can be applied to product customization more quickly, cheaply (or profitably), and reliably than to product development. A similar approach is being used by the automotive industry currently toward what they also call “platforms”. Vehicle platform-sharing combined with flexible-manufacturing technology enables automakers to sharply reduce product development and changeover times, while modular design and assembly allow building a greater variety of vehicles from one basic set of engineered components.(17)
1. Kaindl, H.; Kramer, S.; Kacsich, R. “A Case Study of Decomposing
Functional Requirements Using Scenarios.” Third International
Conference on Requirements Engineering: 1998.
2. Malan, R. and D. Bredemeyer. “Functional Requirements and Use Cases”. http://www.bredemeyer.com/use_cases.htm
3. Booch, G., J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison Wesley. Upper Saddle River, NJ: 1999.
4. George, J., Batra, D., Valacich, J. and Hoffer, J. Object-Oriented Systems Analysis and Design. Pearson Prentice Hall. Upper Saddle River, NJ, 2004.
5. Marakas, George M. System Analysis and Design. McGraw-Hill Irwin. New York: 2006
6. Harris, David. Systems Analysis and Design for the Small Enterprise. Thomson Course Techonlogy. Boston: 2003.
7. Jacobson, I. M. Christerson, P.Jonsson, and G. Overgaard. Object-oriented Software Engineering: A Use-case Driven Approach. Addison-Wesley. Reading, MA: 1992.
8. Constantin, Larry L. and Lucy Lockwood. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley. Upper Saddle River, NJ: 1999.
9. Ambler, Scott W. “System Use Cases” http://www.agilemodeling.com/artifacts/systemUseCase.htm
10. Rosenberg, D. and K. Scott. Use Case Driven Modeling with UML. Addison-Wesley, Reading, MA: 1999.
11. Cockburn, A. “Structuring Use Cases with Goals.” http://alistair.cockburn.us/Structuring+use+cases+with+goals
12. Cockburn, A. Writing Effective Use Cases. Addison-Wesley, Reading, MA: 2001.
13. Meyer, Bertrand. OOSC2: The use case principle, Objected-Oriented Software. Construction 2nd ed. Naval Air Systems Command Systems Engineering Guide: 2003
14. Sam-Bodden, B. and Judd, C. Enterprise Java Development on a Budget. Apress: 2004.
15. Dzida, W. and R. Freitag. Making Use of Scenarios for Validating Analysis and Design. IEEE Transactions on Software Engineering. v.24 n.12 December 1998. p1182-1195.
16. Ambler, Scott W. “System Use Cases” http://www.agilemodeling.com/artifacts/systemUseCase.htm
17. Schlie, E., Yip, G. "Regional follows global: strategy mixes
in the world automotive industry", European Management Journal 18 (4):
343–354 (August 2000)
18. “Writing effective Use Case Examples” http://www.gatherspace.com/static/use_case_example.html