The requirements activities of ACtE0801 — elicitation, analysis, specification, validation and management — do not change in an object-oriented project. WHAT CHANGES is the form the output takes and the rhythm in which it is produced. THE OO EMPHASIS: · requirements are captured largely as USE CASES, which describe interactions rather than function lists · the domain vocabulary is captured as a CONCEPTUAL MODEL (a class diagram of domain concepts) alongside the use cases · requirements work is ITERATIVE and INCREMENTAL — a portion is elaborated and built, then the next · the same artefacts carry through to design, so there is no translation step: a use case becomes a set of interactions, and a conceptual class becomes a design class THE UNIFIED PROCESS phases, since this syllabus's OO material follows that tradition: INCEPTION establish the business case and scope; identify the critical use cases (perhaps 10% elaborated); decide whether to proceed ELABORATION elaborate most use cases; build a baseline ARCHITECTURE and prove it with an executable skeleton; identify and mitigate the highest risks CONSTRUCTION build the remaining functionality incrementally TRANSITION deploy to users; beta testing; training; correction THE CRITICAL POINT ABOUT ELABORATION: its purpose is NOT to finish the requirements. It is to resolve the RISKS and prove the ARCHITECTURE, by building something that runs. The Unified Process is described as USE-CASE DRIVEN, ARCHITECTURE-CENTRIC, ITERATIVE AND INCREMENTAL — and "architecture-centric" means the architecture is validated by execution early, not designed on paper and hoped for. WHY ELABORATE ONLY 10% AT INCEPTION? Because detailed requirements for features that will be cut, deferred or reconceived are waste. From the requirements management topic: requirements are volatile, and the volatile ones should not be detailed early.

A worked set for the licence system, showing how each artefact feeds the next. This chain is the answer to "what does the OO requirements process actually produce?" 1. VISION / BUSINESS CASE "Reduce licence issuance time from 11 days to 2, and eliminate the paper register." One paragraph. It is what every later decision is checked against, and a project without it cannot resolve priority arguments. 2. GLOSSARY Applicant, Application, Licence, Fee, District, Officer, Endorsement, Renewal Window… WRITTEN FIRST, and continuously. Recall from the SRS topic that defining a term forces the expert to state the convention hidden inside it. "Renewal Window" turned out to mean 90 days before expiry to 30 days after — which nobody had said, and which changes the validation rules. 3. USE CASE MODEL — the actors and their goals Actors: Applicant, Counter Officer, Reviewing Officer, Cashier, National ID Service, Payment Gateway Use cases: Submit Application · Verify Identity · Review Application · Pay Fee · Issue Licence · Renew Licence · Reverse Issuance · Report Revenue Each use case gets a brief description now, and a full flow when it is about to be built. 4. SUPPLEMENTARY SPECIFICATION — everything a use case cannot express, which is chiefly the NON-FUNCTIONAL requirements from ACtE0801: p95 under 2 s · 99.9% availability · AES-256 at rest · audit retention 7 years · 500 concurrent users in July THIS DOCUMENT IS FREQUENTLY FORGOTTEN, and it is where the architecturally significant requirements live. A use-case model alone cannot express "within 2 seconds", so a project that captures only use cases has no input for architectural design. 5. CONCEPTUAL / DOMAIN MODEL The noun structure: Applicant 1—* Application, Application 1—1 Licence (once issued), Application *—1 District, Application 1—* StatusChange… Derived from the glossary and the use cases, and validated with the domain expert. 6. PRIORITISED USE CASE LIST driving the iterations: iteration 1 Submit Application, Pay Fee — the core revenue path, and it exercises the payment gateway integration, which is the biggest technical risk iteration 2 Review, Issue Licence iteration 3 Verify Identity (external dependency), Renew iteration 4 Report Revenue, Reverse Issuance NOTE THE ORDERING PRINCIPLE: iteration 1 was chosen because it carries the HIGHEST RISK, not because it is the easiest or the most obviously valuable. Building the risky integration first means discovering in week 3 rather than month 5 that the payment gateway cannot do what was assumed. RISK-DRIVEN ITERATION ORDERING is the single most valuable planning idea in this topic. HOW MUCH DETAIL PER ITERATION — the practical rule: the use cases for the NEXT iteration are fully detailed (main flow, all extensions, acceptance criteria) the ones after that have a brief description the rest are one line on the list This is progressive elaboration, and it directly implements the "don't detail volatile requirements early" conclusion.

WHY RISK-DRIVEN ORDERING PAYS — with numbers, because the argument is usually made by assertion. THE SITUATION: a 6-month project, four iterations. One requirement — "the payment gateway can refund a partial amount" — is ASSUMED but unverified. It is false: the gateway supports full refunds only. DISCOVERED IN ITERATION 1 (month 1): redesign the refund flow to issue a full refund plus a new charge 16 h renegotiate the requirement with the business 6 h revise 3 use cases and the domain model 8 h ──────────────────────────────────────────────────── 30 person-hours, and no built code is discarded DISCOVERED IN ITERATION 4 (month 5): the same redesign 16 h the same renegotiation 6 h revise the use cases and domain model 8 h PLUS rework of code built on the false assumption: refund handling appears in the payment module, the reporting module, the audit trail and the reconciliation job 64 h PLUS re-testing all four 28 h PLUS the schedule impact — this lands in the final month, so it either delays release or displaces planned work (a business cost) ──────────────────────────────────────────────────── 122 person-hours, plus schedule damage A 4× DIFFERENCE IN EFFORT for the identical discovery, and the late case additionally arrives at the worst possible moment. THE VALUE OF EARLY DISCOVERY IS NOT THAT THE PROBLEM IS SMALLER — it is identical — BUT THAT LESS HAS BEEN BUILT ON TOP OF IT. THIS IS THE COST-OF-CHANGE CURVE AGAIN, and it is why iterations are ordered by risk. The purpose of iteration 1 is not to deliver the most value; it is to convert the largest assumption into a fact. A PRACTICAL RISK LIST for requirements, worth building explicitly: · an EXTERNAL INTERFACE whose behaviour is assumed but not tested — the highest-frequency killer · a NON-FUNCTIONAL requirement never measured (can we actually serve 500 concurrent users?) · a DOMAIN RULE taken from one person's account, unverified against the regulation · a STAKEHOLDER who has not yet been consulted · a TECHNOLOGY nobody on the team has used For each: what is the cheapest experiment that would settle it? Frequently a spike of a day or two, which is a remarkable return against 122 hours. VALIDATION IN AN ITERATIVE SETTING — the mechanism that makes it work: Each iteration ends with a DEMONSTRATION of running software to the stakeholders. That is the validation technique from ACtE0801 — prototyping — institutionalised as the process rhythm. Recall the finding there: a misunderstanding that survives three document reviews dies in thirty seconds of use. An iterative process gets that thirty seconds every few weeks instead of once at acceptance testing.