Integrating Collaborative Requirements Negotiation and Prioritization Processes: A Match Made in Heaven Nupul Kukreja Annual Research Review 14 th March.

Slides:



Advertisements
Similar presentations
Metrics and Databases for Agile Software Development Projects David I. Heimann IEEE Boston Reliability Society April 14, 2010.
Advertisements

Extreme Programming Alexander Kanavin Lappeenranta University of Technology.
Systems Analysis and Design in a Changing World
Chapter 8: Evaluating Alternatives for Requirements, Environment, and Implementation.
CS 325: Software Engineering January 13, 2015 Introduction Defining Software Engineering SWE vs. CS Software Life-Cycle Software Processes Waterfall Process.
Continuous Value Enhancement Process
Winbook Nupul Kukreja Annual Research Review 6 th March 2012 Process Implications of using Social Networking based Tools for Requirements Engineering 3/6/20121ARR.
An Introductory Overview to Multi Criteria Evaluation GEOG 5161: Research Design Professor Kenneth E. Foote Petra Norlund 2010.
An Approach to Evaluate Data Trustworthiness Based on Data Provenance Department of Computer Science Purdue University.
Architecture is More Than Just Meeting Requirements Ron Olaski SE510 Fall 2003.
Quality is about testing early and testing often Joe Apuzzo, Ngozi Nwana, Sweety Varghese Student/Faculty Research Day CSIS Pace University May 6th, 2005.
Trade Study Training Need and Goals Need Consistent methodologies and practices performing trade studies Pros/cons, advantages/disadvantages, customer/management.
8 Systems Analysis and Design in a Changing World, Fifth Edition.
© 2005 Prentice Hall, Decision Support Systems and Intelligent Systems, 7th Edition, Turban, Aronson, and Liang 6-1 Chapter 6 Decision Support System Development.
Strategic Project Alignment With Team Expert Choice
CS3500 Software Engineering Agile Software Development (1) Agile software development, proposed in 2001 by the non-profit Agile Alliance, has four basic.
Agile Process: Overview n Agile software engineering represents a reasonable compromise to conventional software engineering for certain classes of software.
Software Engineering Lecture No:12. Lecture # 7
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR ESM'2009, October 26-28, 2009, Holiday Inn Leicester, Leicester, United Kingdom.
What is Business Analysis Planning & Monitoring?
Copyright Course Technology 1999
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
MULTICRITERIAL REASONING of PRIORITIES1 THE PRINCIPLES OF MULTICRITERIAL REASONING OF THE DEVELOPMENT PRIORITIES Buracas & Zvirblis
Cooperative Meeting Scheduling among Agents based on Multiple Negotiations Toramatsu SHINTANI and Takayuki ITO Department of Intelligence and Computer.
Interaction Design Process COMPSCI 345 S1 C and SoftEng 350 S1 C Lecture 5 Chapter 3 (Heim)
Feasibility Study.
Centro de Estudos e Sistemas Avançados do Recife PMBOK - Chapter 4 Project Integration Management.
Creating a Brand New Project using Scrum and Agile Techniques Matt Turner, Mark Wightman Red Gate Software.
Value-Based Requirements Prioritization And Evolution Executing Incremental Stakeholder Commitment Nupul Kukreja 5 th November,
IT Requirements Management Balancing Needs and Expectations.
Value Based Requirements Engineering And Prioritization Percolating ‘Value’ into the SDLC (Software Development Lifecycle) Nupul Kukreja 15 th October,
AP-1 5. Project Management. AP-2 Software Failure Software fails at a significant rate What is failure? Not delivering it on time is an estimation failure.
Gary MarsdenSlide 1University of Cape Town Human-Computer Interaction - 4 User Centred Design Gary Marsden ( ) July 2002.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 other methodologies 1 Method/Process = step-by-step description of the steps involved.
Systems Analysis and Design in a Changing World, Fourth Edition
An overview of multi-criteria analysis techniques The main role of the techniques is to deal with the difficulties that human decision-makers have been.
Develop Project Charter
Value Based Requirements Engineering And Prioritization
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 4 Agile Development Discussion of Agile Development and Agile Process.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang School of Computer Science The.
Software Project Management Lecture # 2 Originally shared for: mashhoood.webs.com.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Stand Up Comedy Project/Product Management
Stakeholder WinWin And Requirements Prioritization Nupul Kukreja 19 th October
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Product Design Alternative Generation, Evaluation, and Selection.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Agile Methodology. -Dhanashree Kumkar -Plus91 Technologies.
ECE 2799 Value Analysis Determine an Optimum Solution by Prof. Mazumder Prof. Bitar Updated: 3/22/2016.
Systems Analysis and Design in a Changing World, Fifth Edition
Chapter 8 Environments, Alternatives, and Decisions.
Project Management – PTM721S
Requirement Prioritization
Preliminary Power Point Slides
Computer Aided Software Engineering (CASE)
Project Integration Management
Stakeholder WinWin And Requirements Prioritization
Systems Analysis – ITEC 3155 Evaluating Alternatives for Requirements, Environment, and Implementation.
Value Based Requirements Engineering And Prioritization
By: Hugh R. Alley August 22nd, 2007 Presenter: Maged Younan
Agile concepts in System of Systems engineering Alexey Tregubov
Department of Computer Science The University of Texas at Dallas
DMAIC Analyze, Improve, Control
Agile Process: Overview
Objectives 1. An understanding of the importance of management to society and individuals 2. An understanding of the role of management 3. An ability to.
Objectives 1. An understanding of the importance of management to society and individuals 2. An understanding of the role of management 3. An ability to.
Human Computer Interaction Lecture 14 HCI in Software Process
Presentation transcript:

Integrating Collaborative Requirements Negotiation and Prioritization Processes: A Match Made in Heaven Nupul Kukreja Annual Research Review 14 th March 2013

Outline 1 Motivation 2 High-level overview 3 Background and Related work 4 Two-step Prioritization Approach 5 Evaluation and Results

Motivation Not enough time and money to implement all requirements – Need to prioritize requirements w.r.t. budget and schedule constraints High coordination and transaction costs to ascertain requirement priorities or reprioritizing new/changed requirements Too many ties using MoSCoW or 1-10 scoring – Assumes stakeholders can correctly score requirements as per intrinsic value – Difficult to ascertain value of new/changed requirements in relation to others

Solution Value-Based Requirements Prioritization (VBRP)! Stakeholders select the most valuable requirements for implementation – “Value lies in the eyes of the beholder” – but can be captured with some effort Decision theory folks working on this for a long time – Some models (e.g. AHP) have been used for requirements prioritization with varying degrees of success Propose a ‘lightweight’ two-step approach based on TOPSIS (Technique of Ordered Preference by Similarity to Ideal Solution)

Two-step Approach – Overview Prioritize w.r.t. business goals (TOPSIS) Prioritize w.r.t. business value, relative penalty & ease of realization (TOPSIS) Decompose System into MMFs Decompose MMFs into low level requirements

Ideal Alternative (S’) TOPSIS (What?) Criterion 1 Criterion 2 Alternative 1 Alternative 2 Non-Ideal Alternative (S*) Aim: Rank order alternatives by their ‘closeness to ideal’ and ‘distance from non-ideal’ Criterion: Has ‘direction of preference’ i.e. more/less of the criterion is preferred Ideal: Best score for each criterion Non-ideal: Worst score for each criterion 6

TOPSIS (Why?)

8

9

Winbook A collaborative, social networking based tool for requirements brainstorming similar to facebook… …with requirements organization using color- coded labels similar to Gmail… …to collaboratively converge on software system requirements reaching win-win equilibrium (based on Theory-W)… …by keeping it short and simple like XP’s user stories! 10

11

TWO-STEP PRIORITIZATION

0.Goals Articulation & Prioritization WinWin methodology assumes project goals are captured and prioritized before commencing “WinWin Negotiations” Added a “precursor” step for capturing and prioritizing goals prior to initiating negotiations Goals captured in Winbook and prioritized using success sliders 13

1.MMF Decomposition Top-down decomposition of system into Minimum Marketable Features (MMF) – Units of software value creation – Components of intrinsic marketable value Prioritize MMFs against project goals: – MMFs scored against each goal on a 1-9 scale (1 = MMF has little to no contribution in realizing the goal; 9 = MMF wholly contributes towards realizing the goal. Absolute scale okay too) – MMF priorities ascertained by underlying TOPSIS algorithm 15

16 MMFs are ‘leaves’ of tree

17 MMFs

2.Win Condition Capture & Prioritization Win Conditions (WCs): Stakeholders’ desired objectives stated in an easy to understand manner and formalized where necessary (“functional” WCs captured in ‘user-story’ format) MMFs decomposed into constituent WCs Win conditions prioritized against: – Business Value (1: low; 9: high) – Relative Penalty (1: low; 9: high) – Ease of Realization (Story-points/Fibonacci scale) WCs priorities also computed by TOPSIS and scaled by MMF they belong to (Similar GUI as previous slide) 19

Two-Step Prioritization Goals Success Sliders MMFsGoal 1Goal 2…Goal nRequirements Business Value Relative Penalty Ease of Realization : Influences Priority Score MMFs influenced by business goals Win condition scores influenced by MMFs they belong to Change in goal weights  change in requirement priorities Dynamically (re)prioritizable product backlog Developers can ‘pull’ most valuable requirements from (up-to-date prioritized) backlog

Evaluation & Results Two-step approach deployed in software engineering project course USC since Fall 2011 Empowered teams to perform sensitivity analyses: – Varying goal weights and gauging impact on MMFs/WCs – Varying criteria weights to ascertain high-value, high- risk or complex WCs for prototyping New requirements/changes comparable with existing ones to ascertain optimum scope leading to channelized negotiation sessions 21

Evaluation & Results (Cont’d) Ability to have requirements backlog with accompanying rationale for each requirement TOPSIS-Winbook approach provided significant improvements in organizing, updating and accessing captured rationale over previous versions of the WinWin negotiation systems Live traceability from goals to win conditions (and vice versa) vs. static traceability matrix – Makes explicit contribution of MMFs to goals (and consequently WCs to goals) 22

Limitations TOPSIS rank reversals – inclusion of spurious alternatives can change prioritization order of requirements – Not a major concern for cooperative teams (not intent on gaming the system) – Cause of concern for negotiation among competitors Hierarchical prioritization may not agree with intuition/gut-feel – Teams manually account for discrepancies Prerequisites/dependencies not handled in current version of Winbook 23

Conclusion Two-step prioritization decouples business (goals/MMF) prioritization from individual requirements Ability to quickly gauge impact of changing business goal priorities on individual requirements Provides dynamic reprioritizable product backlog for use in lean/agile/kanban projects 24

Integrating a decision theory based prioritization framework with a collaborative requirements negotiation and management tool thus provides a rationale-backed prioritization of requirements allowing the stakeholders to channelize their negotiation and development efforts around the most valuable requirements. A match truly made in heaven… 25

Thank you! Questions?