1 / 51

Naseer Jan

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

grace
Download Presentation

Naseer Jan

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline • Requirements engineering • Large scale requirements engineering • VBSE brief overview • Motivation and definitions • VBSE Agenda • Seven key practices • 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 • 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. Analysis 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

  27. Customer Value Drivers

  28. Product management reference framework

  29. 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. MDREvs 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. 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 What & why 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

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

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

  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 39

  40. Value Proposition Model-Clash spiderweb diagram

  41. Business Case Analysis

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

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

  48. Value-based requirements engineering 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 48

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

More Related