Analysis: Elicitation, Modeling, and Requirements Quality
Eliciting, modeling, and verifying
Analysis converts raw elicitation into a validated, prioritized, testable requirement set. Know the techniques and when each fits: interviews (depth), workshops (consensus and conflict resolution), focus groups (opinions), observation and job shadowing (tacit work), surveys (breadth), document and interface analysis, prototyping (unclear interface), brainstorming, and reverse engineering.
Analysis concepts: process models, use cases and user stories, data models, state diagrams, decision tables and trees, business rules, glossary, decomposition, assumptions, constraints, and dependencies. Classify requirements as functional, non-functional (quality attributes such as performance, availability, usability, security), and transition. Prioritization options include MoSCoW, weighted ranking, and Kano.
Verification versus validation is the most tested distinction: verification asks whether the requirement statement is well formed - unambiguous, complete, consistent, atomic, feasible, testable, traceable; validation asks whether it faithfully represents the stakeholder's real need. Acceptance criteria belong to the requirement, not to the tester alone.
Traps. Accepting vague quality attributes ("user-friendly", "fast"). Omitting exception and negative paths. Letting a design decision slip into the baseline. Prioritizing by the loudest stakeholder rather than by value and risk.
Rule of thumb: rewrite every requirement into testable form before approval - "given a locked account, when the customer submits a valid password, then the system shows the lock message and does not authenticate."
Worked example: "The report must be easy to use" fails every quality test. Rewritten: "Given a user with reporting rights, when they request the monthly summary, then the report renders in under five seconds for twelve months of data."