Functional, Quality, Process, Implementation, and Business Requirements: 25-Comp-B11 Advanced Software Design, December 2018, Q2

Question 2: Functional, Quality, Process, Implementation, and Business Requirements (Part I)

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.

These five categories (Wiegers' requirements taxonomy) refine the coarse functional/non-functional split into more specific, independently-traceable buckets, each with a different SOURCE and a different kind of verification.

(a) Functional Requirement

A statement of a service the system must provide or of how it must behave for given inputs. Example: "The system shall let a registered user search for a book by ISBN and display its title, author, and availability."

(b) Quality Requirement

A measurable attribute of how well the system performs its functions (performance, reliability, usability, security — the same territory as a "non-functional requirement," quantified per Question 3). Example: "The search shall return results within 2 seconds for 95% of queries under 200 concurrent users."

(c) Process Requirement

A constraint on HOW the software is to be developed, rather than on the delivered product itself — e.g. a mandated development methodology, required code-review or documentation standard, or a contractual milestone/reporting schedule. Example: "The supplier shall follow the customer's configuration-management standard and deliver a traceability matrix at each milestone."

(d) Implementation Requirement

A constraint on the technical solution itself — a mandated platform, language, database, or third-party component the delivered system must use, independent of what the system must DO. Example: "The system shall be implemented in Java and shall persist data in a PostgreSQL database already licensed by the customer."

(e) Business Requirement

A high-level statement of why the project exists — the business objective or benefit the sponsoring organization expects, from which functional and quality requirements are later derived and against which they are justified. Example: "Reduce average book-checkout processing time by 50% within one year of deployment."

The five categories are not mutually exclusive labels on disjoint requirement sets but different LENSES: a single business requirement (e) is refined into several functional requirements (a), each of which may carry attached quality requirements (b), while process (c) and implementation (d) requirements constrain the project and product independently of what functionality is being delivered.

Concept & Theory: Requirements Categories by Source and Verification

Topic: Five requirement categories, each traceable to a different stakeholder concern and verified a different way.

Key relations: Business requirement (why) → functional requirements (what) → quality requirements (how well); process and implementation requirements constrain the HOW independently of the WHAT.

Why this works: Separating "constrains the product's behaviour" (functional/quality) from "constrains the project or the technology" (process/implementation) prevents a technology mandate from being mis-verified as if it were a testable behaviour, and vice versa.

Common pitfall: Collapsing quality requirements back into "non-functional requirements" and stopping there — the finer taxonomy specifically separates process and implementation constraints, which come from very different stakeholders (procurement/IT policy) than quality targets (end users/operations).

Source: Wiegers, Software Requirements (3rd ed.), ch. "Software Requirements."

Question 2 of 28: Functional, Quality, Process, Implementation, and Business Requirements