Object-Oriented SoftwareAnalysis and Design

MISM/MSIT, CMULecture 2

Dr. Rahmi MARASLI

Today’s Topics More Requirements Analysis

Vision and Scope Document User Involvement Case Study: POST (Larman 1998)

Use Cases Introduction to Conceptual Model

Vision and Scope Document

Example: Project Management Software Project (PMan) Company X has project managers

who are always on the road Project documents are thus often

unavailable to managers, causing delays and lost business

Project documents are often out of date, making oversight difficult

Vision & Scope Document Business Requirements

Background Business Opportunity Business Objectives & Success Criteria Customer or Market Needs Business Risks

Vision of the Solution Scope and Limitations Business Context

PMan: Business Requirements Background

We have project managers who are always on the road Project documents are thus often unavailable to

managers, causing delays and lost business Project documents are often out of date, making

oversight difficult Business Opportunity

Internet connectivity is everywhere, so let’s use it A Web-based system providing access to project

documents Allow read, edit, addition, with privilege restrictions No inexpensive equivalent commercial product We have lots of folks who can build this during idle time

PMan: Business Requirements Objectives & Success Criteria

Reduce calls to home office to fax project documents by 75%

Reduce home office support costs by 15% Reduce customer service complaints by 35%

Customer/Market Needs Reduce by 75% the amount of “stuff” project managers

need to carry on the road, without loss of effectiveness Business Risks

A “home-grown” solution will take so long that it won’t be cost effective vs. a commercial solution

We may not think of product details that are most effective

Vision & Scope Document Business Requirements Vision of the Solution

Vision Statement Major Features Assumptions & Dependencies

Scope and Limitations Business Context

PMan: Vision of the Solution Vision Statement

For our project managers Who are on travel, and also at the home office The PMan application Is a document access system That permits viewing and updating project files,

that is Unlike existing manual methods and existing

affordable commercial systems. Our product gives project managers the ability to

access all project-related document while on travel, eliminating the need for home office support for lookup, faxing and updating.

PMan: Vision of the Solution Major Features

Secure login Allow editing of project documents Allow editing of personnel assignments Allow communication with other

project managers Allow entry of new projects, including

client info, project requirements, cost projections, profit opportunities

PMan: Vision of the Solution Assumptions & Dependencies

All of our project managers have Web access while on the road

The PMan system can successfully access and integrate with the home-office information systems

Our home-office IT people are capable of supporting any new technologies we use

Vision & Scope Document Business Requirements Vision of the Solution Scope and Limitations

Scope of Initial Release Scope of Subsequent Releases Limitations & Exclusions

Business Context

PMan: Scope and Limitations Scope of initial release

Focus on reading/modifying existing project documents

Time stamps, version control Very simple menu-based interface

PMan: Scope and Limitations Scope of subsequent releases

Improve interface Add capability to originate new projects Add user privilege functionality Allow personnel assignments

Limitations and exclusions The system will be coupled with the home

office database only The system will not replace any existing

communication modes, e.g., email

Vision & Scope Document Business Requirements Vision of the Solution Scope and Limitations Business Context

Stakeholder Profiles Project Priorities Operating Environment

PMan: Business Context Stakeholder Profiles

Project managers Benefits include improved access to project

information, communication of project details with other personnel, faster interaction with clients

Likely to quickly embrace system …

Senior management Clients Home office personnel

PMan: Business Context Project priorities

Releases as described in the scope Use our own programmers, but

initially only when they have no other project duties. If the system appears successful, assign more programmer time, but no more than 10% of anyone’s time

PMan: Business Context Operating environment

The system is based on Internet connectivity Assume project managers will have adequate

wireless/wired Internet access Managers must be able to download 10-page

MS Word document in less than 1 minute at 56K

System must be available weekdays 8:00-11:00 am, 4:00-9:00 pm, weekends 10:00-4:00.

Vision & Scope Document Business Requirements Vision of the Solution Scope and Limitations Business Context

Note that there is much more to consider in a larger project;See Wiegers, Ch. 5, for more details.

User Involvement

Getting Customer Involvement Everyone agrees this should happen, but

it happens too seldom… Try these steps

Identify the user classes Identify sources of user requirements Select representatives of user classes and

work with them Agree on who the requirements decision

makers are

No Customer Involvement? Expectation gap Cool but useless features Rework Delay Dissatisfaction

Another Diagram: User Classes

Stakeholders

Customers Others

UsersProcurersManagers

Favored User Classes

Disfavored User Classes

Ignored User Classes

Other User Classes

Other Distinguishing Attributes Frequent vs. infrequent users Level of domain expertise Features actually used Tasks performed Access privileges

Who Are The Favored Users? The ones you rely on when making

priority decisions and resolving conflicts

The ones whose acceptance of the system determine success

Not necessarily upper management Then there are the disfavored users:

The ones who aren’t supposed to use the product!

PMan: User Classes Project managers (favored) Upper management Home office support staff Home office programmers writing

the system

User Representatives and Product Champion At least one representative from

each user class Someone who will be available

throughout the product lifecycle A “product champion” as high up

as possible, someone enthusiastic, and can get things done

Eliciting Requirements

Interviews Joint Application Design Prototypes Questionnaires Observation Sampling

CASE Study:POST

POST System Point-of-Sale Terminal (POST)

System A computerized system used to

record sales and handle payments Typically used in a retail store Includes hardware components

such as computer and bar code

Larman 1998

POST: Goals Quick checkout for customers Fast and accurate sales analysis Automatic inventory control

POST: System Functions (Basic) R1.1 – Record the current sale – the items

purchased R1.2 – Calculate current sale total, including tax and

coupon calculations R1.4 – Reduce inventory quantities when sale is

committed R1.5 – Log completed sale R1.6 – Cashier must login with an ID and password

to use system R1.7 – Provide a persistent storage mechanism R1.8 – Provide inter-process and inter-system

communication mechanism R1.9 – Display description and price of item

recorded

POST – System Functions (Payment) R2.1 – Handle cash payments, capturing amount

tendered and calculating balance R2.2 – Handle credit card payments, capturing

credit information from a card reader or by manual entry, and authorizing payment with store’s (external) credit authorization service via a modem connection

R2.3 - Handle check payments, capturing drivers license by manual entry, and by authorizing payment with the store’s (external) check authorization service via a modem connection

R2.4 - Log credit payments to accounts receivable system, since the credit authorization service owes the store payment amount

Use Cases

Definition “A use case is a narrative document that

describes the sequence of events of an actor (an external agent) using a system to complete a process” [Jacobson]

They are stories of cases of using a system They are not exactly requirements or

functional specifications A sequence of steps for completing a

required task

Example:Buy Items Use Case: Buy Items Actors: Customer, Cashier Description: A Customer arrives at

a checkout with items to purchase. Cashier records the purchased items and collects payment

Use Cases Notice that the emphasis is on users Traditionally, we’ve asked what the

system should do The objective is to describe all tasks

that users need/want to perform Then the stakeholders verify that they

are within the current scope

What Good Are Use Cases? Generate and validate requirements,

make sure nothing is missed View system from an external

viewpoint Help identify system objects Basis for test plan Basis for user manual Users often describe most important

use cases first, so this helps prioritize

Expanded Use Cases Use Case: Name of use case Actors: List of actors (external

agents), indicating who initiates use case

Purpose: Intention of the use case Overview: Repetition of high level

use case, or some similar summary Cross Reference: Related use cases

and system functions

Expanded Use Cases (cont) Typical course of events

Heart of expanded use case Describes, in detail, the interaction between

system and the actors Critical: Only include most common, or typical,

sequence of events – average story of activities and successful completion of a process

Alterative Courses: Describe important alternatives and exceptions

Example: Buy Items with Cash Use Case: Buy Items wit Cash Actors: Customer (initiator), Cashier Purpose: Capture a sale and its cash

payment Description: A Customer arrives at a

checkout with items to purchase. Cashier records the purchased items and collects a cash payment

Cross References: System Functions R1.1, R1.2, R1.3, R1.7, R1.9, R2.1

Buy Items with Cash (cont) Typical Course of Actions:

Actor Actions:1. This use case begins when a

Customer arrives at a POST checkout system with items to purchase

2. Cashier records the identifier for each item

If there is more than one of the same item, Cashier enters the quantity

4. On completion of item entry, Cashier indicates to POST that item entry is complete

6. Cashier tells Customer the total

System Response:

3. Determines item price and adds item info to the running sales transaction

Description and price of the current item is presented

5. Calculates and presents sale total

Buy Items with Cash (cont)

Actor Actions:7. Customer gives a cash

payment8. Cashier records the cash

received

10. Cashier deposits the cash received and extracts balance owing

Cashier gives balance owing and receipt to Customer

12. Customer leaves with items purchased

System Response:

9. Shows the balance due back to Customer

Generates a receipt

11. Logs the completed sale

Typical Course of Actions (cont):

Buy Items with Cash (cont) Alternative Courses:

Line 2: Invalid identifier entered. Indicate error

Line 7: Customer did not have enough cash. Cancel sales transaction

Actors An entity external to the system

who participates in story of use case Usually stimulates the system with

input events Typical Actors:

Roles that people play Computer systems Electrical or mechanical devices

Alternative Courses of Events Things don’t always go smoothly! Additional paths can be recorded in

one or more “Alternate Course” blocks

These describe reasons why the normal course (the “happy path”?) isn’t followed, and what alternate actions are performed

Identifying Use Cases Actor-Based Approach:

Identify actors related to a system or organization Then, for each actor, identify the process they

initiate or participate in Event-Based Approach:

Identify external events that a system must respond to

Relate events to actors and use cases Yet Another approach:

Express business processes in terms of specific scenarios, then generalize

A Common Mistake Representing individual steps,

operations, or transactions as use cases

Question: In POST system, is there a use case called “printing receipt”?

Tip: Use case is relatively large end-to-end

process description that typically includes many steps or transactions

Use Cases and System Functions Traceability All system functions should be

allocated to use cases This should be traceable via Cross

Reference sections of use cases

Use Case Formats High Level

Describe a process very briefly, usually in 2-3 sentences

Useful to have them for quickly understanding the degree of complexity and functionality

They are vague wrt design Expanded

Includes a detailed Typical Course of Events section During requirements phase, useful to write

expanded use cases only for the most important and influential ones

Rest can be deferred until design/development cycle

UML Use Case Notation A simple diagram, like this:

Use Case

Actor

POST System Use Cases

Buy Items

Cashier Customer

Log In

Refund Purchased Items

POST

Splitting Use Cases Write major steps or branching

activities of a use case as a separate one when: They are duplicated in other use

cases They are complex and long and

separating them helps factor the use cases into manageable pieces

UML: Include Relationship

Buy Items

Cashier CustomerPay By Credit

POST

Pay By Cash Pay By Check

<<include>><<include>><<include>>

UML: Extend Relationship Used when a second use case story

follows the story of a prior use case Extending a use case is, effectively,

an alternate course of base use case Introduce an extending use case

whenever logic for an alternate course of action is at a complexity level similar to that of your basic course of action

UML: Use Case Inheritance? Use cases can inherit from other

use cases Used very rarely!

UML: More Examples

Enroll InUniversity

Perform Security Check

University Enrolment System

Enroll Family Member in University

Enroll inSeminar

Registrar

Student

InternationalStudent

Applicant

<<include>>

<<extend>>

Wiegers’ Use Case Traps Too many use cases Highly complex use cases GUI-containing use cases Data definitions or algorithms in use

cases Use cases users don’t understand (!) New business processes

Introduction toConceptual Model

Definition “A representation of concepts in a

problem domain” [J.Martin/J.Odell] and [M.Fowler]

Most important step in O-O analysis and investigation Decomposition of problem into

individual concepts and objects

Conceptual Model It is a representation of real-world

things, not of software components It may show

Concepts Association between concepts Attributes of concepts

Concepts Informally, an idea, thing or object Formally, considered in terms of its

symbol, intension and extension [J.Martin/J.Odell]: Symbol - words or images

representing concepts Intension – definition of a concept Extension – set of examples to which

concept applies

Concepts: Example The event of a purchase transaction

Symbol – Sale Intension – Represents the event of a

purchase transaction, and has a date and time

Extension – Set of all sales

Identifying Concepts General guideline:

It is better to overspecify a conceptual model with lots of fine-grained concepts, than to underspecify it

It is common to miss concepts during initial phase and discover them later (e.g., during design)

Do not exclude a concept simply because requirements do not indicate any obvious need for it

It is perfectly acceptable to have purely behavioral or attributeless concepts

Identifying Concepts (cont) Two strategies:

Concept Category List Noun Phrase List

Concept Category List Create a conceptual model by

making candidate concepts from a list

Contains many common categories that worth considering (not in any particular order)

Concept Category List (cont)Concept Category Examples

Physical or tangible objects POST

Places Store

Transactions Sale, Payment

Transaction line items SalesLineItem

Roles of people Cashier

Containers of other things Store, Bin

Things in a container Item

Other computer or electro-mechanical systems external to our system

CreditCardAuthorizationSystem

Specifications, designs, or description of things

ProductSpecification

Concept Category List (cont)

Concept Category Examples

Organizations SalesDepartment

Events Sale, Robbery, Meeting

Processes (often not represented as a concept, but may be

SellingAProduct

Rules and policies RefundPolicy

Catalogs ProductCatalog

Records of finances, work, contracts, legal matters

Receipt, Ledger, EmploymentContract

Financial services and instruments LineOfCredit

Manuals, books EmployeeManual

Abstract noun concepts Hunger

Noun Phrase Identification Proposed by R.Abbot, 1983 Identify nouns and noun phrases in textual

description of a problem and consider them as candidate concepts or attributes Expanded use cases are excellent description

to draw concepts Warning: a mechanical noun-to-concept

mapping isn’t usually possible and words in natural language are ambiguous

Candidate Concepts for POST Drawn using concept category list

and noun-phrase analysisPOST ProductSpecificationItem SalesLineItemStore CashierSale CustomerPayment ManagerProductCatalog

Why not a Receipt concept? Receipt is a record of a sale and relatively

important concept in domain of sales Receipt is report of a sale. In general, showing

a report in a conceptual model is not useful since all its info is derived from other sources

However, it has a special role in terms of business rules; customer uses it to return a previously bought item

So, what to do? Is “purchase item return” included in

requirements?

UML Notation

Concept

Concept

Attribute1Attribute2….

In UML, conceptual model is illustrated via a set of static structure diagrams in which no operations are described

POST Concepts in UML

POST Item Store Sale

SalesLineItem Cashier Customer Manager

Payment ProductCatalog ProductSpecificatin

How to make a conceptual model1. List candidate concepts using Concept

Category List and noun phrase identification related to current requirements under consideration

2. Draw them in a conceptual model3. Add associations necessary to record

relationships for which there is a need to preserve some memory

4. Add attributes necessary to fulfill information requirements

N

ext

class

On Naming and Modeling Things: Mapmaker Make a conceptual model in the spirit of

how a cartographer or mapmaker works Use existing names in territory

Use the vocabulary of domain when naming concepts and attributes

Exclude irrelevant features Exclude concepts in the problem domain not

pertinent to the requirements (e.g., pen, paperbag)

Do not add things that are not there Exclude things not in the problem domain under

consideration

Concept vs. Attribute Do not represent something as an attribute

when it should have been a concept Guideline

If X cannot be considered as number or text in real world, X is probably a concept, not an attribute

Question: Is Destination an attribute of Flight or separate concept named Airport?

When in doubt, make it a separate concept

An Item Concept Example Item instance represents a physical

item in a store Item has a description, price and

UPC which are not recorded anywhere else

When an Item is sold, corresponding entry is deleted from software dBase

Problems w/Item Concept Duplicate data (description, price,

UPC) Very space inefficient

Store sells out LowCarbBurger, a high demand Item

Can we answer a question like “how much LowCarbBurger cost”?

Solution: Specification Concept Solution to Item concept problem is

to add a new concept called ProductSpecification It represents a description of

information about items

More on Item Example

Item

DescriptionPriceSerialNumberUPC

ProductSpecification

DescriptionPriceUPC

Item

SerialNumber

Worse Better

1 *

Describes

Flight Example What airport a flight goes to is in the

Flight instance An airline company suffers a fatal crash All their flights are cancelled for 6

months Their corresponding Flight objects are

deleted from software dBase How can you get record of flight

routes?

More on Flight Example

Flight

datenumbertime

Worse Better

Airport

name

Flight

datetime

Airport

name

FlightDescription

number

* 1

Flies-to * 1

Described-by

*

1

Describes-flies-to

Specification Concept In general, add a description or

specification concept when Deleting instances of things they

describe results in loss of information that needs to be maintained

It reduces redundant or duplicate information