This chapter is from the book
This chapter is from the book
This chapter is from the book
1.2 Achieving System Qualities
A system is constructed to satisfy some organizational objectives. The system may be externally facing, or it may be created for internal purposes. In either case, the operational objectives can be manifested as a set of quality goals or requirements. These requirements may be either explicit or implicit, but they always exist. For example, a performance requirement will help determine how quickly the users of the system can achieve their desired task.
Achieving quality in an AI system depends mostly on three aspects: the life-cycle processes, the software architecture, and the AI model. The quality of the AI model, in turn, depends on the data quality. Figure 1.1 highlights these three aspects of AI systems. We discuss these influences in their own sections after we discuss system quality more generally, and we will defer the discussion of data quality to Section 1.5.1, “Data.” The quality of all artifacts, such as code, configuration, and user interface design, is certainly important and interacts with all these aspects, but they are outside the scope of this book.
)
Figure 1.1 Influences on achieving system quality.
Quality requirements for a system are formalized as quality attributes. “A quality attribute (QA) is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders beyond the basic function of the system.”4 A quality attribute requirement is thus a requirement for the quality of the system that has a measurable or testable condition. It is insufficient to say, “A system should be highly available.” Instead, the requirement should give the conditions under which availability should be considered, a source of a threat to availability, and the desired system response with measurable characteristics.
Quality requirements may be stated for both the AI and non-AI portions of the system. The AI portion may include output quality expectations such as accuracy, robustness, fairness, and other mandated restrictions on the AI models used or their outputs. The non-AI portions may have requirements for attributes such as performance, security, availability, and modifiability. Chapters 7–11 of this book enumerate a collection of qualities that may apply to the system under construction as well as considerations and techniques that may apply to these qualities. The AI portions of a system may change the traditional quality requirements. For example, security requirements now need to consider possible attacks to change the system’s behavior by manipulating machine learning (ML) training data and pipelines.
For non-AI systems, the achievement of a quality attribute requirement is strongly influenced by architectural tactics specific to the quality being considered. For example, “introduce redundancy” is a tactic for the achievement of a reliable system. For AI systems, the architectural considerations are supplemented by considerations of data. For example, the reliability and robustness of a model are strongly influenced by the distribution of data used for training. Out-of-distribution (OOD) data, by definition, is not part of the training data. Nevertheless, there will always be some OOD data, even if designers try to be as inclusive and representative as possible. There are three main ways to enhance reliability and robustness: (1) expanding the training dataset to include as much OOD data as possible; (2) using more advanced training algorithms that can generalize better; and (3) employing out-of-model approaches to detect and manage OOD data. These general approaches—better data for the model, better training algorithms, and better out-of-model system-level methods—are applicable to many other aspects of quality.
Although quality requirements, like other requirements, may emerge during the construction and operation of the system, it is important for the designer to be aware of these requirements as soon as possible. Quality requirements often conflict with each other, and the designer must make decisions about the tradeoffs among these requirements. Such decisions can be made either consciously or unconsciously, but they will be made. We, of course, advocate for making tradeoff decisions with full consciousness of the alternatives and their respective advantages and disadvantages.
Returning to the three influences identified in Figure 1.1, we discuss the life-cycle processes first, as that sets the context for exploring the other two.
