Requirements

Overview

A requirement in Holarch is an entity of the LML class Requirement: a capability, characteristic or quality factor the system must have. Requirements usually live in a requirements document (see Documents), but each one is an entity in the model, so the same requirement appears in the Database, in diagrams, in the Traceability Matrix and in the RVTM.

The Needs & Requirements group in the navigation rail holds every requirements page:

Baselines (frozen snapshots for reviews) are made from a document or from Plan & Deliver → Baselines & Versions. Links to functions, assets and tests are covered in Traceability.

Concepts

Requirement and Statement

Statement is the parent class of Requirement. Use a Statement for text that is not binding: section headings, assumptions, context. Use a Requirement for each binding "shall" statement. Only Requirements are scored by the Quality Checker, listed on the TBD/TBR register, flagged by suspect-link tracking and counted in the RVTM; Statements are skipped.

A requirement has the common entity fields Number, Name and Description (the requirement statement itself, as rich text), plus the attributes below.

Requirement attributes

In the inspector's Attributes card the fields an author sets come first, in this order: Priority, Status, Verification Method, Verification Level, Owner, Source, Criticality, TBD/TBR, TBD Owner, TBD Due Date. The score and the nine criteria sit in a collapsed Quality group whose summary reads, for example, "89% · 8 of 9 criteria met", or "not checked yet". Holarch remembers whether you left the group open.

Projects can add their own requirement attributes and choices; see Schema Extensions.

Requirement labels

Labels classify requirements without changing their class. The built-in requirement labels are Functional Requirement, Performance Requirement, Interface Requirement, Environmental Requirement, Reliability Requirement, Safety Requirement, Verification Requirement and Stakeholder Need (a need stated by a stakeholder, before it is turned into system requirements).

Verification Method is also a label group with the labels Analysis, Demonstration, Inspection and Test. The label and the attribute stay in sync: adding the label Test sets Verification Method to Test, and choosing Test in the attribute adds the label, in the same undo step. Older projects and imports that carry only the labels are merged into the attribute when the project opens.

The requirements workflow

Each requirement moves through four statuses:

1. Draft: being written.
2. In Review: waiting for a decision. Listed on the Approvals page.
3. Approved or Rejected: decided. Each decision records who made it, when, and an optional reason.

Three mechanisms keep the record honest after approval:

• Re-review on edit. Editing the name or description of an Approved requirement moves it back to In Review with the note "Text changed after approval".
• Stale quality. Editing the name or description marks its quality results stale and clears manual quality overrides.
• Suspect links. Editing the name, description or a key attribute flags the links to the items downstream of it.

All three happen in the same undo step as the edit, so ⌘Z reverses them together.

Open items: TBD, TBR and TBS

A requirement is an open item when its TBD/TBR attribute is TBD or TBR, or when its name or description contains the word TBD, TBR or TBS. Open items appear on the TBD/TBR register until they are closed.

Baselines

A baseline is a read-only snapshot. A document baseline holds one document: the document artifact, its items, their attributes, the relationships that touch them and the entities one hop away, plus the document's outline settings. A project baseline holds every entity and relationship in the project. Baselines can carry approval records (name, role, statement, date) that are locked once saved.

How to use it

When and why

Requirements work spans the left side of the systems engineering V: capture stakeholder needs, derive system requirements, check that each statement is well formed, get them approved, and freeze them at a review (SRR, PDR, CDR). After the baseline, the work turns to change control: every change is re-reviewed, its downstream impact is checked, and the open TBD/TBR values are closed before the design is committed.

The requirements pages answer these questions:

The Quality, Suspect Links, TBD/TBR and Approvals pages link to each other from the chips at the right of their scope bar, so you can walk through all four checks in turn.

Write a requirement

1. Open Needs & Requirements → Documents and open the requirements document, or create one with + New Document (see Documents).
2. In the Quick add bar under the document, choose where the item goes (for example Under 3 Electrical Power), type the requirement statement and press Enter. Holarch adds an item of the document's default class (Requirement in a requirements document) and numbers it after its siblings.
3. With the requirement selected, open the inspector on the right and fill in the Attributes card: Priority, Verification Method, Verification Level, Owner, Source, Criticality, Rationale and Success Criteria.
4. Add a type label in the Labels column or the inspector, for example Performance Requirement.
5. If a value is not known yet, write the best estimate, set TBD/TBR to TBD, and fill in TBD Owner and TBD Due Date.

Result: the requirement shows a Status of Draft, appears on Needs & Requirements → Requirements, and, if it has a TBD, on the TBD/TBR register.

Check the wording

1. Open Needs & Requirements → Quality, or in the document choose More ▾ → Quality Check.
2. Choose the scope in the scope bar: All Requirements in Project or Document: <name>.
3. Click Run Quality Check in the top bar. The toast reads "Checked 32 requirements" (or your count).
4. Read the tiles: Requirements, Average Score, Good (≥ 67%), Needs Rework (< 67%) and, when any exist, Stale (text changed).
5. For each requirement below 67%, read the Suggestions column, or point at a ✘ to see the messages for that criterion.
6. Click the requirement's name to open it, fix the text, and run the check again.
7. Decide the two judgment criteria. Correct and Feasible always need a person: click the ✘ to mark it Yes once you have reviewed the requirement, or use ✦ AI ▾ → AI Quality Review (N requirements)… to get a first opinion.

Result: each requirement has a score from 0 to 100% and a ✔ or ✘ per criterion.

Approve requirements

1. When a requirement is ready, set its Status to In Review (in the inspector, the Database or a document column).
2. The reviewer opens Needs & Requirements → Approvals. The page lists every requirement whose Status is In Review.
3. Click a row. The inspector shows the approval box: the status, the last decision ("In Review by P. Warmuth · Oct 7, 2026 at 9:58 PM") and the buttons.
4. Click Approve, or Reject… and enter an optional reason. Reopen puts an Approved or Rejected requirement back to In Review.

Result: the toast reads "Approved", "Rejected" or "Moved to In Review", the status changes, and the decision is recorded with your name and the time. The requirement leaves the Approvals list.

Freeze a document for a review

1. In the document, open the Baselines tab of the left pane and click + Create Baseline (or choose More ▾ → Baseline…).
2. Keep or change the Name (the default is "<document> Baseline <n>").
3. Under Approvals, fill in one row per approver: Name, Role and Statement (default "Approved for release."). + Add Approver adds a row; × removes one.
4. Click Create.

Result: the toast reads "Baseline created". The document header shows "Last baseline: <name>", and each row gets a change bar when it differs from the latest baseline.

Handle a change after the baseline

1. Edit the requirement text in the document.
2. Holarch reacts in the same undo step: an Approved requirement moves to In Review; its quality results become stale ("Quality: stale — re-run"); its downstream links are marked suspect. A toast summarizes, for example "1 approved requirement moved to In Review; 6 links marked suspect."
3. Open Needs & Requirements → Suspect Links. Review each linked item; click Diff to see the text change.
4. When a linked item still holds, select its row and click Clear Selected… (or Clear… on the row), write what you checked, and click Clear.
5. Run the Quality Check again, and send the requirement back through approval.
6. Open the Baselines tab, select the baseline and click Changes Since to list every change, then Export XLSX for the change board.

Close TBD and TBR items

1. Open Needs & Requirements → TBD/TBR.
2. Read the tiles: Open TBD/TBR, Overdue, No Owner, and the count per document.
3. Sort out the overdue rows first (tinted, with "Overdue" under the due date). Assign a TBD Owner where the owner shows "—".
4. When the value is settled, edit the requirement text to the final value and click Close on the row. Close sets TBD/TBR to None.
5. Use Export XLSX to send the register to the owners.

Import an existing specification

1. Open Needs & Requirements → Import and choose the tab for your file: Word (.docx), Excel / CSV (.xlsx, .csv), ReqIF (.reqif) or Plain Text (.txt).
2. Configure: keep Import as: Document and Document label: Requirements Document, and set the Default class to Requirement.
3. Click Next ›. Select: drop the file on the drop zone or click to browse. The status line reads, for example, "Analyzed “SRS.docx”: 48 rows, 5 columns."
4. Click Next ›. Customize: name the new document and check what each column maps to.
5. Click Next ›. Preview: check the class counts, the warnings and the New/Updated status of each row.
6. Click Save.

Result: with no warnings, Holarch opens the new document. With warnings, the Import Complete card lists them with buttons to open the document, the Database, a Spider or Tree diagram, or the Quality Check. One ⌘Z removes the whole import.

Worked example: the CubeSat EO-1 demo

The demo project CubeSat EO-1 — Earth Observation Demo (create it from Manage Projects) has a 32-requirement specification, SRS-001 EO-1 System Requirements Specification, with an SRR baseline and changes made after it.

Quality. Open Needs & Requirements → Quality and click Run Quality Check. The tiles show 32 requirements, an average of 93%, 29 Good and 3 Needs Rework. The three weak requirements are written that way on purpose:

• 2.5 Safe Mode Recovery ("The spacecraft should recover from safe mode quickly and resume imaging as appropriate") scores 56%. The suggestions include "R34 - Performance term(s) that cannot be measured: [quickly]", "R8 - Escape clause(s) weaken the requirement: [as appropriate]", "R19 - Contains combinator(s); split into separate requirements: [and]", "Finish the statement with a period." and "No verifying Requirement or Test Case is linked."
• 3.5 Battery Thermal Control ("…keep the battery warm enough (TBD).") scores 56%: "R21 - Contains parentheses; move the bracketed text to Rationale." and "Contains TBD/TBR placeholders."
• 6.4 Operator Interface ("…shall be user friendly and/or easy to use.") scores 56%: "R34 - Performance term(s) that cannot be measured: [user friendly, easy to use]" and "R19 - Contains combinator(s); split into separate requirements: [and, and/or, or]".

Rewrite 2.5 as "The spacecraft shall resume imaging within 6 hours of a safe mode entry.", link a test case with verified by, and run the check again: the combinator, escape clause and vague-term messages disappear.

TBD/TBR. Open TBD/TBR: three open items. 3.5 Battery Thermal Control is a TBD owned by the Thermal Engineer and is overdue; 2.4 Target Slew (ADCS Lead) and 5.3 Downlink Link Margin (Comms Lead) are TBRs due later.

Change after the baseline. The document's Baselines tab holds SRR Baseline, approved by P. Warmuth (Systems Lead), R. Okafor (Mission Principal Investigator) and L. Brandt (Program Manager). After SRR, requirement 3.1 Orbit Average Power changed from 28 W to 30 W. Because 3.1 was Approved, it moved back to In Review with the note "Text changed after approval", and Suspect Links lists six suspect links from 3.1: 1.3.1 Solar Arrays, F3 Generate and Store Power, F3.1 Convert Sunlight to Power, EQ-1.1 Solar Power Generation, EQ-1.4 Power Margin Check and TC-06 Solar Array Power Test. Click Diff on any row to see "28 W" struck out and "30 W" inserted.

Review them: TC-06 expects peak power ≥ 72 W, which still supports 30 W orbit average, so clear that link with the comment "TC-06 margin still covers 30 W". Check that the solar array sizing still closes before clearing 1.3.1.

Changes Since. Select SRR Baseline and click Changes Since. The report lists 3.1's Description, Rationale, Status and Quality Score changes, 2.4 Target Slew's Status change (Draft → In Review), and the new requirement 4.4 Downlink Encryption with its two new satisfies links.

Approvals. Open Approvals: nine requirements are In Review, including 3.1, 1.5 Daily Collection Volume and 5.3 Downlink Link Margin.

Tips and good practice

• Write one "shall" per requirement, in active voice, with a number, a unit and a condition. The Quality Checker rewards exactly that.
• Put the reason in Rationale, not in the statement. Purpose phrases ("so that", "in order to") and parentheses are flagged as R20 and R21.
• Fill in Verification Method while writing. A requirement with a method but no test case shows as Planned-only in the RVTM instead of Unverified.
• Set TBD/TBR with an owner and due date rather than only typing "TBD" in the text: the attribute gives the register an owner and a due date to track.
• Baseline before each review. The change bars and Changes Since only work against a baseline.
• Clear suspect links with a comment. The comment is added to the linked item and recorded on the link, so the review leaves an audit trail.

Common mistakes

How it connects to other features

• Feeds from: stakeholder input and existing specifications through Import; documents written in Documents.
• Feeds into: Functional Analysis (functions extracted from requirements), the Traceability Matrix (satisfied by, verified by), the RVTM and Test Center (verification status), Model Checks (rules Requirement.1 to Requirement.10), Home (approval and verification counts), document reports (Quality Checker Report, RVTM, VCRM, change reports) and Review Packages.
• AI: the document and Entity View ✦ AI ▾ menu has Improve Wording…, Make Measurable…, Simplify…, Split into Singular Requirements…, Draft Rationale…, Suggest Name… and AI Quality Review. AI changes are previewed before they apply. See Ask AI and AI Tools.

The Requirements page

Needs & Requirements → Requirements is the Database filtered to class:Requirement. Every Database feature works here: sort and filter columns, edit cells in place, select rows for the bulk bar (set attributes or labels on many requirements at once), export, and open the Traceability Matrix for the selected rows. Click a row to show the requirement in the inspector; double-click to open its Entity View. A suspect requirement shows a ⚠ Suspect badge on its row. See The Model and the Database for the table, queries and bulk edit.

Useful queries:

Requirements Quality Checker

The Quality page (title "Requirements Quality Checker") scores each requirement against nine criteria. Score = 100 × (criteria met) / 9, rounded. A score of 67% or more is Good; below 67% is Needs Rework. The bar color is red below 34%, yellow from 34% to 66% and green from 67%.

Page layout

• Top bar: More ▾ with Clear Manual Overrides (resets every manual Yes/No in the scope and re-runs the check) and Open Document (when the scope is a document); Export ▾ with Excel (.xlsx) and CSV; Run Quality Check. The ✦ AI ▾ control holds AI Quality Review (N requirements)….
• Scope bar: the scope list (All Requirements in Project or Document: <name>), the checkbox Re-check automatically when the text changes, and chips to Suspect Links, TBD/TBR and Approvals.
• Tiles: Requirements, Average Score, Good (≥ 67%), Needs Rework (< 67%), and Stale (text changed) when any are stale. Stale scores are left out of the average. The note under the tiles reads: "Automated checks reach at most 7 of 9 attributes (78%); Correct and Feasible require human verification — click a ✘ to mark it Yes."
• Table: Number, Name (with the description below), Quality Score, one column per criterion, and Suggestions (every message, prefixed by its criterion). Rows are sorted by number.

A row with no result shows "Not run" in the score column. A stale row shows "Stale — re-run". When the scope has no requirements, the page shows "No requirements" and "Only entities of class Requirement are scored; Statements are skipped."

Criteria and checks

Each criterion is ✔ (Yes) when it has no messages, ✘ (No) when it has at least one, and – when not checked. The checks match whole words and phrases, case-insensitive. The messages below are the exact text shown; the bracketed list at the end of a message names the words found.

Unambiguous

Complete

Singular

Conforming

Appropriate

Necessary

Verifiable

Feasible

Correct

Because Correct and Feasible end with "Needs a reviewer’s judgment" until someone decides, the highest automatic score is 7 of 9 (78%).

Manual overrides

You can override any criterion:

• On the Quality page: click a criterion cell to toggle it between ✔ and ✘. The cell shows a manual marker, and its tooltip ends "(manual)".
• In the inspector or Entity View: each criterion is a list with Yes and No; a criterion set by hand also offers Auto (re-check), which returns it to the automatic result. Hand-set values show "manual".

A manual value is kept when the check re-runs, and a manual No with no other message shows "Marked No manually." Overrides are cleared when the requirement's name or description changes (they stay in History; Undo brings them back), or with More ▾ → Clear Manual Overrides.

Stale results

When a requirement's name or description changes after a check, its results are marked stale:

• The Quality page shows "Stale — re-run" with the tooltip "The text changed after the last check. Run the Quality Check again."
• A document's Quality Score column shows "Quality: stale — re-run".
• The inspector shows "Quality: stale — re-run".

With Re-check automatically when the text changes turned on, Holarch re-runs the rule check on the edited requirement right away instead. The setting is kept in this browser.

Quality Check from a document

In a document, More ▾ → Quality Check checks the selected requirement, or, with no requirement selected, every visible requirement in the document. The results open in the Quality Check — <name> dialog with the tiles and table, and the buttons Export CSV, Export XLSX, Open Quality Checker and Close. A document with no requirements shows "This document has no Requirements to check (Statements are not scored)."

AI Quality Review

✦ AI ▾ → AI Quality Review (N requirements)… asks the configured AI provider to judge the three criteria a rule cannot decide: Correct, Feasible and Necessary. Requirements are sent in groups of 20, with up to 300 other requirements for duplicate checks.

The review dialog lists each requirement with a Yes/No verdict and a reason per criterion, "currently Yes/No" where the verdict differs, an optional comment, and, where the AI proposes one, a Use suggested rewrite: checkbox with a word diff. Criteria that differ start ticked; rewrites start unticked; Approved, baselined and locked requirements start unticked and are flagged. Check all and Uncheck all set every criterion. Apply Selected applies the ticked items in one undo step: verdicts become manual values (kept when the check re-runs) with the message "AI: <reason>", and rewrites replace the description and re-run the check. The toast reads "Applied N AI changes".

Quality exports

Approvals

Needs & Requirements → Approvals opens the Database with the query Requirement:"Status=In Review". It has every Database feature: select several rows and use the bulk bar to set Status or labels together, export the list, or double-click a row for the Entity View and full history.

The approval box

The approval box appears in the inspector and the Entity View of every requirement. It shows:

• The current status as a colored chip (Draft when none is set).
• The last recorded decision: "<status> by <name> · <date and time>", followed by "— <note>" when there is one (for example "— Text changed after approval"), or "No approval recorded".
• The buttons that apply to the current status:

The name recorded is your account name. Setting Status by hand in a table or the inspector also records a decision with your name and the time. Viewers see the box without buttons.

TBD/TBR Register

Needs & Requirements → TBD/TBR lists every open item. From a document: More ▾ → TBD/TBR Register, which opens the register scoped to that document.

• Top bar: Help and Export XLSX (disabled when the register is empty).
• Scope bar: the scope list and chips to the other requirements-health pages.
• Tiles: Open TBD/TBR, Overdue, No Owner, and Per document chips ("<document>: <count>") that open each document.
• Open items over time: a burn-down of the open count, rebuilt from the requirements' history (up to 60 points from the oldest requirement to now). Point at a dot for its date and count. With too little history it shows "Not enough history for a burn-down yet."
• Table: Number, Name (with the description), Document, Type (TBD, TBR or TBS, with "attribute", "in text" or both), Owner (TBD Owner, else the requirement's Owner, else "—"), Due Date (with "Overdue" under a past date; overdue rows are tinted), Age (days since the item opened) and Close.

Close appears only when the TBD/TBR attribute is set. It sets the attribute to None:

• With nothing left in the text, the toast reads "Closed".
• With TBD, TBR or TBS still in the text, the toast reads "Attribute closed; the text still contains TBD."
• A text-only item has no Close button; edit the text to close it.

When nothing is open the page shows "No open TBD/TBR items. Set a requirement's TBD/TBR attribute, or write TBD, TBR or TBS in its text, to list it here."

Export XLSX writes TBD-TBR Register.xlsx with Number, Name, Document, Type, Source (attribute, text or both), Owner, Due Date, Opened, Age (days), Overdue (Yes in red) and Description.

Suspect Links

A link becomes suspect when the requirement at its upstream end changes. Needs & Requirements → Suspect Links lists them; from a document use More ▾ → Suspect Links.

What makes a link suspect

A change to any of these on a requirement:

• Name or Description.
• Priority, Criticality, Verification Method or Verification Level.
• Any numeric, percent or duration attribute.

flags each of its links of these types: decomposed by, derived by, refined by, satisfied by, verified by and traced to. The other end of each link (the child requirement, the satisfying function or asset, the verifying test case, and so on) is the suspect item. Further changes to the same requirement add to the list of changed fields on the same flag.

Where suspect items show

• Suspect Links page: one row per suspect link.
• Documents and the Database: a ⚠ Suspect badge on the suspect item's row ("Suspect: an upstream requirement changed. Click to review.").
• Inspector and Entity View: a banner "⚠ Suspect: <requirement> changed since this link was last reviewed." with Review…, which opens the Suspect Links — <item> dialog for that item. The dialog has Open Suspect Links and Close.
• The inspector's Relationships card: a ⚠ next to each suspect link, with the changed fields and date in its tooltip.

The Suspect Links page

The page explains the rule at the top and shows a table:

• Diff opens Change — <requirement> with a word diff of the name and description. When only attributes changed it reads "Only attributes changed: <fields>. Open the entity history for details." History… opens the requirement's history.
• Clear…, Clear Selected… and Clear All (N)… open Clear N Suspect Link(s): "Confirm that the linked items still hold after the change. A comment is added to each linked item." Type an optional comment (for example "Child still valid; no change needed.") and click Clear. The toast reads "Cleared N suspect links". Clear Selected… with nothing selected shows "Select links to clear first."

Clearing records the review on the link (who, when, the comment and the fields) and, when you wrote a comment, adds "Suspect link reviewed (<requirement> changed: <fields>): <comment>" to each suspect item's comments. Undo reverses a clear.

With no suspect links, the page shows "No suspect links. A link becomes suspect when the requirement at its upstream end changes."

Baselines and version comparison

Document baselines

Create and use document baselines in the document's Baselines tab (left pane):

• Main (the live document), each baseline of this document (newest first), and, under Project baselines, every project baseline as "<name> (project)". "No baselines of this document yet." when there are none.
• + Create Baseline opens Create Baseline: Name * (required), Approvals (rows of Name, Role, Statement; + Add Approver; "No approvers." when empty) and the note "A baseline is a read-only snapshot of this document: its entities, their attributes and relationships. Approval records are dated now and cannot be edited afterwards." The first approver row is filled with your name.

Click a baseline to view it. The document becomes read-only with the banner "Viewing baseline “<name>” (read-only) — created <date>" and the approvals list, and these buttons:

In the live document, each row carries a change bar against the latest document baseline (or the latest project baseline when the document has none): new since the baseline, changed since the baseline, or unchanged.

Baseline Change Report

Changes Since (or the document Reports) opens the Baseline Change Report. Choose the Source baseline and the Target (a later baseline or Current). The table lists Number, Name, Change Type, Field and Change (a word diff for modified text). Change types:

Export XLSX writes "<document> Change Report.xlsx" with Number, Name, Class, Change Type, Field, Old Value and New Value. With no baseline, the button shows "Create a baseline of this document first."

The document Reports dialog also has Post-Baseline Change Report (XLSX) (changes since the latest baseline) and Baseline to Baseline Change Report (XLSX) (choose Source baseline and Target). Both fail with "This document has no baselines yet." when there is none. Basic Document Output fills the Revision History and Approvals tables of the Word output from the document's baselines.

Baselines & Versions page

Plan & Deliver → Baselines & Versions (also the project menu's Project Version Control) manages every baseline in the project. "Baselines are read-only snapshots. Project baselines hold every entity; document baselines hold one document (created from the document’s More → Baseline)."

• Create Project Baseline: type a name (default "Baseline <n>", placeholder "Baseline name, e.g. "SRR"") and press Enter or click Create Baseline. The card shows the current entity and relationship counts. Toast: "Baseline created".
• Baselines card: filter with All baselines, Project baselines or Document: <name>. Columns: Name, Document (a link to view the document at that baseline, or "Project"), Created, Approvals ("✔" and the approver names; point at them for role, date and statement; "by <name>" for the creator), Entities, Relationships, and the actions:
  • Compare: sets this baseline as From and the current working copy as To.
  • Rename: Rename Baseline.
  • Export: downloads "<name>.json" (format holarch-baseline, with the snapshot and approvals).
  • Restore (project baseline): "Replace all current entities and relationships with baseline "<name>"? Undo is available (⌘Z)." Toast: "Restored "<name>"".
  • Revert (document baseline): "Restore document "<doc>" to baseline "<name>"? Only that document's entities and structure change. Undo is available." Disabled when the document was deleted.
  • Delete.
• Clean Baselines (shown when needed): "N baselines of deleted documents", each with Restore Document (re-creates the document artifact and its entities from the baseline) and Delete.
• Compare card: From (older) → To (newer), where To is Current working copy or another baseline of the same scope. Tiles: Entities added, Entities removed, Entities changed, Relationship changes. The table shows Entity, Change, Field and Difference (word diff). Export CSV and Export XLSX write "Changes <from> to <to>". With nothing to show: "No differences between “<from>” and “<to>”."

With no baselines: "No baselines yet. Create one to capture the current state of the project."

Import requirements

Needs & Requirements → Import (title "Import Analyzer") brings requirements in from files in four steps: Configure → Select → Customize → Preview. ‹ Prev and Next › move between steps; Save on the Preview step imports. Choosing a different tab resets the wizard. This section covers the requirements formats; for project files, XMI and every other import and export, see Import and Export.

The tabs are Word (.docx), the project-file tab (.inno, .json, .xml), Excel / CSV (.xlsx, .csv), Plain Text (.txt), UML/SysML (.xmi) and ReqIF (.reqif). Dropping a file switches to the matching tab automatically.

Step 1: Configure

"A file whose rows are all Statements or Requirements (or their subclasses) becomes a requirements document." A file with other classes becomes a plain document.

Outline formats (Plain Text, and Word files whose numbering is typed rather than Word list numbering): Automatic; Numbered List with Period; Numbered List with Parenthesis; Numbered List; Uppercase Roman Numerals List with Period; Lowercase Roman Numerals List with Period; Uppercase Letter List with Period; Lowercase Letter List with Period; Lowercase Letter List with Parenthesis; Multi-Level Numbered List with Period (1. 1.1. 1.1.1.); Multi-Level Numbered List (1 1.1 1.1.1); Multi-Level Lowercase List with Periods (1. a. i.); Multi-Level Lowercase List with Parentheses (1) a) i) (1) (a) (i)); Multi-Level Alphanumeric List (I. A. 1. a) (1) (a)); Multi-Level DoD List (1. a. (1) (a) 1. a.); Custom Outline Format….

Custom Outline Format… shows Outline levels (up to six):, one row per level with Numbering (Decimal, Lowercase Alpha, Number, Roman Numeral, Uppercase Alpha), Delimiter (Space, Period, End Parenthesis, Double Parenthesis) and Start. + Add Level adds a level; × removes one.

Step 2: Select

Drop a file on "Drag and drop a file here or click to browse". The accepted extensions are listed under the drop zone. Instead of a file you can paste text into the box and click Analyze Pasted Text (CSV with a header row, ReqIF XML, or document text). For plain text the box keeps the imported content editable; edit it and click Analyze Again.

• Workbooks: when a workbook has more than one sheet, choose the Sheet: ("<name> (N rows)"). The first sheet with data is preselected.
• The status line reads "Analyzed “<file>”: N rows, M columns." (plus "(sheet “<name>”)" and, for Word, ", N table(s)").

Step 3: Customize

Enter Name of the new Document: (defaults to the file name). Then map each column:

Holarch guesses the mapping from the header:

New Attribute creates an attribute named after the column on each imported class (a number attribute when every value is a number, a choice list when there are few short distinct values, long text for values over 120 characters, text otherwise). Quality criteria, computed and file attributes cannot be mapped.

Hierarchy. Outline numbers rebuild the hierarchy: "1.2.3" becomes a child of "1.2". A Parent Number column or Row ID/Parent Row ID pair sets the parent explicitly. Items with no parent become the document's top-level items.

Word tables. For a Word file, the Word Tables section lists each table (tables that repeat with the same header across sections share one mapping): "Import a requirements table as entities, one per row, and map its columns. Other tables stay as tables in the description of the item they follow." Set each to Entities (one per row) or Table in the description, and map its columns to Number, Name, Description, Class, Labels, Attribute, New Attribute or Ignore. Headers such as ID, Req ID, Requirement ID, Ref or Paragraph map to Number; Shall, Shall Statement, Requirement Statement, Requirement Text, Statement or Text map to Description. A table with a number or description column and "shall" rows starts as entities.

The warnings found so far appear under the table, or "No warnings."

Step 4: Preview

Statistics counts the entities per class and in total. A note says what document will be created: "A requirements document “<name>” will be created and will be the source of the top-level entities." or "A document “<name>” will be created (the file contains classes other than Statement/Requirement)." The warnings follow, then a preview of the first 500 rows with Status (New or Updated), Class, Number, Name and Description.

Click Save. The toast reads "Imported N new, M updated". With no warnings Holarch opens the new requirements document (or the Database). Otherwise the Import Complete card lists the warnings ("No warnings reported on import." when clean) with Open Document, Open Database, Spider Diagram, Tree Diagram, Quality Check and Import Another File. The new document's description lists the import warnings.

How each format is read

• Word (.docx): headings and Word list numbering become the outline and keep their numbers. A heading becomes a Statement; body text under it becomes its description. A paragraph with shall, must, will or should, or a numbered list item, becomes a child Requirement (a Statement when it has no modal verb), named from the words after the modal verb. Bullet items, pictures and tables join the description of the item they follow, keeping bold, italic, lists and tables. The original .docx is attached to the new document when it is within the per-file attachment limit. PNG and JPEG pictures are kept; other picture formats are skipped with a warning.
• Excel (.xlsx, .xlsm) and CSV: one row per entity, any columns, first row = header. Multi-line cells keep their line breaks. Excel 97-2003 (.xls) files are not read: save them as .xlsx or .csv first.
• ReqIF (.reqif, .reqifz): each SPEC-OBJECT becomes a row with ReqIF ID, Parent ID (from the specification hierarchy), Type (its object type, mapped to Class), Long Name and one column per attribute definition. Columns with no match default to New Attribute; XHTML attributes become rich-text attributes and enumeration attributes become choice lists. SPEC-RELATIONs become relationships by name, or traced to when the name does not match a relationship the schema allows. A .reqifz archive is unpacked automatically.
• Plain Text (.txt) or pasted text: a numbered line ("3.1 Battery") or a short line without a period becomes a heading (Statement); each sentence with shall, must, will or should becomes a Requirement under the current heading; other text joins the previous item's description. With an outline format other than Automatic, the chosen numbering decides the levels.

Update requirements from a spreadsheet

1. In the Database (or the Requirements page), export the requirements to Excel with the Global ID column.
2. Edit the values in the spreadsheet. Keep the Global ID column.
3. Import the file with Import as: None and Match existing entities by: Global ID.

Matched rows show "Updated" in the preview. Only the mapped columns are written: a missing Description column keeps each existing description. Labels from the file are added to the existing labels. Without a Class column, a row matched by Global ID keeps its entity's class.

Import messages

Requirements shortcuts

For every shortcut in the app, see Keyboard Shortcuts.

Settings

Messages

Limits

• Quality Check: every requirement in the scope is compared with the others for duplicates (75% similarity threshold).
• AI Quality Review: 20 requirements per AI request, with up to 300 other requirements as context.
• The suspect-link diff keeps the first 500 characters of the old name and 4,000 of the old description.
• TBD/TBR burn-down: up to 60 points.
• Import: names and numbers up to 255 characters; preview of the first 500 rows; the first 50 warnings are listed ("…and N more"); custom outlines up to 6 levels; ReqIF/XML files up to 100 million characters and 3,000,000 elements; .reqifz and .docx archives up to 10,000 entries, 300 MB per entry and 600 MB in total. Pictures and the original Word file are kept only within the per-file attachment limit set by your administrator (25 MB by default).

Related

• Documents: write and structure specifications, reports and DOCX output.
• Traceability: relationships, the Traceability Matrix, coverage and impact.
• The Model and the Database: queries, columns and bulk edit.
• Schema Extensions: add requirement attributes, choices and labels.
• Import and Export: every file format.
• Help: Requirements, Status and Approval, Requirements Quality, TBD/TBR Register, Suspect Links, Approvals, Import, Baselines & Versions, RVTM.