25-Comp-B11 Advanced Software Design · Undated paper
Question 2 of 28: Functional vs. Non-Functional Requirements and Their Role in Design
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
17-Comp-B11 Advanced Software Design — National Exams, May 2019. 3 hours, closed book exam with two aid sheets allowed (written on both sides), no calculator permitted. The paper is organized into five parts, and candidates were instructed to answer any five (5) questions in Part I, any three (3) in Part II, any four (4) in Part III, any two (2) in Part IV, and any five (5) in Part V — only the first questions answered, in each part, as they appear in the answer book are marked. All questions carry equal weight, so the 19 questions actually marked (5+3+4+2+5 of 28) each count for 100/19 ≈ 5.26% of the paper. All 28 questions are answered below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software processes, requirements engineering, design principles, testing, dependability, reuse; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/metrics/quality coverage; Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software — pattern-language structure, the GoF pattern catalogue, and the "favor object composition over class inheritance" / "program to an interface, not an implementation" principles; Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, visibility, encapsulation, interfaces; Bertrand Meyer, Object-Oriented Software Construction — design by contract, preconditions/postconditions/class invariants; Barbara Liskov's 1987 substitutability paper for Question 12; Stroustrup, The C++ Programming Language, for friend/access-control semantics (Question 25).
Question 12 prints “Liskpv substitution principle”, a typo in the paper; it is answered as the Liskov substitution principle.
PART I — General Principles (answer any 5 of 7)
Question 2: Functional vs. Non-Functional Requirements and Their Role in Design (Part I)
A functional requirement (FR) states a service the system must provide or how it must behave for a given input — it describes something the system DOES (e.g. "the system shall let a user search contacts by name"). A non-functional requirement (NFR) is a constraint on those services or on the system as a whole — performance, security, reliability, usability — describing HOW WELL the system must behave, not a discrete service in its own right (e.g. "a search shall return within 1 second for up to 10,000 contacts").
How design uses FRs. Each FR is traced directly into the FUNCTIONAL decomposition of the design: it becomes (or is covered by) a use case, which in turn maps onto one or more operations on one or more classes (Question 4's use-case-to-class-diagram derivation). FRs therefore drive the STRUCTURE of the design — which classes exist and what methods they expose.
How design uses NFRs. NFRs rarely map to a single class; instead they drive ARCHITECTURAL decisions that cut across the whole design — a strict response-time NFR might force a caching layer or an indexed lookup structure rather than a linear scan; a security NFR might force an authentication/authorization layer that every operation must pass through; a maintainability NFR might be the deciding factor between two functionally-equivalent architectural styles (e.g. layered vs. microkernel). Where an FR is satisfied by adding the right class or method, an NFR is satisfied by choosing the right architecture, algorithm, or cross-cutting mechanism.
