Eliciting
Uncovering the requirement behind the request
Stakeholders asked for “a better dashboard”. Structured elicitation — a focused workshop and a few well-chosen interviews — revealed the real need was a weekly exception report, not a dashboard at all. The request and the requirement were two different things.
Requirements engineering in action
Asking “why” with the right techniques, instead of building what was first asked for, saved months of work on the wrong thing.
Documenting
Writing requirements developers can actually build
Requirements were vague one-liners open to interpretation, and every sprint surfaced disagreements about what was meant. Rewriting them as clear, testable statements with acceptance criteria ended the guesswork.
Requirements engineering in action
User stories with proper acceptance criteria cut the clarification back-and-forth dramatically — and the rework that came with it.
Managing Change
Keeping control as requirements evolve
Halfway through delivery, scope kept creeping and no one was sure which version of the requirements had actually been agreed. A simple change-control and traceability approach restored order without slowing the team down.
Requirements engineering in action
Traceability meant every change could be traced to its source and its impact — so decisions about scope were deliberate, not accidental.
