Requirements and plans

The requirements register

Requirements with keys, versions and approval by people; baselines; what each requirement leads to; importing from a requirement you reviewed.

The requirements register keeps what your product must do as numbered requirements (REQ-1, REQ-2, ...). It sits next to the requirement pipeline (documents to brief, features and stories), and the two work together. It is a module: an admin of your organisation switches it on (PUT /v1/modules/requirements).

Today the register is used through the Yavaren API (/v1/requirements/..., /v1/trace/... and /v1/search, listed under API); the console's screens for it are not available yet.

A requirement

Each has a type (business, functional, non-functional, security, ...), a title, a statement, acceptance criteria, a priority and an owner. Every save is kept as a version; Restore brings an old version back as a new one. If someone saved after you opened it, your save is refused: reload, then save again.

Approval

1. A member writes the requirement (a draft) and chooses Submit for review.
2. A person who may approve reads it and chooses Approve, Reject or Ask for changes.

For the admins of your organisation.

Who may approve: the people your admin names in the register's settings; when nobody is named, any member or admin.

The approval covers the exact version that was read: if the text changes later, the requirement goes back to review. Only a person signed in approves. An API key, a runner, and Yavaren itself never approve, even a requirement Yavaren drafted.

Baselines

A baseline freezes the current version of a set of requirements ("what we agreed for release 2"). Compare a baseline with today, or two baselines with each other: added, removed and changed requirements.

What a requirement leads to

Link a requirement to work items, pull requests, test runs, releases, deployments and pages. Then ask:

• Impact: everything the requirement leads to, and from a work item or a pull request, which requirements it serves.
• Not implemented yet: requirements no work item implements.
• Not tested: work items that implement a requirement but no test verifies.
• Released and deployed: the releases and deployments the requirement's changes reached.

Anything you may not see (a page of a restricted space) is counted, never named.

From the requirement pipeline

• Import: when the brief and features of a requirement in the pipeline are approved, Import turns its business rules and features into draft requirements, each saying where it came from. Importing again adds nothing twice.
• Draft from a description: describe what is needed and choose a project. Yavaren starts the requirement pipeline with it; review its brief and features as usual, then import them.

Search

One search covers work items, pages and requirements of the parts your organisation uses. Pages of a restricted space you are not on never appear.