Requirements API

A requirement is one sentence the client and the team agree the system must honour: a functional requirement says what it does for a person (CRM-FR-12), a non-functional one says a quality it keeps while it does it (CRM-NFR-3), with the category the quality belongs to and a measure with the metric and the target. Each kind numbers on its own sequence, so the kind is fixed the moment a requirement is numbered. The record carries the statement and the rationale, where the requirement came from (a stakeholder of the project, or words), its MoSCoW priority, how it will be shown to be met, who answers for it and where it stands, from draft through review to approved, baselined or deprecated.

Every save of a requirement writes a version. The versions are read and put back through the endpoints below, under the requirement's own abilities.

The reads here see the requirements of the projects the token may see; a client guest's token sees the approved and baselined ones only, because a draft is the analyst's working note until the client signs it off. A requirement outside that set is a 404 RESOURCE_NOT_FOUND, never a 403. Every write runs the same action the Requirements page runs, under the project permissions, and announces itself as a requirement.* event.

EndpointsCopy Anchor Link

Related

Stakeholders APIThe people a requirement can be sourced from.Epics APIAnd [work items](/api/v1/reference/work-items): the scope and the stories that will implement the requirements once links land.Activity APIWho changed a requirement and when, beside the versions themselves.requirement.* eventsThe lifecycle of a project's requirements: a functional or non-functional requirement added, changed, moved along its review lifecycle, put back to an earlier version and deleted.