cs 564 – problem analysis lecture 8. five steps in problem analysis gain agreement on problem...
Post on 21-Dec-2015
218 Views
Preview:
TRANSCRIPT
CS 564 – Problem AnalysisLecture 8
Five Steps in Problem Analysis
• Gain Agreement on Problem Definition
• Understand Root Causes
• Identify the Stakeholders and the Users
• Define the Solution System Boundary
• Identify the Constraints to be Imposed on the Solution
Problem Statement Format
• The Problem of :• affects:
• the result of which:
• Benefits of:
• Describe the problem• Identify Stakeholders
affected by the problem
• Describe the impact of this problem on stakeholders and business activity.
• Indicate the proposed solution and list a few key benefits
Understand Root Cause
Too Much Scrap!
Custom
er returns
Dam
aged in
Shipm
ent
Inaccurate Sales
Orders
Fin
ishe
d G
oods
Obs
oles
cenc
e
Man
ufac
turin
g D
efec
ts
Oth
er
Addressing Root Cause
0
5
10
15
20
25
30
35
40
45
50
Contributions
Inaccuate SalesOrders
Damaged inShipment
Customer Returns
Finished GoodsObsolescence
ManufacturingDefects
Other
Identify the Stakeholders and Users
• Who are the users of the system?• Who is the customer (economic buyer) for the
system?• Who else will be affected by the outputs that the
system produces?• Who will evaluate and bless the system when it is
delivered and deployed?• Are there any other internal or external users of the
system whose needs must be addressed?• Who will maintain the system?• Is there anyone else?
Define the Solution System Boundary
SystemInputs Outputs
OurSolution
Users
I/O
System Boundary
Other SystemsI/O
Identify Constraints
• Economic
• Political
• Technical
• System
• Environmental
• Schedule and Resources
Proposed System
Proposed System
Check Status
Create Order
Shipment Notice
Inventory
Assign Inventory to Order
Inventory Assigned
New Inventory for Held Orders
Assign Order to Truck
Truckload Report
Shipping Invoices
Order Update
Order Display
Problem ResolutionDispatch
Accounting
Management Reports
Customer
Check Credit &
Completion
Users
Catalog
Orders
OrderCreation
Credit Check
InventoryAssignment
Held OrderProcessing
Completion
DispatchSupport
ProblemResolution
ManagementReporting
OA&M
Software Costing
Attribute Simple Average ComplexInputs (I) 3 4 6Outputs (O) 4 5 7Data Files {F} 7 10 15Interfaces (N) 5 7 10Inquiries (Q) 3 4 6
Complexity Ratings
Basic Function Point Type Count Complexity UFPOrder Processing Order Entry logon N 1 7 7 create order N 1 7 7 add item N 1 7 7 checkout N 1 7 7Order Status I 1 4 4Shipping Notice Q 1 7 7Credit Check N 1 10 10Inventory Processing Assign Inventory N 1 10 10Held Order N 1 10 10Problem Resolution Display Q 1 3 3Update/Create Order I 1 6 6Dispatch 0Assign to Truck I 1 4 4Truck Report Q 1 4 4Shipment Invoice Q 1 4 4Completion N 1 7 7Reports Q 10 4 40FilesUsers F 1 10 10Catalog F 1 10 10Orders F 1 15 15OA&MTransactions I 5 4 20Reports Q 5 4 20Tables F 10 7 70Outputs O 5 4 20
Total Unadjusted Function Points 302
General System Characteristic Rating1 Data Communications 22 Distributed Data/Processing 23 Performance Objectives 24 Heavily Used Configuration 35 Transaction Rate 16 On-Line Data Entry 47 End-User Efficiency 58 On-Line Update 59 Complex Processing 2
10 Reusability 211 Conversion/Installation Ease 412 Operational Ease 413 Multiple Site Use 414 Facilitate Change 4
Total Degree of Influence 44
UFP (.65+.01*TDI)302 1.09
Adjusted Function Points 329
Software Costing
• Cost Development using FPA
• Estimate • Requirements
Engineering (1/3 of development
• Design (1/5 of development)
• Testing (1/4 of development
• Documentation & Training
FP per mo 5Dev Staff Mos 65.8Dev Staff Yrs 5.5Sys Eng 1.8Design 1.1Test 1.8Doc 1.0Trng 1.0Total 12.2
Staff Cost $150,000Project Cost $1,836,173
Opportunity Assessment Context
CustomerBusiness
Case
= NPV = (Benefits, Time) - (Costs, Time)
ProductBusiness
Case
= NPV = (Revenue, Time) - (Costs, Time)
(Price, Market Size)
Software CostEstimation
(Hardware)
Units
Setting PriceElement License Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Total
Usage Block 200000 Units 3 9 12 12 12
RevenueOM License $599,000 $1,797,000 $5,391,000 $7,188,000 $7,188,000 $7,188,000 $28,752,000Amoritization $0 $0 $0 $0 $0 $0 $0 $0Other COS 36% $646,920 $1,940,760 $2,587,680 $2,587,680 $2,587,680 $10,350,720 Total Incurred Costs $646,920 $1,940,760 $2,587,680 $2,587,680 $2,587,680 $10,350,720
$0Margin $0 $1,150,080 $3,450,240 $4,600,320 $4,600,320 $4,600,320 $18,401,280% Margin 64% 64% 64% 64% 64% 64%
$0Expenses $0Actual R&D $1,836,173 $300,000 $2,136,173Capitalized R&D $0 $0R&D $1,836,173 $300,000 $0 $0 $0 $0 $2,136,173 Marketing/Sales 25% $0 $449,250 $1,347,750 $1,797,000 $1,797,000 $1,797,000 $7,188,000 Distribution $0 G & A 8% $0 $143,760 $431,280 $575,040 $575,040 $575,040 $2,300,160 Total Expenses $1,836,173 $893,010 $1,779,030 $2,372,040 $2,372,040 $2,372,040 $11,624,333
$0Other Income $0
$0Operating Income -$1,836,173 $257,070 $1,671,210 $2,228,280 $2,228,280 $2,228,280 $6,776,947
OROS 14.3% 31.0% 31.0% 31.0% 31.0% 23.6%
Capitalizing Software
Balance Sheet
Assets
Capitalized SW
Liabilities
Balance Sheet
Assets
Capitalized SW
Liabilities
Income Statement
RevenueCost of Sales Amoritization
ExpensesR&D Capitalized SW
Income Statement
RevenueCost of Sales Amoritization
ExpensesR&D Capitalized SW
Capitalize
Amoritize
Gossamer Balance SheetPeriod Ending 31-Dec-02 30-Sep-02 30-Jun-02 31-Mar-02
Cash And Cash Equivalents $9,677,091 $9,443,970 $12,675,030 $14,489,818 Short Term Investments $48,126,424 $41,980,545 $38,313,939 $39,457,818 Net Receivables $12,057,939 $12,063,212 $11,662,000 $11,474,303 Inventory N/A N/A N/A N/A Other Current Assets $1,377,212 $1,517,182 $1,671,303 $1,796,091 Total Current Assets $71,238,667 $65,004,909 $64,322,273 $67,218,030
Long Term Investments $665,030 $2,022,182 $3,826,515 $1,289,061 Property Plant And Equipment $6,751,515 $6,833,364 $6,838,152 $6,580,303 Goodwill $1,645,273 $1,640,303 $1,610,061 $1,478,970 Intangible Assets $1,336,394 $1,464,000 $1,438,424 $655,606 Accumulated Amortization N/A N/A N/A N/A Other Assets $162,394 $634,939 $695,182 $713,394 Deferred Long Term Asset Charges $4,520,818 $3,491,455 $4,549,273 $2,880,636 Total Assets $86,320,091 $81,091,152 $83,279,879 $80,816,000
Payables And Accrued Expenses $10,707,515 $9,504,242 $10,584,970 $10,534,697 Short Term And Current Long Term Debt N/A N/A $1,727,273 $1,727,273 Other Current Liabilities $12,807,788 $11,878,303 $12,995,212 $12,763,576 Total Current Liabilities $23,515,303 $21,382,545 $25,307,455 $25,025,545 Long Term Debt N/A N/A N/A N/A Other Liabilities $651,091 $632,030 $673,818 $683,394 Deferred Long Term Liability Charges $2,892,727 $2,822,364 $2,925,485 $3,120,576 Minority Interest N/A N/A N/A N/A Negative Goodwill N/A N/A N/A N/ATotal Liabilities $27,059,121 $24,836,939 $28,906,758 $28,829,515
Current Liabilities
Current Assets
Long Term Assets
Gossamer Income Statement Period Ending: 31-Dec-02 30-Sep-02 30-Jun-02 31-Mar-02Total Revenue $15,522,909 $14,279,182 $14,612,485 $14,644,455 Cost Of Revenue $5,395,879 $5,177,364 $5,495,182 $5,537,030 Gross Profit $10,127,030 $9,101,818 $9,117,303 $9,107,424 Margin 65.2% 63.7% 62.4% 62.2%
Research And Development $2,675,909 $2,515,212 $2,652,939 $2,494,939 Selling General And Administrative Expenses $5,110,485 $4,692,424 $4,653,273 $4,691,394 Non Recurring ($36,485) N/A $263,000 $84,848 Other Operating Expenses N/A N/A N/A N/ATotal Operating Expense $7,749,909 $7,207,636 $7,569,212 $7,271,182
Operating Income $2,377,121 $1,894,182 $1,548,091 $1,836,242 Total Other Income And Expenses Net $345,667 $169,909 $256,909 $219,364 Earnings Before Interest And Taxes $2,722,788 $2,064,091 $1,805,000 $2,055,606 Operating Return on Sales (OROS) 17.5% 14.5% 12.4% 14.0%
Operating Expenses
Net Income Applicable To Common Shares $1,739,697 $1,351,970 $1,091,515 $1,349,818 Shares outstanding 6000000 6000000 6000000 6000000Earnings per Share $0.290 $0.225 $0.182 $0.225Share Price at end of period $6.47 $5.95 $6.09 $6.10
Absorbing the project will substantially reduce Operating Income => Capitalize
CapitalizationElement License Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Total
Usage Block 200000 Units 3 9 12 12 12
RevenueOM License $599,000 $1,797,000 $5,391,000 $7,188,000 $7,188,000 $7,188,000 $28,752,000Amoritization $1,000,000 $21,000 $63,000 $189,000 $252,000 $252,000 $244,000 $1,000,000Other COS 36% $646,920 $1,940,760 $2,587,680 $2,587,680 $2,587,680 $10,350,720 Total Incurred Costs $709,920 $2,129,760 $2,839,680 $2,839,680 $2,831,680 $11,350,720
$0Margin $0 $1,087,080 $3,261,240 $4,348,320 $4,348,320 $4,356,320 $17,401,280% Margin 60% 60% 60% 60% 61% 61%
$0Expenses $0Actual R&D $1,836,173 $300,000 $2,136,173Capitalized R&D $1,000,000 $1,000,000R&D $836,173 $300,000 $0 $0 $0 $0 $1,136,173 Marketing/Sales 25% $0 $449,250 $1,347,750 $1,797,000 $1,797,000 $1,797,000 $7,188,000 Distribution $0 G & A 8% $0 $143,760 $431,280 $575,040 $575,040 $575,040 $2,300,160 Total Expenses $836,173 $893,010 $1,779,030 $2,372,040 $2,372,040 $2,372,040 $10,624,333
$0Other Income $0
$0Operating Income -$836,173 $194,070 $1,482,210 $1,976,280 $1,976,280 $1,984,280 $6,776,947
OROS 10.8% 27.5% 27.5% 27.5% 27.6% 23.6%
Customer Benefits
• Customer Business Case• Very strong cash flow• Strategic for customer
Element Year 0 Year 1 Year 2 Year 3 Year 4 Year 5 NPV Interest($K) ($K) ($K) ($K) ($K) ($K) ($K) 0.028
Year 0 1 2 3 4 5 1/(1+I)**n 1.000 0.973 0.946 0.920 0.895 0.871
Operations Savings $3,977,727 $0 $3,869 $3,764 $3,661 $3,562 $3,465 $18,321 PMO per Order $40.40 FMO per Order $18.65 Orders per Year 182884Hardware Costs $35 $35 $5 $5 $5 $5 $5 $60 Hardware $30 Maintenance (18%) $5Software Costs $599 $599 $599Services $216 $216 $216
Cash Flow ($850) $3,864 $3,759 $3,657 $3,557 $3,460 $17,446 NPV
Risks
• Too Good to Be True• Study at next level of detail
• New Customer, New Problem Domain• High diligence on requirements• Create friendly customer arrangement
• Minor risk with hardware selection• Convince customer for forward sizing
Opportunity Assessment
• Quantify the model• Improves your understanding of the value• Improves your understanding of the business
• Refine estimates that matter• Hardware was pretty inconsequential in this case
study• Stepwise refinement to get to investment
decisions
• A quantified model can drive your investment
Software Requirements Taking Stock
Now on to:
• Requirements Synthesis
• Technology Investment
• Requirements Selection
• Requirements Homework
Requirements Engineering Process
Requirements ElicitationRequirements Elicitation
Requirements Analysis & Negotiation
Requirements Analysis & Negotiation
Agreed Requirements
Draft Requirements Document
Requirements Document & Validation Report
Informal Statement of Requirements
Decision Point: Accept Document or re-enter spiral
Requirements SpecificationRequirements Specification
Requirements ValidationRequirements Validation
• Process Models• Process Actors and
Stakeholders• Process Support
and Management• Process Quality and
Improvements• Relationship to the
Business Decision
Requirements Process - Context
• Varied Sources• Functional• NonFunctional• Risk Factors
• Continuity• Strategic• Process & Project
• Varied “Consumers”• Development• Marketing• Training & Documentation• Information Base
RequirementsEngineering
Process
BusinessStrategy
BusinessStrategy
TechnologyStrategy
TechnologyStrategy
Project, Process & DocumentationStandards
Project, Process & DocumentationStandards
OpportunityAnalysis
MarketAnalysis
CustomerRequest
SoftwareDesign
SoftwareDevelopment
SoftwareTesting
Requirements Document
Requirements Document
Marketing,Etc.
Yet another Software Requirements Document Structure
Prospectus Describe the need for the system. Describe system functions and
rationale for the software and the MOVThe System Model
Set out full system model, showing the relationships between the system components. An abstract data model should also be described.
System Evolution Describe fundamental assumptions on which the system is based and
describe anticipated changes due hardware evolution, changing user needs,etc.
Functional Requirements The services provided for the user are described using natural
languages with cross references to the requirements specification. Non-functional Requirements
The constraints imposed on the software operation and restrictions on the design.
Glossary
Requirements Process
• Elicitation• Request Analysis
• Sourcing & Screening
• Definition• Purposeful• Understand value
• Analysis• Interrelationships• Prioritization• Risk & Cost Assessment
• Specification• Modeling
• Validation• Agreement
• Change Management
RequestAnalysis
RequirementsDefinition
RequirementsAnalysis
RequirementsSynthesis
RequirementsSpecification
RequirementsValidation
Req
uirm
ents
Cha
nge
Man
agem
ent
Requirements Elicitation Review
Requirements Sources• Goals (Value)• Domain Knowledge• System
Stakeholders• Operational
Environment• Organizational
Environment
Elicitation Techniques• Interviews• Scenarios• Prototypes• Facilitated Meetings• Observation• Workshops
Interviewing
• Target Stakeholders• Usually appropriate for managers and
nonuser stakeholders
• Context Free Questions• Open not closed
• Preparation• Research company and person’s
background.
Observations
• Target Users• Observe work steps• Identify different use cases/scenarios
• Scope• Repetitive• Across target market
• Preparation• Operations background from local
management.
Workshops
• Target Users, user management, analysts, project management
• Baseline the team• Summary of Objectives and analyst
findings
• Trained Facilitator• Experienced in facilitating innovation
Levels of Customer Requirements
• Expecters• Customer assumes is
part of the product or service
• Spokens• Specific features the
customer desires
• Unspokens• Uncommunicated part of
customer’s expectation
• Exciters• Unexpected features
making the product unique
I assume it meets all federal, state, and local codes.
Expecters
3 car garage2 bedrooms
2 baths
Spokens
I’ll know it when I see it
Unspokens Exciters
Wow! A lifetime warranty on the
roof
Technology Strategy- NonFunctional
Technology Initiatives
Metric: Percent of Revenue due to new products for past three years
From Market From MarketingIdeas from StaffTechnology Assessments
Processes &Products (with embedded new Technology)
Inputs
Outputs
Roles in Technology Strategy
1. Executive CabinetCEOCTOCIOVPs
2. Chief Technology Officer3. Office of Technology Planning4. Development Teams
Executive Cabinet’s Job
•Assure that the Technology Plan is Consistent with the Strategic Plan
•Hire a CTO who can be an ‘out-of-the-box’ thinker
•Encourage and Reward Invention
•Stimulate Innovations from Inventions
CTO’s Job
• Lead the Office of Technology Planning• Create a Technology Vision • Fund Technology Trials and Jumpstarts• Approve and Communicate Initiatives• Integrate with Product Lines• Create R&D Personnel Policies• Chair Intellectual Property Team• Create a climate of Innovation: ‘the dither
index.’
Office of Technology Planning
• Recommend Technology Priorities• Assess Technology Payoffs• Drive to Asset Based Business: Platforms
& Components• Encourage Technology Transfer/ Diffusion• Professional Community Contacts• Foster Benchmarking
Development Teams
• Try new Technologies• Adopt and deploy sanctioned
technologies• Avoid maverick technologies• Embrace the Technology Plan
Innovation Process
Make or Buy ?
Plan
MOV: 1. 20 % of revenue derived from new
products in every three year window 2. 20% productivity improvement per
decade
Acquire
Contract &Evaluate
Deploy
Prioritize
Innovation Process- with Feedback
Make or Buy ?
Plan
MOV: 1. 20 % of revenue derived from new
products in every three year window 2. 20% productivity improvement per
decade
Acquire
Contract &Evaluate
Deploy
Prioritize
Fullfilling Customer Requirements
Cu
stom
er Satisfactio
nL
ow
Hig
h
Achievement of RequirementsLow High
Expecters
Spokens
Unspokens
Exciters
As of 28 Oct
Six Aspects of Good Software Products
Systematic Prioritizing Requirements
Quality Function Deployment is a systematic good practice to setting priorities and tracing critical requirements in the software product realization process.
Quality Function Deployment
What is QFD?
• Integrates Design Process
• Maps Customer Requirements into• Definable & measurable product &
process parameters
• Format & Language can be used with customers
• Constructed to resolve divergent needs of the stakeholders
• Benefits• 30% to 50% reduction in
engineering changes• 30% to 50% shorter design cycles• 20% to 60% lower start up costs• 20% to 50% fewer warranty claims
CorrelationMatrix
TechnicalRequirements
(Hows)
Target MovementObjective
RelationshipMatrix
Whats
Imp
ort
an
ce R
atin
g
Cu
sto
me
r C
om
pe
titiv
eA
sse
ssm
en
t
Technical CompetitiveAssessment
(How Muches)
Absolute Score
Relative Score
Target Goals
House of Quality
Correlations
Technical Aspects
RelationshipsCustomer Needs Customer’s
Priority
Technical Aspect Importance
Quality Function Deployment
QFD Process
1. Define customer requirements
2. Determine requirement importance
3. Assess competitive position
4. Define Hows (Technical Requirements)
5. Define Target Goals
6. Determine correlation matrix elements
7. Assess competitor technical performance and set objective values
8. Complete the relationship matrix
9. Compute the absolute score
10. Determine relative ranking of the Hows
CorrelationMatrix
TechnicalRequirements
(Hows)
Target MovementObjective
RelationshipMatrix
Whats
Imp
ort
an
ce R
atin
g
Cu
sto
me
r C
om
pe
titiv
eA
sse
ssm
en
t
Technical CompetitiveAssessment
(How Muches)
Absolute Score
Relative Score
Target Goals
Example: Good Video Game
EasyTo Use Good
Visualeffects
Don’t getHurt
Playing
EverybodyCan use
itAffordable
SturdyControls
No eyestrain
VersatileControls
NotBreakEasily
InterruptablePlay
WideAssortmentOf Action
Objective: What are the qualities of a good video game?
EasyTo Use
GoodVisualeffects
Don’t getHurt
Playing
EverybodyCan use
it
Affordable
SturdyControls
No eyestrain
VersatileControls
NotBreakEasily
InterruptablePlay
WideAssortmentOf Action
GetMoney’sWorth
CompetitiveExcitement
SafeDesign
Example: Good Video Game
Objective: What are the qualities of a good video game?
Easy To Use
Good visual effects
Don’t get hurt playing
Everybody can use it
Affordable
Sturdy Controls
No eye strain
Versatile Controls
Not Break Easily
Interruptable Play
Wide AssortmentOf Action
GetMoney’sWorth
CompetitiveExcitement
SafeDesign
GoodVideoGame
Easy to UseNot break easilyVersatile controlsAffordableGood visual effectsEverybody can use itSturdy ControlsInterruptable PlayWide Assortment of ActionNo eye strainDon't get hurt using
Customer needs
Get
M
oney
's
Wor
th
Pro
vide
s C
ompe
titiv
e E
xcite
men
tS
afe
D
esi
gn
Importance Rating
• Voice of the Customer• Customer Participation or• Customer Advocate
• Consultants• Sales & Marketing
• Methods• Use a 1-9 rating system• Rate on initial pass• To Refine
• Rank Order• Distribute 100 points• Full Pairwise Comparison• Force uniform distribution• Priority inversion for case
where there is a pre-requisite
Impo
rtan
ce
Easy to Use 4Not break easily 3Versatile controls 2Affordable 3Good visual effects 5Everybody can use it 3Sturdy Controls 4Interruptable Play 2Wide Assortment of Action 5No eye strain 3Don't get hurt using 4
Customer needs
Get
M
oney
's
Wor
th
Pro
vide
s C
ompe
titiv
e E
xcite
men
tS
afe
D
esi
gn
Degree of Contribution
• Weak =1
• Moderate = 3
• Strong = 5
• Very Strong = 7
• Extreme = 9
Voice of the Customer
100Page RFP
Military RFP for a new Plane
Fly Higher………………….3Fly Faster………………….2Carry more Weight……….5Be more Maneuverable….4
First Cut Feature/Attribute Analysis
Easy Fly Higher
Fly
Faster
Less
Weight
More
Manu
Relib. 1 1 1 9 3
Faster
Soft.3 3 3 1 9
Mem.
Red.
5 1 1 9 1
Matrix Analysis-Judgment Applied
Easy Total E x T Priority Over-
ride
Relib. 1 14 14 3 1
Faster
Soft.3 16 48 2 3
Mem.
Red.
5 12 60 1 2
Competitive Position
• Rate Self• Rate Competitors• Set Planned Level• Compute Improvement
Ratio• Determine Sales Points• Determine Importance
Weight• (Importance *
Improvement Ration)
• Determine Relative Weight• Express Importance
Weight as a %
Cur
rent
Com
pany
Rat
ing
Com
petit
or A
Com
petit
or B
Pla
nned
Lev
el
Impr
ovem
ent
Rat
io
Sal
es P
oint
Impo
rtan
ce W
eigh
t
Rel
ativ
e W
eigh
t
3 4 4 4 1.3 5.2 11.84 4 3 4 1.0 3.0 6.82 2 3 4 2.0 O 4.0 9.03 2 3 3 1.0 3.0 6.83 4 2 4 1.3 6.5 14.75 3 3 5 1.0 O 3.0 6.84 3 2 4 1.0 o 4.0 9.04 4 2 4 1.0 2.0 4.53 4 3 4 1.3 6.5 14.74 2 3 4 1.0 o 3.0 6.84 4 3 4 1.0 4.0 9.0
Total 44.2
Impo
rtan
ce
Easy to Use 4Not break easily 3Versatile controls 2Affordable 3Good visual effects 5Everybody can use it 3Sturdy Controls 4Interruptable Play 2Wide Assortment of Action 5No eye strain 3Don't get hurt using 4
Customer needs
Get
M
oney
's
Wor
th
Pro
vide
s C
ompe
titiv
e E
xcite
men
tS
afe
D
esi
gn
Technical Requirements (Hows)
• Cross Functional Team• Uses Customer
Requirements to Define Technical Requirements
• If I control “the how” then I am meeting my customers’ objective to “provide the what”.
• Collect data from• RFPs• Publications• Technical Interchanges
with customers
• Tier• Place details in subsystems
Hum
an F
acto
rs S
afet
y
Sof
twar
e D
esig
n
Par
t F
ailu
re r
ate
Tim
e to
initi
ate
play
Scr
een
reso
lutio
n
No.
/typ
e of
inte
rfac
e co
ntro
ls
Tec
hnol
ogy
cost
/sch
edul
e
Leve
ls o
f di
ffic
ulty
Impa
ct r
esis
tanc
e
Num
ber/
type
s of
gam
es
Target Goals
• Quantify the Goal• Increase/Decrease• Specific Objective
• Product Test Rating• MTBF, Returns
• Unable to Quantify• Restate the technical
requirement• From Software Design• To Improved graphics or
improved responsiveness
Target Values No
Saf
ety
Haz
ard
10,0
00 li
nes
of c
ode
MT
BF
900
,000
cyc
les
Avg
tim
e: 1
min
256
colo
rs,
320
x 19
2 pi
xels
5 in
put
devi
ces
$1M
/6m
onth
s
5 le
vels
20 f
t-lb
s
16 g
ames
/ 4
each
cat
egor
y
Impo
rtan
ce
Hum
an F
acto
rs S
afet
y
Sof
twar
e D
esig
n
Par
t F
ailu
re r
ate
Tim
e to
initi
ate
play
Scr
een
reso
lutio
n
No.
/typ
e of
inte
rfac
e co
ntro
ls
Tec
hnol
ogy
cost
/sch
edul
e
Leve
ls o
f di
ffic
ulty
Impa
ct r
esis
tanc
e
Num
ber/
type
s of
gam
es
Target Goals X - + - + + - + + +
+ # ##-
+++#+
#++
# +++ -
#
Technical Interactions
• Correlation matrix• Shows interaction of
technical requirements• Positive correlation
• Implies synergy• Cost advantages
• Negative correlation• Tradeoffs required
• Revisit Technical Requirements• Remove technical
requirement negative correlation
• Alternative approaches
Impo
rtan
ce
Hum
an F
acto
rs S
afet
y
Sof
twar
e D
esig
n
Par
t F
ailu
re r
ate
Tim
e to
initi
ate
play
Scr
een
reso
lutio
n
No.
/typ
e of
inte
rfac
e co
ntro
ls
Tec
hnol
ogy
cost
/sch
edul
e
Leve
ls o
f di
ffic
ulty
Impa
ct r
esis
tanc
e
Num
ber/
type
s of
gam
es
Target Goals X - + - + + - + + +
++ Strong Positive+ Weak Positive- Weak Negative# Strong Negative
++ Strong Positive+ Weak Positive- Weak Negative# Strong Negative
Technical Competitive Assessment
• Rate Own Company on the Technical Requirements
• Rate Competitors and compare
Target Values No
Saf
ety
Haz
ard
10,0
00 li
nes
of c
ode
MT
BF
900
,000
cyc
les
Avg
tim
e: 1
min
256
colo
rs,
320
x 19
2 pi
xels
5 in
put
devi
ces
$1M
/6m
onth
s
5 le
vels
20 f
t-lb
s
16 g
ames
/ 4
each
cat
egor
yOur Company 3 4 2 3 3 5 4 4 3 4Competitor B 4 4 2 2 4 3 3 4 4 2Competitor A 4 3 3 3 2 3 2 2 3 3
Technical Comparison
0123456
1 3 5 7 9
11
Our Company
Competitor B
Competitor A
Correlating Technical Requirements & Customer Needs
• Rate ability for Technical Requirement to satisfy customer need
• If I control (the technical requirement) it will (significantly/moderately/ slightly/or not) impact my customers needs to (specific customer need).
• Multiple rating systems• 9/3/1/0
• 5/3/1/0
• 4/2/1/0
Impo
rtan
ce
Hum
an F
acto
rs S
afet
y
Sof
twar
e D
esig
n
Par
t F
ailu
re r
ate
Tim
e to
initi
ate
play
Scr
een
reso
lutio
n
No.
/typ
e of
inte
rfac
e co
ntro
ls
Tec
hnol
ogy
cost
/sch
edul
e
Leve
ls o
f di
ffic
ulty
Impa
ct r
esis
tanc
e
Num
ber/
type
s of
gam
es
Target Goals X - + - + + - + + +
Easy to Use 4 5 5 3 3Not break easily 3 3 5 5Versatile controls 2 5 3 5Affordable 3 3 5 5 5 3 5 3 1 3Good visual effects 5 1 3 5 5Everybody can use it 3 3 1 3 5Sturdy Controls 4 3 5Interruptable Play 2 5Wide Assortment of Action 5 5 1 3 3 5 3 5No eye strain 3 5 5 5 5 5Don't get hurt using 4 5 3 3
Customer needs
Get
M
oney
's
Wor
th
Pro
vide
s C
ompe
titiv
e E
xcite
men
tS
afe
D
esi
gn
Scoring Results
• Compute absolute score• Weighted Importance of
Technical Requirements• Sum of correlation rating *
customer importance for a specific technical requirement
• Relative score• Weighted importance for a
technical requirement divided by total weighted importance (x100).
• Shows which technical requirements best satisfy customer needs
Impo
rtan
ce
Hum
an F
acto
rs S
afet
y
Sof
twar
e D
esig
n
Par
t F
ailu
re r
ate
Tim
e to
initi
ate
play
Scr
een
reso
lutio
n
No.
/typ
e of
inte
rfac
e co
ntro
ls
Tec
hnol
ogy
cost
/sch
edul
e
Leve
ls o
f di
ffic
ulty
Impa
ct r
esis
tanc
e
Num
ber/
type
s of
gam
es
Target Goals X - + - + + - + + +
Easy to Use 4 5 5 3 3Not break easily 3 3 5 5Versatile controls 2 5 3 5Affordable 3 3 5 5 5 3 5 3 1 3Good visual effects 5 1 3 5 5Everybody can use it 3 3 1 3 5Sturdy Controls 4 3 5Interruptable Play 2 5Wide Assortment of Action 5 5 1 3 3 5 3 5No eye strain 3 5 5 5 5 5Don't get hurt using 4 5 3 3
Weighted Importance 43 110 60 34 73 70 65 66 50 49Relative Weight 7 18 10 5 12 11 10 11 8 8
Customer needs
Get
M
oney
's
Wor
th
Pro
vide
s C
ompe
titiv
e E
xcite
men
tS
afe
D
esi
gn
Requirements Request Analysis
Formalizing the Request• Clearly stated• Categorized
• Discretionary/Non-discretionary
• Cost/Benefit
• Business Strategy Alignment, e.g.,• Migration to e-business• Corporate data access
• Technology Strategy Alignment, e.g.,• Commitment to middleware• Data base technology
RequirementsRequest
RequestScreening
BusinessStrategy
BusinessStrategy
TechnologyStrategy
TechnologyStrategy
Alignment Screening
Source: Andriole, Stephen J., Managing System Requirements, Methods,
Tools, and CasesMcGraw-Hill, 1996
Source: Andriole, Stephen J., Managing System Requirements, Methods,
Tools, and CasesMcGraw-Hill, 1996
ImperativeImperative PotentialValue
PotentialValue
DiscardDiscard
Requirements Request Analysis
• Captures description and source
• Prioritization• References to Use
cases and other documents
Requirement #: Requirement Type: Event/UseCase #:
Description:
Rationale:
Source:
Fit Criterion:
Customer Satisfaction: Customer Dissatisfaction:
Dependencies: Conflicts:
Supporting Materials:
History:
Snow Cards
Requirements Synthesis
• When are you done?• Have a plan and execute to plan.
• Diversity of stakeholders and customers
• Track knowledge churn• Dates/sources on SNOW cards• Revise plan if you are still learning• You’re done when your base stabilizes
– I.e., interviews and observations are only clarifying known requirements
Analysis Approach
• Stakeholders• Organization
• PMO• Value Proposition• Context Diagram• FMO
• Role Playing
• “ilities”• Perfomance• Reliability• Maintainability, etc.
Organizing the Requirements
• Context Diagram• Current Operation• Identify Business Events
or Use Cases• Process Orientation
• Affinity Diagrams• Mind Maps• Functional Orientation
• Document Archaeology• Identifies “things”• Data Orientation
Context Diagram
Customer
Software Reliability Engineering
• The reliability of a system as a function of time R(t), is the conditional probability that the system has (not failed) in the interval [0,t], given that it was operational at time t=0
• The most common reliability model is:
R(t) = e-t,
• where is the failure rate. • It is reasonable to assume that the failure rate is
constant even though faults tend to be clustered in a few software components.
Two-state Reliability Model
• In a two-state continuous-time Markov chain the parameters to be estimated are failure rate and repair rate .
• The Mean Time Between Failures (MTTF) = 1/ . • The Mean Time To Repair (MTTR)= 1/.• Availability = MTTF/(MTTF +MTTR) = 1/[1 + /]
• The goal of Software Fault Tolerance is to make Availability = 1.• This can be approached by making very small and/or by
making very large.
Maximizing Availability
Decreasing • Best Practices
• Case Tools• Traceability• Inspections• Testing
• Architecture• Re-use• Platforms• Factoring• Failure Protection SW
Increasing • Architecture
• Fail-over• Restarts
Software Reliability Engineering
• List Associated Systems• Base product and variations• Supersystems
• Implement Operational Profiles• An operation is a major system
task (use case)• Occurrence probability
• Engineer “Just Right” Reliability• a failure as any departure of
system behavior in execution from user needs
• choose a common measure for all failure intensities
• set the total system failure intensity objective (FIO) for each associated system
Requirements and
Architecture
Design and Implementati
on
Test
1. List Associated Systems
2. Implement Operational Profiles
3. Engineer “Just Right” Reliability
4. Prepare for Test 5. Execute Test
6. Guide Test
Control System Reliability
• Control Systems• If the system fails because the
time constraints are not satisfied the system is a real-time one.
• If the response time becomes arbitrarily long the system is an on-line one.
• Reliable Software• Demands that the computations
are completed in the required time.
• System does not degenerate due to:
• computational lags in controlling external equipment,
• round-off errors in computing control commands,
• truncation errors induced when equations are approximated.
ExternalEquipment
ComputerContaining
ControlEquations
= x(n) – y(n-1)
x(n)
Delays
y(n)y(n-1)
Wherex(n) is the physical input to the external equipment that is sampled and encoded with a certain number of bits or precision.y(n) is the computer output from the computers control equations using the error from the previous sampled time as the input
Other Functions
Impact on Requirements
• Quantification of Operations (use cases)
• Reliability Requirements• By Operation• Estimation of Value
• Analysis of Control Equations• Impact of Timing Variations• Numerical Analysis and Requirements for
bounding behavior
Reliability Requirements
• Availability• Percent Available• Programmed down time.
• Mean Time Between Failure (MTBF)• Usually in hours• Careful specification of “failure”
• Mean Time to Repair (MTTR)• Profile (90% restored in 5 minutes)• Careful specification of “restore”
• Accuracy• Precision in numerical outputs
• Maximum bugs or defect rate• Bugs per KLOC or bugs per function point
• Bugs per type• Minor, significant, critical
top related