{"title":"On the Role of Early Architectural Assumptions in Quality Attribute Scenarios: A Qualitative and Quantitative Study","authors":"D. Landuyt, W. Joosen","doi":"10.1109/TWINPEAKS.2015.10","DOIUrl":"https://doi.org/10.1109/TWINPEAKS.2015.10","url":null,"abstract":"Architectural assumptions are fundamentally different from architectural decisions because they can not be traced directly to requirements, nor to domain, technical or environmental constraints, they represent conditions under which the designed solution is expected to be valid. Early architectural assumptions are similar in nature, with the key difference that they are not made during architectural design but during requirement elicitation, not by the software architect (a solution-oriented stakeholder), but by the requirements engineer (a problem-oriented stakeholder). They represent initial assumptions about the system's architecture, and allow the requirements engineer to be more precise in documenting the requirements of the system. The role of early architectural assumptions in the current practice of quality attribute scenario elicitation and related development activities in the transition to architecture is unknown and under-investigated. In this paper, we present the results of an exploratory study that focuses on the role and nature of these assumptions in the early development stages. We studied a reasonably large set of quality attribute scenarios for a realistic industrial case, a smart metering system. Our study (i) confirms that quality attribute scenario elicitation in practice does rely heavily on early architectural assumptions, and (ii) shows that they do influence the perceived quality of the requirements body as a whole, in some cases positively, in other cases negatively. These findings provide empirical arguments in favor of making such assumptions explicit already during the requirements elicitation activities. Especially in the context of iterative software development methodologies such as the Twin Peaks model, a well-defined and -documented set of assumptions could smoothen the transition between successive development iterations.","PeriodicalId":112329,"journal":{"name":"2015 IEEE/ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture","volume":"50 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114707545","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Is Requirements Engineering Inherently Counterproductive?","authors":"P. Ralph, Rahul Mohanani","doi":"10.1109/TWINPEAKS.2015.12","DOIUrl":"https://doi.org/10.1109/TWINPEAKS.2015.12","url":null,"abstract":"This paper explores the possibility that requirements engineering is, in principle, detrimental to software project success. Requirements engineering is conceptually divided into two distinct processes: sense making (learning about the project context) and problem structuring (specifying problems, goals, requirements, constraints, etc.). An interdisciplinary literature review revealed substantial evidence that while sense making improves design performance, problem structuring reduces design performance. Future research should therefore investigate decoupling the sense making aspects of requirements engineering from the problem structuring aspects.","PeriodicalId":112329,"journal":{"name":"2015 IEEE/ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture","volume":"88 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115863993","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Preethu Rose Anish, Balaji Balasubramaniam, J. Cleland-Huang, R. Wieringa, M. Daneva, S. Ghaisas
{"title":"Identifying Architecturally Significant Functional Requirements","authors":"Preethu Rose Anish, Balaji Balasubramaniam, J. Cleland-Huang, R. Wieringa, M. Daneva, S. Ghaisas","doi":"10.1109/TWINPEAKS.2015.9","DOIUrl":"https://doi.org/10.1109/TWINPEAKS.2015.9","url":null,"abstract":"Failure to identify and analyze architecturally significant functional and non-functional requirements (NFRs) early on in the life cycle of a project can result in costly rework in later stages of software development. While NFRs indicate an explicit architectural impact, the impact that functional requirements may have on architecture is often implicit. The skills needed for capturing functional requirements are different than those needed for making architectural decisions. As a result, these two activities are often conducted by different teams in a project. Therefore it becomes necessary to integrate the knowledge gathered by people with different expertise to make informed architectural decisions. We present a study to bring out that functional requirements often have implicit architectural impact and do not always contain comprehensive information to aid architectural decisions. Further, we present our initial work on automating the identification of architecturally significant functional requirements from requirements documents and their classification into categories based on the different kinds of architectural impact they can have. We believe this to be a crucial precursor for recommending specific design decisions. We envisage ArcheR, a tool that (a) automates the identification of architecturally significant functional requirements from requirement specification documents, (b) classify them into categories based on the different kinds of architectural impact they can have, (c) recommend probing questions the business analyst should ask in order to produce a more complete requirements specification, and (d) recommend possible architectural solutions in response to the architectural impact.","PeriodicalId":112329,"journal":{"name":"2015 IEEE/ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture","volume":"34 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132355683","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
G. Lucassen, F. Dalpiaz, J. V. D. Werf, S. Brinkkemper
{"title":"Bridging the Twin Peaks -- The Case of the Software Industry","authors":"G. Lucassen, F. Dalpiaz, J. V. D. Werf, S. Brinkkemper","doi":"10.1109/TWINPEAKS.2015.13","DOIUrl":"https://doi.org/10.1109/TWINPEAKS.2015.13","url":null,"abstract":"We review the relationship between software architecture and requirements in the context of software products. Based on empirical evidence from a comparative case study, we promote four positions: (1) the requirements/architecture alignment problem for software products is inherently different than the same problem for tailor-made software, (2) bridging the Twin Peaks corresponds to defining and enacting a stepwise evolution of the product architecture, (3) communication tasks are ascribed to the product manager rather than the architect, and (4) integrated and cross-disciplinary tools are key to maintain requirements/architecture alignment. We argue that these positions motivate and characterize future research in the field.","PeriodicalId":112329,"journal":{"name":"2015 IEEE/ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture","volume":"2675 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123385663","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Scenario-Based Architecting with Architecture Trace Diagrams","authors":"E. Hebisch, Matthias Book, V. Gruhn","doi":"10.1109/TWINPEAKS.2015.11","DOIUrl":"https://doi.org/10.1109/TWINPEAKS.2015.11","url":null,"abstract":"Designing a software architecture requires a lot of effort. Functional and quality requirements need to be considered in relation to each other and balanced in order to define viable architectural abstractions that support them. Architects usually rely on their intuition and experience to create and choose between architecture alternatives. The viability of a decision can be checked by evaluating the architecture only after it has been created. In this paper, we propose an approach for creating architectural alternatives more directly from the requirements, enabling the evaluation of design decisions even before an architecture exists. We use architecture trace diagrams (ATDs) to model the interplay of components involved in the execution of business processes. We show how the shape, semantics and annotated characteristics of the ATDs can be used to derive architectural decisions, reducing the effort for the documentation of their rationale.","PeriodicalId":112329,"journal":{"name":"2015 IEEE/ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129380629","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Architecting to Ensure Requirement Relevance: Keynote TwinPeaks Workshop","authors":"J. Bosch","doi":"10.1109/TWINPEAKS.2015.8","DOIUrl":"https://doi.org/10.1109/TWINPEAKS.2015.8","url":null,"abstract":"Research has shown that up to two thirds of features in software systems are hardly ever used or not even used at all. This represents a colossal waste of R&D resources and occurs across the industry. On the other hand, product management and many others work hard at interacting with customers, building business cases and prioritizing requirements. A fundamentally different approach to deciding what to build is required: requirements should be treated as hypothesis throughout the development process and constant feedback from users and systems in the field should be collected to dynamically reprioritize and change requirements. This requires architectural support beyond the current state of practice as continuous deployment, split testing and data collection need to be an integral part of the architecture. In this paper, we present a brief overview of our research and industry collaboration to address this challenge.","PeriodicalId":112329,"journal":{"name":"2015 IEEE/ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture","volume":"14 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2015-05-16","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125433226","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}