# Create requirement cards

A requirement card is the smallest unit of a stakeholder request, organised in the form "as a [who], I want to [what]".

![PM on Rails requirement card. One request with background, acceptance conditions and priority. Before: the requester's words and the spec were mixed. After: why you are building it stays on the card.](https://pmonrails.com/docs-img/demands.png)

## Automatic generation and digging deeper

- **Automatic extraction** — extract requirement cards from the meeting notes and documents in knowledge. Long text is split automatically and processed in parallel.
- **5 Whys analysis** — dig down to the root cause through five levels of "why?" (AI generated, editable).
- **Latent needs** — surface 2 to 5 hidden needs that were never stated explicitly, each with a confidence level.
- **Estimated value (Value Axis)** — automatically attach 1 to 3 of the seven axes: "time saved / accuracy / safety / simplicity / cost reduction / visibility / automation". This is the unit in which you agree value with the stakeholder.
- **A history of source citations** — record "which meeting notes it was drawn from" on every create and update.

## Scoring and priority

Requirement cards are scored on several axes. **People can edit only three of them**; the values the AI observed are display-only (not editable). You edit them in the requirement card detail panel by selecting the axis label.

| Axis | Kind | Editing |
| --- | --- | --- |
| Importance | Human judgement | Editable |
| User acceptance | Human judgement | Editable |
| Effort | Human judgement | Editable |
| Impact, request frequency | Value observed by AI | Display only |
| Confidence | The AI's internal self-assessment | Hidden |

- **Automatic overall score** — value, effort and acceptance are weighted into a single overall score, which serves as a guide for prioritising.
- **Automatic priority** — "required / high / medium / low / deferred" is assigned automatically from the score.

> **The design allows the AI's priority and a person's priority to diverge.** A card where they diverge surfaces as "a card where AI and people judge it differently — one worth discussing".

## Duplicate detection and bulk processing

- **Duplicate candidates** — new cards are compared with existing ones by vector search to decide "create new / update existing / no change". Multiple candidates are presented newest-first.
- **Update impact** — when you update a requirement card, the stories and scenarios that move with it are shown, along with "which fields will change".
- **Bulk processing of meeting notes** — extract from multiple segments at once → (diff check) → choose new/update/skip and apply in bulk.
- **Past bugs as a reference too** — during the diff check you are also shown what defects occurred in the past for similar requests, so you notice where problems tend to recur.

## Connecting to requirements and stories

Organised requests expand into technical "requirements" (how to build it) and into [user stories](https://pmonrails.com/en/docs/stories.md).

> A requirement is not "an agreement with the stakeholder" but **an engineer's technical proposal**. Responsibility is split on the idea that what you agree with the stakeholder stops at the requirement card.

## Next step

- [Decide the scope](https://pmonrails.com/en/docs/scope.md)

---

https://pmonrails.com/en/docs/demands