Modularizing Early Architectural Assumptions in Scenario-Based Requirements

Abstract

Abstract. Early architectural assumptions (EAAs) are initial assumptions about the architectural solution that are made already during requirements elicitation. Such EAAs are inherently present when applying requirements engineering methods and techniques situated at the transition to architecture, for example those adhering to the Twin Peaks model to software engineering.In the current state-of-the-art, early architectural assumptions (EAAs) are documented implicitly, and they are tangled within and scattered across heterogeneous requirement artifacts. This makes it hard to distinguish EAAs from actual requirements, analyze their relevance, and bring them in relation to architectural decisions taken in later development stages. As a consequence, early development activities in the transition to architecture are hindered by the lack of explicit support for EAAs.In this paper, we address this problem in the context of scenario-based requirements (use cases and quality attribute scenarios). We present a system meta-model for EAAs, and provide an aspect-oriented requirements language that allows the instantiation of EAAs in terms of use case-level pointcuts. We employ our prototype implementation of abovementioned techniques to evaluate and illustrate the benefits of making EAAs explicit in the early stages of development, specifically in terms of modularity and requirements navigability.

Evaluation of a process for architectural assumption management in software development

“…Ease of understanding the AAM process Interval N/A Five-point Likert Scale (i.e., 1 = "Very difficult" and 5 = "Very easy") Appendix D. Checklist used in the case study (1) Ensure adequate integration of the study into the course topics The objective of the case study is to validate the effectiveness of the AAM process in the context of requirements engineering and architecture design, while the goal of the course is to help students to acquire knowledge of requirements engineering and architecture design, and practice the learned knowledge in the course project. As evidenced in the systematic mapping study [4], assumptions should be managed from early stages (e.g., requirements engineering or software design [2,3,21]) of software development [4], and AAs are related to various types of artifacts (e.g., requirements and design decisions) [4,10]. Therefore, the case study is consistent with the topics of the course, and the course project is reasonable for meeting both the research and course objectives.…”

“…Assumptions are not independent in software development, but intertwined with many types of software artifacts. For example, when managing assumptions in software design (e.g., [2,3]), assumptions are commonly related to requirements, design decisions, components, etc. This is further elaborated in Section 2.3.…”

“…There are several frameworks designed for Assumption Description. For example, Van Landuyt and Joosen [3] proposed a meta-model and an instantiation strategy based on quality attribute scenarios and use cases to document AA. Another way to document assumptions in software development is to use specific languages.…”

“…Therefore, there is a need for systematic management of AAs in software development. Various AA management approaches have been proposed in literature (e.g., [1,3]), which can be used to support individual AA management activities (e.g., description of AAs). However, there is currently no work that explicitly proposes a general AA management process, comprised of a set of AA management activities.…”

Assumptions and their management in software development: A systematic mapping study

“…Assumptions are not independent in software development, but intertwined with many types of software artifacts. For example, when managing assumptions in software design (e.g., [26,27]), assumptions are usually related to requirements, design decisions, components, etc. However, as mentioned in Point (2) of this section, the existing studies only focus on limited types of assumptions (e.g., requirement assumptions [9]).…”