# Importing and Reviewing Requirements

> Upload requirement documents, extract text, AI-parse them into typed requirements, then review, edit, and approve the requirements that drive test generation.

Source: https://totalshiftleft.ai/help-center/product-documentation/importing-and-reviewing-requirements

## Overview

On the **Requirement Documents** tab of Rule Intelligence, you upload requirement documents and turn them into structured, approvable requirements. This is the walkthrough for the full loop: upload → **Extract text** → **AI Parse** → review and approve in the **Extracted Requirements** panel. Background: [Understanding Rule Intelligence](/help-center/product-documentation/understanding-rule-intelligence).

## Before you begin

- Open the workspace: in the project editor, click the **Requirements** tab (or open the standalone **Rule Intelligence** hub and select a project). The **Requirement Documents** tab is selected by default.
- The header reads **Requirement Documents** with the note *"Add BRD, PRD, Excel, Word, and other business requirement documents. (API specs — Swagger/WSDL/GraphQL — go in Setup → API Specs.)"* and *"Upload starts as soon as you choose files."*
- **AI Parse requires an AI provider** (**Settings → AI**). Uploading and **Extract text** work without one; **AI Parse** does not.
- **Supported protocols are REST, SOAP, and GraphQL.** gRPC is not supported — there is no gRPC executor or test editor, and it can't be imported or tested.

## Step 1 — (Optional) set the document type

At the top-right of the header, above the upload button, is a document-type dropdown. It defaults to **Auto-detect**; the other options are **API Module**, **BRD**, and **Generic**. Leave it on **Auto-detect** unless a document is being misclassified — the value you pick is passed to the next AI Parse as a `documentTypeOverride`.

## Step 2 — Upload documents

1. Click **Choose requirement files**.
2. Select one or more files. Accepted formats: **.pdf, .doc, .docx, .xls, .xlsx, .csv, .html, .htm, .mht, .mhtml, .json, .yaml, .yml, .txt, .md, .markdown**.
3. Upload begins immediately. The button reads **Uploading...** while it runs; on success you get a **Document uploaded** (or **N document(s) uploaded**) confirmation.

Each file becomes a row in the table with columns **Name**, **Type**, **Status**, **Created**, and **Actions**. New rows start at status **Uploaded**. If nothing is uploaded yet, the empty state lists the supported formats and points you back to **Choose requirement files**.

## Step 3 — Run the three-step row workflow

Every requirement row exposes three always-visible, re-runnable buttons on the left of the **Actions** cell. Each is gated on the previous step:

| Button | Icon | What it does | Enabled when |
|--------|------|--------------|--------------|
| **Extract text** | green play | Pulls raw text out of the document | Always |
| **AI Parse** | blue sparkle | Sends the text to the AI to extract typed requirements | After text is extracted (disabled while status is **Uploaded**) |
| **Show / Hide requirements** | purple list | Opens or closes the **Extracted Requirements** review panel | Once status is **Parsed** |

There are also **Download** and **Delete** buttons on every row. Delete asks you to confirm (**Delete document**, *"This cannot be undone."*).

### 3a. Extract text

Click the green **play** button. The status cell shows *Extracting text...* with a spinner, then settles on **Text Extracted**, and the row hint reads *Ready to parse*. You'll see a **Text extracted successfully** confirmation.

### 3b. AI Parse

Click the blue **sparkle** button. The status shows *Extracting requirements...*, then **Parsing**, then **Parsed**. On success the **Extracted Requirements** panel opens automatically and you'll see an *N requirements extracted* confirmation. While a document is **Parsing Queued** or **Parsing**, the list auto-refreshes every few seconds.

Once parsed, the row hint disambiguates the outcome:

- **No rules extracted** — parsed cleanly but found no extractable rules.
- **N approved · N pending** — how many requirements are approved vs. awaiting review.

## Step 4 — Handle a partial or re-parse case

**Partial parse.** If some document sections fail, ambiguities are raised, or requirements can't be saved, a banner appears above the list instead of a plain success toast. It summarizes *"N of M requirement(s) ready to approve"* and how many sections were processed, and expands into buckets:

- **N requirement(s) could not be saved** (blocking errors)
- **N item(s) need review**
- **N item(s) auto-corrected (no action needed)**
- **Show ambiguities** and **Per-section yield** breakdowns

If sections failed during AI extraction, the banner offers **Retry failed sections** (the LLM is non-deterministic, so a retry often succeeds).

**Re-parse guard.** If you AI-Parse a document that already has approved or human-reviewed requirements, the platform stops and opens a **Re-parse will replace reviewed requirements** dialog, e.g. *"…already has N approved and N human-reviewed requirement(s). Re-parsing wipes them and replaces with a fresh AI extraction. This cannot be undone."* Choose **Re-parse anyway** to proceed or close the dialog to keep your reviewed set.

## Step 5 — Review in the Extracted Requirements panel

The panel is headed **Extracted Requirements**. When a parse spanned multiple sections it also notes *Processed N sections* and *Merged N duplicate(s)*.

**Sort.** When there's more than one requirement, a **Sort by** dropdown offers **Confidence (low first)** (the default, so likely-needs-review items surface at the top), **Priority**, **Status**, and **Title**. Requirements are grouped by their target endpoint (or **General**).

**Read a row.** Each requirement shows its **title**, **description**, and a set of chips:

- Its **type** (e.g. **Field Constraint**, **Business Rule**, **Error Handling**).
- The **target entity** and **field: …** it applies to.
- The **expected status code** (→ 400) and any **error code**.
- A **status** chip: **AI Extracted**, **Reviewed**, **Approved**, **Rejected**, or **Deprecated**.
- **Confidence: NN%**. Below **70%** confidence *and* still AI-extracted, it also shows a **Needs review** chip.
- **Low fidelity NN%** when the structured constraint fields are thin, and **Salvaged** / **N fields dropped** when the AI emitted fields that failed validation.

## Step 6 — Approve, reject, edit, or delete

On the right of each row:

| Action | Result |
|--------|--------|
| **Approve** (green check) | Status → **Approved**. Approved requirements are the only ones that drive generation. |
| **Reject** (red X) | Status → **Rejected**. Ignored by the generator. |
| **Edit** (pencil) | Opens the inline edit form (see below). |
| **Delete** (trash) | Removes the requirement. |

Every requirement stays selectable regardless of status, so you can flip an approved item back to rejected or vice versa at any time.

## Step 7 — Bulk-approve or bulk-reject

Tick the checkbox on individual rows, or use **Select all (N)** in the panel header. A blue action bar appears showing **N selected** with:

- **Approve selected**
- **Reject selected**
- **Clear selection**

## Step 8 — Edit a requirement's fields

Click the **Edit** (pencil) button to open the inline form. Title and description are required.

| Field | What it does |
|-------|--------------|
| **Title** | Short name of the requirement (required). |
| **Description** | Full text of the rule (required). |
| **Priority** | **Critical**, **High**, **Medium**, or **Low**. |
| **Target entity** | The entity the rule applies to, e.g. `User`. |
| **Target field** | The specific field the constraint targets. |
| **Operator** | The constraint operator, e.g. `is_required`, `in`, `between`. |
| **Value (JSON for arrays)** | The constraint value, e.g. `100`, `"active"`, `["a","b"]`. |
| **Expected status code** | The HTTP status the requirement expects (100–599), e.g. `400`. |
| **Error code** | The expected error code, e.g. `ORD-002`. |
| **Error message contains** | A substring the error message should contain. |
| **Max latency (ms)** | Performance ceiling for the requirement. |

Click **Save changes** (the button shows **Saving…** while it runs) or **Cancel**. The same server-side validation the parser uses runs on save, so an invalid value is reported immediately.

## Step 9 — Scope a requirement to endpoints

Expand **Applies to endpoints** on a row. By default a requirement is set to **All endpoints (auto-match)**. To narrow it, tick specific endpoints from the list; the summary updates to *N endpoints selected*. Un-ticking everything returns it to auto-match.

## Notes

- Status labels across the flow: **Uploaded**, **Text Extracted**, **Parsing Queued**, **Parsing**, **Parsed**, **Review Pending**, **Approved**, **Failed**.
- Deleting a document also removes its extracted requirements and closes the review panel if it was open for that document.
- Your edits, approvals, and rejections are learning signals — see [Continuous learning insights](/help-center/product-documentation/continuous-learning-insights).

## Related articles

- [Understanding Rule Intelligence](/help-center/product-documentation/understanding-rule-intelligence)
- [Test data and generation setup](/help-center/product-documentation/test-data-and-generation-setup)
- [Coverage and fidelity](/help-center/product-documentation/coverage-and-fidelity)
- [Generate endpoint test cases](/help-center/product-documentation/ai-generated-tests)