# The basic vocabulary (terms and relationships)

Here are the words you meet in PM on Rails, explained in the order they connect. No technical knowledge needed.

![PM on Rails requirement card list. Who wants what, background, acceptance conditions and priority on each card. Before: wishes and decisions were mixed. After: you ask only about what is still open, then set scope.](https://pmonrails.com/docs-img/demands.png)

## The overall flow

> meeting notes and documents → requirement card → requirement → user story → scenario / task

It starts from "the requester's words" and gradually becomes concrete enough to build.

## One at a time

| Word | In plain terms |
| --- | --- |
| Project | One engagement. Requests and tasks live inside it |
| Meeting notes and documents (knowledge) | Records of meetings and the documents you were given. The starting point for everything |
| Requirement card (Demand) | A stakeholder request: "as a [who], I want to [what]" |
| Requirement (Requirement) | A non-functional requirement or constraint. Functional specs go in the user story overview |
| User story (User Story) | The unit of development: "an actor can do X". The overview holds the stakeholder-facing functional spec |
| Scenario (Scenario) | The steps for confirming completion: "in this situation, if you do this, this happens" |
| Task (Task) | The actual work. It hangs under a story (a defect, i.e. a bug, is a task too) |
| Board | The board where tasks move through "to do / in progress / review / done" |
| Traceability | Being able to follow the "connections" from request to implementation |
| Graph | Holding information as "points and lines" rather than as tables ([How the AI works](https://pmonrails.com/en/docs/graphrag.md)) |
| AI extraction and structuring | AI raising requests and stories from meeting notes automatically |

## Requests and requirements are different things

- **A request** = a stakeholder's (a client, the business side, a teammate — whoever asks) "this is what we want". Agreement goes this far and no further.
- **A requirement** = the engineer's technical proposal of "then here is how we build it".

Managing them separately keeps "why we are building it" from getting mixed up with "how we build it".

## How this maps to the screens

Each screen in the left-hand menu corresponds to a stage in this flow (Documents and notes / Requirement cards / Confirm scope / Stories and scenarios / Kanban / Testing and feedback, and so on).

---

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