---
title: "To review"
description: "Review the new, changed and dropped requirements and open questions found in meetings, wiki pages and files before they reach the table."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.heizen.work/llms.txt
> Use this file to discover all available pages before exploring further.

# To review

**To review** is where proposals from an [import](/studio/product/requirements#import-from-meetings-wiki-and-files)
wait for a decision. Open it from **To review**, the first item under Product
in the project sidebar. **Import** in the page header, or in the empty list,
starts a new import.

## The list

Proposals are grouped by the meeting, wiki page or file they came from, then by
module inside each source, so you can see which area of the product each one is
about. A module the proposals suggest that doesn't exist yet is marked **New
module**, and proposals without a module are listed last under **No module**.
The list is a table, so you can judge a proposal without opening it. Each row
shows the kind, the requirement ID for a change, the title, the type (`BR`,
`FR` or `NFR`), the personas it is for, its scope, value, priority, effort,
and its status (outdated, a later event, or a lower confidence). The
narrower columns are hidden on small screens. Select a row to see the quote
and the proposed change beside the list:

- **New** adds a requirement.
- **Change** edits an existing requirement. In the review panel the current
  text is struck through in red and the proposed text is shown in green.
- **Remove** takes an existing requirement out of the plan, because the source
  dropped it.
- **Question** is something the source asked and left unanswered.

Quotes from wiki pages and files are shown formatted, with tables as tables.
Long quotes are cut short; choose **Show all** to read the whole passage.

Proposals with **Medium** or **Low confidence** say so on the row. Something
the client said or confirmed is High. Wiki pages and files, and speakers whose
side isn't clear, are Medium. An idea only the team raised is Low. Select the
arrow on a source or module to collapse it.

## Review a proposal

Select a proposal to review it beside the list. Drag the divider to resize the
panel.

- **What was said** shows the exact quote in its original language, who said
  it, and the meeting time or document section. Under it is why this was
  proposed, for example which requirement it changes, and who the speaker is
  taken to be, such as "Client (inferred: approves scope)". When a later
  source dropped a waiting proposal, it says so here and the proposal drops to
  Low confidence.
- **Proposed change** or **Proposed requirement** shows the values that will be
  saved. Select any proposed value to edit it before you accept; **Undo edits**
  goes back to what was proposed. For a new requirement, choose its type and
  module. When the proposal suggests a module that does not exist yet, it is
  created when you accept. Every field is filled in: technical notes and
  technical criteria for engineers, value, priority (Must, Should, Could or
  Won't), client benefit and effort (Low, Medium, High or Very high). What the
  source doesn't say is estimated, so check these and change any of them before
  accepting. **Used by** lists the personas it
  is for, taken from the user roles the source defines, such as Auditor or Admin;
  missing ones are created when you accept.
- **Data fields** lists the data the requirement enters, shows or uses: what it
  means, where it comes from (entered by the user, derived, generated by the
  system, from another system or configured), an example, format, unit,
  default or allowed values, and its rules. **New field** marks a field that
  isn't in the [data dictionary](/studio/product/data-dictionary) yet.
  **Inferred** marks a field the source didn't name, and **Suggested** a rule it
  didn't state; check both before you accept. Fields and rules that already
  exist are reused, never added twice, and only their empty details are filled
  in.
- **Links** lists how it connects to other requirements: **Depends on**,
  **Needed by**, **Conflicts with** or **Related to**, each with the reason.
  Select **×** to remove a link before you accept, or the undo arrow to keep it
  after all. Accepted links are added as suggested links that need a check. A
  link to a proposal that is still waiting is added once both are accepted.
- **Delivers …** appears on a requirement whose business requirement is still
  waiting for review. **Review it** opens that one.
- **What this change affects** shows the requirements linked to the one being
  changed, one column per step. Select any of them to read it, then **Back to
  the proposal**. **Open FR-12 as it is now** shows the requirement before the
  change.

## Decide

- **Apply change** or **Add requirement** saves the proposal, with your edits.
  An approved requirement gets a new version and goes back to Ready. A toast
  offers **Open** to jump to the requirement.
- **Accept all** on a new business requirement adds it together with the
  waiting requirements that deliver it.
- When you add a requirement whose business requirement is still waiting,
  Studio asks first. **Add both** adds the business requirement, then this one,
  linked to it.
- **Move to Not in scope** accepts a removal. The requirement moves to the
  **Not in scope** scope, keeping its history and links, so it can be brought
  back. **Delete** removes it for good, after you confirm.
- **Resolved** closes a question once it is answered. The answer itself is
  picked up when you import the meeting or document it comes up in.
- **Leave out** sets the proposal aside and asks why. The requirement is not
  touched either way.
- **Not needed**: if a later import finds the same thing again, it is not
    proposed again unless the source clearly brings it back.
- **Poor suggestion**: the requirement is fine but the proposal wasn't. A
    later import, for example with **Read imported sources again**, can propose
    it again.

If a similar requirement was added after a proposal was made, accepting it
stops and shows the requirement, for example *FR-40 "Sign in with Google" was
added after this was proposed*. Choose **Merge into FR-40** to turn the
proposal into a change of that requirement, **Add anyway** to keep both, or
**Leave out**.

### When a later meeting or document returns to a proposal

Importing many sources doesn't pile up duplicates. When a later source talks
about something that is still waiting for review:

- **The same thing again** isn't proposed twice. The proposal records the new
  quote under **Later sources**.
- **More detail or a change** updates the waiting proposal in place. The row
  shows **Updated**, and **Later sources** shows what changed, with the quote.
- **An answer to an open question** marks the question **Answered**, with the
  answer. If the answer adds or changes a requirement, that proposal is linked
  from the question; mark the question resolved when the answer is captured.
- **Dropping it** marks the proposal **Dropped** and suggests **Leave out**.
  Nothing is deleted. An older source never drops something a newer one asked
  for. If a later source wants it again, it shows **Wanted again** and its
  confidence comes back.
- **Keeping something a waiting removal would drop** withdraws that removal,
  so it no longer waits for review.
- **A less certain source** never overwrites a proposal: an idea only the team
  raised doesn't change what the client said. Its suggestion is recorded under
  **Later sources** instead.

Nothing is decided for you: every update stays waiting until you accept it or
leave it out.

### Decide several at once

Tick the box on each proposal, or the box on a source or module to select
everything in it. **Accept** then adds, changes or removes each one as proposed.
Selected business requirements are accepted before the requirements that
deliver them; a requirement whose business requirement is still waiting and
wasn't selected is not accepted. **Leave out** sets them all aside, for the reason you choose. Outdated
proposals are skipped, and any that can't be accepted, such as one that looks
like a requirement added since or one whose business requirement is still
waiting, stay selected so you can open them and decide one by one.

After each decision the next proposal opens, so you can work through the list
without going back to it.

A change is marked **Outdated** when someone edited the requirement after the
proposal was made. It can no longer be applied safely: leave it out, and import
the source again for a fresh proposal.

Source: https://docs.heizen.work/studio/product/proposals/index.mdx