analysis. analysis -2 requirements artifacts define stakeholders business goals system functions...

Analysis

Analysis -2

Requirements Artifacts

Define

• 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

Information Needed Information Representation

Analysis -3

Actors

An actor is an external entity that interacts with the system

Analysis -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

Analysis -5

Use Case TemplateUse 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.}

Analysis -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 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:

Analysis -7

Good Foundation

Analysis -8

Use Case to Test Case

Instance 1

Instance n

Instance n+1

Instance n+m+1

Instance n+m+j

Instance n+m

Test case 1

Test case n

Test case n+1

Test case n+m+1

Test case n+m+j

Test case n+m

*

* A use case instance is often called a scenario

Analysis -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

Analysis -10

Complete Set of Actors

Identifying a complete set of actors means I will captureall of the user’s viewpoints

Analysis -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

Analysis -12

Impossible

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

Analysis -13

Parallel Levels of Abstraction

Requirements Artifacts Development Artifacts

Business requirementsfirst few levels of use cases

domain models

interface specificationslevel at which interface bindings areintroduced

application models

architectures

more detailsseveral more levels of use cases

detail designs

complete detailed specificationsfinal level of use cases

source code

Analysis -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

Analysis -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

Analysis -16

Use Case Hierarchy

• 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

Analysis -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

Analysis -18

Understanding Matures

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

Analysis -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

Analysis -20

Each Level is Complete

Use case 1.1 is a specific, more detailed, complete use case within thecategory of use cases defined by use case 1.

1. Define course policies

1.1 Define late policy 1.2 Define category weights

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

Analysis -22

Business requirements should be kept separate from interface

specifications

This is the idea of essential use cases - see bibliography

1

1

Analysis -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

Analysis -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

SystemInterface

Analysis -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

Analysis -26

Levels of Use Cases

• High Level

• Expanded (high) level

• Detail level (including exception and alternate courses of action)

• Abstract level (for common functionality)

Analysis -27

Boiling it down

• Essential use cases

• Concrete use case

• Abstract use case

Analysis -28

Essential Use Cases

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

1Larry Constantine, p70

Analysis -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

Analysis -30

Knowing Why Is Important

Analysis -31

It Took Joint Stars 2 Years Without the “WHY”

Analysis -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 actor’s goal

• Focus is on the details of the basic and alternative courses of action

Analysis -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

Analysis -34

Use Case Instance(Scenario)

Analysis -35

Test Everything

Requirements Artifacts Development Artifacts

Business requirementsfirst few levels of use cases

domain models

interface specificationslevel at which interface bindings areintroduced

application models

architectures

more detailsseveral more levels of use cases

detail designs

complete detailed specificationsfinal level of use cases

source code

Analysis -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

Analysis -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 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

Analysis -38

Case of the Useless Use Cases

Case Study

Analysis -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

Analysis -40

Consequences

• Poor quality requirements

• Poor quality designs – “functional decomposition” in “object

clothing”

• Wasted time and effort

Analysis -41

Framework Team

Analysis -42

Send Us Your Use Cases

Analysis -43

By the Book

Analysis -44

Recycling Machine

Analysis -45

12,386 Use Cases

Analysis -46

Filed

Analysis -47

12,386 Useless Use Cases

• Wrong level of abstraction

• 1/2 Million $$

• Morale cost

• Confidence in the framework team was eroded

Analysis -48

Really Sad Part

• Not only too detailed

• Typically full of errors

• Almost always have to be redone

:-(

Analysis -49

Continued Information

For Articles Regarding Use Cases

and E-Mail Updatesregister at

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

Analysis -50

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.

Use Case Bibliography

Analysis -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

Analysis -52

Outline





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

Discover

Analysis -54

Domain Analysis Process

• High-level software requirements

• Domain Knowledge

• Existing Domain Models

• New Domain models• Updated Domain Models

DomainAnalysis

Define

Analysis -55

Domain Analysis -- Steps & Deliverables

StepGain initial understanding of application

requirementsDetermine domain limitsIdentify domain actors and their basic interactions

with domainDetermine the activities of interest within the domainIdentify key concepts in domainClarify meaning of domain key conceptsDetermine static relationships between all key

domain objectsRecord standardized dynamic behaviorRecord domain algorithmsSummarize knowledge of domain

DeliverableInitial problem statement

Domain Dimensions and Change CasesUse Case Diagram

Domain activities (Domain-level use-cases)List of classesClass description cardsDomain class diagram

State transition diagramsSequence diagramsDomain digest

Analysis -56

The classes represent domain concepts, NOT software components!

Analysis -57

Analysis -58

RUP Vocabulary

• Domain Analysis• Business Analysis• Business Engineering

Analysis -59

Outline





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

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

Analysis -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

Analysis -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

Analysis -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

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

Application.

Analysis -66

Outline





Analysis -67

RUP Summary

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

Core Workflows Phases

Iterations

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

Analysis -68

Examining Core Workflows

Inception Elaboration Construction Transition

Requirements

Analysis

Core Workflows Phases

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.

Analysis -69

Which Comes First?

• Functional Requirements (Use cases)• Domain Analysis

Analysis -70

Outline





Analysis -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

Analysis -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

Analysis -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

• Don’t let design or implementation considerations creep into the domain model

analysis. analysis -2 requirements artifacts define stakeholders business goals system functions...

Documents