Question 2 of 6: Design Quality, Non-Functional Requirements and Attribute Conflicts

Question 2: Design Quality, Non-Functional Requirements and Attribute Conflicts (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 act as both design constraints and evaluation criteria: they shape which architectural style, data structures and algorithms a 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) Correctness vs. Maintainability: Execution-Evaluable or Not

Correctness can be evaluated by executing the designed system: it is checked by running test cases against the implementation and comparing the actual output to the expected output for each input, so it is a dynamic (system) quality attribute measured through execution. Maintainability cannot be evaluated by executing the system: running the program tells an assessor nothing about how easy the code will be to understand, modify or extend later. Maintainability is instead assessed by static review — inspecting module cohesion and coupling, the clarity of naming and documentation, and how localised a typical change would be — so it is a static (software) quality attribute judged from the design or source text itself rather than from a test run.

(c) Do Correctness and Maintainability Conflict?

Correctness and maintainability do not inherently conflict, and in a well-engineered design they reinforce each other: code that is clearly structured, well-named and loosely coupled is also easier to verify and easier to reason about, which makes it easier to get and keep correct. A conflict can appear indirectly, however, when a team under schedule pressure chases correctness through quick, targeted patches rather than a clean redesign — for example, fixing an edge-case bug in a billing calculation by adding a special-case if branch directly in a shared function rather than refactoring the calculation into its own clearly-named module. The patch restores correctness for that input immediately, but it increases the function's complexity and coupling, degrading maintainability and making the next bug fix riskier. So the two attributes are not fundamentally opposed, but they can trade off in practice when correctness is pursued through expedient patching instead of proper redesign.

Practical Application

A payment-processing service illustrates the distinction cleanly: its correctness is proven by executing transaction-accuracy test suites before every release, while its maintainability is judged in code review by inspecting whether the payment logic stays cleanly separated from fraud-check logic — a review that happens without ever running the code.