Requirements Analysis and Design Definition
Scope
This domain turns elicited information into structured, verified requirements and defined designs. It includes specify and model requirements, verify requirements, validate requirements, define requirements architecture, define design options, and analyze potential value and recommend a solution.
Concepts to grasp
Specification means expressing requirements clearly in text and models - process flows, data models, state diagrams, use cases - chosen to suit the audience. Verification asks whether the requirements are well formed: complete, consistent, unambiguous, testable. Validation asks a different question: do they deliver the value the stakeholders need? Requirements architecture organizes requirements into a coherent whole and checks relationships and conflicts. Design options are alternative ways to satisfy the requirements, evaluated for value, cost, and risk, then recommended. Know the distinction between requirements (what is needed) and design (how it will be met).
Traps
The classic trap is confusing verification with validation. Another is presenting a single design as inevitable, skipping option analysis. A third is choosing models for the analyst's comfort rather than the reader's needs. Also watch for requirements that are untestable ("the system shall be user-friendly") and for architecture that duplicates or contradicts requirements.
Rule of thumb
Verification: did we write the requirement right? Validation: did we write the right requirement?
Worked example
"Reports must load quickly" fails verification - no measure. Rewrite: "A standard monthly report shall display within five seconds for 95% of requests at peak load." Then validate: does fast reporting actually serve the manager's decision need, or is the real need a scheduled alert? Confirm before designing.