REQUIREMENTS VALIDATION is concerned with demonstrating that the requirements define the system that the CUSTOMER REALLY WANTS. VERIFICATION vs VALIDATION, applied to requirements: verification — are we writing the document right? validation — are we writing the right document? WHY IT MATTERS SO MUCH: requirements-error costs are HIGH. Fixing a requirements error after delivery may cost up to 100 TIMES the cost of fixing an implementation error — because it invalidates design, code and tests, and possibly the architecture. THE FIVE CHECKS TO PERFORM ON EVERY REQUIREMENT: VALIDITY CHECKS does the system provide the functions that BEST support the customer's needs? (Different stakeholders' needs may combine into a function nobody individually asked for.) CONSISTENCY CHECKS are there conflicts? COMPLETENESS CHECKS are all functions required by the customer included? REALISM CHECKS can the requirements be implemented given the available budget, technology and schedule? VERIFIABILITY can each requirement be tested? Write the test now, on paper, to find out. THE TECHNIQUES: REQUIREMENTS REVIEWS Systematic manual analysis by a team including both customer and developer representatives. Formal or informal. Good communication between all parties resolves problems at an early stage. A review CHECKLIST asks of each requirement: VERIFIABILITY is it realistically testable? COMPREHENSIBILITY is it properly understood? TRACEABILITY is the origin clearly stated? ADAPTABILITY can it be changed without large-scale effects on other requirements? PROTOTYPING An executable model is demonstrated to end-users and customers. The most effective validation technique there is, because users respond to what they can touch, and a misunderstanding that survives three document reviews dies in thirty seconds of use. TEST-CASE GENERATION Requirements should be testable. Developing tests DURING validation frequently reveals requirements problems — if a test is hard to design, the requirement is usually incomplete or ambiguous. This is the cheapest high-yield technique on the list. AUTOMATED CONSISTENCY ANALYSIS For requirements expressed in a structured or formal notation, a tool can check structural and internal consistency. Limited to what the notation captures. REQUIREMENTS SHOULD NEVER BE ASSUMED VALIDATED. It is difficult to demonstrate that a set of requirements meets a user's needs, because users must imagine the system in operation. Validation is a matter of raising confidence, not achieving proof.

REQUIREMENTS MANAGEMENT is the process of managing changing requirements during the requirements engineering process and system development. Requirements are INEVITABLY INCOMPLETE AND INCONSISTENT: · new requirements emerge as the system is developed and the business context changes · different stakeholders have different and possibly contradictory priorities · the people paying for the system and the users are rarely the same people · the business environment changes, changing the priorities ENDURING vs VOLATILE REQUIREMENTS — the key planning distinction: ENDURING stable, derived from the core activity of the organisation. A hospital will always have patients, doctors and records. These relate to the domain and change slowly. VOLATILE change during development or in use. Government health-policy requirements, tax rules, reporting formats. → design so that VOLATILE requirements are isolated in few modules. That is what "design for change" concretely means, and it is why this distinction is a design input, not just a planning note. CLASSES OF VOLATILE REQUIREMENT: MUTABLE change because of the system's environment EMERGENT emerge as understanding of the system develops CONSEQUENTIAL result from the introduction of the system itself — the system changes how people work, which creates new requirements COMPATIBILITY depend on other equipment or processes THE CHANGE MANAGEMENT PROCESS — three stages: 1. PROBLEM ANALYSIS AND CHANGE SPECIFICATION The problem or change proposal is analysed to check it is valid. The result is fed back, and may be withdrawn. 2. CHANGE ANALYSIS AND COSTING The effect is assessed using TRACEABILITY INFORMATION and general knowledge of the requirements. Cost is estimated in terms of modifications to the requirements document, the system design and the implementation. Once done, a decision is made whether to proceed. 3. CHANGE IMPLEMENTATION The requirements document, and where necessary the design and implementation, are modified. The document should be organised so changes can be made WITHOUT extensive rewriting — which means minimal cross-referencing, and modular structure. THE RULE THAT MAKES IT WORK: changes must be applied to the DOCUMENT FIRST, then the code. If urgent changes are made directly to the system, the document and the system diverge — and the document becomes worthless, at which point nobody maintains it, and the project has lost its only record of why the system is the way it is. TRACEABILITY — what makes change analysis possible at all: SOURCE traceability requirement → the stakeholder who proposed it, so you can ask them REQUIREMENTS trace. requirement → dependent requirements DESIGN traceability requirement → the design/code modules implementing it Held in a TRACEABILITY MATRIX. Without it, "how much would this change cost?" has no answerable form, and every estimate is a guess.

CHANGE REQUEST CR-114 "Licence fees shall vary by district, not be a single national rate." STAGE 1 — PROBLEM ANALYSIS Valid: arises from a genuine policy amendment. Source: Ministry circular 2026/07. Not withdrawable. STAGE 2 — CHANGE ANALYSIS USING TRACEABILITY Traceability matrix query: what touches requirement R-042 ("fee shall be NPR 2,500")? requirements R-042 fee amount → EDIT R-043 fee display on receipt → EDIT (must now show which district rate applied) R-088 refund calculation → EDIT R-091 annual revenue report → EDIT (must now break down by district) design FeeCalculator, ReceiptRenderer, RefundService, RevenueReport → 4 modules database new district_fee table; existing rows need a district assigned — a MIGRATION, and the historical rows must keep the OLD rate or every past receipt reprints wrongly tests 17 test cases reference the constant 2500 interfaces the payment gateway request carries the amount — no interface change documents SRS §4.6, §6.3, §9.2 ESTIMATE requirements edits 6 person-hours design + implementation 40 person-hours data migration + backfill 16 person-hours test updates 20 person-hours regression + UAT 24 person-hours ─────────────── 106 person-hours ≈ 13 person-days THE FINDING THAT JUSTIFIES THE WHOLE EXERCISE: the historical- rate problem in the migration. Nobody proposing this change thought about reprinting old receipts, and without the traceability matrix it would have been discovered in production, by an auditor. STAGE 3 — DECISION AND IMPLEMENTATION Approved. SRS amended first (new version 2.4, with the change rationale recorded in the preface), then design, then code, then tests. R-042 is reclassified VOLATILE, and FeeCalculator is refactored so future rate changes are configuration rather than code — because a requirement that changed once will change again.