Unit 3 — Requirements Engineering

Learning objectives

• Distinguish functional requirements, quality requirements, constraints, and domain rules.
• Write testable user stories and acceptance criteria.
• Recognize ambiguity, incompleteness, inconsistency, and unverifiable language.

From needs to verifiable statements

A requirement should help a team make design and validation decisions. Statements such as "the system shall be user-friendly" are difficult to verify unless the expected quality is made measurable or operationally observable.

User story template

As a role, I want capability, so that benefit.

The story is a conversation placeholder, not a complete specification. Acceptance criteria define important examples and boundaries.

Example acceptance criteria

Scenario: Reject an expired reset token
  Given a password-reset token older than 30 minutes
  When the user submits the token
  Then the reset request is rejected
  And no password is changed

Traceability

A lightweight trace may connect:

stakeholder need → issue/story → design decision → code change → test → release

This is especially useful when systems evolve and teams need to know why behavior exists.

Requirements smells

Watch for vague terms ("fast", "simple", "robust"), optional phrases ("if possible"), compound requirements, passive voice with missing actor, and unverifiable absolutes.