Business Analysis and Requirements Definition
Core concepts
Business analysis is the discipline of identifying business needs and recommending solutions that deliver value. Candidates must know the difference between a business need (a problem or opportunity), a requirement (a condition or capability a solution must meet), and a design (a specific way to satisfy a requirement). Understand requirement levels: business, stakeholder, solution, and transition requirements. Know elicitation techniques (interviews, workshops, observation, document analysis, surveys, prototyping) and when each fits. Know the characteristics of good requirements: unambiguous, testable, traceable, feasible, and necessary. Understand requirement prioritization (MoSCoW, value vs. effort) and traceability matrices that link needs to requirements to test cases.
Traps
Questions often present a vague statement such as "the system should be fast" and ask you to classify it. That is not a testable requirement; a correct answer usually calls for a measurable criterion. Another trap confuses a requirement with a solution: "users need a dropdown menu" is a design decision, not a need. Watch for answer choices that skip elicitation and jump to building. Also beware of "gold plating" (adding unrequested features) and of scope creep disguised as a minor clarification.
Worked rule of thumb
When classifying any statement, ask three questions in order: Whose need is it? (level), Is it verifiable? (quality), and Does it prescribe how? (requirement vs. design). If a statement prescribes a specific technology, it is likely a design constraint, not a pure need. If it cannot be tested, rewrite it before accepting it.
Example: "The checkout page must load within 2 seconds for 95% of sessions" is a measurable, testable non-functional requirement; "the checkout should feel snappy" is not.