Upload
melvin-wright
View
228
Download
0
Tags:
Embed Size (px)
Citation preview
Requirements Negotiation Tools
CSE5/7316LiGuo Huang
2
Pervasiveness of Software• Software-intensive systems prevalent across
industries/domains – E.g.: automotive, finance, consumer electronics, medical devices
etc.,• Information systems:
– Collects, stores, transforms, transmits, and/or processes information or data
– Goal: Provide information at right place/time– Ex.: Accounting system
• Embedded software-intensive systems:– Software only ONE (important) part of overall system– Often closely integrated with hardware– Ex.: Anti-lock braking system of a car
3
Challenges in Software Development• Software-based innovations
– Customers demanding innovative features software is key for realizing innovation
• Increasing Complexity– Greater number of functions realized by software increasing
complexity i.e., increased integration with external systems, customizability etc.,
• Higher quality demands– Pervasiveness of software higher level of quality
• Shorter development times– Increasing competition faster time to market
• Pressure to reduce costs– Increasing market pressure software systems must be developed at
lower costs
4
Project Success Rate
2000 2002 2004 2006 20080
10
20
30
40
50
60
4951
53
4644
23
1518 19
24
28
34
29
3532
2010 Standish Group CHAOS Summary Report
ChallengedFailedSucceded
Challenged: Over budget/schedule or undelivered projectsFailed: Cancelled projects
5
Lack of Stakeholder involvement and convergence viewed as major causes of project failure
1. User Involvement2. Executive Support3. Clear Business Objectives4. Emotional Maturity5. Scope Optimization6. Agile Process7. Project Management Expertise8. Skilled Resources9. Execution Capability10.Tools and Infrastructure
CHAOS ’10 – Factors Influencing Project Success
7
Why Is RE Important?• Flawed requirements a major cause of project
failure • Fixing an error in later phases 10x more
expensive• Incorrect requirements ↔ Incorrect system leads
to wasted costs• System maybe unreliable for practical use
disrupting normal day-to-day operations• The primary vehicle for going from “vision” to
“realization”
8
RE and the Enterprise
Requirements Engineering
Marketing
Customer Relationship Management
Product Management
Product roadmap/ strategy, key
requirements
New and revised
requirements
Customer wishes, Reported problems
Realized changes and
enhancements
Market needs and trends,Price range
New Features
9
RE and Software Development
Requirements Engineering
Project Management
System Maintenance
Quality Assurance
Requests for clarification and
improvement
Requirement Artifacts Change requests
Status of change requests
Project plan, Approved goals
Requirements & constraints Design &
Development
Solutions, New technologies
Monitoring data, Elicited goals
10
Types of Requirements• Functional Requirements: specify the functionality the system
shall provide to its users– Ex.: The system shall allow the users to access their profile page after
they provide valid credentials• Quality Requirements (a.k.a., Levels of Service): define the quality
properties of the entire system or of a system component, service or function– Ex.: Reliability, performance under high loads etc.,– “-ilities”: Availability, flexibility, scalability, usability, robustness,
interoperability etc.,• Constraints: Organization or technological requirement that
restricts a way in which the system shall be developed– Ex.: Legal constraints (Sarbanes-Oxley), Project/Budget/ Schedule
constraints, Physical constraints etc.,
11
Goal of RE: Establishing a Vision in Context
• Requirements Engineering processes start with an aim to change current reality
• Vision: (a.k.a “system vision”)– Essence of desired change defined briefly and
precisely– Describes overall goal(s) of the system– Usually associated with particular point in time of
when the vision should be realized– Serves as a guide during development for all Success
Critical Stakeholders (SCS) involved in the project
12
Goal of RE: Establishing a Vision in Context
• Each system is embedded within a given context
• Context (a.k.a. “system context”): Part of the system environment relevant for– Defining, understanding & interpreting system
requirements
13
Visualizing “Vision” in “Context”
Vision defines focus
• Establish system vision within existing system context• Deal with parts of the real world that are relevant and
their relation to the development context
14
Framework For RE
System Context
Core Activities
Requirements Artifacts
Valid
ation
Man
agem
ent
15
Framework For RE
System Context
Subject FacetMaintain
information about objects/events in
the real world.
Usage Facet Desired workflows,
usage goals, different user
groups, interaction models, laws & standards etc.,
IT System FacetExisting hardware,
software, communication
networks, peripheral devices
etc.,
Development FacetProcess guidelines
and constraints, QA methods, maturity
models, development
environments etc.,
16
Relationship Between Facets
Subject Facet
Representation
PresentationApplication
Usage Facet Development Facet
IT System Facet
RE happens here!!
17
Three Dimensions & Goals of Requirements Engineering
• Content:All relevant requirements are explicitly known and understood at the required level of detail
• Agreement:A sufficient agreement about the system requirements is achieved between the success critical stakeholders
• Documentation:All requirements are documented and specified in compliance with the relevant documentation/specification formats & rules
18
Visualizing The “Three Dimensions” Content
Documentation
Agreement
complete
vague
informal compliant with rules
individual views
consolidated views
Goal
19
Framework For RE
Core Activities
Documentation Document & specify elicited requirements as per defined
documentation and specification rules. Also
capture rationale and other relevant information
Elicitation
Negotiation1.Detect conflicts and make them explicit2. Resolve identified conflicts
20
Framework For RE
Elicitation
Identifying Requirement Sources
StakeholdersExisting Documentation
Existing System(s)Elicit Existing Requirements
Elicit already “known” requirements from relevant
sources
Developing new & innovative requirements
Typically not elicit-able and require collaborative and
creative processes
21
Techniques For Elicitation• Interviews• Workshops• Focus Groups• Observation of stakeholders/users etc.,• Questionnaires • Perspective-based readingUsually supported by “Assistance Techniques”– Brainstorming– Prototyping– Mind Mapping– KJ Analysis/Method– Elicitation Checklists
22
Framework For RE
Goals Stakeholder intention with
regard to the objectives, properties or use of the
system
ScenariosPositive/Negative,
Misuse,Exploratory,
Current-state/desired state,Main, alternative or exception
Solution oriented requirementsData Model,
Functional Model,Behavioral Model
Requirements Artifacts(Documented Requirements)
23
Framework For RE• Validation of context consideration
Check whether all relevant aspects in 4 contexts have been elicited, documented within the RE process
• Validation of execution of activitiesCheck adherence of activities to process, standards, guidelines etc.
• Validation of requirement artifactsCheck documented requirements w.r.t. content, documentation and agreements
Valid
ation
24
Validation Techniques• Inspections• Walkthroughs• Desk-checking (checking programs with
pen-paper)• PrototypingAbove are usually assisted by:• Validation checklists• Perspective-based reading• Verbalization of models• Creation of artifacts
25
Framework For RE• Observation of system context
Identification and management of context changes• Management of RE activities
Monitoring, controlling and adjustment of planned workflow of elicitation, documentation, negotiation and validation activities – standard project management
• Management of requirements artifacts– Establishing traceability between different artifacts– Prioritizing requirements– Managing changes via change management processes
Man
agem
ent
26
RE Framework == VBSE 4+1
• RE Framework advocated by Klaus Pohl is, in essence, isomorphic to VBSE’s 4+1
• VBSE brings value considerations to the foreground; RE Framework doesn’t seem to make it explicit
• Each of the ‘steps’ of the RE framework is traceable in VBSE’s 4+1 structure (and vice versa)
27
Theory-WCustomer
Developer
STOP THIS MADNESS!
Think of requirements as stakeholder negotiated win
conditions!!
As a team discuss what will make each of you “win”
(a.k.a. win conditions)
Identify any issues and come up with options to resolve them
Reach a mutual consensus and move
forward (WinWin Equilibrium)
Dr. Boehm
28
VBSE 4+1 • Theory W -“which values are important?”
and “how is success assured?” for a given software engineering enterprise.
• Utility theory (how important are the values?)• Decision theory (how do stakeholders’ values
determine decisions?)• Dependency theory (how do dependencies
affect value realization?) • Control theory (how to adapt to change and
control value realization?).
29
VBSE 4+1
30
VBSE 4+1
31
WinWin Negotiation tools Evolution• The first generation of WinWin requirements negotiation
support system was developed at USC in 1994• Easy WinWin: is the fourth generation implementation for the
WinWin requirements negotiation approach based on a Group Support System
• Wiki WinWin: The WikiWinWin approach includes a stakeholder collaboration process and corresponding support tools. The WikiWinWin creates a sequence of steps and instructions to guide the stakeholders working out mutually satisfactory requirements.
• Winbook: A Social Networking Based Framework for Collaborative Requirements Elicitation and WinWin Negotiations
32
WinWin Negotiation tools Evolution• What is EasyWinWin?• EasyWinWin is a requirements definition methodology that builds on the
win-win negotiation approach and leverages collaborative technology to improve the involvement and interaction of key stakeholders. With EasyWinWin, stakeholders move through a step-by-step win-win negotiation where they collect, elaborate, and prioritize their requirements, and surface and resolve issues to come up with mutually satisfactory agreements
• The WinWin negotiation model defines 4 types of artifacts – Win Condition, Issue, Option, and Agreement (WIOA)
33
WinWin Negotiation tools Evolution Activities• Review and expand negotiation topics• Brainstorm stakeholder interests• Converge on Win Conditions:• Capture a glossary of Terms• Prioritize Win Conditions• Reveal Issues and Constraints• Identify Issues, Options• Negotiate Agreements
34
WinWin Negotiation tools Evolution• Review and expand negotiation topics
35
WinWin Negotiation tools Evolution• Brainstorm stakeholder interests
36
WinWin Negotiation tools Evolution• Converge on Win Conditions:
37
WinWin Negotiation tools Evolution• Prioritize Win Conditions• Reveal Issues and Constraints• Identify Issues, Options• Negotiate Agreements
38
Wiki WinWin• A wiki is actually two things: a program that makes it exceptionally easy
for people to edit web pages and a philosophy regarding how users should go about the editing of web pages
• A wiki has several key characteristics, which make it different from the other widely used collaborative technologies, e.g., discussion forums, weblogs, and GSS (group support systems)
• It uses simple syntax and conventions to allow users easy editing or organizing of web pages
• It enables web documents to be authored collectively without individual ownership of the document
• The wiki can preserve the revision history, allow new information to update, and overwrite the old version
• Wiki in general makes a basic assumption of the goodness of people. It allows content to be immediately published upon being saved. And it relies on the community of users to catch malicious content and correct it
39
Wiki WinWin• Many wiki engines are good in supporting collaboration activities e.g. the
popular MediaWiki and TWiki. The Wikipedia, built upon the MediaWiki wiki engine, is one of the most well known cases. It’s an online encyclopedia, collaboratively written by a group of about 50,000 volunteers.
• Yahoo uses TWiki internally to manage documentation and project planning; Disney uses TWiki as the central resource for ideas, notes, how to’s, specs, and brainstorming; and SAP uses TWiki for multi-team collaboration.
40
Wiki WinWin• The WikiWinWin• The WikiWinWin approach includes a stakeholder collaboration process
and corresponding support tools. The WikiWinWin creates a sequence of steps and instructions to guide the stakeholders working out mutually satisfactory requirements.
• Ease of use• Maintain the WIOAs• Guidance for negotiation process• Support of synchronous collaboration• Versioning across several pages
41
Wiki WinWin
42
Wiki WinWin
43
Wiki WinWin
44
WinbookTheory - W
Requirement Specifications
Putting It All Together
User Stories
Facebook Gmail
45
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!
46
47
48
Tutorial• http://www.youtube.com/watch?v=xFUj9Gj5X
TU&feature=youtu.be