Question 2 of 11: Design Quality, Non-Functional Requirements and Conflicting Attributes

Question 2: Design Quality, Non-Functional Requirements and Conflicting Attributes (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Quality and Non-Functional Requirements

The quality of the system that emerges from design is, to a large degree, a direct measure of how faithfully the design satisfies the system's non-functional requirements (NFRs) — performance, reliability, security, usability, maintainability and the like. Functional correctness alone does not make a system high-quality: a system that computes the right answer but takes ten seconds to respond, cannot survive a single server failure, or exposes user data to attackers is functionally correct yet poor-quality. NFRs therefore act as design constraints and evaluation criteria simultaneously — they shape which architectural style, data structures and algorithms the designer chooses, and afterward they are exactly the criteria against which the resulting design's quality is judged. ISO/IEC 25010 formalises this by defining product quality as a set of characteristics (functional suitability, performance efficiency, reliability, security, maintainability, portability and others) that are, in essence, a structured restatement of a system's NFRs.

(b) System Quality Attributes vs. Software Quality Attributes

Correctness, Reliability and Performance are system (dynamic) quality attributes: each can only be genuinely evaluated by running the system. Correctness is checked by executing test cases and comparing actual output to expected output; Reliability is measured from failure statistics (mean time between failures) accumulated while the system runs under real or simulated load; Performance is measured by timing and profiling the system while it executes a workload. None of the three can be verified from the design or source text alone. Maintainability, Portability and Security are software (static) quality attributes: they are assessed by reviewing the design or code itself rather than by running the program. Maintainability is judged by inspecting module cohesion, coupling and documentation quality; Portability is judged by reviewing how much of the design depends on a specific operating system, hardware or library; Security (at the design level) is judged through threat modelling and secure-design review of the architecture and access-control logic, examining the design for exploitable weaknesses before a single line is executed.

(c) Conflicting Quality Attributes

Quality attributes frequently trade off against one another because improving one consumes a resource (time, memory, generality) that another attribute needs. Performance versus Portability conflict when a designer hand-tunes code to a specific processor or operating system's native APIs to extract maximum speed; the resulting design runs fast on that platform but must be substantially reworked to run anywhere else, directly sacrificing portability for performance. Performance versus Maintainability conflict when a design is aggressively optimised — inlining logic, hand-managing memory, collapsing several clear modules into one tightly coupled routine to remove call overhead — because the resulting code is faster but far harder for another engineer to read, test or safely change later. A third example, Security versus Performance, appears whenever encryption, input validation and authentication checks are added on every request: each check strengthens security but adds measurable latency, so a design that must meet an aggressive response-time target and a strict security policy at once has to negotiate a deliberate balance rather than maximise either attribute alone.

Practical Application

A payment-processing service illustrates all three points at once: its correctness and performance are proven by executing load and transaction-accuracy tests before release, its maintainability and portability were judged during design review of the code's module boundaries, and its designers explicitly traded some raw throughput for the mandatory encryption and fraud-check logic that security compliance required.