CS 564 – On Requirements Lecture 4

CS 564 – On RequirementsLecture 4

QSE Lambda Protocol

• Prospectus

• Measurable Operational Value

• Prototyping or Modeling

• sQFD

• Schedule, Staffing, Quality Estimates

• ICED-T

• Trade-off Analysis

Requirements Specification Spec

1. Project Title, Revision Number and Author2. Scope and Purpose of the system3. Measurable Operational Value4. Description5. Feature List including ICED T and Simplified QFD

analysis6. Interfaces7. Constraints8. Change Log and Expected Changes9. Responses to the unexpected10. Measurements11. Glossary12. References

Software Business Models

Mass MarketMass Market NicheNicheGeneral

Product CentricProduct Centric CustomCustomSoftware

In-HouseIn-House OutsourceDevelopment

OutsourceDevelopment

Requirements •Functional – Industry

•Configurable

•Functional – Company specific

Software vs. Hardware Income Statement

Hardware Software ConsultingProduct Centric Custom

($M) ($M) ($M)

Revenue $300 $300 $300Costs Cost of Sales $190 $20 $150 Amortization $0 $60 $0 Total Incurred Costs $190 $80 $150

Margin $110 $220 $150% Margin 37% 73% 50%

Expenses Development $10 $100 $50 Marketing/Sales $65 $65 $65 Distribution $10 $0 $0 G & A $5 $5 $5 Total Expenses $90 $170 $120

Other Income $0 $5 $0

Operating Income $20 $50 $30

OROS 7% 17% 10%

Capitalization/Amoritization Intervals

Research & Development Expense

Technical Feasibility

Product Realization Expense

General Availability

Capitalization

Marketing Expense

Amoritization

Asset Balance=0

Income Statement Elements

Line Item Hardware Software Consulting

Revenue Hardware Revenue and Maintenance

Licensing, services and maintenance

Services and Maintenance

Cost of Sales Manufactured and purchased componentsDedicated labor to assemble

Purchased componentsInstallation services

Labor related to deliverables

Amortization Writing off capitalized R&D

Margin Revenue minus Costs Revenue minus Costs Revenue minus Costs

Development Expenses

R&D to develop hardware R&D to develop software R&D to develop practices and non-billable hours

Marketing & Sales Sales and marketing program costs

Sales and marketing program costs

Sales and marketing program costs

Distribution Cost of distribution

G&A Overhead Overhead Overhead

Other Income Co-marketing income

Operating Income Revenue minus Costs minus Expenses

Revenue minus Costs minus Expenses

Revenue minus Costs minus Expenses

Mapping Requirements to a Framework

• ICED T• Intuition• Consistent• Efficient• Durable

• Thoughtful

• UML Framework• Use Cases• Structure • Business Rules

PMO Models

Requirements

ElicitationReports

Use Cases

Use Cases

Static Structure

Static Structure

Activity Model

Activity Model

ICED T Mappings

• Ratings• 1= ‘Worst I have ever seen’• 2 = ‘Worse than Average’• 3 = ‘Average, like most other systems’• 4 = ‘Better than Average’• 5 = ‘Best I have ever seen’

Simplified QFD (scale 0 to 10)

Features/

Functions

Track Delivery Trucks

.On-line Customer Inquiry

Credit Check

1. Easy to Order

0 9 3

2. 10% Less Inventory

0 0 0

3. 20% Profit Increase

3 9 9

4. Speed Product Introduction

0 9 0

Total 3 27 12

Systems Engineering

Systems Engineering

“An interdisciplinary approach and means to enable the realization of successful systems.”

– INCOSE (The International Council on Systems Engineering)

System:

“A group of interacting, interrelated, or interdependent elements that together form a complex whole.”

– NGE Project (Next Generation Education Project)

A systems engineer has smart friends.

A Framework for Systems Analysis

FormulatingThe

Problem

Identifying,Designing,

AndScreening

TheAlternatives

BuildingAnd

Using ModelsFor

PredictingThe

Consequences

ComparingAnd

RankingAlternatives

Initiation

Boundaries & Constraints

Objectives

Values and Criteria

Alternatives

ForecastingFuture

Contexts

Consequences (Impacts)

Communicate Results

Formulation Research Evaluation and Presentation

Source: Miser, Hugh J., Quade Edward S., Handbook of Systems Analysis Overview of Uses, Procedures,

Applications, and PracticesNorth-Holland, 1985

Source: Miser, Hugh J., Quade Edward S., Handbook of Systems Analysis Overview of Uses, Procedures,

Applications, and PracticesNorth-Holland, 1985

Systems Engineer

CustomerNeeds

CustomerNeeds SolutionsSolutions

UnderstandDomain

Knowledge

UnderstandDomain

Knowledge

CommunicateDomain

Knowledge

CommunicateDomain

Knowledge

Customer Domain Development Domain

Some SE Foundation Concepts

• System Architecture Planning and Business Planning are not separate disciplines, but are a part of Systems Engineering

• Good Front End decisions of necessity are not serial, but a cascaded series of iterative decisions, at various levels, that optimize across:

• Customer Driven Requirements• Architecture requirements and needs (Function, Form, Economy and Time)• Business Strategies, sales needs and related considerations

• The difficulty in balancing these factors cannot be over-emphasized • There are many complex, inter-relating issues to solve• Zealots of various kinds can force particular views, losing balance

• In the final analysis, the above is an art, and any and all insights/data, etc. can help (even clairvoyance)

Work Areas for Systems EngineersPrimary work products:

• Gathering of customer needs and technology opportunities• Opportunity analysis, problem definition and objectives selection• Solution synthesis and analysis• System architecture and alternative selection including developing• business cases• Product specification including requirements generation • and documentation• Development planning to select implementation plan• Project feedback assessment and documentation

Interdisciplinary Skills:• People • Business• Financial• Technical

• • •

Concept of Systems Engineering Tiers

• Layers or Tiers• Many Applications

• Business

• Product Definition

• Interrelates the Artifacts

• Related to Craft Skill Model• Apprentice• Novice• Journeyman• Master

Tier 1Tier 1

Tier 2Tier 2

Tier 3Tier 3

Tier 4Tier 4

Context, Concepts, Framework, Architecture

Use Cases, Scenarios

Detailed Requirements

Business Cases, Customer Value Proposition

Skill Level

Master

Novice

Requirements Engineering Success

• Do the Right Thing• Evaluate Opportunities

• Customer Benefits• Business Case• Feasible Project

• Do It the Right Way• Valid Requirements

• Focused on Customer Value• Customer Agreement• Clearly communicated to Development, etc.

Requirements Specification Spec

1. Project Title, Revision Number and Author2. Scope and Purpose of the system3. Measurable Operational Value4. Description5. Feature List including ICED T and Simplified QFD

analysis6. Interfaces7. Constraints8. Change Log and Expected Changes 9. Responses to the unexpected10. Measurements11. Glossary12. References

Required Measurements

• Function Points

• Logical Consistency from sQFD metrics

• Stability = feature changes/month

• ICED T

Key Question

• What’s the problem?

Engineering Economics

=V0(1+i) =V1(1+i) =V2(1+i)

=V0(1+i)2 =V1(1+i)2

=V0(1+i)3 FV=PV(1+i)n

PV =V0 V1 V2

o 1 2 3

V3

n

FV=Vn

Time-Value of Money

o 1 2 3 n

Value of a Cash Flow

Annual Benefit

Net Present Value Annual

BenefitAnnual Benefit

Cost Cost Cost


PV =

a1=a0(1+i) a2=a0(1+i)2

o 1 2 3 n

Value of an Annuity

a a a a

a3=a0(1+i)3 an=a0(1+i)n

a

(1+i)1+

a

(1+i)2+

a

(1+i)3+

a

(1+i)n+… …

PV =(1+I)n -1

i(1+i)na PV =

As n a

i


o 1 2 3 n

Value of a Cash Flow

Annual Benefit

Net Present Value Annual

BenefitAnnual Benefit

Cost Cost Cost

Interval 1/(1+I)**n Benefit Costs Cash FlowPresnt Value Interest

($K) ($K) ($K) ($K) 5%0 1.000 $500 ($500) ($500)1 0.952 $2,500 ($2,500) ($2,381)2 0.907 $2,000 ($2,000) ($1,814)3 0.864 $5,000 $500 $4,500 $3,8874 0.823 $5,000 $500 $4,500 $3,7025 0.784 $5,000 $500 $4,500 $3,526

Net Present Value $6,420

The Origin of Discounting

• Samuelson showed in 1937 under certain assumptions that the value today of something received k years from today is its value when received in year k discounted by the factor 1/(1+i)k, where i is a positive number

• He specifically made statements that• The model had no demonstrated descriptive validity with

respect to empirical data• The model had no prescriptive validity as a method of

determining social welfare

• Nevertheless, Samuelson’s constant rate discounting is now the method prescribed by the U.S. government and others for making life cycle cost comparisons

Source: Discounting Models for Long-TermDecision Making, Kenley, C. Robert, Armstead,

Conference on Systems Integration,Stevens Institute of Technology,

March 13, 2003



March 13, 2003

Problems of Constant Rate Discounting

• Discrete Time• A cost occurring at the beginning of an

interval is discounted the same as a cost on the last day of an interval

• Preference Stationarity • Delay can change preference implying that

the model is inaccurate



March 13, 2003



March 13, 2003

A Live Experiment (Question 1)

14 Oct2005

2:00 PM

15 Oct2004

2:00 PM

ALERNATIVE A ALTERNATIVE B

• What is your preference: A or B?

Source: Kenley, ArmsteadSource: Kenley, Armstead

14 Oct.2005

2:00 PM

15 Oct.2006

2:00 PM

ALERNATIVE A ALTERNATIVE B

A Live Experiment (Questions 2 & 3)

• Now what is your preference: A or B?• What is your preference on 14 October 2104?


Definition: Preference Reversal

• When A is preferred to B at one time but B is preferred to A at another (later) time

• For instance, one might prefer 1 candy bar today to 2 candy bars tomorrow, but one would surely prefer 2 candy bars in one year and one day to 1 candy bar in a year

• Constant rate discounting does not allow preference reversal!


Discounting Models

Discounting M odel Name

Time Perception Function (t)

Discount Factor w t at Time t

Constant Rate t

1 1 i t

Exponential

h

ln (1 i)t

1 e h t

Hyperbolic

h

glog 1 i (1 gt )

1 1 gt hg

Relative

h log 1 i (1 t )

1 1 t h

Proportional

log 1 i (1 gt )

1 1 gt


Constant

• If the time difference between receipt of 1 candy bar and 2 candy bars is constant, the preferences remain the same• If 1 candy bar 1 day from today is

equivalent to 2 candy bars 2 days from today, then

• 1 candy bar 1 year from today is equivalent to 2 candy bars 1 year and 1 day from today

• 1 candy bar 4 years from today is equivalent to 2 candy bars 4 years and 1 day from today

Relative Rate Discounting

• The preference relationship is relative in that if ratio of the delay is constant then the ratio of the equivalent rewards is constant• If 1 candy bar 1 day from today is

equivalent to 2 candy bars 2 days from today, the 1 candy bar 1 year from today is equivalent to 2 candy bars 2 years from today

Preference Implication for Proportional Discounting

• The preference relationship is proportional in that the acceptable amount of delay is proportional to the amount of reward• A delay of 1 year for 1 candy bar is equivalent to a delay of 4 years for 4

candy bars


Research Summary

• Empirical studies all agree that proportional discounting best fits data

• Proportional discounting allows for preference reversals

• Proportional discounting can be derived from the same type of axiomatic rationale as constant discounting

• Constant discounting has an inherent 40-year maximum


Selecting A Proportional Discount Parameter

• At year 30, a proportional model with parameter g = 7.2% is equivalent to a constant discount rate of 3.9% applied to cost and benefits incurred in year 30

• 3.9%is the OMB-approved rate for 30-year internal government project tradeoff analyses

• This provides an “anchor point” for proportional discounting to match the OMB guidance

1

1 0.072 30

1

1.03930

Years 3 5 7 10 30

OMB Approved Constant Discount Rate 0.021 0.028 0.030 0.031 0.039


Opportunity Analysis


• Opportunity Valuation• Customer Value• Willingness to pay• Market Size

• Strategic Fit• Business Direction• Product Direction

• Manageable Risks• Incremental • Bounded• Exit Strategies• Core Competency Match

Idea Filtering

Business & TechnologyStrategy

Business & TechnologyStrategy

TechnologyDrivers

MarketDrivers

Customer

TechnicalProspectus

TechnicalProspectus

Idea Generation

OpportunityDefinition

Feasibility/Sizing

OpportunityEvaluation

Gate

Concept Concept

ConceptValidation


Technical Prospectus• Basis for the Concept of

Operations document• Product Concept• Constraints• Trade-Off Analysis

• Support the Preliminary System Design• Product Concept• Sizing Model

• Support Business Case• Customer Benefit Model• Market Sizing

TechnicalProspectus

TechnicalProspectus

Concept ofOperations

Concept ofOperations

CustomerBenefitModel

CustomerBenefitModel

Market Sizing

Market Sizing

Sizing Model

Sizing Model

System Design

System Design

ProductConcept

ProductConcept

BusinessCase

BusinessCase

Defining the Problem

• Understand Domain• Processes• Operations Strategy• Costs

• Critical Problem• Root Cause of Costs• Pareto Analysis

• Define Scope• Identify Constraints• Market Realities

• Values• “Good” Solution

UnderstandDomain

Processes,Operations,& Expense

Processes,Operations,& Expense

Focus onCritical

Problem

DefineValues

Define Scope

Get the Big Picture

• Management Concerns• New Services• Reduce Debt

• Must get OPEX Savings

• Operations represents ~35% of the total expense before taxes

• About $14 per subscriber per month

• Software can often be used to reduce operations expenses

• Expense savings flow directly to the bottom line

• Examples?• Web Access• Bundling of activities• Reduction of Back Office

CATV Operations Opportunity

CATV Expenses

37%

13%11%

17%

7%

15% Content & Interconnect

Marketing & Sales

Custpmer Service

Technicians

G&A

Debt Service

Workflow Model

TroubleEntry

TroubleEntry

ServiceChangeServiceChange

DispatchDispatch

STB ActivationSTB Activation

100 Customer Calls from 10 Subscribers

10 Orders

4 Orders85 Calls

4.5 Tickets

8.5 Dispatches

0.2 Orders

Bulk Loading

8.5 Dispatches

90 Orders

10 Rework

Subscriber

InquiryInquiry

5 Tickets

10 Orders

ScreenScreen

Formulating a Solution

• Objectives• Customer Key Strategies

• Process Approach• Mechanization• Business Process Automation• Business Process

Improvement• Business Process Re-

Engineering

• Constraints• Business• Industry Practices

• Boundaries• Scope of the System

SystemDefinition

Objectives

ProcessInnovation

Constraints

Boundaries

PMO Workflow Model

Need to Capture Key Activities & Costs

Model where you have impact Lower call volume

Web Svcs Lower Dispatch rate

Correlation of troubles

Customer Self-Install

Need to cross check with other data

Overall Expense Consistent with Labor

Allocation

Operations Labor

49%

7%6%

21%

17% 0%

CSRs Dispatch Clerks Line Techs

New Install Techs Svc/Mtce Techs Contract Install

Activity/Task

Work Content

(hrs)Rate ($/hr) Cost ($)

Work Occur Automation ReWorkContent Factor(hr)

Customer SvcsBilling Inq 0.05 4.00 0.0% 0.5% 0.20 $50.00 $10.05Svc Inq 0.05 4.00 0.0% 2.0% 0.20 $50.00 $10.20New Acct & Video Svc 0.30 0.20 0.0% 2.0% 0.06 $50.00 $3.06New Data Svc 0.30 0.20 0.0% 2.0% 0.06 $50.00 $3.06Vertical Svc 0.10 0.40 0.0% 2.0% 0.04 $50.00 $2.04Disconnect 0.10 0.20 0.0% 0.5% 0.02 $50.00 $1.01

Trouble Report 0.05 0.50 0.0% 0.0% 0.03 $50.00 $1.25Svc Inq 0.05 0.50 0.0% 0.0% 0.03 $50.00 $1.25

DispatchScreen Troubles 0.10 0.50 0.0% 0.0% 0.05 $50.00 $2.50Loading 0.05 0.85 0.0% 0.0% 0.04 $50.00 $2.13

TechnicianDispatch Install Video 0.50 0.20 0.0% 5.0% 0.11 $100.00 $10.50Dispatch Disc Ord 0.50 0.20 0.0% 20.0% 0.12 $100.00 $12.00Disp Cust Install Data 0.50 0.20 90.0% 5.0% 0.02 $100.00 $1.50Trouble 0.50 0.45 0.0% 5.0% 0.24 $101.00 $23.86

STB ActivationUpdate STB 0.20 0.00 0.0% 2.0% 0.02 $50.00 $1.00

Labor per Subscriber per Year 1.23 $85.40

Activity Cost (hrs)

FMO Operations

• Key System Attributes• Web to offload

Customer Services

• Correlation of troubles to equipment outages

• Customer STB Turn-Up

• Savings• ~$10 per sub

per year

Activity/Task

Work Content

(hrs)Rate ($/hr) Cost ($)

Work Occur Automation ReWorkContent Factor(hr)

Customer SvcsBilling Inq 0.05 4.00 25.0% 0.5% 0.15 $50.00 $7.55Svc Inq 0.05 4.00 25.0% 2.0% 0.15 $50.00 $7.70New Acct & Video Svc 0.30 0.20 5.0% 2.0% 0.06 $50.00 $2.91New Data Svc 0.30 0.20 5.0% 2.0% 0.06 $50.00 $2.91Vertical Svc 0.10 0.40 25.0% 2.0% 0.03 $50.00 $1.54Disconnect 0.10 0.20 25.0% 0.5% 0.02 $50.00 $0.76

Trouble Report 0.05 0.50 0.0% 0.0% 0.03 $50.00 $1.25Svc Inq 0.05 0.50 0.0% 0.0% 0.03 $50.00 $1.25

DispatchScreen Troubles 0.10 0.50 25.0% 0.0% 0.04 $50.00 $1.88Loading 0.05 0.85 0.0% 0.0% 0.04 $50.00 $2.13

TechnicianDispatch Install Video 0.50 0.20 65.0% 5.0% 0.04 $100.00 $4.00Dispatch Disc Ord 0.50 0.20 0.0% 20.0% 0.12 $100.00 $12.00Disp Cust Install Data 0.50 0.20 90.0% 5.0% 0.02 $100.00 $1.50Trouble 0.50 0.45 0.0% 5.0% 0.24 $100.00 $23.63Disp Cust Install Video 0.5 0.00 0.0% 5.0% 0.00 $100.00 $0.00STB Shipping 0.60 0.13 0.0% 0.0% 0.08 $50.00 $3.90

STB ActivationUpdate STB 0.20 0.80 98.0% 2.0% 0.01 $50.00 $0.32

Labor per Subscriber per Year 1.09 $75.21

Activity Cost (hrs)

Case Study: PV of Benefits

o 1 2 3 5

Present Value

a a a a

(1+i)n -1

i(1+i)nPV = a

4

a

What’s a?

6M customer deployment - $10/customer/year

a = $60M per year

(1+.05)5 -1

.05(1+.05)5= $60M = $259.7M

Or = $43 per Sub

Relative Project Costs

Relative Cost Range x

1.25x

1.5x

2x

4x

0.8x

0.5x

0.8x

0.67x

Phases and Milestones

Feasibility

Concept of Operation

Plans and Requirements

Requirements Specifications

Product Design

Product Design Specifications

Detailed Design

Detailed Design Specifications

Development and Test

Accepted Software

Motivation for Value-Based Software Engineering

• Current Software Engineering Methods are basically value neutral• Every requirement, use case, object, and defect is equally

important• Object oriented development is a logic exercize• “Earned Value” systems don’t track business value• Separation of concerns: SE’s job is to turn requirements into

verifiable code• Practitioners escape from blame

• Value-neutral SE methods are increasingly risky• Software decisions increasingly drive system value• Corporate adaptability to change achieved via software

decisions• System value-domain problems are the chief sources of

software project failures Source: Value-Based Software Engineering, Boehm, Barry, USC

CSE Annual Research Review,March 18, 2003

Source: Value-Based Software Engineering, Boehm, Barry, USC


7 Key Elements of VBSE

1. Benefits Realization Analysis2. Stakeholders’ Value Proposition Elicitation

and Reconciliation3. Business Case Analysis4. Continuous Risk and Opportunity

Management5. Concurrent System and Software

Engineering6. Value-Based Monitoring and Control7. Change as Opportunity





DMR/BRA* Results Chain

Initiative

* DMR Consulting Group’s Business Realization Approach

Outcome OutcomeContribution Contribution

AssumptionOrder to delivery time is an important buying decision

Reliable service is an important buying criteria

Implement New Network Operation

Reduce Time to Provision Service

Improve MTTR

Reduced order processing cycle

Reduced MTTR

(Intermediate Outcome)

Improved service perception

Increased Video Sales

Case Study: Repair Operations System

• In the 1970’s, New York Telephone was experiencing a service crisis. Customers had complained to the PUC about NYTel’s service level for telephone repair.

• Complaints ranged from long repair times, lost trouble tickets, and missed appointments.

• NYTel was facing fines for poor performance.• NYTel believed that computerization of the

repair records would enable them to improve service and to clearly report on their performance.

Repair Center Circa 1970

Subscriber

Line Card Tub File

TroubleTickets

Customer calls Repair Bureau

Repair Service Attendant creates a Trouble Ticket Screener picks

up Trouble Ticket

Screener retrieves line card for telephone line and screen trouble

Trouble referred to dispatch

Trouble referred to test

Trouble referred to Field Technician

SwitchingCenter

Trouble referred to switching

Repair Center Operations Circa 1970

• Centers cover approximately 25K lines• Trouble rate is 1/line/yr.• Average Busy Hour is unknown but a busy day for a 25K line office is 135 troubles.• Most troubles are taken between 9 and Noon.

• Most Personnel at $40K/yr loaded salary• Testers are at $60K/yr loaded salary• Screening function removes tester load.

• RSA function• One of the customer complaints is that RSB phones are not answered.• Hold times for a trouble report are 2 minutes.• NYT has set an objective to answer calls within 30 seconds in the busy hour.

• Screeners perform a variety of functions• Complete troubles from the field during the busy end of day closeout.• Update Line Record file for service order and cable maintenance activity

• Order activity is 1 order/line/year

• Track and complete tickets referred to switching or cable maintenance.

• Management is a critical issue• Cannot find TR when customer wants current status.• Difficult to tell how mis-matched force is to load.

• Customer Environment• Environment is largely manual records.• Exception is there is a locally developed service order processor that can provide a batch file of

completed service orders• The service order will contain services the customer ordered and plant assigned to those services.

Workflow Model

TroubleTicket

Creation

TroubleTicket

CreationScreeningScreening TestingTesting

DispatchDispatch

SwitchingSwitching

200 Customer Calls

100 Troubles

72 Troubles

Network Systems Western Electric

STARNET

STARNET

STARNET

STARNET

100 Troubles

20 Troubles

57 Troubles

8 Troubles

37 Troubles

Subscriber

3 Troubles

5 Troubles

30 Troubles Test OK

5 Troubles Closed

AM Load

PM Load

Assignment

• Define objectives, operations strategies, and a solution concept for NYT’s problem

• Construct a benefit model for the solution.

• Determine the NPV for the benefits.• Use a term of 5 years and 8% interest.

Automation of Provisioning

Provisioning Functions

1. Accept, edit and process service orders.

2. Interpret service order -- translate it to a request for “so many pairs at such-and-such an address.”

3. Assign the pairs -- find unused pairs for the service; rearrange existing telephone company pairs as needed.

4. Assign central office equipment -- connect the assigned pairs to the main distributing frame.

5. Request telephone company people to make the needed connections if none already exist.

6. Activate dial tone.

7. Rearrange telephone company plant as new pairs are installed in anticipation of neighborhood growth.

8. Assign new pairs when repair is needed

Goal: Flow-Through Provisioning

Technicians

Cost of Work Today Technician

New Costof Work

SystemAdministrator

Cost of SystemOperation

Cost of System

Hardware

Software

Training

Standards ReuseProcesses

ToolsTechnology

$100m/yr

Developer

Benefits of Automation

Organization Structure

SYSTEM REQ.S

ALGORITHMS

TRANSACTIONPROJECTIONS

FEATUREENGINEERING

ARCHITECTURE

TRAFFICENGINEERING

ENGINNERINGREPORTS SUPPORT/ OPERATIONS

- COMPUTER CENTER - DEVELOP.MACHINE - TEST MACHINE

SOFTWAREDEVELOPMENT

HUMAN FACTORS

DEVELOPMENT

SOFTWAREMANUFACTURE INTEGRATION

TO SITES

Project A: Order Reading and Analysis Software

Size of Prototyping Effort: 12K lines of C Code (10% of final system module) Purpose: Find a method for order reading and analysis, applicable to variable formats. Duration and Staff of Prototype:

Four people for eight months.

Experience:

1. Final requirements based on prototype results.

2. Alerted developers' to the possibility of a having a tunable system.

3. Early evaluation of functional decomposition and performance showed bottlenecks in the dispatcher.

4. Eliminated the possibility of reusing code from another project.

5. Prototype was thrown away due to decomposition and performance problems.

Project B: Outside Plant Data Base System

Size of Effort: 5% of 500K line of source code. Purpose:

To evaluate database structures for an outside plant data and to experiment with approaches to handling multiple future states of equipment usage. Duration: Three people for 15 months.

Experience:

1. A data base structure using hyper graph theory was invented.

2. An algorithm for handling both time-driven and event-driven assignments was invented

3. The prototype became the basis for the production code.

4. UNIX flat files were used to model loop plant by way of a directed graph.

5. The prototype showed database portability from Unix to the Mainframe.

Why bad things happen to good systems

• Customer buys working software product.

• System works with 40-60% flow- through

• Developers make requested changes

BUT

• Customer refuses critical Module

• Customer demands 33 enhancements and allows data corruption

• Developers misgauge extent of changes

CONCEPT of Operations TemplateTable of Contents

• 1. Scope • 2. References• 3. Definitions • 4. Concept of Operations Document Guide • 4.1 SCOPE (Clause 1 of the ConOps Document)

• 4.1.1 Identification (1.1 of the ConOps Document).

• 4.1.2 Document Overview (1.2 of the ConOps Document).• 4.1.3 System Overview (1.3 of the ConOps Document

• 4.2 REFERENCED DOCUMENTS (Clause 2 of the ConOps Document).

• 4.3 THE CURRENT SYSTEM OR SITUATION (Clause 3 of the ConOps Document).

• 4.3.1 Background, Objectives, and Scope (3.1 of the ConOps Document).

• 4.3.2 Operational Policies and Constraints (3.2 of the ConOps Document).

• 4.3.3 Description of the Current System or Situation (3.3 of the ConOps Document).

• 4.3.4 Modes of Operation for the Current System or Situation (3.4 of the ConOps Document).

• 4.3.5 User Classes and Other Involved Personnel (3.5 of the ConOps Document).

• 4.3.6 Support Environment (3.6 of the ConOps Document).

• 4.4 JUSTIFICATION FOR AND NATURE OF CHANGES (Clause 4 of the ConOps Document).

• 4.4.1 Justification for Changes (4.1 of the ConOps Document).

• 4.4.2 Description of Desired Changes (4.2 of the ConOps Document).

• 4.4.3 Priorities Among Changes (4.3 of the ConOps Document).

• 4.4.4 Changes Considered but not Included (4.4 of the ConOps Document).

• 4.4.5 Assumptions and Constraints (4.5 of the ConOps Document).

• 4.5 CONCEPTS FOR THE PROPOSED SYSTEM (Clause 5 of the ConOps Document).

• 4.5.1 Background, Objectives, and Scope (5.1 of the ConOps Document).

• 4.5.2 Operational Policies and Constraints (5.2 of the ConOps Document).

• 4.5.3 Description of the Proposed System (5.3 of the ConOps Document).

• 4.5.4 Modes of Operation (5.4 of the ConOps Document).• 4.5.5 User Classes and Other Involved Personnel (5.5 of

the ConOps Document).• 4.5.6 Support Environment (5.7 of the ConOps Document).

• 4.6 OPERATIONAL SCENARIOS (Clause 6 of the ConOps Document).

CONOPS Template• 4.7 SUMMARY OF IMPACTS (Clause 7 of the

ConOps Document).• 4.7.1 Operational Impacts (7.1 of the ConOps

Document).• 4.7.2 Organizational Impacts (7.2 of the ConOps

Document).• 4.7.3 Impacts During Development (7.3 of the

ConOps Document).

• 4.8 ANALYSIS OF THE PROPOSED SYSTEM (Clause 8 of the ConOps Document).

• 4.8.1 Summary of Improvements (8.1 of the ConOps Document).

• 4.8.2 Disadvantages and Limitations (8.2 of the ConOps Document).

• 4.8.3 Alternatives and Trade-offs Considered (8.3 of the ConOps Document).

• 4.9 NOTES (Clause 9 of the ConOps Document).

• 4.10 APPENDICES (Appendices of the ConOps Document).

• 4.11 GLOSSARY (Glossary of the ConOps Document).

• Assignment Template• Objectives• Problem Description

• PMO Description

• Operations Strategies• Solution Description

• FMO Description

• Solution Architecture

• System Features

• Customer Business Case• Customer Benefits

• Customer Costs

• Operations Modelb• Use Cases

• Transaction Model

• Business Case• Potential Market

• Income Statement

CS 564 – On Requirements Lecture 4

Documents

Transcript of CS 564 – On Requirements Lecture 4