slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Naseer Jan PowerPoint Presentation
Download Presentation
Naseer Jan

Loading in 2 Seconds...

play fullscreen
1 / 51

Naseer Jan - PowerPoint PPT Presentation


  • 195 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Naseer Jan' - grace


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

CSE 5316/7316Software Requirements

  • Fall 2013

Computerscience Department,

Lyle school of engineering, SMU

Value-based requirements engineering

Naseer Jan

Course Instructor :

Dr. Huang

outline
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
requirement 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
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
  • 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
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
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
AHP (Cont..)
  • Find sum of Row
  • Eigen Vector
ahp cont1
AHP(Cont..)
  • Consistency Ratio result should be less than 0.10 (Ideal Prioritization)
ahp cont2
AHP(Cont..)
  • Value distribution of requirements
  • Cost distribution of requirements
ahp cont3
AHP(Cont..)
  • Cost-value distribution of requirements
ahpcpg
AHPcPG
  • Cost-value analysis for pile 1, Pile 2, Pile 3
100 dollars
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
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
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 industries
  • Analysis of twenty seven companies----- case studies in terms of prioritization techniques from year 2003 to 2006
requirements lifecycle management
Requirements Lifecycle Management
  • Requirement Driven Evolution Model process (RDEM)
requirements lifecycle management1
Requirements Lifecycle Management
  • REPEAT (Requirements Engineering Process At Telelogic)
requirements abstraction model ram
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
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

mdre cont
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
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
motivation
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
introduction
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
introduction cont
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 cont1
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.
7 key elements of vbse
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
slide38

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

stakeholder value proposition reconciliation
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

continuous risk and opportunity management
Continuous Risk and Opportunity Management

Understanding People’s Utility Functions

Risk-averse people

Reconcile people’s utility functions

42

value based monitoring and control
Value-Based Monitoring and Control
  • Software CMM or the CMMI :EVM
slide45
Cont(..)
  • Value Realization
vbse agenda
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

value based requirements engineering
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

slide49

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.

slide50
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