Colin Werner

Topic

The Iceberg Theory on the Shared Understanding of Non-Functional Requirements in Continuous Software Engineering

Department of Computer Science

Date & location

• Friday, March 1, 2024

• 9:00 A.M.

• Clearihue Building

• Room B007

Reviewers

Supervisory Committee

• Dr. Daniela Damian, Department of Computer Science, University of Victoria (Supervisor)

• Dr. Neil Ernst, Department of Computer Science, UVic (Member)

• Dr. Daniel Berry, Cheriton School of Computer Science, University of Waterloo (Outside Member)

• Dr. Klass-Jan Stol, Computer Science and Information Technology, University of College Cork (Outside Member)

External Examiner

• Dr. Krzysztof Wnuk, Software Engineering, Blekinge Institute of Technology 

Chair of Oral Examination

• Dr. Tao Lu, Department of Electrical and Computer Engineering, UVic

   

Abstract

While software is largely considered to be heavily associated with technology, it is ultimately software developers that design, discuss, architect, write, test, re-write, and maintain the code that is compiled into the respective software. These humans are, after all, not perfect, and for the most part are not working in isolation from one another. Thus building a shared understanding amongst a group of software developers, including requirements, is key to ensuring downstream software activities are efficient and effective. Non-functional requirements (NFR), which include performance, availability, and maintainability, are vitally important to overall software quality and that the software fulfills its intended purpose. Research has shown that NFRs are, in practice, poorly defined and di cult to verify, especially in agile environments. A lack of attention to NFRs could potentially derail a software project. Organizations must frequently make trade-o s between timely delivery of promised software features and rigorous system design that incorporates sufficient attention for vital NFRs. 

The software industry has always sought to shorten the time of delivery of systems and features, including the adoption of iterative and incremental methods, in particular agile methods, which have become the norm. Practices such as Continuous Integration, which relies on automatically testing newly integrated code, inspired the automation of other activities within software development, allowing the whole development process to become more continuous. This has led to a trend that has been called continuous software engineering (CSE). CSE relies on automated and fast releases of new versions, delivering new features quickly to users. However, feature development is usually driven by functional requirements (FR), while such fast delivery frequently means that non-functional requirements receive less attention. Previous work has pointed out that NFRs are frequently neglected in agile development, and indeed, little work exists that has explored NFRs in the context of CSE. A major complication of NFRs is that they relate to an entire systems architecture, which is problematic for two reasons. First, evaluating the impact of frequent updates, which comes with a continuous software engineering process, on NFRs is very challenging. Second, it can be challenging for all developers in a project to have a shared and common understanding of a systems architecture, in particular for very large systems. 

 In this dissertation, I describe a multi-year, multi-case study to empirically investigate how four organizations, for which NFRs are paramount to their business survival, build, manage, and maintain the shared understanding of NFRs in their continuous practices. My research goal is to develop a deep and rich understanding of the relationship between an organization and their shared understanding of NFRs in CSE. Through the results and insights from this in-depth research, I developed the Iceberg theory on the complex and intricate relationship between a shared understanding of NFRs and CSE. The theory includes a classification of (lack of) a shared understanding, nine practices an organization may use to build a shared understanding, in addition to the associated challenges and the triggers that prompted an organization to build said shared understanding.