Analysis - PowerPoint PPT Presentation

Business goals

System functions

Technical system requirements

Fundamental domain concepts and relationships

Domain algorithms

Domain level state behavior

application behavior, look and feel

Define

Information Needed Information Representation

• 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

An actor is an external entity that interacts with the system

• 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

• 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.}

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 user’s 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:

System Test Process

WELL DEVELOPED USE CASES

*

Test case 1

Instance 1

Basic Course

...

...

Test case n

Instance n

Test case n+1

Instance n+1

Alternative 1

Use Case

...

...

Test case n+m

Instance n+m

Alternative 2

Test case n+m+1

Instance n+m+1

...

...

Test case n+m+j

Instance n+m+j

...

...

...

*

A use case instance is often called a scenario

• 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

Identifying a complete set of actors means I will capture

all of the user’s viewpoints

What if the actors don't understand the true business needs?

What if the development team misunderstands the 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

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

Never assume the client knows and

can articulate real business needs

• 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

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

• Manage complexity
• Top level < 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

• 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

• You can’t get the use cases totally correct at the beginning of the project

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

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.

• 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.

1

Accept Payment

Electronic Cash

1

This is the idea of essential use cases - see bibliography

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

• 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

Interface

System

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

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

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

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

1

1

Larry Constantine, p70

• 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

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

• 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

Sue inserts $1.00, selects and recieves a diet coke and $0.15 change

• 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?

• 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 can’t build good use cases without good domain knowledge
• One size doesn’t fit all. Configure your use case process carefully and manage it wisely

Case Study

• 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

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

If use cases misused

then

Architecture team realized they would need to understand

the scope of the requirements

What do you suppose the framework team

did with all of these use cases?

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

:-(

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

For

Articles Regarding Use Cases

and E-Mail Updates

register at

http://www.korson-mcgregor.com/usecase.htm

• 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
• D’Souza, 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.

• 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

• 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

Discover

• 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.

Define

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

Domain

Analysis

• New Domain models
• Updated Domain Models

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

The classes represent domain concepts, NOT software components!

• Domain Analysis
• Business Analysis
• Business Engineering

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

• 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!

• 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.

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

Case Study: SEI Lecture Series – radar signal processing

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

• 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

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

.

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

Phases

Core Workflows

Inception Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Test

Preliminary iteration(s)

Itr. #1

Itr. #2

Itr. #n

Itr. #n+1

Itr. #n+2

Itr. #m

Itr. #m+1

Iterations

*Figure 11.2 page 296 “The United Software Development Process, Jacobson, Booch, Rumbaugh

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.

• Functional Requirements (Use cases)
• Domain Analysis

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

• 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

• 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

• 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
• Don’t let design or implementation considerations creep into the domain model