Upload
timothy-lucas
View
214
Download
0
Embed Size (px)
Citation preview
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