A Use Case-Driven Approach to
Materials gathered from Chapter 3 (above)
– Kulak and Guiney and
Use Case Driven Object Modeling – Doug
Rosenburg and other personal notes.
Guiding Principles to
Focus on business interactions
Reduce duplicates and inconsistencies
Create requirements that users can understand easily
Create requirements that are useful to designers,
developers, and project managers
Leave a requirements trail
Leave design until later
Keep the plan in mind.
Mission, Vision, Values
Many think this is the first document. Arguable. But
certainly worth thinking about:
Vision: What will the end product be?
– Future. Vision of operations and filling needs…
Mission: What will with project do?
– Immediate; now. How will it work? Will it fulfill the
needs of the stakeholders?
Values: What principles will guide the project while
they do what they will do and build what will be…
– What principles underpin what we do? Organization;
seeking quality products; integrity; communications, etc.
Steps in Gathering Requirements
Requirements are created iteratively.
– Iteration means doing things over and over; enriching the
value of the artifacts, etc.
– Increments refer to the gradual, piece by piece evolution
of the application; building on earlier work.
Requirements specs will change frequently due to
reliance on other peoples ideas about the application.
– other artifacts may tie back to requirements,
– sometimes only tie back to fuzzy ideas.
We consider the Vision Document (which might
include Mission, Vision, Values, and a host of
other items, such as scope, objective, overview,
user demography, constraints, assumptions,
staffing, costs, environment, etc.) as a primary
– This defines the scope and general overview of work to
– All these documents tied to vision and initial business
modeling include risk analyses, business rules, etc.
– These are essential artifacts.
Steps - continued Steps - continued
– Used to identify the user interface – NO MORE!
– Will identify requirements missed.
– Recognize emphasis is on requirements not the
specific widgets (buttons, etc.) used.
– These are implementation details which will be
decided upon later.
Steps: Use Case - Driven
The Use Case model is at the conceptual center of the entire
approach because it drives everything else that follows.
– Oftentimes developed in conjunction with Domain Model because the
text of the Use Case supports development of the Domain Model.
» Helps to identify nouns (entities and attributes) and verbs (responsibilities)
– Drives Analysis Model (preliminary design)
– Drives Interaction diagrams (ahead) – refine analysis model into a
detailed design model using objects identified in creating the analysis
model and showing how messages flow between objects within use cases.
– Requirements Tracing – involves connecting user requirements with use
cases and classes.
Use Cases drive entire development effort.
Use Cases are sequences of actions that an actor
(usually a person, but certainly can be an external
entity like another system or a device) performs
with an expectation of achieving a particular
result; gets value.
Always use present tense very in active voice.
Model Use Cases via Use Case Diagrams
Capture Use Cases (that is, the interactions) via
Use Case Narrative (Use Case „Scripts‟)
Let‟s review and add some detail:
Most efforts start with a Business Modeling effort (domain analysis) and the
capturing the Domain via Domain Modeling, Glossary, and associated
Related artifacts typically include some kind of vision document that include:
– Risk Analysis (may be included in Vision Document or as an adjunct artifact)
– Business Rules (see textbook page 61-62) for more examples.
– Vision Statements – short encapsulating statements outlining „vision.‟
– Environmental Constraints and more…
There are a number of approaches…
Most uses cases are defined during the same iteration
Typically a first cut of key use cases may be developed as part of the
Inception Phase – generally around 20% of use cases (key ones)
But they are refined via subsequent iterations to provide increasing levels of
These details are absolutely required to drive the entire development process.
Statement of Work
Most development projects have some kind of Statement
of Work (SOW) How the work is going to be
accomplished – work plans, assignments, internal
Represents a contract between the developers and the
users and/or a contract between a consulting company
and the customer.
See textbook for details.
It is generally more than just bullets – can be bullets,
but should have more ‘assignment’ details…
A list of risks that may impact the successful
development of the application.
You now need to revisit these and prioritize by
impact. (probability of occurrence * cost if
occurs); other formulas
Provides data as to whether the development
effort should start/proceed.
Risk MUST be addressed and mitigated.
Risk is consistently re-addressed as part of
assessment following every iteration
Business Rules Artifact
Business Rules are both written and unwritten rules that
govern how the company does business.
– relate to the specific application only
– Examples: discounts to seniors; discounts if order is > some
magic number; corporation discounts; …
We use use cases and business rules very closely.
Use Case templates should have a Business Rules
„attribute‟ (row) that cites „references‟ to any business
rules that is associated with the use case
While Use Cases address the functional requirements by
covering interactions between the client and the
application, these interactions are often governed by
business rules that dictate the environment and constraints
within which the application operates. 13
Closer Look on Business Rules
May be conditions that must be true/false
Action restricting – conditions prohibiting an action
(don‟t accept a bad check…)
Inferences – drawing a conclusion from conditions that
may be/become true
Calculations – formulas / discounts. etc.
Must be atomic!!
– means must be stated at the finest level of granularity
As stated: see Use Case textbook, Table 3.3, p. 61 for
Mock-up of user interface. Storyboarding…
Graphical or pictures clearly and perhaps interactively.
Introduced now; refined later after the requirements have stabilized a
bit. Avoids temptations to proceed solving problems before they are
Prototype demonstrates a „proof of concept‟
It also forms the rough basis for a user manual – as if the prototype
were a working system…
– Prototype should be „rapid.‟
– Means ignore many alternatives (exceptions…)
After closure on screens/windows, this greatly facilitates locking in
the Use Cases that „realize‟ descriptions of the interface just
Also greatly facilitates identification of boundary objects (along with
Use Cases) for our analysis modeling effort (preliminary design). 15
Prototype can be simple.
Generic symbols (buttons may later become drop down
menu….not terribly important at this time.)
Should contain some kind of windows navigation
diagrams and perhaps action resulting in navigating to a
Can link your screen designs to your use cases – either
manually or in context of a visual - modeling tool
Coupling between screens and text is intuitive….
Be careful: Your use case text (coming) should not
include too many presentation details, since these are
design considerations, and we are really trying to lock in
requirements – not show implementation.
“Whether you use prototyping, screen mockups, or the results of
mining legacy user manuals, it‟s important that you do a
thorough job before you start writing use case text. If you don‟t,
you could end up spending a lot of extra time trying to pin down
what your users expect to be doing with the new system.”
Don‟t try to write use cases until you know what the users will
actually be doing!!
Great way to learn this is through user interface prototyping.
Note: some advocate building use case text and prototypes
(also domain model) at the same time or „near‟ the same time, in
that they can act as checks (validation) on each other.
Role of Use Cases
The Use Cases are clearly the major artifacts of
Requirements Gathering efforts.
Use Cases – great for communications
– contain the essence of desired interactions.
– no jargon as found in DFDs, ERDs, etc.
Particularly good for Functional and to a lesser degree (in
some cases) non-functional requirements. (performance,
extensibility, maintainability, backup, recovery, security,
persistency, distribution, etc.) But these latter requirements
are normally documented in a Supplementary Specs
Good for ensuring requirements traceability – because they 18
are used for design, testing, construction, delivery, and ...
Role of Use Cases
When used to drive the lifecycle, they assure
stakeholders that all use cases are being
addressed in the development effort.
Use cases discourage premature design. If the
use cases narrative has several steps before
responding to the user, this is a tip off that we
are undertaking too much designing…STOP!
Remember: these are still the WHATS of the