1. Naseer Jan Course Instructor : Dr. Huang Value-based requirements engineering CSE 5316/7316 Software Requirements Fall 2013 Computer science Department, Lyle school of engineering, SMU

2. Outline  Requirements engineering  Large scale requirements engineering  VBSE brief overview  Motivation and definitions  VBSE Agenda  Seven key practices 1.Benefits Realization Analysis 2.Stakeholders’ Value Proposition Elicitation and Reconciliation 3.Business Case Analysis 4.Continuous Risk and Opportunity Management 5.Concurrent System and Software Engineering 6.Value-Based Monitoring and Control 7.Change as Opportunity  Value-Based Requirements engineering

3. Requirement Engineering  Requirement engineering is a process, which is a proper set of activities in a well structured manner for discovering, documenting and maintaining large number of requirements  Requirements engineering process contain set of activities: – Requirements Elicitation – Requirement Analysis and Negotiation – Requirements Validation – Requirements Prioritization – Requirements management

4. Requirements elicitation  Interface prototyping  Meeting Discussion  Brainstorming  Structured or semi structured Interview  Group Meetings  Workshop  Questionnaires  Prototyping  Expert Interviews  Observation  Scenarios  Business case analysis  Demonstrations and walkthroughs  Document extraction

5. Requirements Prioritization  Requirements prioritization is as an activity in which the requirements are prioritized in terms of cost, value and risk – Requirement prioritization plays a key role in software development life cycle. The risk of software failure is reduced up to greater extent with the help of requirements prioritization – The most important requirements are identified with the help of requirements prioritization

6. Requirements Prioritization Techniques  There are different requirements prioritization techniques for the prioritization of requirements. Each technique usage and importance varies in various situation and area Analytic Hierarchy Process (AHP) Planning Game AHPcPG (AHP combined PG) Cumulative Voting or 100 Dollars EVOLVE Hierarchical Cumulative Voting (HCV) Binary Search tree (BST)

7. Analytic Hierarchy Process (AHP) AHP is well known and is considered very helpful technique in making of decisions in requirement engineering. Requirements are compared on the basis of relative value and cost by using AHP technique According to AHP method we placed the candidate requirements in m x n matrix and then performed pair-wise comparison in order to find their relative value

8. AHP (Cont..) Find sum of Row Eigen Vector

9. AHP(Cont..) Consistency Ratio result should be less than 0.10 (Ideal Prioritization)

10. AHP(Cont..) Value distribution of requirements Cost distribution of requirements

11. AHP(Cont..) Cost-value distribution of requirements

12. Planning Game

13. AHPcPG Cost-value analysis for pile 1, Pile 2, Pile 3

14. 100 Dollars Cumulative voting is also known as hundred dollar method which is considered as simple and easy method for the prioritization of requirements Its importance has been seen in the political setup Hundred dollar method is a simple approach 100$ is given to the stakeholders Stakeholder assign and distribute hundred dollars among different requirements

15. Evolve Evolutionary and incremental approach helpful in decision making for software releases Evolve approach make use of genetic algorithm AHP technique for stakeholders Cross over and mutation is also done

16. Hierarchical Cumulative Voting (HCV) HCV is simple, easy and efficient way of prioritizing the requirements In this method different level of hierarchies (i.e. categories like HLH1....n and LLH1....n) in the developing product are identified and then the requirements are placed in those hierarchies using CV (also called 100$) method It is not necessary to prioritize different level of hierarchies at the same time

17. A NALYSIS OF INDUSTRIES Analysis of twenty seven companies----- case studies in terms of prioritization techniques from year 2003 to 2006

18. Bespoke requirements engineering

19. Market driven requirements engineering(MDRE)

20. Requirements Lifecycle Management  Requirement Driven Evolution Model process (RDEM)

21. Requirements Lifecycle Management  REPEAT (Requirements Engineering Process At Telelogic)

22. Requirements Abstraction Model (RAM)  Requirements Abstraction Model (RAM)  Action Step One – Specify (elicit) – Description – Reason/Benefit/Rationale – Restrictions/Risks – Title  Action Step Two – Place – Product Level – Feature Level – Function Level – Component Level  Action Step Three – Abstraction (Work-up) This third step of RAM involves abstracting and/or breakdown of a requirement, depending on the initial placement of the original requirement. The work-up process involves creating new requirements (called work-up requirements hereafter) on adjacent abstraction levels or linking to already existing ones, depending on the situation.

23. Post-release Analysis of Requirements Selection Quality (PARSEQ) Step 1: Requirements Sampling Step 2: Re-estimation of Cost and Value Step 3: Root Cause Analysis Step 4: Elicitation of Improvements improving the release planning activity in project management. The method is based on a re -evaluation of candidate requirements for prior releases in order to uncover release planning decisions that would have been made differently today

24. Gap Analysis

25. Customer Value analysis

26. Customer Value Drivers

28. Product management reference framework

30. MDRE (cont..)  Market-driven Requirements Engineering Challenges – Simple techniques for basic needs – Communication gap between marketing staff and developers – Writing understandable requirements – Requirements Dependencies – Managing the constant flow of new requirements – Requirements volatility – Requirements traceability and interdependencies – Requirements are invented rather than discovered – Implementing and improving RE within the organization – Resource allocation to RE – Organizational stability – Selecting the right process – Release planning based on uncertain estimates – Selection / Release Planning  Fixed Releases (time-to-market)  Estimation  Prioritization – Gap between Marketing/Management and Technical Management/ Development – Market Pull vs. Technology Push

31. MDRE vs Bespoke Objectives and Initiations – objective of MDRE is to hit the market segments by delivering right product with appropriate features at right time to take and enhance market shares, whereas in Bespoke the fulfillment of contract and adherence with the software requirement specification is strictly followed, that reflects the customer wishes and demand – The MDRE is not initiated with respect to the customer request, as it is a continuous process; it is started when it is needed. Whereas in Bespoke, it is initiated with customer request, wishes and demands Customers Sources of requirements Time to market : fixed vs customer set Lifecycle of the product : Fixed releases ----dev + maintenance Elicitation Analysis and Negotiation Requirement validation Documentation Release planning Change management

32. 32 Why Software Projects Fail

33. Motivation Standish Group Reports 1994, 1995, 2007 Failure rates for software development projects are up to 85% 50% of all software projects --  total failures 40% --  are partial failures Approximately 31 % of corporate software development projects -  cancelled before Completion 53% --  challenged and cost --  180% 46% of software projects are having cost or time overruns or not fully meeting user's requirements and 19% are outright failures Project failure rate is high Roughly 15% never deliver a final product costing $67 billion per year Stories of software failure attract public attention. Additionally

34. Introduction Value-Based Software Engineering Value-based software engineering (VBSE) is an emerging field, which integrates value-oriented perspectives into software engineering. Software engineering – Value-neutral settings: ignorance of stakeholders’ interests, neutral value assignment to every requirement; use case, object and defect, separation of concerns within the development organization – For example: In such a setting, critical requirements or defects--- no required attention 80% defects comes from 20% of modules and half of modules are error free 90% of downtime comes from 10% defects While, 80% of software value comes from 20% of software features What & why

35. Introduction Cont..  Past research and practices: cost, time to market and quality improvement- -------- competitive edge/differential advantage in market.  In today's global competitive environment, Cost, time to market, Quality improvement and cost – necessity but not sufficient  Integration of value-oriented perspectives  processes and practices overcome value-oriented shortfalls  Value is a key success factor  economic output and productivity.  Important for success/competitive edge/differential advantage, economic output, productivity and for long term business sustainability

36. Introduction Cont..  The global dynamic business environment  high global competition, dynamic market needs and emerging technologies.  incredible pressure -  organizations  achieve and sustain competitive edge.  This competition -   innovation  focus on value of different customers and markets  new market entrants  emerging technology  fulfilling needs, demands and wishes of different customers and users  handling uncertainty in dynamic and complex markets  Integration of technical decisions and the business strategy  uncertain economic circumstances and rapid product development.  In this environment with shortened product and technology life cycles, software industry is influenced to maximize value creation for a given investment.

37. 37 7 Key Elements of VBSE 1.Benefits Realization Analysis 2.Stakeholders’ Value Proposition Elicitation and Reconciliation 3.Business Case Analysis 4.Continuous Risk and Opportunity Management 5.Concurrent System and Software Engineering 6.Value-Based Monitoring and Control 7.Change as Opportunity

38. 38 DMR/BRA* Results Chain INITIATIVE OUTCOME Implement a new order entry system ASSUMPTION Contribution Order to delivery time is an important buying criterion Reduce time to process order Reduced order processing cycle (intermediate outcome) Increased sales Reduce time to deliver product *DMR Consulting Group’s Benefits Realization Approach

39. 39 Stakeholder Value Proposition Reconciliation Expectation Management – Be aware of the number of potential value proposition conflicts – Lessons learned retrospectives – Well-calibrated cost model – “simplifier and complicator” Visualization and trade-off analysis – Prototypes; scenarios, estimation models Prioritization – Pairwise comparison, scale-of-ten ratings of importance and difficulty Groupware – Easywinwin Business case analysis – ROI

40. Value Proposition Model-Clash spiderweb diagram

41. Business Case Analysis

42. 42 Continuous Risk and Opportunity Management Understanding People’s Utility Functions – Risk-averse people – Reconcile people’s utility functions

43. Concurrent System and Software Engineering

44. Value-Based Monitoring and Control Software CMM or the CMMI :EVM

45. Cont(..) Value Realization

46. Change as Opportunity Think……

47. 47 VBSE Agenda Value-based requirements engineering Value-based architecting Value-based design and development Value-based verification and validation Value-based planning and control Value-based risk management Value-based quality management Value-based people management A theory of value-based software engineering

48. 48 Value-based requirements engineering – Value-based requirements elicitation – Value-based requirements analysis and negotiation – Value-based requirements validation – Value-based requirements prioritization – Value-based release planning – Value-based product line engineering

49. 49 References C. Baldwin & K. Clark, Design Rules: The Power of Modularity, MIT Press, 1999. B. Boehm, “Value-Based Software Engineering,” ACM Software Engineering Notes, March 2003. B. Boehm, C. Abts, A.W. Brown, S. Chulani, B. Clark, E. Horowitz, R. Madachy, D. Reifer, and B. Steece, Software Cost Estimation with COCOMO II, Prentice Hall, 2000. B. Boehm and L. Huang, “Value-Based Software Engineering: A Case Study, Computer, March 2003, pp. 33-41. B. Boehm & K. Sullivan, “Software Economics: A Roadmap,” The Future of Software Economics, A. Finkelstein (ed.), ACM Press, 2000. B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison Wesley, 2003 (to appear). S. Faulk, D. Harmon, and D. Raffo, “Value-Based Software Engineering (VBSE): A Value-Driven Approach to Product-Line Engineering,” Proceedings, First Intl. Conf. On SW Product Line Engineering, August 2000. R. Kaplan & D. Norton, The Balanced Scorecard: Translating Strategy into Action, Harvard Business School Press, 1996.

50. 50 D. Reifer, Making the Software Business Case, Addison Wesley, 2002. K. Sullivan, Y. Cai, B. Hallen, and W. Griswold, “The Structure and Value of Modularity in Software Design,” Proceedings, ESEC/FSE, 2001, ACM Press, pp. 99-108. J. Thorp and DMR, The Information Paradox, McGraw Hill, 1998. Economics-Driven Software Engineering Research (EDSER) web site: www.edser.org MBASE web site : sunset.usc.edu/research/MBASE