A Use Case-Driven Approach to
Requirements Gathering
Materials gathered from chapter title
(above) – Kulak and Guiney and Use Case
Driven Object Modeling – Doug
Rosenburg and other personal notes.
1
Guiding Principles to
Requirements Gathering
 Reduce
Risk
 Focus on business interactions
 Reduce volume
 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.
2
Four Steps in Gathering Requirements


Requirements are created iteratively.
Requirements specs will change constantly due to reliance on
other peoples ideas about the application.
– other artifacts may tie back to requirements, but requirements can
only tie back to fuzzy ideas.

Author’s approach to use cases:
– outlining, widening, focusing, touching up.
– four ‘mind sets’ Not always all required.
– Chapters 4-7 cover these in detail: façade, filled, focused, and
finished.
– Various authors use different ‘names’ for the evolution of use cases.
3
Use Case - Driven

The Use Case model is at the conceptual center of the
entire approach because it drives everything else that
follows.
– Developed in conjunction with Domain Model
– Drives Analysis Model (preliminary design)
– Drives Interaction diagrams – 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.
4
Use Cases:
 Use
Cases are sequences of actions that an actor
(usually a person, but perhaps 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
 Document Use Cases via Use Case Narrative or
Use Case Description - Scenarios
5
Early Deliverables


Most efforts start with Business Modeling and capturing
the Domain via Domain Modeling, Glossary, and
associated artifacts most of which come from the Domain
Modeling Discipline.
Related artifacts include:
–
–
–
–



Risk Analysis
Business Rules
Vision Statements
Environmental Constraints and more…
There are a number of approaches…
Most uses cases are defined during the same iteration
But they are developed via iterations that provide
increasing levels of detail – required to drive the entire
development process.
6
Statement of Work
How the work is going to be accomplished – work
plans, assignments, internal deliverables, etc.
 Represents a contract between the developers and
the users and/or a contract between a consulting
company and the customer.
 See textbook (p.57) for details.
 It is generally more than just bullets – can be
bullets, but should have more ‘assignment’
details…
 I call the Statement of Work the Anticipated
Deliverables. But Statement of Work is a more
universally-accepted term.

7
Risk Analysis
 A list
of risks that may impact the successful
development of the application.
 Prioritized 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 in each
deliverable in the SOW – particularly early on in
the project.
8
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.
 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.
9

More on Business Rules
may be conditions that must be true/false
 action restricting – conditions prohibiting an
action (don’t accept a bad check…)
 action triggering
 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
possible.

See Use Case textbook, Table 3.3, p. 61 for
examples.
10
Prototype








Mock-up of user interface.
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 understood.
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…)
Demonstration is great for locking in presentation aspects of
requirements with users
After closure on screens, this greatly facilitates developing Use
Cases that ‘realize’ descriptions of the interface just demonstrated.
Also greatly facilitates identification of objects (along with Use11
Cases) for our analysis modeling effort (preliminary design).
Prototype
 Prototype
can be simple.
 Generic symbols (buttons may later become drop down
menu….)
 Can be boxes within boxes.
 Should contain some kind of windows navigation
diagrams and perhaps action resulting in navigating to a
new menu/window.
 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
12
requirements!!
Warning
 “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!!
13
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 in some cases nonfunctional requirements. (performance, extensibility,
maintainability, backup, recovery, security, persistency,
distribution, etc.) But these latter requirements are normally
documented in a Supplementary Specs document…
 Good for ensuring requirements traceability – because they
are used for design, testing, construction, delivery, and 14
more.
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 has several steps before responding
to the user, this is a tip off that we are
undertaking too much designing…STOP!
 These are still the WHATS of the application!
15