Skip to main content
Project Intelligence

Requirements work

Who this is for​

This block is for business, system, and project analysts: requirements collection, verification and agreement, detailing, and analysis.

Project quality starts with requirements quality. The system provides tools so requirements are complete, consistent, and agreed.

Search over stored project context for managers and administrators is in Navigator; control of already approved scope during delivery belongs with PMs and portfolio leads via /scope-check.

Core competencies​

The full requirement cycle — from idea to approval:

  • Elicitation: explicit and implicit needs from meetings, mail, and documents.
  • Structuring and description: specifications, user stories, acceptance criteria.
  • Boundary management: what is in the project and what is not (/scope).
  • Validation and agreement: contradictions and formal sign-off.
  • Analysis and detailing: sharpen wording, acceptance criteria, and open decisions before handoff to the plan.

How to work with requirements​

1. Collection: “Analyze the customer meeting minutes and list explicit and implicit requirements for the reporting module.”

2. Boundaries (Scope): “Define what is out of project scope so we can agree it with the client.”

3. Specification: “Turn these tax-calculation notes into a specification section with user stories and acceptance criteria.”

Skills used​

  • Elicitation (/elicit): meaning from raw inputs.
  • Specification (/specify): formal documents.
  • Scope definition (/scope): the work-boundary statement.
  • Initiation (/initiate): charter and goals — start of requirements governance.
  • Requirements collection (/requirements): BRD skeleton.
  • Decision work (/question): open questions in the BRD and specifications.

Why it matters​

Requirement errors are the most expensive class of defect. Fixing them in analysis is far cheaper than in code. The system highlights gaps and contradictions before implementation starts.