scispace - formally typeset
Search or ask a question

Dimensions of Concerns in Requirements Negotiation and Architecture Modeling 1

TL;DR: In this paper, the authors present a taxonomy of concerns used in the WinWin requirements negotiation approach and present the CBSP (Connector, Bus, System, Property) taxonomy supporting the classification and refinement of WinWin negotiation results.
Abstract: The development and refinement of system requirements into an architecture satisfying those requirements relies heavily on the successful collaboration of stakeholders with different backgrounds, expertise, and responsibilities. Stakeholders involved in this iterative process need comprehensible views that may be provided through multi-dimensional separation of concerns. Stakeholder objectives, constraints, and agreements captured in a requirements negotiation have to be organized e.g., by system features, system properties, or stakeholder contribution. On the other hand in software architecture modeling, components and connectors are the dominant dimensions of concerns used for decomposition. We will discuss dimensions of concerns used in the WinWin requirements negotiation approach and present the CBSP (Connector, Bus, System, Property) taxonomy supporting the classification and refinement of WinWin negotiation results. We will also discuss tools supporting this process.

Content maybe subject to copyright    Report

Citations
More filters
Proceedings ArticleDOI
06 Sep 2000
TL;DR: The experience shows that EasyWinWin helps to improve stakeholder involvement in the requirements engineering process and enhances the frequency, directness, and extent of stakeholder interactions.
Abstract: The EasyWinWin methodology supports collaborative elaboration, prioritization, and negotiation of system requirements. The approach enhances the WinWin negotiation model by integrating group productivity techniques and collaborative tools. EasyWinWin has been used in real-client custom development projects and for real-world COTS product release planning. Our experience shows that EasyWinWin helps to improve stakeholder involvement in the requirements engineering process and enhances the frequency, directness, and extent of stakeholder interactions. This helps to develop a deeper and broader set of deliverables in a shorter time and to identify and mitigate risks earlier in the life cycle.

78 citations

Journal ArticleDOI
TL;DR: This paper introduces a set of "connectors" to bridge models, both within and across the "upstream" activities in the software development lifecycle (specifically, requirements, architecture, and design).

55 citations

Proceedings ArticleDOI
16 Jul 2008
TL;DR: This paper encourages the industry to prioritize requirement, with help of B-Tree method in which the number of comparison required by the proposed method can be kept low.
Abstract: A software projects is bounded by number of constraints such as time, features, budget and resources. The needs & expectations of the customer are dynamic and depend on the various factors which keep changing. In order find out their relevance [24], to increase the customer satisfaction [23], planning the release of new prototype or version the requirements [16] prioritization have gained importance and have became an essential characteristic of requirements [24]. This is also important when there are strict constraints on schedule & resources one must negotiate & prioritize the most essential features to be incorporated as to make project successful. In industrial projects, there are many requirements which keep on increasing as the projects undergo development, so prioritization is must [23, 24, 26, 27] but often it is dropped because of large number of growing requirements need more number of comparisons. "Yet there has been little progress to date, either theoretical or practical, on the mechanisms for prioritizing software requirements [2]."[1]. This paper encourages the industry to prioritize requirement, with help of B-Tree method in which the number of comparison required by the proposed method can be kept low.

44 citations


Cites background from "Dimensions of Concerns in Requireme..."

  • ...Customers and developers must collaborate on requirements prioritization & negotiation [12, 13, 14]....

    [...]

  • ...[12] Grnbacher, Paul, Egyed, Alexander, and Medvidovic, Nenad, "Dimensions of Concerns in Requirements Negotiation and Architecture Modeling", in Proc....

    [...]

Journal ArticleDOI
TL;DR: The overall System Dynamics-based simulation model of EasyWinWin is presented and details and results of the requirements elicitation component of the model are provided to assess the issues associated with the social and behavioural aspects of the Easy WinWin process and to explore how these issues affect the overall outcome of the process.

38 citations

Proceedings ArticleDOI
05 Sep 2000
TL;DR: Two COTS products are integrated: a collaboration platform and a CASE environment to provide support for stakeholder collaboration as well as modeling and analysis for requirements negotiation.
Abstract: A methodology for collaborative requirements engineering has to provide intuitive and straightforward means for involving success-critical stakeholders like customers, users, and developers. A promising approach is to provide a set of views presenting comprehensible portions of the evolving requirements model to the stakeholders. We have developed such views for requirements negotiation in the course of the EasyWinWin project. Tools supporting these views need to provide support for stakeholder collaboration as well as modeling and analysis. We have therefore integrated two COTS products: a collaboration platform and a CASE environment.

19 citations

References
More filters
Journal ArticleDOI
TL;DR: A definition and a classification framework for architecture description languages are presented and the utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations, enabling us, in the process, to identify key properties ofADLs.
Abstract: Software architectures shift the focus of developers from lines-of-code to coarser-grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation and programming languages on the other. This paper attempts to provide an answer to these questions. It motivates and presents a definition and a classification framework for ADLs. The utility of the definition is demonstrated by using it to differentiate ADLs from other modeling notations. The framework is used to classify and compare several existing ADLs, enabling us, in the process, to identify key properties of ADLs. The comparison highlights areas where existing ADLs provide extensive support and those in which they are deficient, suggesting a research agenda for the future.

2,148 citations


"Dimensions of Concerns in Requireme..." refers background or methods in this paper

  • ...This may involve rapid prototyping of the application, as supported by SAAGE [8, 9]....

    [...]

  • ...As a next step in this research, we will combine the tools with SAAGE [8, 9] to enhance the integration with architectural modeling and analysis....

    [...]

  • ...The focus is clearly on decomposition by identifying components and connectors of the future system as well as their roles and responsibilities [9]....

    [...]

Proceedings ArticleDOI
16 May 1999
TL;DR: A new paradigm for modeling and implementing software artifacts is described, one that permits separation of overlapping concerns along multiple dimensions of composition and decomposition, which addresses numerous problems throughout the software lifecycle.
Abstract: Done well, separation of concerns can provide many software engineering benefits, including reduced complexity, improved reusability, and simpler evolution. The choice of boundaries for separate concerns depends on both requirements on the system and on the kind(s) of decomposition and composition a given formalism supports. The predominant methodologies and formalisms available, however, support only orthogonal separations of concerns, along single dimensions of composition and decomposition. These characteristics lead to a number of well-known and difficult problems. The paper describes a new paradigm for modeling and implementing software artifacts, one that permits separation of overlapping concerns along multiple dimensions of composition and decomposition. This approach addresses numerous problems throughout the software lifecycle in achieving well-engineered, evolvable, flexible software artifacts and traceability across artifacts.

1,452 citations


"Dimensions of Concerns in Requireme..." refers background in this paper

  • ...Multi-dimensional separation of concerns is a powerful concept supporting stakeholder-relevant views across life-cycle phases [5, 11]....

    [...]

Proceedings ArticleDOI
16 May 1999
TL;DR: An architecture description language (ADL) specifically designed to support architecture-based evolution and discuss the kinds of evolution the language supports and a component-based environment that enables modeling, analysis, and evolution of architectures expressed in the ADL, as well as mapping of architectural models to an implementation infrastructure.
Abstract: Software architectures have the potential to substantially improve the development and evolution of large, complex, multi-lingual, multi-platform, long-running systems. However, in order to achieve this potential, specific techniques for architecture-based modeling, analysis, and evolution must be provided. Furthermore, one cannot fully benefit from such techniques unless support for mapping an architecture to an implementation also exists. This paper motivates and presents one such approach, which is an outgrowth of our experience with systems developed and evolved according to the C2 architectural style. We describe an architecture description language (ADL) specifically designed to support architecture-based evolution and discuss the kinds of evolution the language supports. We then describe a component-based environment that enables modeling, analysis, and evolution of architectures expressed in the ADL, as well as mapping of architectural models to an implementation infrastructure. The architecture of the environment itself can be evolved easily to support multiple ADLs, kinds of analyses, architectural styles, and implementation platforms. Our approach is fully reflexive: the environment can be used to describe, analyze, evolve, and (partially) implement itself, using the very ADL it supports. An existing architecture is used throughout the paper to provide illustrations and examples.

301 citations


"Dimensions of Concerns in Requireme..." refers methods in this paper

  • ...This may involve rapid prototyping of the application, as supported by SAAGE [8, 9]....

    [...]

  • ...As a next step in this research, we will combine the tools with SAAGE [8, 9] to enhance the integration with architectural modeling and analysis....

    [...]

  • ...The voting process indicates that the win condition should be refined into a component win condition W03C and a bus property win condition W03BP: The far right part of the figure suggests a possible architectural solution using the C2 architectural style [8]....

    [...]

01 Jan 1998
TL;DR: The WinWin spiral model was used by 15 teams to prototype, plan, specify, and build multimedia applications for the Integrated Library System (ILS) at USC as discussed by the authors, and the results showed the model's utility and cost-effectiveness.
Abstract: Fifteen teams used the WinWin spiral model to prototype, plan, specify, and build multimedia applications for USC's Integrated Library System. The authors report lessons learned from this case study and how they extended the model's utility and cost-effectiveness in a second round of projects.

299 citations

Journal ArticleDOI
TL;DR: The WinWin spiral model was used by 15 teams to prototype, plan, specify, and build multimedia applications for the Integrated Library System (ILS) at USC as mentioned in this paper, and the results showed the model's utility and cost-effectiveness.
Abstract: Fifteen teams used the WinWin spiral model to prototype, plan, specify, and build multimedia applications for USC's Integrated Library System. The authors report lessons learned from this case study and how they extended the model's utility and cost-effectiveness in a second round of projects.

276 citations