Requirements

A requirement records what the code must do and why. Links connect that statement to its implementation, tests, supporting knowledge and system parts.

Write a requirement

1. Open Requirements and choose the repository scope, or keep the workspace view.
2. Choose Add requirement. Write one observable outcome under What the code is held to, and explain Why it exists.
3. Choose its kind: Requirement, Acceptance criteria or Constraint. Set its priority and status: draft, open, agreed, met or obsolete.
4. Record how it is shown true: a test, inspection, demonstration or analysis. Add a person or team responsible for it and a source reference when available.
5. Use Add a file for supporting material, then choose Add requirement to save.

Priorities are Must have, Should have, Could have and Won't have, this time. Open an existing requirement to inspect its details or edit it.

Improve the wording

Under Sharpen it, choose Make it testable, Give it a reason, Split it up or Cut the hedging, or write your own request. A suggestion appears beside your draft. Choose Use this to apply it, then save the requirement.

Organise work into groups

Use Add a group to create a project, feature, task or release. Groups can contain other groups. In the requirement editor, What it is part of lets you file a requirement under more than one group and shows each group's full path.

Select a group to see requirements filed there and in its nested groups. Use the unfiled view to find requirements that do not belong to a group. Filing a requirement in another group does not move it out of its existing groups.

Link implementation and evidence

In a requirement's detail view, add links to code that implements it, tests that verify it, another requirement, written knowledge, a system or a file already kept. Supply the relevant path or identifier, or choose a system or requirement, then select Link it.

The list offers Not implemented, Not verified, Verified and All views. These are calculated from recorded links:

• No code links: nothing implements it.
• Code links without test links: not verified.
• Both code and test links: implemented and verified.

Here, coverage counts links. It does not run the tests or judge whether the linked code satisfies the requirement. The status you set and the verification method you choose are separate from these counts.

Read repository issues

Select a repository to reveal Read issues. By default, the importer reads issues labelled requirement or acceptance-criteria. Open issues become open requirements; closed issues become met requirements. Source references point back to the issue. Importing does not write changes back to GitHub.

The open core also exposes requirements, links, coverage and groups through HTTP and MCP. See Local setup to connect a coding tool, and Requirements engineering for the distinction between these features and planned capabilities.