CSE
This presentation is the property of its rightful owner.
Sponsored Links
1 / 47

Naseer Jan PowerPoint PPT Presentation


  • 72 Views
  • Uploaded on
  • Presentation posted in: General

CSE 5316/7316 Software Requirements Fall 2013 Computer science Department, Lyle school of engineering, SMU. WinWin Negotiation tools. Naseer Jan. Course Instructor : Dr. Huang. Pervasiveness of Software. Software-intensive systems prevalent across industries/domains

Download Presentation

Naseer Jan

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


Naseer jan

  • CSE 5316/7316Software Requirements

  • Fall 2013

    Computer science Department,

    Lyle school of engineering, SMU

WinWin Negotiation tools

Naseer Jan

Course Instructor :

Dr. Huang


Pervasiveness of software

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


Challenges in software development

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


Project success rate

Project Success Rate

Challenged: Over budget/schedule or undelivered projects

Failed: Cancelled projects


Chaos 10 factors influencing project success

CHAOS ’10 – Factors Influencing Project Success

  • User Involvement

  • Executive Support

  • Clear Business Objectives

  • Emotional Maturity

  • Scope Optimization

  • Agile Process

  • Project Management Expertise

  • Skilled Resources

  • Execution Capability

  • Tools and Infrastructure

Lack of Stakeholder involvement and convergence viewed as major causes of project failure


Why is re important

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”


Re and the enterprise

RE and the Enterprise

Marketing

Market needs and trends,

Price range

New Features

Requirements Engineering

Product roadmap/ strategy, key requirements

Realized changes and enhancements

Product Management

Customer Relationship Management

New and revised requirements

Customer wishes, Reported problems


Re and software development

RE and Software Development

Project plan, Approved goals

Requirements & constraints

Project Management

Design & Development

Monitoring data, Elicited goals

Solutions, New technologies

Requirements Engineering

Requests for clarification and improvement

Status of change requests

Quality Assurance

System Maintenance

Requirement Artifacts

Change requests


Types of requirements

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


Goal of re establishing a vision in context

Goal of RE: Establishing a Vision in Context

  • Requirements Engineering processes start with an aim tochange 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


Goal of re establishing a vision in context1

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


Visualizing vision in context

Visualizing “Vision” in “Context”

  • Establish system vision within existing system context

  • Deal with parts of the real world that are relevant and their relation to the development context

Vision defines focus


Framework for re

Framework For RE

System Context

Validation

Core Activities

Management

Requirements Artifacts


Framework for re1

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


Relationship between facets

Relationship Between Facets

IT System Facet

Subject Facet

Representation

Presentation

Application

Usage Facet

Development Facet

RE happens here!!


Three dimensions goals of requirements engineering

Three Dimensions & Goalsof 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


Visualizing the three dimensions

Visualizing The “Three Dimensions”

Content

Goal

complete

Agreement

consolidated views

vague

individual views

Documentation

informal

compliant with rules


Framework for re2

Framework For RE

Core Activities

Documentation Document & specify elicited requirements as per defined documentation and specification rules. Also capture rationale and other relevant information

Negotiation1.Detect conflicts and make

them explicit

2. Resolve identified conflicts

Elicitation


Framework for re3

Framework For RE

Elicitation

Identifying Requirement SourcesStakeholders

Existing Documentation

Existing System(s)

Developing new & innovative requirementsTypically not elicit-able and require collaborative and creative processes

Elicit Existing Requirements

Elicit already “known” requirements from relevant sources


Techniques for elicitation

Techniques For Elicitation

  • Interviews

  • Workshops

  • Focus Groups

  • Observation of stakeholders/users etc.,

  • Questionnaires

  • Perspective-based reading

    Usually supported by “Assistance Techniques”

    • Brainstorming

    • Prototyping

    • Mind Mapping

    • KJ Analysis/Method

    • Elicitation Checklists


Framework for re4

Framework For RE

Requirements Artifacts

(Documented Requirements)

Goals Stakeholder intention with regard to the objectives, properties or use of the system

Scenarios

Positive/Negative,

Misuse,

Exploratory,

Current-state/desired state,

Main, alternative or exception

Solution oriented requirementsData Model,

Functional Model,

Behavioral Model


Framework for re5

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 activities

    Check adherence of activities to process, standards, guidelines etc.

  • Validation of requirement artifacts

    Check documented requirements w.r.t. content, documentation and agreements

Validation


Validation techniques

Validation Techniques

  • Inspections

  • Walkthroughs

  • Desk-checking (checking programs with pen-paper)

  • Prototyping

    Above are usually assisted by:

  • Validation checklists

  • Perspective-based reading

  • Verbalization of models

  • Creation of artifacts


Framework for re6

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

Management


Re framework vbse 4 1

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)


Theory w

Theory-W

STOP THIS MADNESS!

Customer

Dr. Boehm

Think of requirements as stakeholder negotiated win conditions!!

Developer

As a team discuss what will make each of you “win” (a.k.a. win conditions)

Reach a mutual consensus and move forward (WinWin Equilibrium)

Identify any issues and come up with options to resolve them


Vbse 4 1

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?).


Vbse 4 11

VBSE 4+1 


Vbse 4 12

VBSE 4+1 


Winwin negotiation tools evolution

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


Winwin negotiation tools evolution1

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)


Winwin negotiation tools evolution2

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


Winwin negotiation tools evolution3

WinWin Negotiation tools Evolution

  • Review and expand negotiation topics


Winwin negotiation tools evolution4

WinWin Negotiation tools Evolution

  • Brainstorm stakeholder interests


Winwin negotiation tools evolution5

WinWin Negotiation tools Evolution

  • Converge on Win Conditions:


Winwin negotiation tools evolution6

WinWin Negotiation tools Evolution

  • Prioritize Win Conditions

  • Reveal Issues and Constraints

  • Identify Issues, Options

  • Negotiate Agreements


Wiki winwin

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


Wiki winwin1

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.


Wiki winwin2

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


Wiki winwin3

Wiki WinWin


Wiki winwin4

Wiki WinWin


Wiki winwin5

Wiki WinWin


Naseer jan

Putting It All Together

Winbook

Theory - W

Requirement Specifications

User Stories

Gmail

Facebook


Winbook

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!


Tutorial

Tutorial

  • http://www.youtube.com/watch?v=xFUj9Gj5XTU&feature=youtu.be


  • Login