FUNCTIONAL REQUIREMENTS — WHAT the system must do. services, behaviour, inputs, outputs, reactions to particular inputs. "The system shall allow a registered user to transfer funds between their own accounts." "The system shall email a receipt after each transaction." "The system shall reject a withdrawal exceeding the available balance." NON-FUNCTIONAL REQUIREMENTS (NFRs) — HOW WELL, and under what constraints. properties and constraints on the system as a whole, rather than on individual functions. "A funds transfer shall complete within 2 seconds for 95% of requests." "The system shall be available 99.9% of each calendar month." "All stored account numbers shall be encrypted at rest." THE CRITICAL ASYMMETRY: a failed functional requirement makes one feature unusable. A failed non-functional requirement can make the WHOLE SYSTEM unusable — a correct system that takes 30 seconds per page is not a working system. WHY NFRs ARE HARDER: · they are EMERGENT — they arise from the whole system, so no single module can be held responsible · they often CONFLICT with each other (from the quality attributes topic: security vs usability, efficiency vs maintainability) · they are frequently stated non-measurably ("the system shall be user friendly"), which makes them untestable · they constrain the ARCHITECTURE, so discovering one late is expensive in exactly the way the cost-of-change curve predicts DOMAIN REQUIREMENTS — the third category, easily forgotten: requirements that come from the APPLICATION DOMAIN rather than from users. They may be functional or non-functional, and their distinguishing feature is that domain experts consider them so obvious they do not mention them. "Deceleration shall be computed as D_train = D_control + D_gradient." (railway signalling) "Interest shall be computed on the daily closing balance." (banking convention) DANGER: because they are unstated, they are the commonest source of "the system is technically correct and professionally useless". The requirements engineer must actively extract them.

The standard three-way split (Sommerville): PRODUCT REQUIREMENTS — constraints on the delivered software performance response time, throughput usability training time, error rates reliability MTBF, availability portability target platforms space memory / storage footprint security confidentiality, integrity ORGANISATIONAL REQUIREMENTS — from the developing or using organisation's policies process "development shall follow the company's XYZ-2019 standard" delivery "the system shall be delivered in three increments" implementation "the system shall be written in Java 21" environmental "the system shall run on the existing Kubernetes cluster" EXTERNAL REQUIREMENTS — from outside both organisations regulatory "the system shall comply with the Nepal Data Protection guidelines" legislative audit-trail retention periods ethical "user location shall not be recorded" interoperability "the system shall exchange data with the national ID service using its published API" safety/security certification requirements MAKING AN NFR TESTABLE — the single most valuable skill here. Every vague NFR has a measurable form: VAGUE MEASURABLE ───────────────────────────────────────────────────────────── "shall be easy to use" "a trained clerk shall complete a booking in under 90 s with fewer than 2 errors" "shall be fast" "p95 response under 500 ms at 200 concurrent users" "shall be reliable" "MTBF ≥ 2000 hours; availability ≥ 99.9% monthly" "shall be maintainable" "a defect in any module shall be localisable within 4 person-hours" "shall be secure" "shall pass OWASP ASVS Level 2; no plaintext credentials at rest" "shall be portable" "shall run unmodified on Linux and Windows; ≤ 5% of code platform-specific" THE TEST FOR A GOOD REQUIREMENT: could two engineers independently decide whether it has been met, and agree? If not, it is a wish, not a requirement. METRICS FOR NFRs, by property: speed transactions/second, response time, ms size MB, number of chips ease of use training time, number of help frames reliability MTBF, probability of unavailability, rate of failure occurrence robustness time to restart after failure, % of events causing failure portability % of target-dependent statements, number of target systems

A STAKEHOLDER SAYS: "We need a fast, secure, easy-to-use system for issuing licences that can handle our busy season." NONE of that is a requirement. Each clause needs interrogation: "FAST" → fast at what? Which operation matters? → FR: "The system shall display an applicant's status given a licence number." → NFR: "The status lookup shall return within 1 second for 99% of requests, measured at the server." (note: "measured at the server" — otherwise the network is in scope and the requirement is untestable) "SECURE" → secure against whom, protecting what? → NFR: "Applicant personal data shall be encrypted at rest using AES-256 and in transit using TLS 1.3 or later." → NFR: "All read access to applicant records shall be logged with the accessing user, timestamp and record id; logs shall be retained 7 years and shall not be editable by application users." "EASY TO USE" → for whom, doing what, measured how? → NFR: "A counter clerk with 2 hours' training shall complete a new-licence entry in under 3 minutes with no more than one validation error." "BUSY SEASON" → what is the actual load, and when? → NFR: "The system shall sustain 500 concurrent users and 50 licence issuances per minute during the July– August renewal period, with response times per the requirement above." → this is the one that DECIDES THE ARCHITECTURE. 500 concurrent users needs connection pooling, caching and probably horizontal scaling. Discovering it after the design is fixed is the expensive case. WHAT THE INTERROGATION PRODUCED: 1 functional requirement 4 non-functional requirements, all testable 1 architectural constraint And note what happened to "fast": the vague word became TWO decisions — which operation, and what percentile. A p50 ("average") target is nearly useless because it says nothing about the users having a bad experience; p95 or p99 is what users actually feel.