naseer jan course instructor : dr. huang value-based requirements engineering cse 5316/7316 software...
TRANSCRIPT
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..)
• Consistency Ratio result should be less than 0.10 (Ideal Prioritization)
AHP(Cont..)
• Value distribution of requirements
• Cost distribution of requirements
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
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
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
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
42
Continuous Risk and Opportunity Management
• Understanding People’s Utility Functions– Risk-averse people– Reconcile people’s utility functions
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
