Requirements Engineering
Eliciting, Analysing, and Documenting Requirements
Requirements engineering is the systematic process of eliciting, analysing, documenting, and validating requirements. Candidates must distinguish between functional requirements (what the system must do) and non-functional requirements (how well it must do it, e.g., performance, security, usability). A common trap is misclassifying a requirement; for example, "the system must respond within 2 seconds" is non-functional.
Requirements can be captured in various forms: user stories, use cases, business rules, and functional specifications. The requirements catalogue or requirements traceability matrix helps manage them. MoSCoW prioritisation (Must have, Should have, Could have, Won't have) is a common technique. A trap is treating "Won't have" as "will not be done now" rather than "not in this release".
Elicitation techniques include interviews, workshops, observation, questionnaires, and document analysis. Each has strengths and weaknesses; for example, workshops are good for resolving conflicts, while observation is good for understanding actual work practices. A trap is assuming one technique is always best; the choice depends on context.
Requirements analysis involves checking for ambiguity, inconsistency, and completeness. Requirements validation ensures the requirements are correct, feasible, and testable. A common trap is confusing validation (are we building the right thing?) with verification (are we building it right?).
Requirements documentation may follow standards like IEEE 830 or use agile formats. The exam may test the characteristics of a good requirement: unambiguous, testable, traceable, and necessary.
Worked example / rule of thumb: When writing a requirement, use the rule: If you can't test it, it's not a requirement. For prioritisation, remember MoSCoW: Must have is non-negotiable; Should have is important but not critical; Could have is desirable; Won't have is explicitly out of scope for now.