The Requirements Lifecycle
A requirement in Vanillaround follows a defined path from initial idea to approved, development-ready item. Understanding this lifecycle helps every role know where they are in the process and what the next step is.
The stages
Section titled “The stages”1. Idea → Spec page
Section titled “1. Idea → Spec page”Every requirement starts as a conversation — a feature request, a user story, a business rule. In Vanillaround, that conversation gets written down as a Spec page.
A spec page is a rich-text document. At this stage it might be rough: an outline, a description of the problem, some open questions. The Provider typically drafts this; the Client reviews it.
2. Spec page → Requirement cards
Section titled “2. Spec page → Requirement cards”Once a spec page has enough shape, the Provider embeds requirement cards directly into the document. Each card represents one discrete, approvable item: a specific feature, a behaviour, a constraint.
Cards give structure to prose. Instead of a paragraph that says “the user should be able to do X, Y, and Z”, you get three separate cards that can each be assigned, tracked, and approved independently.
3. Cards → Assigned and in draft
Section titled “3. Cards → Assigned and in draft”When a card is created it starts in Draft state. The Provider fills in the details: type, description, assigned members, priority, due date. At this point the requirement exists but has not yet been submitted for Client review.
4. Draft → Submitted for approval
Section titled “4. Draft → Submitted for approval”The Provider submits the card for Client approval. The assigned Client members receive a notification and can see the card is awaiting their decision.
5. Submitted → Approved or Rejected
Section titled “5. Submitted → Approved or Rejected”The Client reviews the requirement in context — the card lives inside the spec page, so all surrounding context is visible. They either:
- Approve — the requirement is confirmed, development can proceed
- Reject — the requirement needs changes; it returns to Draft with feedback
6. Approved → Synced to Jira
Section titled “6. Approved → Synced to Jira”Once approved, the requirement card can be pushed to Jira as an issue. The Jira issue link appears on the card, creating a two-way connection between the requirements document and the development backlog.
7. Jira → Boards → Done
Section titled “7. Jira → Boards → Done”The Provider picks up the Jira issue and begins development. Progress can be tracked back in Vanillaround via Boards, where cards move through columns as work progresses.
Why this matters
Section titled “Why this matters”The lifecycle creates a chain of accountability. Every approved requirement has:
- A written spec with context and rationale
- A named card with assigned owners
- A formal approval from the Client
- A linked Jira issue for development tracking
If a question arises mid-development about what was agreed, the answer is in Vanillaround — in writing, with a timestamp and a name.