Issues Dealing with Non-Functional Requirements across the Contractual Divide

Abstract

Abstract-Agreement on Non-Functional Requirements between customer and supplier is crucial to a successful IT solution delivery project. In an ideal world, stakeholders and architects cooperate to achieve their common goals in a win-win situation. In a commercial setting, however, one dominant feature often introduces powerful forces from outside the technical realm. That feature is the customer/supplier relationship, usually formalized in bidding rules or as a delivery contract. Formal customer/supplier relationships often place severe limitations on information exchange between stakeholders and architects. In this paper, we explore the effect of such limitations on the interaction of architectural design with the quantification of Non-Functional Requirements, and explore a number of avenues to deal with them.

Software Architects’ Experiences of Quality Requirements: What We Know and What We Do Not Know?

“…RQ6: How do QRs get quantified, if at all? Our results agree with [11] on the importance of QRs quantification in practice. However, unlike [4], our SAs did not indicate that searching for new or better quantification techniques was their prime concern.…”

“…We think the contrast is because our SAs came from regulated environments where terminology, roles and processes are determined, well communicated, and lived up to. Our findings agree with [11] on the importance that SAs place on gaining as deep as possible understanding of the QRs and using it to deliver a good quality architecture design.…”

“…Moreover, our review of these 18 studies indicated that none of them considered the SAs' perspective. More recently (2010-2012), RE research yielded five publications [6,8,9,10,11] dedicated specifically to the SAs' perceptions on QRs. These studies agree that the perspectives of SAs and RE specialists do differ in both interpreting the role of QRs in downstream software development activities and in reasoning about how QRs problems and solutions are framed, analysed and resolved.…”

“…As the Introduction mentioned, the SAs' perspective on QRs was the explicit focus of five studies [6,8,9,10,11]. In [9], a survey with one company's SAs uncovered the importance of QRs as perceived by SAs, the ways in which they dealt with QRs, and the impact this had on IT project success.…”

“…Also, projects that used QRs verification techniques were more successful than those that did not. In [11], the authors explain the effect of contractual client-vendor relationship on the interaction of software architecture and quantification of QRs. The authors put forward that if information-sharing between parties is limited, this would significantly impede the quantification of QRs.…”