The WinWin Approach in Software Engineering Education

Making Every Student a Winner: The WinWin Approach in Software Engineering Education Paul Norbert Grünbacher Seyff Johannes Kepler University Linz Austria paul.gruenbacher @jku.at

Robert O. Briggs U of AK, Fairbanks, USA

Hoh Peter In Korea Univ. Seoul, Korea

Hasan Kitapci Univ. of South. Cal., USA

Daniel Port Univ. of Hawaii USA

bob.briggs @uaf.edu

hoh_in @korea.ac.kr

kitapci @usc.edu

dport @hawaii.edu

Abstract In this paper we show how Theory-W and the WinWin requirements negotiation approach have influenced software engineering education in a number of institutions worldwide. After a short summary of Theory-W and the WinWin negotiation model, processes, and tools the paper discusses how students can benefit from WinWin in their software engineering education. We explore different options for teaching the approach and present concrete examples and experiences from different universities.

1

Introduction

The WinWin approach to software requirements definition developed by Boehm and others [1, 3, 6] provides an important perspective on how to deal with requirements in software development. Boehm argues that instead of defining requirements in a waterfall-like manner an approach that emphasizes the success-critical stakeholders and their win conditions is more likely to succeed. In their 1989 paper Boehm and Ross introduced a software project management approach called Theory-W [6]. It is based on the fundamental principle that all success-critical stakeholders should be made winners in a software project by considering software technology, economics, and human relations in the specific project context. Boehm has demonstrated that win-lose situations among stakeholders often develop into lose-lose situations and it is preferable to seek mutually acceptable win-win situations. The WinWin spiral model thus complements the original Spiral Model with activities to identify and involve success-critical stakeholders and to reconcile their different objectives and expectations (win conditions). Researchers have been developing refinements of the WinWin focusing on the negotiation process, tool support, or facilitation techniques [1, 2, 4, 5, 12]. This paper discusses the impact of WinWin on software engineering education. In Section 2 we briefly summarize Theory-W, the WinWin negotiation model, negotiation process, and existing tool support. Section 3 discusses how WinWin helps software engineering students to cope with real-world problems. In Section 4 we explore options for using WinWin in concrete software engineering courses. Section 5 gives detailed examples of teaching and experiences from several universities. The paper rounds out with a conclusion and discussion.

2

The WinWin Approach

The WinWin approach to requirements definition and software management is comprised of an underlying theory, a negotiation model, negotiation processes, and supporting tools: Theory-W: Making everyone a winner is the fundamental principle of this theory. Win-lose situations among stakeholders often develop into lose-lose situations and therefore an approach

Proceedings of the 19th Conference on Software Engineering Education & Training (CSEET’06) 1093-0175/06 $20.00 © 2006

IEEE

that aims at reaching win-win situations, i.e., mutually acceptable solutions, is to prefer [6]. Key activities of Theory-W include: identification of success-critical stakeholders; elicitation of the success-critical stakeholders’ primary win condition; negotiation of mutually satisfactory win-win solution packages (e.g., requirements, architectures, plans, critical components); monitoring and control of the WinWin equilibrium throughout development. WinWin negotiation model: The model defines 4 basic negotiation elements. Stakeholders formulate their individual objectives and expectations as win conditions. If all stakeholders concur the win conditions are turned into agreements. If stakeholders do not concur, they identify their conflicting win conditions and capture conflicts, risks, or uncertainties as issues. Stakeholders jointly seek options to overcome issues and explore tradeoffs. Options are iterated and turned into agreements that capture mutually satisfactory solutions. The WinWin equilibrium condition tests if all win conditions are covered by agreements or if there are any unresolved issues. A domain taxonomy is used to organize WinWin artifacts. Stakeholders also collect important terms in a glossary to define the project language. WinWin negotiation process: While the WinWin negotiation model provides rough guidance to carry out a negotiation it is often complemented with more detailed negotiation processes [10]. For example, EasyWinWin is a process that adopts group facilitation techniques helping stakeholders to diverge and converge, to evaluate their choices, and to attain consensus [8]. It has also been emphasized that besides the actual negotiation pre- and post-negotiation phases are crucial for success. WinWin tools: Researchers have been developing several generations of tools to support the WinWin negotiation process [4]. Experience shows that the most successful tools provide sufficient guidance while at the same time allow a certain degree of leeway. Typically, a pure tool-based approach doesn’t work and integrating facilitation techniques improves success [7]. Universities have also been developing prototypes to experiment with novel features. For example, ARENA (Anytime, Anyplace REquirements Negotiation Aids) is a web-based tool supporting negotiations of distributed stakeholders [9]. The rapid advent of novel technologies has also led to the development of WinWin tools for mobile stakeholders: The ARENA-M system is available on Personal Digital Assistants or Smart Phones and allows capturing requirements directly in the workplace of future system users [15].

3

Why Teach WinWin?

It is well known that many of the problems in software engineering can be traced to shortfalls in the requirements process. Software engineering education often focuses on teaching students how to document and specify requirements (and there is definitely not a lack of languages, notations, and techniques for this task). However, little emphasis is put on the elicitation and negotiation of requirements including skills on how to acquire and discover requirements. Teaching the WinWin approach helps to narrow this gap as it emphasizes communication and shared understanding, reconciliation of conflicts, surfacing of issues, as well as discussion of uncertainties, and hidden assumptions. The approach makes students aware of the difficulties in eliciting stakeholder interests, understanding different stakeholder views and positions, and attaining mutually satisfactory agreements. WinWin is not just another technique for specifying requirements. Rather, WinWin teaches key principles of software engineering management: Identifying and involving key stakeholders to understand their value propositions: Students learn that taking a wider, system-level perspective is essential and that many of the problems in software engineering stem from excluding important stakeholders and their concerns. Developing a shared vision and common language: Students learn that stakeholders from different domains use their own jargons and have different perspectives on the system being


IEEE

Table 1. WinWin at different Universities. University

Teaching Context

Theory and Tools Covered

Examples and Projects

Facilitation and Communication

Johannes Kepler U Linz (Austria)

Grads / Requirements Eng. class

Theory W, negotiation model, EasyWinWin, GSS

Previous neg. results, role play with realworld stakeholders

Face-to-face with Facilitator

U of Arizona (USA), DePaul U (USA), Delft U of Techn. (Netherlands), U of N Omaha (USA)

Undergrads & grads / Systems Analysis & Facilitation classes

Theory W, negotiation model, EasyWinWin, ThinkLets, GroupSystems GSS

Previous negotiation results

Face-to-face with students in the role of systems analyst

Korea U (Korea)

Undergrads / Software Engineering class

Theory W, negotiation model, EasyWinWin & XP

USC Library projects, role play with hypothetical stakeholders

Face-to-face without facilitator

U of Southern California (USA)

Grads / Software Engineering class

Theory W, negotiation model, EasyWinWin, GSS

Previous project as tutorial example, realworld projects

Face-to-face and distr. neg. with student facilitators

Columbia U (USA)

Grads and undergrads / Sw Eng. class

Theory W, neg. model, WinWinLight & custom systems

Previous projects, sample WinWin homework answers

Varies, usually website based and email

developed. Students learn how to deal with the resulting communication problems and misunderstandings. Negotiating and reconciling positions to attain mutually satisfactory solutions: Students learn that projects need to be aware of constraints such as budget, schedule, skills and that the team of stakeholders has to negotiate a feasible solution rather than just defining requirements by asking questions [14]. Students also learn that stakeholders cannot get everything they want but only what has been mutually agreed. Understanding conflicts, risks, and uncertainties: Students become aware that a simplistic “blue-sky thinking” approach does not work and that project managers need to look at the underlying conflicts, risks, and uncertainties early on. WinWin teaches them that one has to actively deal with these issues and seek for options to overcome the identified problems. Dealing with changes: Students learn that the assumptions of the waterfall model typically do not hold and that flexibility and iterative development are essential when defining requirements. This allows to better deal with new wishes, emerging risks, and new solution options at any time in a project. Students will also learn such changes can make agreements obsolete and that re-negotiation is the normal case rather than the exception.

4

Teaching Options

Instructors and lecturers in their software engineering classes have many options for teaching WinWin. We used a set of four characteristics to describe how classes differ from each other as summarized in Table 1: Teaching context: WinWin can be either part of an introductory course in software engineering or part of specialized classes on requirements engineering or software management. Students on both undergraduate and graduate level can benefit from the approach. Theory covered: In Section 2 we have discussed important elements of the WinWin approach. Based on the teaching context the lecturer has to define the scope of the material covered. Lecturers will have to find a good balance between theory and practical exercises. Theoretical courses will focus on the principles of Theory-W and the negotiation model while more practical courses will expose students to the negotiation process, facilitation techniques, and the use of collaborative tools.


IEEE

Examples and projects: Students need practical training and exercise to fully understand what WinWin is all about. In theoretical classes instructors can demonstrate the approach with examples of existing negotiations without directly involving students in the negotiations. Preferably, students take part in a negotiation to get a feeling for the issues and problems. A simple yet effective approach is a role play with instructions for individual students to represent different stakeholders (e.g., developers, customers, users, managers, etc.). A real-world project course however makes negotiations even more realistic by allowing students to interact with real stakeholders. Facilitation and collaboration setting: If a role play or real-world project is chosen the lecturer has to decide how to organize the WinWin sessions. Face-to-face meetings with a facilitator are a frequent option as guidance and support can be given easily. In this case students can also act as facilitators and thereby gain additional experience. Distributed settings are also feasible, in particular if preceded by an initial face-to-face kick-off meeting. Tool support: Depending on the facilitation and collaboration mode tool support has to be considered. In face-to-face settings students can role play with simple paper and pencil based approaches such as whiteboards, cards. For larger teams and distributed settings groupware tools are available as described in Section 2.

5

University Experiences

People from around the world have been successfully teaching WinWin as part of their software engineering curricula. Here we summarize a few concrete examples of teaching the approach based on post-mortem reflections by the authors. 5.1

Johannes Kepler University Linz (Austria)

WinWin is an integral part of a course on Requirements Engineering in which students are educated in eliciting, analyzing, documenting, validating, and managing requirements. The course is attended mainly by graduate students, typically between 15 and 20. In order to make the course as realistic as possible a real project is used throughout the course. Students jointly acquire requirements using EasyWinWin complemented by a scenario-based approach. The requirements are then documented using informal and semi-formal notations, and later transferred to a requirements management tool. Three experiences are particularly interesting: (1) In the course real clients typically propose a project and participate in the requirements negotiation as stakeholders. There is an interesting mix of real clients and students role-playing stakeholders such as future system users or developers. It typically takes two full days to negotiate agreements in a face-to-face workshop. (2) Students also serve as facilitators (supported by a facilitator’s guidebook), which increases their motivation and willingness to participate. (3) Besides EasyWinWin, the course also uses RESCUE, a scenario-based requirements discovery process developed at City University London [13]. Experiences show that a combination of these approaches is very useful: While EasyWinWin allows students to understand the ‘big picture’ and to develop a shared vision, RESCUE helps them to elaborate more detailed requirements by exploring key scenarios of usage. 5.2

University of Arizona (USA) and Delft University of Technology (Netherlands)

The University of Arizona, in cooperation with other universities, has three different approaches to teaching EasyWinWin, each serving a different purpose: The 1st approach was used by a faculty member at University of Arizona who used audio links and remote presentation capabilities to deliver single two-and-a-half hour lectures to groups of 12 to 20 undergraduate systems analysis and design students in Chicago, Omaha, and Delft. These events used conventional lecture-plus-handouts to convey what each of the


IEEE

EasyWinWin process steps seeks to accomplish and why it is important to accomplish each step. These talks exclude the specifics of how to conduct an EasyWinWin workshop. This approach has also been used effectively for face-to-face presentations to professional associations and academic conferences. The purpose of this approach is to stimulate learners to question the assumptions underlying any requirements design methodology, and to highlight the value of attending to the concepts that gave rise to EasyWinWin – Theory-W and the WinWin negotiation model. The 2nd approach uses a complete moderator’s guidebook for the EasyWinWin methodology developed jointly at University of Arizona, University of Southern California (USA), and Kepler University. The book is a highly-detailed explanation of what, why, and how to conduct an EasyWinWin workshop using a specific collaborative software platform by GroupSystems. It includes everything the moderator must do and say at every stage of the process to move a group through the negotiation. It includes instructions for using the GroupSystems tools and background information and useful insights about each step of the process. We used this book to conduct a series of two-day workshops for groups of 3 to 12 professional systems analysts, software engineers, and graduate students. The learners first experience each step as participants, and then practice conducting the step themselves under the guidance of an instructor, with frequent feedback from their peers. The 3rd approach, with groups of 2 to 10 professionals and graduate students, replaces the extensive guidebook with a stack of six 5” X 8”cards, each of which documents a different facilitation technique. Each technique produces a predictable, repeatable pattern of interaction in a group (“e.g. Brainstorming causes a group to generate lots of ideas”) [7]. In a 2-day workshop, learners learned and practiced the facilitation techniques on GroupSystems and on paper. Then, participants learned to conduct the EasyWinWin process as an ordered sequence of the facilitation techniques they already know. This approach seems to be faster and easier to learn than the second one, and it leaves the learners not only able to run a WinWin negotiation, but able to run with a variety of support technologies, and it leaves them with general-purpose facilitation techniques that stand them in good stead for other collaboration tasks. 5.3

Korea University (Korea)

In a software engineering course 33 undergraduate students performed 15 projects of ubiquitous computing applications such as location-based services or RFID-based public security applications (see http://embedded.korea.ac.kr/teaching/ 2004_fall_csce316.php). The class material covered basic principles of software engineering, Theory-W, and the WinWin negotiation model. Most of the project teams adopted the WinWin negotiation model together with eXtreme Programming (XP). Students did not use collaborative tools. Instead, in face-to-face role plays with hypothetical stakeholders they simply took notes on paper. There was no formal facilitator and so the project managers guided the discussion informally. The negotiation results of a USC digital library project was presented as an example. Students learned that different stakeholders in a project have different perspectives and that it is critical for the project success to reconcile these perspectives. Due to the limited time, however, many students failed to report explicit win conditions of each stakeholder in their final project deliverables. The student projects where technically quite complex. As a result students spent more time to familiarize with RFID, GPS, etc. and regarded process issues as less important. A lesson learned in this course was that simpler project topics would have made it easier for students to understand WinWin and topics related to software engineering processes. In another case in the same semester 44 graduate students took a class on software development methods. They were all working in industry during the day and studied computer science for the master degree in an evening program. They had between 5 and 10 years of working experience. Students carried out 9 simple and routine IT project topics such as a bulletin board


IEEE

system (BBS), chat programs, customer relation management for video rental service, ring service on mobile phone, and a simple networked on-line game. Students were familiar with the domains of these projects. Since they worked during the day, there was not much time to discuss and negotiate requirements face-to-face, instead negotiations were carried out using phone conversation or MSN Messenger. The WinWin negotiation model created attention because students knew from their working experience the importance and difficulties of requirements negotiation. They pointed out how win-win situations can be achieved in real-world environments. They suggested, for example, that use senior manager as facilitators in case of conflicts between two departments (typically, engineers and designer vs. marking department or customers). They also suggested ‘private win conditions’ that should not be shared with other stakeholders initially – an interesting cultural issue: People born and raised in the Asian culture typically hesitate to explicitly show their intentions. Teaching the WinWin negotiation model to Korean undergraduate and graduate students made them aware that expressing their needs explicitly is important in software projects. 5.4

University of Southern California (USA)

At USC 15 to 20 electronic services applications are developed as part of the Software Engineering team project course each year. The first half of the course covers the application of software engineering process models and management approaches for developing plans, requirements, and the architecture of the future system. Computer science graduate students (1/3 are experienced software developers from industry) take this course remotely. In real-world projects they collaborate in teams with real clients and apply the WinWin Spiral model and Model Based System Architecting and Software Engineering (MBASE) guidelines for software engineering. With MBASE, stakeholders use the USC/GroupSystems.com EasyWinWin requirements negotiation tool. This process is carried out in parallel with initial system prototyping. This ensures that the prioritized win conditions are realistic, and that the domain model and product model are feasibly scoped. For e-services application projects it takes the teams roughly 11 weeks in fall semester to develop LCO (life cycle objectives) and LCA (life cycle architecture with various prototypes) packages from a short problem statement. The course starts off with some basic software engineering concepts such as Theory-W, spiral model and MBASE. Another lecture is given on the WinWin negotiation approach and EasyWinWin, followed by a live demonstration of the tool and the process. Two weeks or so into the course, the students are required to build a team and select their project out of a wide range of projects. Each project is conceived by a real client and is derived out of a need in his/her community. Besides proposing the system, the clients are also involved in negotiating the requirements with their teams. Teams choose one of their members as the facilitator of their negotiations. This person manages the initial preparation and the workload between the team members during the negotiation. In addition, a sample negotiation schedule is provided to the teams to ensure the efficient negotiation with the clients. The requirements negotiation is divided into two sessions with a few days in between. The first session includes reviewing and expanding negotiation topics, brainstorming of stakeholders’ interests, converging on win conditions, capturing keywords for the glossary, and prioritizing win conditions. The second session starts with a prototype to increase the understanding of the problem and to find missing win conditions. Teams then elaborate the results by revealing hidden constraints and assumptions. Students review the win conditions and identify issues and options for those issues. Finally, the teams negotiate agreements and check the completeness of the results using the list of negotiation topics. EasyWinWin is used both synchronously and asynchronously: Since the time allocated for the teams to use the conference rooms which is provided during their negotiations is limited to about 2 hours for each session, teams use the tool and work with their clients to asynchro-


IEEE

nously finish the negotiation process. Teams use a teleconferencing utility to run distributed negotiation with remote team members or clients. During the last ten years, USC student teams have conducted over 150 real-client requirements negotiation for e-services application projects. The strongest positive effects of using the WinWin approach are increased cooperativeness, stronger focus on key issues, reduced friction, and better support for distributed collaboration. Further details at http://sunset.usc.edu/ cse/pub/courseroot/ course_list.html#577a. 5.5

Columbia University (USA)

In 1999 the WinWin approach was introduced into the undergraduate and graduate software engineering courses at Columbia University. These courses were extremely demanding. Students learned and applied software engineering principles and practices on a full development lifecycle (inception, elaboration, implementation, and transition to client). The participating students of one semester (26 to 107 students) were asked to build teams of about 5 people and to realize a real-client project. Introduction to WinWin was similar to USC’s approach: First, Theory-W was introduced, then the WinWin negotiation model, followed by examples of WinWin negotiations and use of WinWin tools like “WinWinLite” from previous projects. Due to the extremely compressed schedule, much of this had to be streamlined to cover just the essentials. This introduction was followed by an individual (not team based) homework assignment challenging the students to pre-position themselves to use the WinWin approach within their project and helped to rapidly establish a project specific guideline for the negotiations with clients. In particular, based on each team member’s recommendation after completing the homework, the team could choose to use existing WinWin tools or choose to implement their own approach to managing WinWin negotiation and subsequent artifacts. Most opted for the latter and developed some remarkably innovative approaches. For example, one team developed a simple collection of web-forms that enabled project stakeholders to enter win conditions, issues, options, and agreements that would directly post to the project web site and simultaneously update various project artifacts. It was common for a team to adapt a WinWin system built by a previous team. As a result, we included several example approaches in the WinWin homework (with references). Each student was asked at the end of the semester to prepare an “Individual Critique” reflecting on their learning experiences. This feedback is not only essential for assisting in grading individual effort within a team based project [11], but also provides invaluable insights for improving and evolving the course and assessing the effectiveness of the software engineering practices. Overall there were many favorable student comments on effectiveness of the WinWin approach, but also critical of formal WinWin tools such as USC WinWin and WinWin Lite. Here are two excerpts: “We did not use a formal WinWin tool. Instead we did most of our negotiations over email and we had the project web page for monitoring risks and other to-do issues. This arrangement worked very well. The volume of the email turned out to be disconcerting sometimes, but we really discussed a lot and it was usually beneficial because issues did not get looked over.” Another student reported: “WinWin was without any doubt, the key of the success of our project. From the very beginning, the first meeting, until the very end at the transition to the customers’ facilities, having fluent communication with the customers helped us understand their expectations and deliver to them exactly what they wanted.” 5.6

Discussion

Our simple framework of teaching options in Section 4 already showed that numerous possibilities exist to teach WinWin. This is confirmed by the experience reports from different schools showing highly different ways to utilize the WinWin model. Here we summarize key elements from these reports:


IEEE

Flexibility. It is important that students understand the flexibility of WinWin by tailoring it to specific situations while not loosing the key WinWin principles. Cultural differences. The Korean example shows that cultural differences might exist that need to be addressed through modifications of the negotiation process. Integration with other approaches. Tailoring and adapting WinWin is also essential in situations where WinWin principles are used to complement or to be combined with other software engineering approaches. The Austrian example shows that a combination of the scenario-based RESCUE process and EasyWinWin is very useful to understand both negotiation-based and scenario-based elicitation approaches. Further, the Korean example reports on adopting the WinWin negotiation model together with the eXtreme Programming process. Making students aware of such issues is essential in addition to the more detailed instructions, guidelines, and tools. Collaboration and facilitation. The examples show that if students feel and understand the need for stakeholder collaboration in software projects they will also appreciate learning more about facilitation techniques and tools.

6

Conclusions

In this paper we discussed the benefits of the WinWin approach in software engineering education and explored options for teaching. Several universities reported their experiences of teaching WinWin principles, practices, and tools. The WinWin approach has been used in hundreds of negotiations in software engineering education around the globe. We hope that the experiences reported in this paper will motivate other lecturers to adopt the WinWin approach as part of their program. We also hope that the discussion of teaching options provide initial guidance and advice.

7

References

[1] Boehm, B.W., P. Bose, E. Horowitz, and M.J. Lee. Software Requirements as Negotiated Win Conditions. In: 1st Int. Conf. on Requirements Engineering. 1994. Colorado Springs, CO, USA: IEEE CS. [2] Boehm, B.W. and A. Egyed. Software requirements negotiation: Some lessons learned. In: 20th International Conference on Software Engineering, 1998. [3] Boehm, B.W., A.F. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy, Using the WinWin Spiral Model: A Case Study. IEEE Computer, 1998(7): pp. 33-44. [4] Boehm, B.W., P. Grünbacher, and R.O. Briggs, Developing Groupware for Requirements Negotiation: Lessons Learned. IEEE Software, 2001. 18(3): pp. 46-55. [5] Boehm, B.W. and H. In. Identifying quality-requirement conflicts. In: ICRE, 1996. Colorado Springs, CO, USA. [6] Boehm, B.W. and R. Ross, Theory-W Software Project Management: Principles and Examples. IEEE Transactions on Software Engineering, 1989. 15(7): p. 902-916. [7] Briggs, R.O., G.J. de Vreede, and J.F. Nunamaker, Collaboration Engineering with ThinkLets to Pursue Sustained Success with Group Support Systems. J of Mgmt Inf. Systems, 2003. 19(4): p. 31-63. [8] Briggs, R.O. and P. Grünbacher. EasyWinWin: Managing Complexity in Requirements Negotiation with GSS. In: 35th Annual Hawaii Int. Conf. on System Sciences. 2002. Big Island, Hawaii: IEEE CS. [9] Grünbacher, P. and P. Braunsberger, Tool Support for Distributed Requirements Negotiation. Cooperative methods and tools for distributed software processes, H. Gall et al (ed) 2003, Franco Angeli. [10] Grünbacher, P. and N. Seyff, Requirements Negotiation, In: Engineering and Managing Software Requirements, A. Aurum and C. Wohlin, Editors. 2005, Springer Verlag. [11] Huffman Hayes, J., T.C. Lethbridge, and D. Port. Evaluating individual contribution toward group software engineering projects. In: 25th IEEE Int. Conf. on Software Engineering. 2003: IEEE CS. [12] In, H., B.W. Boehm, T. Rodgers, and M. Deutsch. Applying winwin to quality requirements: A case study. In: 23rd Int. Conf. on Software Engineering, 2001. [13] Jones, S. and N.A.M. Maiden, RESCUE: An Integrated Method for Specifying Requirements for Complex Socio-Technical Systems, in Rqts Eng for Sociotechnical Systems, J.L. Mate, A. Silva, (eds) 2004, Idea Group Inc. [14] Nuseibeh, B. and S. Easterbrook. Requirements Engineering: A Roadmap. in The Future of Software Engineering, Special Issue 22nd Int. Conf. on Software Engineering. 2000: ACM-IEEE. [15] Seyff, N., P. Grünbacher, N.A.M. Maiden, and A. Tosar. RE Tools Go Mobile. In: 26th IEEE International Conference on Software Engineering (Tool Demonstration), IEEE CS, 2004.


IEEE