Requirements and plans

Requirements: from documents to pull requests

Turn documents or a tracker item into a brief, features, stories and draft pull requests, with your approval at each step.

A requirement takes documents you upload, an item in your tracker, or both, to draft pull requests. A person in your team decides at three points: the business brief, the features and the stories.

The steps

1. Intake. Upload the documents (PDF, Word, text, images) or point to the tracker item.
2. Brief. Yavaren drafts a business brief with a diagram. Review it, edit it, approve it or ask for changes.
3. Features. Yavaren drafts features from the approved brief. Approve all, some, or ask for changes.
4. Stories. Each approved feature is broken into stories. Approve them one by one.
5. Delivery. Every approved story becomes a draft pull request, as in Reviewing draft pull requests.

Every edit you make is kept as a new version, so you can see what changed. If a step fails, the requirement waits until a person retries it.

Questions before each step

Before the brief, the features, the stories and the build, Yavaren checks whether it has what it needs. If not, it asks a few questions, each with why it matters and the assumption it would otherwise make, and the requirement waits with the status Questions. Answer them on the requirement, or reply to the comment on your tracker item with one line per answer (Q1: …). If you would rather not answer, choose Proceed with assumptions. Every answer and assumption is listed in the brief under Decisions and assumptions and used in every later step. An admin can turn questions off for a project, or change how many are asked, under Projects → Delivery preferences.

Who approves

By default the person who created the requirement, or an admin, decides. An admin can name approvers for a requirement under Approvers: then any one of them, and only they, approves the brief, the features, the stories, the set-up pull request and deployments, and answers questions. Each decision records who made it.

Asking for changes

When you ask for changes, add a comment to the whole step or to a single section, feature or story. Each request is a numbered round, and Compare versions shows what changed between two versions side by side.

Diagrams

The brief has three diagrams: the process flow, a business capability map (the stages of your value stream and what each role needs at each stage) and a technical overview (the people, applications, services, data stores and outside systems, where they run, and the trust boundaries between them). Each has a text version and can be downloaded as an SVG image.

Documents

Documents are checked by their content, never run, and only offered back to you as downloads. They are read in an isolated process that holds no credentials.