Use Case-based Requirements
This chapter gives an overall introduction to documenting requirements using use cases.
In this chapter, we will explain the following:
the symbols found in a use case diagrams
the relationships between the symbols in a use case diagram
the textual description of a use case, the use case flow of events
It is quite likely that you have written code in an object-oriented language, such as Java
In these object-oriented languages, you have come to create your programs in
terms of classes where each class has its own data (via variables/attributes) and its own
behavior (via the class methods).
In your programs, you create instances of these classes,
As your program runs, these objects interact with each other to implement
the system functionality.
In this chapter we will discuss a means of documenting your stakeholder functional
requirements in a way that will more easily lead you to discover what classes you will
need to implement.
This approach is called the
Christerson et al., 1992).
When you document your requirements using use cases, these
use cases are then valuable during the next steps in your project development – such as in
the design and testing activities.
Also, it will be easier to write your user manual if you
have documented your requirements by means of use cases.
When we document requirements using use cases, we use textual description along with
use case diagrams.
The use case diagram is a part of the Unified Modeling Language
(Rumbaugh, Jacobson et al., 1999), more commonly referred to as UML. In this chapter,
we will first introduce you to UML.
Then, we will show you how to document your
requirements using use cases.
An Introduction to UML
UML is a modeling language or graphical/diagrammatic notation for object-oriented
programming – a way to express the “blueprints” of your system.
Within UML, there are
several types of diagrams. Some of them are:
Use case diagrams for requirements
State diagrams for object-oriented analysis
Class diagrams and sequence diagrams for object-oriented design
As a software engineer, you need to become well-versed in these UML diagrams.
head towards your professional life, your peers will simply assume that you know these
When you brainstorm together, your co-workers will quickly draw one of
these diagrams on a whiteboard without explaining the symbols or notations, fully
expecting that you understand.
Or, you might receive UML-based requirements, analysis,
or design documents that you will need to work with.