WinWin: A System for Negotiating Requirements

Ellis Horowitz, Joo H. Lee, and June Sup Lee, all from the Center for Software Engineering & Computer Science - U.S.C.

Introduction

WinWin is a computer program that aids in the capture, negotiation, and coordination of requirements for a large system. It assumes that a group of people, called stakeholders, have signed on with the express purpose of discussing and refining the requirements of their proposed system. The system can be of any type. WinWin contains facilities for:

• capturing the desires (win conditions) of the stakeholders
• organizing the terminology so that stakeholders are using the same terms in the same way
• expressing disagreements or issues needing resolution
• offering options as potential solutions
• negotiating agreements which resolve the issues
• using third party tools to enlighten or resolve issues
• producing a requirements document that summarizes the current state of the proposed system
• creating documents that support multimedia and hyperlinks
• tracing the ways by which requirements decisions were reached
• checking the completeness and consistency of requirements

WinWin Functionality

A Simple Scenario

WinWin offers a group of users a great deal of functionality, but as a result some planning is useful before getting started. In this section we offer a simple scenario for how users of WinWin might begin their work.

1. An owner of the project is identified. He identifies the other people who will participate in this negotiation.

2. The owner starts WinWin, creates the new project, and enters the names of all users. These people are called stakeholders.

3. One stakeholder is designated to define or tailor an existing set of terms for the proposed system. He enters them in WinWin.

4. One stakeholder is designated to define or tailor an existing taxonomy for the proposed system. He enters the taxonomy in WinWin.

5. Stakeholders review and iterate the terms and taxonomy.

6. One now begins the negotiation process which continuously loops through steps 6 and 7:

   6a. stakeholders create Win Conditions expressing their preferences, and/or

   6b. stakeholders create Issues that they believe exist, and/or

   6c. stakeholders create proposed Agreements.

7. Stakeholders review newly entered artifacts with existing artifacts.

   7a. a new conflict is observed so a new Issue is created

   7b. stakeholders develop Options to address Issues

   7c. stakeholders create new Agreements and vote on Agreements in-Progress.

Steps 6 and 7 continue until all Win Conditions are covered, all Issues are resolved and all Agreements are passed. Win Conditions and Issues that no longer are relevant, Options that are unused, and Agreements that have failed are marked as INACTIVE. Inactive artifacts are not shown, by default, but there is a way to restore them.

A More Complicated Negotiation

Suppose we have two win conditions involved in an issue. The issue has one option which is adopted by Agreement1. Agreement1 is voted on, passes and in turn covers Win Condition 1 and 2. Now suppose a new win condition is entered which causes Agreement1 to become invalid. What are the actions that should result?

1. The owner of Agreement1 changes its status to INACTIVE. This causes Option1 to be unadopted, Issue1 to be unresolved, and Win Conditions 1 and 2 to be uncovered.

2. A new issue is drafted, Issue2, which involves Win Conditions 1, 2, and 3. Issue2 replaces Issue1.

3. Options to resolve Issue2 are generated and Option2 is chosen to create an agreement, Agreement2. Agreement2 replaces Agreement1.

4. Agreement2 initiates a vote which eventually passes. This causes Option2 to be adopted, Issue2 resolved, and Win Conditions 1, 2, and 3 to be covered.

Rationale Graph

One of the essential elements in any negotiation is a record of the arguments that were used in favor or against a particular issue or option. WinWin assists in the capture and retention of all such arguments through its process model described earlier and a rationale graph. In technical terms, a rationale graph is the transitive closure of the set of nodes that are reachable from an Agreement. In effect this includes all proposed Options, whether adopted or not, all Issues which are eventually addressed and all Win Conditions. This graph is displayed by the program as an indented list. By tracing through the web of interconnections one may completely resurrect the arguments that were used which led to the adoption of the Agreement.

In the Figure 3 is a picture of artifact customer-AGRE-1. This is an Agreement artifact. On the right hand side you see the Artifact Set window. This agreement points to an option, customer-OPTN-1, which in turn points to an issue, customer-ISSU-1. The agreement also points to a win condition, user-WINC-3. At some later point in the process, stakeholders will vote on this Agreement. Once a vote is started, all pointers to artifacts are frozen, as the artifacts must maintain the identical form throughout the voting process. Once a vote is complete, the Agreement either passes or fails.

Another form of rationale support in WinWin is the Rationale field. This field is placed next to the body description of an artifact, and can be seen in Figure 4. The stakeholder may explicitly provide his rationale for a particular artifact by entering a statement in that field.

WinWin Attachments

WinWin recognizes that there may be auxiliary tools that stakeholders desire to use during the course of a negotiation. For example one might use a spreadsheet to analyze the financial impacts of a given Option. Or one might use a program such as COCOMO to estimate the effort and schedule required for a particular decision. WinWin provides a capability to attach such programs and their outputs to any artifact in the system. This is called the Attachment field. By making the Attachment field be a part of every artifact, stakeholders may associate these program elaborations at a desirable level of granularity. The Attachment field allows for an arbitrary number of attachments. Each attachment includes the name of the program and its associated data set.

Mode of Operation

As a tool for requirements capture and negotiation, WinWin assumes that stakeholders will be potentially working at different locations and at different times. Thus WinWin supports a distributed, asynchronous mode of operation. A stakeholder may sign onto the system at any time. There may or may not be other stakeholders using the system. The stakeholder may examine the Messages, a record of all changes made to the WinWin database by the stakeholders. These messages are ordered by date, and each stakeholder has the option to maintain or discard any or all of the Messages.

Figure 6 shows some sample output of the Messages window. Each artifact is named by its unique identifier, e.g., user-TERM-1 is the artifact that belongs to the stakeholder named user and it is an artifact of type TERM. Each line in the Messages window refers to a unique action performed by the stakeholder. For example, the first line in the figure indicates that a new TERM artifact has been created on 02/27/98 at time 19:22. Other messages indicate the date and time that the artifact was modified, including the name of the field that was modified. At the bottom of this window there are three buttons. The Delete button will remove the highlighted Message. Cancel causes the Message window to disappear. OK causes the artifact in the highlighted line to appear.

WinWin Versions

WinWin was developed in C, X-Windows and Motif and runs on Solaris, HP-UX and Linux operating systems. It is available from: http://sunset.usc.edu/WinWin/winwin.html#download

There is a version of WinWin that has been developed using Java. This version can be run from the CSE web site by invoking the URL: http://sunset.usc.edu/javawinwin/winwin.html

You may download the Java class files and install Java WinWin at your own site. To do this invoke the URL: http://sunset.usc.edu/research/WINWIN/winwin_main.html#downloads

WinWin API

We have developed a library of functions which can be used to create programs that interact directly with WinWin. This is referred to as the WinWin Application Programmers Interface or WinWin API. In addition to the library we distribute a test program. This program should be run after WinWin is installed to make sure the API is functioning properly. In addition we have provided source for the test program so people interested in using the API can imitate this program.

Analysis of the WinWin Process Model

Figure 7 shows a state transition diagram that describes the various states of the WinWin database as negotiation proceeds. Nodes describe the possible states of the database while transitions are actions taken by the WinWin system or by the stakeholders.

Acknowledgments

Thanks go to everyone at the Center for Software Engineering who participated in the design and development of WinWin. That includes Prasanta Bose, Ming June Lee, Ahmed Abdullah, Cristina Gacek, Anne Curran, and Barry Boehm. Also to our industrial affiliates who contributed time and effort in testing out earlier versions. Their contributions are gratefully

References

View references for this article.