Requirement register

The requirement record is the reference point for a piece of requested work. A Business Analyst gives it a name, description, project and owner, then records its revision and delivery dates. Its status shows whether work has not started, is in progress, is blocked or is done. The record also holds the accepted date and baseline revision, so the team can compare current work with the version discussed at review.

• Project link. Every requirement belongs to a project; the project gives the team a shared scope and schedule.
• Ownership. A named team member is responsible for keeping the requirement and its revision current.
• Child work. Requirement items carry the smaller assigned tasks, estimates and completion details beneath the requirement.

A requirement can be revised while its delivery work proceeds. The team should keep the revision meaningful: a changed acceptance expectation merits a new revision, while a minor wording fix may follow a lighter local rule. The record can carry an organization as well as a project, but the project link is the required anchor. The item count and hour totals help the owner find requirements with work still open.

Agree who creates requirement records, how codes are assigned, and when an owner may change a revision. Set a common meaning for not started, in progress, blocked and done. In particular, a blocked requirement needs a human explanation in its description or linked work so the next reviewer knows what decision is needed. Agree whether the accepted date is set when the baseline is accepted or when delivery verification finishes; use that rule consistently.

The Business Analyst and Project Manager should also agree how long a requirement description needs to be. It should explain the requested outcome and acceptance context clearly enough that the assigned team can break the work down. A project name alone cannot serve as the requirement. Before importing existing work, map the old project and owner names to current records so the references point to the intended people and projects.

Choose a requirement whose acceptance detail has changed. Open its record, confirm the current revision and owner, and inspect its child items. Check the project and organization before comparing the baseline revision. Move the requirement into progress only when someone is actually carrying the work. If it becomes blocked, the Project Manager should be able to see it in the in-progress list and find the linked item or finding that explains why.

• Requirements In Progress — Requirements in progress or blocked, with owner, revision and remaining hours.
• My Requirements — The current owner’s requirements with dates and project context.

Follow project and requirement setup before item delivery. The baseline review process connects revisions to acceptance.