Naseer Jan Course Instructor : Dr. Huang Value-based requirements engineering CSE 5316/7316 Software...

Naseer Jan

Course Instructor :Dr. Huang

Value-based requirements engineering

CSE 5316/7316 Software RequirementsFall 2013

Computer science Department, Lyle school of engineering, SMU

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

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

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

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

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)

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

AHP (Cont..)

• Find sum of Row

• Eigen Vector

AHP(Cont..)

• Consistency Ratio result should be less than 0.10 (Ideal Prioritization)

AHP(Cont..)

• Value distribution of requirements

• Cost distribution of requirements

AHP(Cont..)

• Cost-value distribution of requirements

Planning Game

AHPcPG

• Cost-value analysis for pile 1, Pile 2, Pile 3

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

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

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

ANALYSIS OF INDUSTRIES

• Analysis of twenty seven companies----- case studies in terms of prioritization techniques from year 2003 to 2006

Bespoke requirements engineering

Market driven requirements engineering(MDRE)

Requirements Lifecycle Management

Requirement Driven Evolution Model process (RDEM)

Requirements Lifecycle Management

REPEAT (Requirements Engineering Process At Telelogic)

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.

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

Gap Analysis

Customer Value analysis

Customer Value Drivers

Customer Value Drivers

Product management reference framework

Product management reference framework

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

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

Why Software Projects Fail

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

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

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

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

38

DMR/BRA* Results Chain

INITIATIVE OUTCOMEOUTCOME

Implement a new orderentry system

ASSUMPTION

Contribution Contribution

Order to delivery time isan 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

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

Value Proposition Model-Clash spiderweb diagram

Business Case Analysis

42

Continuous Risk and Opportunity Management

• Understanding People’s Utility Functions– Risk-averse people– Reconcile people’s utility functions

Concurrent System and Software Engineering

Value-Based Monitoring and Control

• Software CMM or the CMMI :EVM

Cont(..)

• Value Realization

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

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

49

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