Week 03 · Lecture 02 — how architects turn "what the customer wants" into requirements that are actually usable: elicit it, analyze it, write it down right, and prove it's SPECIAL.
Zooming out from Lecture 01: architecture isn't a single activity, it's a repeatable process with five moving parts.
This lecture zooms all the way into step 1 — everything below is about turning raw customer wishes into requirements an architect can actually design from.
Requirements engineering is the disciplined, systematic approach to producing good requirements. Architects don't just do it once — they bounce back and forth between requirements and design constantly, and are sometimes deeply embedded in this phase.
Elicitation identifies stakeholders and uncovers what the customer actually needs (including non-functional requirements) — starting from all the sources that could reveal a requirement.
Different sources can hold similar but conflicting visions of the same system — part of the job is reconciling that later, during Analysis.
1-on-1 conversations with stakeholders
Group sessions to surface shared needs
Watching users do their actual work
Walk through concrete usage stories
Raw requirements are often contradictory, incomplete, vague, or just wrong. Analysis clears the air before detailed design begins.
Sorts requirements by nature, along three axes:
| Axis | Meaning | Example |
|---|---|---|
| Functional vs. Non-functional | What it does vs. how it behaves | "Must allow login" vs. "Must load in 2s" |
| Product vs. Process | What the software must do vs. how it's built | "Must support payments" vs. "Must be built using Agile" |
| Imposed vs. Derived | Given directly by stakeholders vs. inferred by the dev team | "Must run on iOS & Android" vs. "Should use Flutter" |
Defines the system's boundaries — what's in scope and what's out. This is often where architectural design quietly begins, since decomposing the system is essential groundwork.
Example — Online banking system: Inside: login, balance check, money transfer. Outside: ATM hardware, physical cash withdrawal.
| Requirement | Issue found | Resolution |
|---|---|---|
| R1: Secure login | Vague — "secure" undefined | Clarify exact login method with stakeholders |
| R2: Fast & seamless UX | Conflicts with R1 — strong security can slow the app | Balance speed & security (efficient encryption, smart caching) |
| R3: Multiple payment methods | Incomplete — methods not listed | Define required methods explicitly |
| R4: 24/7 availability | Contradicts maintenance downtime needs | Plan rolling updates / redundant servers |
The results of elicitation and analysis get formally captured and documented so every stakeholder can review them. Stakeholders then check the specified requirements for accuracy, completeness, and feasibility — that's validation.
For a specification to actually be usable, each requirement must show a set of desired characteristics — covered next.
SSpecific — clear (not open to interpretation), concise (brief), exclusive (states one thing only).
| Specific? | Requirement |
|---|---|
| No | The software shall search the database. (search for what?) |
| Yes | The software shall search for a product using the product ID. |
| No | The software shall be secure and fast. (secure how? fast how?) |
| Yes | Server acknowledgment shall be sent within ½ second of receiving a request. |
CCorrect — accurately describes a desired system function; incorrect requirements cause incorrect/undesired behavior.
Example: a registration form correctly rejects a duplicate username/password combo with a clear error — matching exactly what was specified.
CComplete — individually (each requirement fully detailed) and collectively (the whole set covers all functionality in the SRS). Incomplete requirements → incomplete design → incomplete system.
| Complete? | Requirement |
|---|---|
| No | The software shall generate product reports. |
| Yes | The software shall generate product reports consisting of description, picture, and price; reports shall be in PDF format. |
CConsistent — doesn't prevent the design/construction of other requirements (no conflicts).
✅ "Support online payments" + "Support credit cards" (compatible). ❌ "Must be offline only" + "Must support online payments" (conflict).
AAttainable — realistically achievable within project constraints (time, technology, budget, resources); applies to both product and process.
| Attainable? | Requirement |
|---|---|
| No | The software shall execute on all future operating systems. |
| Yes | The software shall execute on the Microsoft Windows 7 platform. |
VVerifiable — there must be a way to measure/test that it's been met. Un-verifiable requirements can never be "proven" done — a serious early flaw.
| Verifiable? | Requirement |
|---|---|
| No | The system shall maximize communication speed. |
| Yes | The system's data rate shall be no less than 1 Mbps. |
💡 The recurring pattern across all six: turn vague adjectives ("secure," "fast," "maximize") into numbers, limits, or explicit conditions.
The exam loves handing you one sentence and asking "is this valid?" Train your eye on this pattern:
| Vague requirement | Why it fails | Fixed version |
|---|---|---|
| "The software shall be secure and fast." | Not specific, not verifiable — no measurable target | "Login shall use AES-256 encryption; response time ≤ 1s." |
| "The system shall maximize communication speed." | Not verifiable — no baseline or number | "Data rate shall be no less than 1 Mbps." |
| "The software shall search the database." | Not specific — missing search criteria | "Shall search for a product using the product ID." |
| "The app must handle 1 billion users on a $500 budget." | Not attainable — unrealistic given constraints | "The app must handle 1,000 concurrent users." |
Next session: designing the software architecture using the 4+1 View Model —
Object model
Module organization
Concurrency & workflow
Deployment on hardware
Plus the +1 User (Use-Case) View tying them all together — already covered in the Sheet 09 of the Chapter 2 Blueprint if you want a refresher.