Elicitation and analysis is ITERATIVE, drawn as a spiral — each loop deepens understanding, and you go round until the requirements are agreed. 1. REQUIREMENTS DISCOVERY interacting with stakeholders to collect their requirements; domain and existing-system requirements come in here too. 2. REQUIREMENTS CLASSIFICATION AND ORGANISATION grouping the unstructured collection into coherent clusters — usually around the architectural components or around use cases. 3. REQUIREMENTS PRIORITISATION AND NEGOTIATION stakeholders' requirements WILL conflict. This activity ranks them and resolves the conflicts by discussion, with compromises that all parties can accept. → this is a POLITICAL activity, not a technical one. 4. REQUIREMENTS SPECIFICATION documenting them, formally or informally, and feeding them into the next round of the spiral. WHY IT IS DIFFICULT — the standard list, each with the reason: · STAKEHOLDERS DON'T KNOW WHAT THEY WANT. They know their problem, not the solution. Asked for requirements, they describe their current workaround. · THEY EXPRESS REQUIREMENTS IN THEIR OWN TERMS, with implicit domain knowledge the analyst does not have. · DIFFERENT STAKEHOLDERS HAVE CONFLICTING REQUIREMENTS, and each may express theirs as if it were the only view. · POLITICAL FACTORS may influence requirements — a manager may demand a feature that increases their influence rather than the system's value. This is real and must be handled, not denied. · THE ECONOMIC AND BUSINESS ENVIRONMENT CHANGES DURING ANALYSIS, so the requirements change while you are writing them down. New stakeholders emerge; priorities shift. STAKEHOLDER: anyone who is affected by the system in any way. end-users · managers · system owners · external regulators · domain experts · trade-union representatives · engineers developing or maintaining it · the people whose jobs the system changes MISSING A STAKEHOLDER CLASS is a classic failure. The clerks who must use the system daily are often consulted last and have the most detailed knowledge.

INTERVIEWS CLOSED interviews — a predefined set of questions OPEN interviews — no predefined agenda, explore issues In practice both are mixed. ✔ good for getting an overall understanding and for surfacing opinions ✗ poor for eliciting DOMAIN KNOWLEDGE, because (a) experts use jargon the analyst mishears, and (b) some knowledge is so familiar the expert cannot articulate it — it feels too obvious to say GOOD INTERVIEWERS: are open-minded, avoid preconceived ideas, are willing to listen, and PROMPT with a springboard — a proposal, a prototype, a "walk me through yesterday". → Ask "show me" rather than "tell me". Watching a clerk do the job for ten minutes yields more than an hour of questions. ETHNOGRAPHY / OBSERVATION An analyst immerses in the work environment and observes the actual work. It reveals: · requirements from the way people ACTUALLY work rather than the way the process definition says they work · requirements from COOPERATION and awareness of others' activities — the informal coordination that no process document contains ✔ uniquely effective at finding the workarounds, the exception-handling and the social protocols that are the real system ✗ expensive, slow, and it discovers only EXISTING practice — it cannot tell you what a new process should be → best COMBINED with prototyping: observe, prototype, observe the prototype in use. SCENARIOS A concrete story of one interaction. People find it much easier to relate to a concrete example than to an abstract statement. A scenario includes: · a description of the state at the start · the normal flow of events · what can go wrong, and how it is handled · other concurrent activities · the state on completion USE CASES A scenario-based technique in UML, identifying the ACTORS in an interaction and describing the interaction itself. A set of use cases describes all possible interactions; sequence diagrams add detail by showing the sequence of processing. ✔ good for identifying system boundaries and functional scope ✗ weak at non-functional requirements — a use case diagram cannot express "within 2 seconds" OTHER TECHNIQUES worth naming: QUESTIONNAIRES cheap at scale, poor at depth, and only answer questions you already thought to ask DOCUMENT ANALYSIS forms, regulations, existing reports — a rich and much-neglected source; every field on an existing paper form is a requirement somebody once needed PROTOTYPING the single most effective way to turn "I don't know what I want" into "not that — THIS" WORKSHOPS / JAD all stakeholders in one room, which forces conflicts into the open early rather than at acceptance BRAINSTORMING for novel systems with no precedent

USE CASE Issue a licence ACTORS Licence Officer (primary), Applicant (secondary), National ID Service (secondary system), Payment Gateway (secondary system) PRECONDITION application status = APPROVED; fee unpaid GOAL a printed licence exists and is recorded as ISSUED MAIN FLOW (the normal case) 1. Officer searches by application number. 2. System displays the approved application. 3. Officer confirms the applicant's identity against the National ID Service. 4. Officer records the fee payment. 5. System generates a licence number and prints the licence. 6. System sets status to ISSUED and logs the officer. 7. System sends an SMS to the applicant. EXTENSIONS — the flows that carry the real requirements 3a. ID service unreachable → officer may proceed with a manual identity check, recording the reason. (System must not BLOCK on an external dependency — a genuine availability requirement discovered from an extension.) 3b. ID service returns a name mismatch → status returns to UNDER_REVIEW with the mismatch recorded; no licence is issued. 4a. Payment gateway times out after the applicant was charged → system must reconcile: the payment reference is queried on the next run and the fee marked paid without double-charging. (An IDEMPOTENCY requirement.) 5a. Printer fails mid-print → licence number is already allocated; system must allow REPRINT of the same number, never allocate a second. (A requirement nobody states in an interview, and which causes a serious audit problem if missed.) 7a. SMS provider rejects the number → licence is still ISSUED. Notification failure must not roll back the business transaction. COUNT THE REQUIREMENTS: main flow 7 extensions 6, and every one of them is a rule the officer knows tacitly and would not have volunteered This is why the exception flows are where the value is. Interviews produce the main flow easily; the extensions come from OBSERVATION ("what do you do when the ID site is down?" → "oh, we ring them and write it in the book") and from DOCUMENT ANALYSIS of the paper register.