analysis l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Analysis PowerPoint Presentation
Download Presentation
Analysis

Loading in 2 Seconds...

play fullscreen
1 / 73

Analysis - PowerPoint PPT Presentation


  • 130 Views
  • Uploaded on

Analysis. Stakeholders Business goals System functions Technical system requirements Fundamental domain concepts and relationships Domain algorithms Domain level state behavior application behavior, look and feel. Define. Requirements Artifacts.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Analysis' - napoleon


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
requirements artifacts
Stakeholders

Business goals

System functions

Technical system requirements

Fundamental domain concepts and relationships

Domain algorithms

Domain level state behavior

application behavior, look and feel

Define

Requirements Artifacts

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
actors
Actors

An actor is an external entity that interacts with the system

definition
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
use case template
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.}
use case template continued
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:

good foundation
Good Foundation

System Test Process

WELL DEVELOPED USE CASES

use case to test case
Use Case to Test Case

*

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

no silver bullet
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
complete set of actors
Complete Set of Actors

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?

useful use cases
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
impossible
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.

Never assume the client knows and

can articulate real business needs

fundamental principles of requirements gathering
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
requirements should be organized hierarchically
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

use case hierarchy
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
use cases are best developed iterativaly and incrementally
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
understanding matures
Understanding Matures
  • You can’t get the use cases totally correct at the beginning of the project
hierarchical classification of use cases need not and should not be functional decomposition
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

each level is complete
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.

use case 1
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.

business requirements should be kept separate from interface specifications
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

slide23
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
do not directly derive your design from your use cases
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

Interface

System

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

Types of Use Cases
levels of use cases
Levels of Use Cases
  • High Level
  • Expanded (high) level
  • Detail level (including exception and alternate courses of action)
  • Abstract level (for common functionality)
boiling it down
Boiling it down
  • Essential use cases
  • Concrete use case
  • Abstract use case
essential use cases
Essential Use Cases
  • “are uncontaminated by presumptions about the design of an interface that is yet to be designed”

1

1

Larry Constantine, p70

essential use case template view from 500 20 000 feet
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
concrete use case in the trenches
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
abstract use case reusable use case
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
use case instance scenario
Use Case Instance(Scenario)

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

change cases
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?

use cases summary
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
project x
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
consequences
Consequences
  • Poor quality requirements
  • Poor quality designs
    • “functional decomposition” in “object clothing”
  • Wasted time and effort

If use cases misused

then

framework team
Framework Team

Architecture team realized they would need to understand

the scope of the requirements

12 386 use cases
12,386 Use Cases

What do you suppose the framework team

did with all of these use cases?

12 386 useless use cases
12,386 Useless Use Cases
  • Wrong level of abstraction
  • 1/2 Million $$
  • Morale cost
  • Confidence in the framework team was eroded
really sad part
Really Sad Part

:-(

  • Not only too detailed
  • Typically full of errors
  • Almost always have to be redone
continued information
Continued Information

For

Articles Regarding Use Cases

and E-Mail Updates

register at

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

use case bibliography
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
  • 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.
domain analysis
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
outline
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
domain analysis53

Discover

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.
domain analysis process

Define

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

Domain

Analysis

  • New Domain models
  • Updated Domain Models
domain analysis steps deliverables
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

rup vocabulary
RUP Vocabulary
  • Domain Analysis
  • Business Analysis
  • Business Engineering
slide59

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
why is domain analysis important
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!

why is domain analysis important getting the right requirements
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.
why is domain analysis important getting the requirements right
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

why is domain analysis important keeping everyone on the same page
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

why is domain analysis important development of multi use assets
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
why is domain analysis important because requirements change
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.

.

slide66

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
rup summary
RUP Summary

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

examining core workflows
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.

which comes first
Which Comes First?
  • Functional Requirements (Use cases)
  • Domain Analysis
slide70

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
best practices
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
pitfalls
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
domain analysis summary
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