B. Boehm, et. al., "Software Requirements Negotiation and Renegotiation Aids", Proc. of the 17th pp. 243-253, 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....for distributed negotiations. Section 4 describes ARENA, a new platform for distributed requirements negotiation. Conclusions and an outlook on further work round out the paper. 2 EasyWinWin EasyWinWin [2] 4] 5] is a requirements negotiation approach that builds on the WinWin negotiation model [1] and leverages collaborative technology and facilitation techniques [3] to improve the involvement and interaction of key stakeholders. It guides success critical stakeholders through a process of eliciting, elaborating, prioriTable 1: EasyWinWin negotiation process Purpose Facilitation Technique ....

....success critical stakeholders who are often unsure of their own needs, much less the needs of others. In this process, developers learn more about the customer s and user s world, while customers and users learn more about what is technically possible and feasible. The WinWin negotiation model [1] guides successcritical stakeholders in elaborating mutually satisfactory agreements. Stakeholders express their individual goals as win conditions. If everyone concurs, the win conditions become agreements. In case stakeholders have objections, they identify their conflicted win conditions ....

Boehm, B., Bose, P., Horowitz, E., Lee, M.J. Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach, Proc. ICSE'95, IEEE CS Press, Los Alamitos, Calif., 1995.

....attempted next by appealing to compromises (e.g. through compensations or restriction specialization) or goal substitutions. Finally, the conflict resolution at goal level is down propagated to the requirements level. 5.5 Goal based negotiation Conflict resolution often requires negotiation. Boe95] proposes an iterative 3 step process model for goal based negotiation of requirements. At each iteration of a spiral model for requirements elaboration, 1) all stakeholders involved are identified together with their wished goals (called win conditions ) 2) conflicts between these goals are ....

B. W. Boehm, P. Bose, E. Horowitz, and Ming June Lee, "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", Proc. ICSE-17 - 17th Intl. Conf on Software Engineering, Seattle, 1995, pp. 243-253.

....details back to high level concerns. The higherlevel a goal is, the more stable it is likely to be; goals are thus essential elements for managing requirements evolution [Lam01] Last but not least, goals have been recognized to be the roots at which conflicts can be detected and resolved [Rob89, Boe95, Lam98]. Agents are active system components (or processors ) which may have choice of behavior to ensure the goals they are assigned to [Fea87] Achieving goals in general requires the cooperation of multiple agents. For example, the highlevel goal of safe transportation might require the ....

B. W. Boehm, P. Bose, E. Horowitz, and Ming June Lee, "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", Proc. ICSE-17 - 17th Intl. Conf. on Software Engineering, Seattle, 1995, pp. 243253.

....of a caller, as over time callers learn tactics for publicizing or hiding their identity. Functional Morphology and Value Analysis Numerous proposals have been made for assigning priorities to features or requirements and managing tradeoffs involving multiple requirements and design criteria [Boe95, KR97]. Sullivans [Sul96] application of real options theory to the valuation of product features is a more recent and economically more sophisticated contribution of the same kind. These approaches all have in common the provision of a normative basis for decision making and prioritization, a ....

Boehm, B. P. Bose, E. Horowitz & M.J. Lee. "Software requirements negotiation and renegotiation aids", 17th Intl. Conf on Software Engineering, Seattle, WA, pp. 243-253, 24 - 28 April 1995.

....shown that successful projects view achievement of a viable software architecture as a key milestone in an industrial software development process. Critical evaluation of an architecture typically leads to a much clearer understanding of requirements, implementation strategies, and potential risks [7]. 3 YESTERDAY In the distant past of ten years ago, architecture was largely an ad hoc affair. 1 Descriptions relied on informal box andline diagrams, which were rarely maintained once a system was constructed. Architectural choices were made in idio syncratic fashion typically by adapting ....

....to create domain specific architectural design environments largely by combining the capabilities of existing tools. Other efforts have sought to integrate architectural development tools with other toolsupported aspects of software development, such as requirements elicitation and resolution [7]. Languages explicitly designed with software architecture in mind are not the only approach. There has been considerable interest in using general purpose object design notations for architectural modeling [8, 24] Moreover, recently there have been a number of proposals that attempt to show how ....

B. Boehm, P. Bose, E. Horowitz and M. J. Lee. Software requirements negotiation and renegotiation aids: A theory-W based spiral approach. In Proc 17 th International Conference on Software Engineering, 1994.

....be able to record important design rationale as it happens. Architectural rationale is a more specific design rationale, referring to the reasoning behind the software architecture, or high level system organization. One project looking specifically at architectural rational is the WinWin project (Boehm 1994 and Bose 1995) The WinWin approach involves stakeholders collaborating to negotiate win conditions, tradeoffs, and issues during the requirements and highlevel design phases of development. Extensions to this requirements framework provide explicit schemas for recording the rationale and linking ....

Boehm, P., Bose, P., Horowitz, E. and Lee, M.J. (1994) Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach, in Proceedings of the International Conference on Software Engineering (ICSE 17).

....study, primarily because one person conducted the activities, is that of human conflict resolution. Clearly, when multiple analysts are involved, there will be human issues that must be resolved in addition to simply technical ones. We plan to incorporate some of the lessons learned by Win Win [6] and other conflictresolution strategies into the synthesis process. To address these open issues, our future research will center on refining the architectural synthesis process and its supporting toolkit REMORA (Resolution of MORALE Architectures) REMORA provides a graphical environment where ....

B. Boehm, P. Bose, E. Horowitz, and M. Lee, "Software Requirements Negotiation and Renegotiation Aids: A Theory-W based Spiral Approach," 17th International Conference on Software Engineering (ICSE-17), Seattle, 1995.

....for handling conflicts at the goal level. A procedure was suggested in [Rob89] for identifying conflicts at the requirements level and characterizing them as differences at goal level; such differences are resolved (e.g. through negotiation) and then down propagated to the requirements level. In [Boe95], an iterative process model was proposed in which (a) all stakeholders involved are identified together with their goals (called win conditions) b) conflicts between these goals are captured together with their associated risks and uncertainties; and (c) goals are reconciled through negotiation ....

B. W. Boehm, P. Bose, E. Horowitz, and Ming June Lee, "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", Proc. ICSE-17 - 17th Intl. Conf. on Software Engineering, Seattle, 1995, pp. 243-253.

....is built via extending Rational Rose tool [Ro98] with tools to support for a) Capture of component based software architecture models following the meta model defined in Figure 2. b) Capture of dependencies between architectural decisions and architectural requirements via the WinWin metamodel [Bo98, BBHL95]. c) What if scenario driven analysis for change analysis using model of the Method(Tr, C, R, M) Tr = trace = sequence of input output events e 1 ; e 2 ; C = component relative to which Tr is being checked R = rest of architectural model consisting of other components and coordinators; M ....

Boehm, P. Bose, Ellis Horowitz and Ming June Lee "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", IEEE Proceedings of the 17th ICSE Conference, 1995.

....balance could be achieved if there was a way to capture the rationale as it occurs, but without introducing interruptions to the design process. Conklin et al. 1991) attempted to allow less disruption to the design process with a graphical tool, gIBIS, to record the rationale. The WinWin project (Boehm 1994 and Bose 1995) is looking specifically at recording architectural rationale. While both gIBIS and WinWin attempt to reduce the overhead in capturing rationale, they focus on particular elements that must still be formally documented during the discussions. In this next subsection, we discuss the ....

Boehm, P., Bose, P., Horowitz, E. and Lee, M.J. (1994) Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach, in Proceedings of the International Conference on Software Engineering (ICSE 17).

....the decision rationale, and a formal theory based on that ontology that aids in determining effects of changes in WinWin objects. 2. From here onwards we use the term decision rationale to include decisions on requirements and design. August 8, 1995 3 2 The WinWin Approach The WinWin approach [7] is aimed at addressing collaboration for the requirements engineering phase of the software life cycle. The three key ideas in the approach are: WinWin Spiral process. The process [6] consists of two main steps: i) Identifying stakeholders and their win conditions ii) Creating win win ....

....Hence each client, in essence keeps a copy of all the WinWin objects (winconditions, issues, etc. all of which may not be modifiable by the associated stakeholder. The issues raised are used to focus negotiation between stakeholders. WinWin also provide tools to support the negotiation activity [7]. Issue resolution leads to negotiated changes in win conditions. When all issues have been resolved, agreements are drafted and closed. The closed points of agreement, in concert with backup reference documents, then define the system requirement specifications. 2.1 Decision Maintenance Problem ....

[Article contains additional citation context not shown here]

. B. Boehm, P. Bose, Ellis Horowitz and Ming June Lee "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", IEEE Proceedings of the 17th ICSE Conference, 1995.

....quality are imprecise [4] Actually, as Balzer has pointed out, informality is an inevitable and ultimately desirable feature of the specification process [5] Therefore, capturing the elasticity of imprecise requirements is an important issue. Second, requirements often conflict with each other [6, 7, 1, 8]. Many conflicts between requirements are implicit and difficult to identify. Moreover, tradeoffs among conflicting requirements are difficult to assess. Third, requirements change frequently. Identifying the impact of a requirement change to the rest of the system is challenging. Existing formal ....

....a requirement specification containing conflicting requirements to be inconsistent. Conflicts are studied from a more positive perspective in the modern view. They are considered to be inevitable in the early stage of requirement engineeri ng. They can be beneficial if they can be managed well[6, 7, 1]. Several research works have focused in conflict detection and resolution in a requirement engineering framework [6, 7, 1] Many design rationale documentation methods [11] can also be used to identify conflicts by explicitly presenting arguments about issues although they were not developed ....

[Article contains additional citation context not shown here]

B. Boehm, et. al., "Software Requirements Negotiation and Renegotiation Aids", Proc. of the 17th International Conference on Software Engineering, pp. 243-253, 1995.

....merging redundant information, propagating changes, etc. Viewpoint capture has been advocated since the early days of requirements engineering [Ros77] Preliminary proposals for viewpoint oriented acquisition, negotiation, and cooperative modelling appeared only later [Fin89] Rob89] Pot94] [Boe95]. Two kinds of approaches have emerged. In a multi paradigm approach, specifications in different viewpoints can be written in different notations. Multi paradigm viewpoints are analyzed in a centralized or distributed way. Centralized viewpoints are translated into some logic based assembly ....

B. Boehm, P. Bose, E. Horowitz, M.J. Lee, "Software Requirements Negotiation and Renegotiation Aids: A TheoryW Based Spiral Approach", Proc. ICSE-17 - 17th Intl. Conf. on Software Engineering, Seattle, 1995, pp. 243-253.

....can be done; this procedure determines the degree to which a goal is satisficed denied by lower level requirements, by propagating such information along positive negative support links in the goal graph. Goal models can also be at the root of requirements engineering processes; for example, Boe95] proposes an iterative process model for goal based negotiation of requirements among multiple stakeholders. When goal formulations can be formalized, formal reasoning techniques are expected to do much more than qualitative reasoning. For example, one can use planning techniques to generate ....

Boehm, B., Bose, P., Horowitz, E., Ming June Lee, "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", Proc. ICSE-17 - 17th Intl. Conf. on Software Engineering, Seattle, 1995, pp. 243-253.

....because the activities were conducted primarily by one person is that of human conflict resolution. Clearly, when multiple analysts are involved, there will be human issues that must be resolved in addition to simply technical ones. We plan to incorporate some of the lessons learned by Win Win[5] and other conflictresolution strategies into the synthesis process. We also did not examine the role of architectural version management in this process. This is an area of interest to many software engineering practitioners. We intend to develop this area as an extension to the ACME interchange ....

Boehm B., Bose, P., Horowitz, E., and Lee, M. J., "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach," Proceedings of the 17th International Conference on Software Engineering (ICSE-17), Seattle, April 1995.

....Groupware support: To facilitate requirements negotiation across organizations, groupware that institutionalizes computer supported cooperative work (CSCW) is needed to bridge the geographical and time gap as well as to achieve group decisions. The WinWin requirements negotiation system[BBHL94b, BBHL95] takes in individual stakeholder requirements (win conditions) and help produce reconciled stakeholder requirements (agreements) as illustrated in Figure 1, to address multi stakeholder consideration. In order to achieve this goal, issues are provided to capture sets of conflicting ....

....as illustrated in Figure 1, to address multi stakeholder consideration. In order to achieve this goal, issues are provided to capture sets of conflicting requirements and options are possible resolutions to issues . The system, on the top level, is driven by the WinWin Spiral Process[BBHL95] to accommodate change of requirements. In addition, the WinWin artifacts described in Section 2 keep track of the rationale needed and the WinWin equilibrium model facilitates the process. As groupware, the system provides negotiation support, message passing and multi media document ....

[Article contains additional citation context not shown here]

B.W. Boehm, P. Bose, E. Horowitz, and M.J. Lee. "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach". In Proceedings 17th International Conference on Software Engineering, pages 243--253. ACM Press, April 1995. 22

....in order to point out their commonalties and differences with respect to the key characteristics described above. WINWIN DEVELOPMENT MODEL The WinWin development model incorporates a number of basic models; the WinWin Spiral Model [Boehm, 1988] Boehm,1996] the WinWin Negotiation Model [Boehm et al. 1995][Lee, 1996] COCOMO [Boehm, 1981] and others. It is beyond the scope of this paper to address all of them. In the following, we will therefore only describe the WinWin spiral model and WinWin negotiation model since many of the results presented in this paper are based on the concepts ....

....model, a negotiation support has been developed (the WinWin Negotiation Model) to ensure that the right amount of communication and collaboration is guaranteed during all cycles of the system development process. All teams in both years used this model and its supporting tool the WinWin System [Boehm et al. 1995][Horowitz, 1996] to negotiate the requirements for their respective system. The WinWin Negotiation Model [Boehm et al. 1994] is based on four artifact types: Win Conditions, Issues, Options and Agreements (see Figure 2) Win conditions capture the stakeholder goals and concerns with respect to a ....

Boehm, B.W., Bose, P., Horowitz, E., Lee, M.J. "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", Proceedings of ICSE-17, April 1995, pp.243-253.

.... The Web Distributed Authoring and Versioning (WebDAV) working group of the Internet Engineering Task Force (IETF) has taken on the challenge of supporting collaborative software engineering on the Web by extending the core network protocol of the Web, the Hypertext Transfer Protocol (HTTP) [4], to support remote software development. A team at the University of California, Irvine, working under a grant from the Defense Advanced Research Projects Agency (DARPA) Evolutionary Development of Complex Systems program, brought together interested parties from academia and industry to form the ....

....1.0, W3C Recommendation, REC xml, February, 1998. www.w3.org TR REC xml [3] C. Kaler, J. Amsden, G. Clemm. Versioning Extensions to WebDAV. Internet Draft, Work in Progress, draftietf webdav versioning 01, January, 1999. ftp: ftp.isi.edu internet drafts draft ietf webdav versioning 01.txt [4] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners Lee. Hypertext Transfer Protocol HTTP 1.1 Internet Proposed Standard Request for Comments (RFC) 2068. U.C. Irvine, DEC, MIT LCS. January, 1997. www.ics.uci.edu pub ietf http rfc2068.txt [5] R. Fielding, E. J. Whitehead, Jr. K. ....

[Article contains additional citation context not shown here]

B. Boehm, P. Bose, E. Horowitz, and M. J. Lee, "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach," Proceedings of the 17th International Conference on Software Engineering (ICSE-17), Seattle, April 1995.

....at best orthogonal to the job of specifying a system. More approaches are needed which integrate social, economic, and ethical considerations into the normal process of system definition. Published in the Proceedings of the 15 th IFIP World Computer Congress, The WinWin system discussed here [5] is an attempt to provide such a capability. It is both a telecooperation system and an approach to appropriately specifying telecooperation systems. Section 2 discusses the WinWin system components. Section 3 summarizes our experience with WinWin as a telecooperation system. Section 4 explains ....

....critical stakeholders and their win conditions, system requirements as negotiated win conditions, expectations management, inventing options for mutual gain [11] and risk management of win lose and lose lose risks. 2.2. The WinWin Negotiation Model The main purpose of a negotiation model [5] is to provide a stepwise approach for stakeholders to use in reconciling their individual win conditions. The WinWin Model, as depicted in Figure 1, achieves this. The model contains four major artifact types Win Condition, Issue, Option, and Agreement and their interrelationships, as well ....

[Article contains additional citation context not shown here]

Boehm, B.W., Bose, P., Horowitz, E., Lee, M.J. "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", Proceedings of ICSE-17, April 1995, pp.243-253.

....and make it more broadly available via automated aids for cost conflict resolution. At least three major capabilities are necessary to resolve cost conflicts among requirements: A general capability to surface and negotiate cost conflicts and risks among requirements. The USC CSE WinWin system[4,5] provides an example of such a capability. Capabilities to support the resolution of cost conflicts with functional quality requirements based on early information. The following aids provide examples of such capabilities. Aids for identifying cost conflicts with functional requirements. The ....

Boehm, B., Bose, P., Horowitz, E., and Lee, M.,"Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach," Proceedings of ICSE-17, IEEE Computer Society Press, Seattle, April, 1995.

....and team 15 (full Hughes) 2.4 WinWin System The WinWin system is a requirements negotiation tool which supports the collaboration of a number of stakeholders with the goal of identifying, analyzing, and reconciling requirements. The WinWin System is based on the WinWin negotiation model [3][4][15] It was used by all teams to negotiate the requirements of their systems and it is primarily based on four artifact types: Win Conditions, Issues, Options, and Agreements. Win Conditions capture the stakeholders goals and concerns with respect to a new system. If a Win Condition is ....

Boehm, B.W., Bose, P., Horowitz, E., Lee, M.J. "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", Proceedings of ICSE-17, April 1995, pp.243-253.

....1.2 Resolving conflicts among quality attribute requirements At least two major capabilities are necessary to resolve conflicts among quality attribute requirements: A capability to surface and negotiate conflicts and tradeoffs among quality attribute requirements. The USC CSE WinWin system[4,5] provides an example of such a capability. 3 . A capability to diagnose quality attribute conflicts based on early information. The QARCC (Quality Attribute Risk and Conflict Consultant) tool described in this paper operates on the win conditions captured by the WinWin system to provide such a ....

....to the base of 21 in equilibrium Win Conditions. The new Win Condition, Support the development of multi mission satellite ground stations, caused a cost and schedule conflict with the previous negotiated equilibrium. After determining that WinWin could successfully support such a renegotiation[5], we decided to apply QARCC1 to the body of Win Conditions to see how many potential conflicts it would identify. First, we wanted to see if QARCC would identify the two conflicts used in the renegotiation process. These were conflicts of Cost Schedule with Evolvability and Interoperability, which ....

Boehm, B., Bose, P., Horowitz, E., and Lee, M.,"Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach," Proceedings of the 17th International Conference on Software Engineering (ICSE-17), IEEE Computer Society Press, Seattle, April, 1995.

....concept, architecture, prototype, life cycle plan, and feasibility rationale. The projects were a diverse set of multimedia archive applications desired by USC Library clients. Their clientdriven, evolving nature made the set of projects more of an observatory than an experimental laboratory [4]. The projects (see Table 1) focused on different forms of multimedia data like movies, books, manuscripts, pamphlets, pictures, papers, and so on. However, the project goals were diverse because requirements of an archive for technical reports for instance are quite different from those of an ....

....same development model, called the WinWin Model. The WinWin development model incorporates a number of basic models; the WinWin Spiral Model [2] 5] the WinWin Negotiation Model [3] COCOMO [1] and others [6] The WinWin negotiation model (see Figure 1) and its supporting tool the WinWin System [4] are based on four artifact types: Win Conditions, Issues, Options and Agreements. Win conditions capture the stakeholder goals and concerns with respect to the new system. If a Win condition is non controversial, it is adopted by an Agreement. Otherwise, an Issue artifact is created to record the ....

[Article contains additional citation context not shown here]

Boehm, B.W., Bose, P., Horowitz, E., Lee, M.J. "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", Proceedings of ICSE-17, April 1995, pp.243-253.

No context found.

. B. Boehm, P. Bose, Ellis Horowitz and Ming June Lee "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", IEEE Proceedings of the 17th ICSE Conference, 1995.

No context found.

B. Boehm, et. al., "Software Requirements Negotiation and Renegotiation Aids", Proc. of the 17th pp. 243-253, 1995.

No context found.

Boehm, B., Bose, P., Horowtiz, E., and Lee, M., "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach", in 17 th International Conference on Software Engineering (ICSE-17). Seattle: IEEE Computer Society Press, 1995.

No context found.

B. Boehm, P. Bose, E. Horowitz, and M.J. Lee, Software requirements negotiation and renegotiation aids: a Theory-W based spiral approach, in Proc. 17th Int. Conf. Software Eng., pp. 243#253, 1995.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC