Analysis

1

• Analysis

2
Requirements Artifacts
Information Needed Information Representation

• Stakeholders
• Business goals
• System functions
• Technical system requirements
• Fundamental domain concepts and relationships
• Domain algorithms
• Domain level state behavior
• application behavior, look and feel

• Enhanced actor model
• Textual descriptions - must be traced to the
  architecture
• Use case hierarchy
• Textual descriptions cross referenced to the use
  cases
• Domain class model
• Interaction diagrams
• state transition diagrams
• prototypes

3
Actors
An actor is an external entity that interacts
with the system
4
Definition

• When an actor instance uses a system, it will
  perform a behaviorally related sequence of
  transactions with the system. We call such a
  sequence a use case.
• A use case is a specific way of using a system

5
Use Case Template
Use Case ID This should be coded to identify
the owning team and the level of the use
case Use Case Type Essential, Concrete,
Abstract Use Case Name Short descriptive
phrase Basic Course This is a complete
description of the use. Each subsection is
explained below. Actor Which actor from the
actor model initiates this course of the use
case? Pre-conditions Requirements on the
state of the system prior to this use being
valid. Description Numbered flow of events 1
The user initiates an action by 2 The system
responds by... In this section reference is
made to sub-use cases that this use case
uses. Relevant requirements Reference to other
relevant requirements documents. Post-conditions
This describes the state of the system
following the successful completion of this use.
Affects on other systems and actors may also be
described. Alternative Courses Structured like
the basic course Rationale Explanation of why
this requirement is present in the system. This
field is typically only used for essential use
cases Extensions This section presents
variations on this use case that specializes
it. It presents those use cases that have an
extends relation with the current use
case. Exceptions This section describes all
error conditions that can arise in the use
case. Concurrent Uses This use can occur
concurrently with the uses listed in this
section. Related Use Cases use cases that are
either usually performed just before or after the
current use.
6
Use Case Template(Continued)
Decision Support Frequency How often will this
use of the system occur? This field is combined
with the criticality field to determine the
number of tests that will be used to test the
functionality. It may also be used in certain
design decisions. Criticality How necessary is
this use to the successful functioning of the
program from a users perspective. This field is
used to assist in determining the extent to which
the use will be tested. Risk The project risk
associated with providing this use. This is used
in project planning. Often riskier uses will be
implemented early to provide sufficient recovery
time. -------------------------------------------
--------------------------------------------------
------------------------ Modification History --
Follow the standard corporate document
versioning template Owner Initiation date
Date last modified
7
Good Foundation
System Test Process
WELL DEVELOPED USE CASES
8
Use Case to Test Case

Instance 1
Test case 1
Basic Course
...
...
Test case n
Instance n
Instance n1
Test case n1
Alternative 1
Use Case
...
...
Test case nm
Instance nm
Alternative 2
Instance nm1
Test case nm1
...
...
Test case nmj
Instance nmj
...
...
...

A use case instance is often called a scenario
9
No Silver Bullet

• Use cases have become the standard for
  documenting functional requirements, however,
• Use cases are no more than a structured format
  for gathering and expressing requirements
• Good format is helpful but not sufficient

10
Complete Set of Actors
Identifying a complete set of actors means I will
capture all of the users viewpoints
What if the actors don't understand the true
business needs?
What if the development team misunderstands the
use cases?
11
Useful Use Cases

• Good use case development relies on knowledge
  gained during domain analysis
• To understand a domain it is useful to to know
  the actors and the major domain activities

12
Impossible

• Analysts cant create correct, useful use cases
  if they dont understand the domain.
• This is as true for the client as for the
  development team
• Developers cant implement correct use cases
  correctly if they dont understand the domain.

Never assume the client knows and can articulate
real business needs
13
Parallel Levels of Abstraction
14
Fundamental Principles of Requirements Gathering

• Requirements should be organized hierarchically
• Use cases are best developed iterativaly and
  incrementally (the same way as the rest of the
  system deliverables)
• Hierarchical classification of use cases need
  not, and should not, be functional decomposition
• Business requirements should be kept separate
  from interface specifications
• Do not directly derive your design from your use
  cases

15
Requirements should be organized hierarchically
UC 1 UC1.1 UC1.2 UC1.3 UC1.4
UC1.10 UC1.1.1 UC1.1.2 UC1.1.3
UC1.10.1 UC 1.1.1.1 UC1.1.1.2 UC1.1.1.3
UC1.10.1.1
UC 2
UC3 UC2.1 UC2.2 UC2.3 UC2.4
UC2.10 UC2.1.1 UC21.1.2 UC2.1.3
UC2.10.1 UC2.1.1.1 UC2.1.1.2 UC2.1.1.3
UC2.10.1.1
16
Use Case Hierarchy

• Manage complexity
• Top level lt 12
• No level should have more than 5 to 10 times the
  number of use cases than in the previous level
• Allows for testing of models, architectures,
  etc
• Each level should be complete

17
Use cases are best developed iterativaly and
incrementally

• The only way to get quality is to iterate
• Requirements change while the system is being
  developed
• As the development team better understands the
  domain, the are better able to review the use
  cases

18
Understanding Matures

• You cant get the use cases totally correct at
  the beginning of the project

19
Hierarchical classification of use cases need not
and should not be functional decomposition
UC 1 - customer makes purchase UC 1.1 - scan UPC
UC 1.2 - add tax UC 1.3 - calculate total UC
1.4 - accept payment UC 1.5 - make change
20
Each Level is Complete
1. Define course policies
1.1 Define late policy
1.2 Define category weights
Use case 1.1 is a specific, more detailed,
complete use case within the category of use
cases defined by use case 1.
21
Use Case 1

• Customer buys soda at vending machine
• customer inserts enough coins for purchase
• machine displays total deposited
• customer pushes button to indicate selection
• machine dispenses soda can to bottom tray and
  change to change tray
• customer retrieves soda and change

Most OO teams incorrectly think the first level
of use cases should jump directly to interface
specifications.
22
Business requirements should be kept separate
from interface specifications
1
Accept Payment
Electronic Cash
1
This is the idea of essential use cases - see
bibliography
23
How?

• Keep first n levels of the use case hierarchy
  interface neutral
• Have a separate field in the use case template
  for the interface binding

24
Do not directly derive your design from your use
cases

• Use cases DO describe sequences of actions that
  actors follow in using the system
• Use cases must NEVER specify what steps the
  system takes internally in responding to the
  stimulus from an actor

Use Cases
architecture
System
Interface
25
Types of Use Cases

• Concrete use case
• Abstract use case
• Complete use case
• Essential use case
• Partial use case

• High-level use case
• System-level end-to-end use case
• Functional sub-use case

26
Levels of Use Cases

• High Level
• Expanded (high) level
• Detail level (including exception and alternate
  courses of action)
• Abstract level (for common functionality)

27
Boiling it down

• Essential use cases
• Concrete use case
• Abstract use case

28
Essential Use Cases

• are uncontaminated by presumptions about the
  design of an interface that is yet to be designed

1
1
Larry Constantine, p70
29
Essential Use Case TemplateView from 500 -
20,000 feet

• Interface neutral
• Focus on the basic course (as opposed to
  alternative courses and exceptions)
• Basic course narrative is short prose focusing on
  goals of the actor
• Includes a Rationale field - Explanation of why
  this is a business requirement

30
Knowing Why Is Important
31
It Took Joint Stars 2 Years Without the WHY
32
Concrete Use Case(In the Trenches)

• Interface-specific, complete end-to-end set of
  interactions between an actor and the system to
  accomplish an actors goal
• Focus is on the details of the basic and
  alternative courses of action

33
Abstract Use Case(Reusable Use Case)

• Sometimes called a partial use case, or
  functional sub-use case
• Captures partial set of interactions that is
  common across multiple concrete use cases
• Focus is on common interface-specific details

34
Use Case Instance(Scenario)
Sue inserts 1.00, selects and recieves a diet
coke and 0.15 change
35
Test Everything
36
Change Cases

• Change cases are use case that the architecture
  must support, but that will not be built as a
  part of the current project

?
How does one test for extensibility?
37
Use Cases - Summary

• Use cases are an important part of the
  development process
• Most teams do not get as much value from use
  cases as they should
• One cant build good use cases without good
  domain knowledge
• One size doesnt fit all. Configure your use case
  process carefully and manage it wisely

38
Case of the Useless Use Cases
Case Study
39
Project X

• Over 1000 software developers assigned to the
  project
• 3 continents
• near-simulations development of a
  multi-level framework with numerous applications
  built on the framework

40
Consequences
If use cases misused
then

• Poor quality requirements
• Poor quality designs
• functional decomposition in object clothing
• Wasted time and effort

41
Framework Team
Architecture team realized they would need to
understand the scope of the requirements
42
Send Us Your Use Cases
43
By the Book
44
Recycling Machine
45
12,386 Use Cases
What do you suppose the framework team
did with all of these use cases?
46
Filed
47
12,386 Useless Use Cases

• Wrong level of abstraction
• 1/2 Million
• Morale cost
• Confidence in the framework team was eroded

48
Really Sad Part
-(

• Not only too detailed
• Typically full of errors
• Almost always have to be redone

49
Continued Information
For Articles Regarding Use Cases and E-Mail
Updates register at http//www.korson-mcgregor.com
/usecase.htm
50
Use Case Bibliography

• Berard, Edward V. Be Careful with Use Cases The
  Object Agency, Inc. Publications On-Line,
  www.toa.com/pub/html/use_case.html.
• Cockburn, Alistair, Using Goal Based Use
  Cases, JOOP, The Journal of Object-Oriented
  Programming, November/December 1997, p. 56-62.
• Constantine, Larry, The Case for Essential Use
  Cases, Object Magazine. May 1997, p. 72, 70
• DSouza, Desmond Frances, and Alan Cameron Wills,
  Objects, Components, and Frameworks with UML, The
  Catalysis Approach, Addison Wesley, Reading,
  Massachusetts, ?1999.
• Fowler, Martin with Kendall Scott, UML Distilled,
  Applying the Standard Object Modeling Language,
  Addison Wesley, Reading, Massachusetts, ?1997.
• Jacobson, Ivar, Grady Booch and James Rumbaugh,
  The Unified Software Development Process, Addison
  Wesley, Reading, Massachusetts, ?1999.
• Jacobson, Ivar, Grady Booch and James Rumbaugh,
  The Unified Modeling Language Reference Manual,
  Addison Wesley, Reading, Massachusetts, ?1999.
• Jacobson, Ivar, Object Oriented Software
  Engineering, A Use Case Driven Approach, Addison
  Wesley, Reading, Massachusetts, ?1992.
• Korson, Timothy D., Constructing Useful Use
  Cases, Component Strategies, March 1999, p.
  27-28.
• Korson, Timothy D., Configuring A Use Case
  Process, Component Strategies, September 1998,
  p. 20-21
• Korson, Timothy D., The Misuse of Use Cases
  Object Magazine, May 1998, p. 18, 20.
• Schneider, Geri and Winters, Jason P., Applying
  Use Cases, A practical Guide, Addison Wesley,
  ?1998.

51
Domain Analysis

• What is domain analysis
• Why is it important
• What is the role of domain analysis in RUP
• What are the practical issues involved
• best practices
• pitfalls

52
Outline

• What is domain analysis
• Why is it important
• What is the role of domain analysis in RUP
• What are the practical issues involved
• best practices
• pitfalls

53
Domain Analysis

• Domain analysis is a process whose goal is to
  understand the problem domain, the context or
  environment in which the problem exists. Domain
  models are sometimes called business models.
• We identify concepts, relationships, behavior and
  algorithms that domain experts identify as
  important in the problem domain
• We use the concepts and relationships we find in
  the problem domain as the components and
  relationships in the system being developed.

54
Domain Analysis Process

• High-level software
• requirements
• Domain Knowledge
• Existing Domain Models

Domain Analysis

• New Domain models
• Updated Domain Models

55
Domain Analysis -- Steps Deliverables

• Step
• Gain initial understanding of application
  requirements
• Determine domain limits
• Identify domain actors and their basic
  interactions with domain
• Determine the activities of interest within the
  domain
• Identify key concepts in domain
• Clarify meaning of domain key concepts
• Determine static relationships between all key
  domain objects
• Record standardized dynamic behavior
• Record domain algorithms
• Summarize knowledge of domain

• Deliverable
• Initial problem statement
• Domain Dimensions and Change Cases
• Use Case Diagram
• Domain activities (Domain-level use-cases)
• List of classes
• Class description cards
• Domain class diagram
• State transition diagrams
• Sequence diagrams
• Domain digest

56
The classes represent domain concepts, NOT
software components!
57
(No Transcript)
58
RUP Vocabulary

• Domain Analysis
• Business Analysis
• Business Engineering

59
Outline

• What is domain analysis
• Why is it important
• What is the role of domain analysis in RUP
• What are the practical issues involved
• best practices
• pitfalls

60
Why is Domain Analysis Important?

• Getting the right requirements
• Getting the requirements right
• Keeping everyone on the same page
• Development of frameworks, components, and other
  multi-use assets
• Because requirements change.

The biggest problems in software development have
to do with requirements, not technology!
61
Why is Domain Analysis Important?Getting the
Right Requirements

• Never assume the client knows and can articulate
  true business needs
• Each actor has their own limited point of view
• Doctors, nurses, lab technicians, administrators
• The process of domain analysis helps the project
  stakeholders to understand what they really need.

62
Why is Domain Analysis Important?Getting the
Requirements Right

• Developers often misunderstand written
  requirements understanding the domain models
  helps them correctly read between the lines.

Case Study SEI Lecture Series radar signal
processing
63
Why is Domain Analysis Important?Keeping
Everyone on the Same Page

• Case Study The use case calls for an accountant
  to be able to print a journal
• Case Study NASA, Ease of bringing new employees
  up to speed

64
Why is Domain Analysis Important? Development of
Multi-Use Assets

• Domain analysis is concerned with areas of
  knowledge and families of systems.
• This type of analysis is necessary for the
  identification of multi-use assets
• Components
• Frameworks
• Patterns

65
Why is Domain Analysis Important? Because
Requirements Change

• Because of the constant change in the external
  business world, technology, corporate priorities,
  business strategies, and domain understanding -
  system requirements are always changing.

.
66
Outline

• What is domain analysis
• Why is it important
• What is the role of domain analysis in RUP
• What are the practical issues involved
• best practices
• pitfalls

67
RUP Summary
Phases
Core Workflows
Inception Elaboration Construction Transition
Requirements Analysis Design Implementation Te
st
Preliminary iteration(s)
Itr. 1
Itr. 2
Itr. n
Itr. n1
Itr. n2
Itr. m
Itr. m1
Iterations
Figure 11.2 page 296 The United Software
Development Process, Jacobson, Booch, Rumbaugh
68
Examining Core Workflows
Phases
Core Workflows
Inception Elaboration Construction Transition
Requirements Analysis
Includes both domain analysis and use case
development
Adds detail and structure to the requirements
deliverables
Unfortunately, in the original RUP book, domain
analysis is viewed as optional.
69
Which Comes First?

• Functional Requirements (Use cases)
• Domain Analysis

70
Outline

• What is domain analysis
• Why is it important
• What is the role of domain analysis in RUP
• What are the practical issues involved
• best practices
• pitfalls

71
Best Practices

• Use the domain models to develop a shared mental
  model among the team members and external
  stakeholders
• Spend at most 3-4 weeks on the first cut of the
  domain models
• Involve domain experts other than clients
• Have the domain models widely reviewed

72
Pitfalls

• Not doing domain analysis
• Neglecting the dynamic models
• Not bounding the domain correctly
• Design issues creeping into the domain models
• Analysis paralysis
• Neglecting to keep the domain models up to date

73
Domain Analysis Summary

• The Rational Unified Process incorrectly treats
  domain analysis as optional.
• Without domain analysis, you will not get the
  correct requirements, nor get the requirements
  correct.
• You must have the courage to formally bound the
  domain
• Insist that the top level use cases are complete
• Dont let design or implementation considerations
  creep into the domain model