90 likes | 257 Views
CBSP Bridging Requirements and Architecture Models. Paul Grünbacher Center for Software Engineering University of Southern California, Los Angeles gruenbac@sunset.usc.edu WESAS Workshop @ UCI, May 8-9, 2000. Background. Objectives Improve ties between requirements and architecture models
E N D
CBSPBridging Requirements and Architecture Models Paul Grünbacher Center for Software Engineering University of Southern California, Los Angeles gruenbac@sunset.usc.edu WESAS Workshop @ UCI, May 8-9, 2000
Background • Objectives • Improve ties between requirements and architecture models • Integrate EasyWinWin requirements negotiation and SAAGE architecture research • Challenges • Requirements and architecture models emerge concurrently in an iterative process • The process involves heterogeneous stakeholders with conflicting objectives and expectations • Natural language leads to imprecision and ambiguities of requirements models • Semantic gap between high-level requirements and elements in a system architecture
A set of groupware-supported collaboration techniques (“thinkLets”) enabling stakeholder involvement in the WinWin requirements negotiation process Electronic brainstorming of stakeholder interests Categorization and organization Distributed prioritization Shared definition of terms Shared domain taxonomy Use case analysis EasyWinWin Collaborative Requirements Negotiation
A real-world Negotiation Example:COTS Product Release Planning • 11 stakeholders created 275 statements • 88 win conditions, 108 issues, 150 options • Architectural relevance analysis of the 108 issues • 20: components and connectors • 15: properties of components & connectors (size of client sw, security of connection, …) • 13: system-level properties • 3: low-level design or implementation • 50% of the issues were architecturally relevant
CBSP:Component, Bus, System, Property • C: describe or involve a Component in an architecture • B: describe or imply a connector (Bus) • S: describe System-wide features or features pertinent to multiple components and connectors • CP: describe or imply component properties • BP: describe or imply connector (bus) properties • SP: describe or imply system properties pertaining to the entire architecture
CBSP Benefits • Lightweight approach • Requirements to architecture (synthesis) • Identify and classify WinWin artifacts • Reveal incomplete and puzzling WinWin artifacts • Refine complex WinWin artifacts into CBSP artifacts • Architecture to requirements (analysis) • Capture architectural mismatches • Capture architecture trade-off decisions