CS 564 – On Requirements Lecture 4

1. CS 564 – On RequirementsLecture 4

2. QSE Lambda Protocol • Prospectus • Measurable Operational Value • Prototyping or Modeling • sQFD • Schedule, Staffing, Quality Estimates • ICED-T • Trade-off Analysis

3. Requirements Specification Spec • Project Title, Revision Number and Author • Scope and Purpose of the system • Measurable Operational Value • Description • Feature List including ICED T and Simplified QFD analysis • Interfaces • Constraints • Change Log and Expected Changes • Responses to the unexpected • Measurements • Glossary • References

4. Software Business Models Mass Market Niche General Product Centric Custom Software In-House Outsource Development Requirements • Functional – Industry • Configurable • Functional – Company specific

5. Software vs. Hardware Income Statement

6. Capitalization/Amoritization Intervals Research & Development Expense Product Realization Expense Marketing Expense Capitalization Amoritization Technical Feasibility General Availability Asset Balance=0

7. Income Statement Elements

8. Mapping Requirements to a Framework Elicitation Reports • ICED T • Intuition • Consistent • Efficient • Durable • Thoughtful • UML Framework • Use Cases • Structure • Business Rules PMO Models Requirements Use Cases Static Structure Activity Model

9. 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’

10. Simplified QFD (scale 0 to 10)

11. 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.

12. A Framework for Systems Analysis Source: Miser, Hugh J., Quade Edward S., Handbook of Systems Analysis Overview of Uses, Procedures, Applications, and Practices North-Holland, 1985 Forecasting Future Contexts Formulating The Problem Identifying, Designing, And Screening The Alternatives Building And Using Models For Predicting The Consequences Comparing And Ranking Alternatives Boundaries & Constraints Initiation Objectives Alternatives Consequences (Impacts) Communicate Results Values and Criteria Formulation Research Evaluation and Presentation

13. Systems Engineer Customer Needs Solutions Understand Domain Knowledge Communicate Domain Knowledge Customer Domain Development Domain

14. 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)

15. Work Areas for Systems Engineers Primary 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

16. Concept of Systems Engineering Tiers Master • Layers or Tiers • Many Applications • Business • Product Definition • Interrelates the Artifacts • Related to Craft Skill Model • Apprentice • Novice • Journeyman • Master Business Cases, Customer Value Proposition Tier 1 Context, Concepts, Framework, Architecture Tier 2 Skill Level Tier 3 Use Cases, Scenarios Tier 4 Detailed Requirements Novice

17. 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.

18. Requirements Specification Spec • Project Title, Revision Number and Author • Scope and Purpose of the system • Measurable Operational Value • Description • Feature List including ICED T and Simplified QFD analysis • Interfaces • Constraints • Change Log and Expected Changes • Responses to the unexpected • Measurements • Glossary • References

19. Required Measurements • Function Points • Logical Consistency from sQFD metrics • Stability = feature changes/month • ICED T

20. Key Question What’s the problem?

21. Time-Value of Money o 1 2 3 n PV =V0 V1 V2 V3 FV=Vn =V0(1+i) =V1(1+i) =V2(1+i) =V0(1+i)2 =V1(1+i)2 =V0(1+i)3 Engineering Economics Value of a Cash Flow Net Present Value Annual Benefit Annual Benefit Annual Benefit o 1 2 3 n Cost Cost Cost FV=PV(1+i)n

22. a a a a a (1+i)1 (1+i)3 (1+i)2 i (1+i)n (1+I)n -1 i(1+i)n Engineering Economics Value of an Annuity a a a a o 1 2 3 n a1=a0(1+i) a2=a0(1+i)2 a3=a0(1+i)3 an=a0(1+i)n … … PV = + + + + As n  PV = PV = a

23. Engineering Economics Value of a Cash Flow Net Present Value Annual Benefit Annual Benefit Annual Benefit o 1 2 3 n Cost Cost Cost

24. 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-Term Decision Making, Kenley, C. Robert, Armstead, Conference on Systems Integration, Stevens Institute of Technology, March 13, 2003

25. 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 Source: Discounting Models for Long-Term Decision Making, Kenley, C. Robert, Armstead, Conference on Systems Integration, Stevens Institute of Technology, March 13, 2003

26. A Live Experiment (Question 1) ALERNATIVE A ALTERNATIVE B • What is your preference: A or B? 14 Oct 2005 2:00 PM 15 Oct 2004 2:00 PM Source: Kenley, Armstead

27. A Live Experiment (Questions 2 & 3) ALERNATIVE A ALTERNATIVE B • Now what is your preference: A or B? • What is your preference on 14 October 2104? 14 Oct. 2005 2:00 PM 15 Oct. 2006 2:00 PM Source: Kenley, Armstead

28. 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! Source: Kenley, Armstead

29. Discounting Models Source: Kenley, Armstead

30. 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

31. 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

32. 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 Source: Kenley, Armstead

33. 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 Research Summary Source: Kenley, Armstead

34. 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 Source: Kenley, Armstead

35. Opportunity Analysis

36. Opportunity Analysis Technology Drivers Market Drivers Customer • 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 Generation Idea Filtering Concept Business & Technology Strategy Concept Validation Opportunity Definition Technical Prospectus Feasibility/Sizing Opportunity Evaluation Gate

37. Opportunity Analysis Concept of Operations Product Concept 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 Customer Benefit Model Technical Prospectus Market Sizing System Design Sizing Model Business Case

38. Defining the Problem Processes, Operations, & Expense • Understand Domain • Processes • Operations Strategy • Costs • Critical Problem • Root Cause of Costs • Pareto Analysis • Define Scope • Identify Constraints • Market Realities • Values • “Good” Solution Understand Domain Focus on Critical Problem Define Scope Define Values

39. Get the Big Picture CATV Operations Opportunity • 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

40. Subscriber Workflow Model 100 Customer Calls from 10 Subscribers Bulk Loading 8.5 Dispatches 8.5 Dispatches Inquiry Dispatch 85 Calls 4 Orders 4.5 Tickets 10 Orders 10 Orders Service Change 0.2 Orders STB Activation 5 Tickets Trouble Entry Screen 90 Orders 10 Rework

41. 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 Objectives Process Innovation System Definition Constraints Boundaries

42. 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

43. 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

44. (1+.05)5 -1 (1+i)n -1 = $259.7M PV = a = $60M .05(1+.05)5 i(1+i)n Or = $43 per Sub Case Study: PV of Benefits Present Value a a a a a o 1 2 3 4 5 What’s a? 6M customer deployment - $10/customer/year a = $60M per year

45. Relative Project Costs 4x 2x 1.5x 1.25x Relative Cost Range x 0.8x 0.67x 0.5x Concept of Operation Requirements Specifications Product Design Specifications Detailed Design Specifications Accepted Software 0.8x Feasibility Plans and Requirements Product Design Detailed Design Development and Test Phases and Milestones

46. 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

47. 7 Key Elements of VBSE • Benefits Realization Analysis • Stakeholders’ Value Proposition Elicitation and Reconciliation • Business Case Analysis • Continuous Risk and Opportunity Management • Concurrent System and Software Engineering • Value-Based Monitoring and Control • Change as Opportunity Source: Value-Based Software Engineering, Boehm, Barry, USC CSE Annual Research Review, March 18, 2003

48. DMR/BRA* Results Chain Order to delivery time is an important buying decision Reliable service is an important buying criteria Assumption Outcome Outcome Initiative Contribution Contribution Reduced order processing cycle Reduced MTTR (Intermediate Outcome) Implement New Network Operation Increased Video Sales Reduce Time to Provision Service Improve MTTR Improved service perception * DMR Consulting Group’s Business Realization Approach

49. 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.

50. Customer calls Repair Bureau Subscriber Trouble referred to Field Technician Repair Service Attendant creates a Trouble Ticket Trouble Tickets Trouble referred to dispatch Screener picks up Trouble Ticket Screener retrieves line card for telephone line and screen trouble Trouble referred to test Line Card Tub File Trouble referred to switching Switching Center Repair Center Circa 1970