vmodel.eu reads your specification, classifies the structure, and feeds it to an LLM reviewer. A few small formatting choices change whether the reviewer sees most of your requirements or just the first few. This is also how industry teams write requirements, so the same habits transfer.
Quickest start: download the fill-in template (Markdown) ↓ — a SMART project-goal block plus pre-filled requirement tables. Edit the placeholders, export to PDF, upload.
What good looks like — minimal example
# Functional Requirements — Greenhouse Ventilation Controller
## 1. Sensing
| ID | Requirement | Priority | Pass/Fail Criterion |
|--------|-------------------------------------------------------------|----------|------------------------------------------------|
| FR-S01 | The system shall sample temperature every 30 s. | Must | Logged at 0.0333 ± 0.005 Hz over 1 h |
| FR-S02 | The system shall flag a sensor fault within 5 s. | Must | Fault state observable within 5 s of disconnect |
## 2. Window Actuation
| ID | Requirement | Priority | Pass/Fail Criterion |
|--------|-------------------------------------------------------------|----------|------------------------------------------------|
| FR-A01 | The system shall command each window M1–M3 to open. | Must | Travel from closed→open within spec ±1 s |
No preamble, no TOC, no diagrams. Tables, IDs, priorities, criteria. The reviewer gets to work immediately.
The five required pieces
1. A clearly-titled requirements section
Heading should literally include "Requirements" or "Eisen". The system uses the heading to locate where to start reading.
2. Numbered requirement IDs — from a supported prefix
| Style | Examples |
|---|---|
| Bare prefix + number | F1, NF1, R1, E1 |
| Standard | FR-01, NFR-02, REQ-1, SR-3, UR-1 |
| Category-suffixed | FR-S01 (Sensing), FR-W01 (Wind), FR-MA01 (Master) |
| Dotted sub-IDs | FR-1.2, F2.1.3 |
Not currently supported (you'll get a low-confidence bounce): FA1, Eis 1, Punt 1, free-text labels. Pick from the list above.
3. MoSCoW priority on every requirement
Either spelled out (Must / Should / Could / Won't) or bracketed ([M] / [S] / [C] / [W]).
4. Measurable pass/fail criteria
Replace vague words like "fast", "reliable", "user-friendly" with measurable thresholds: <150 ms p95, MTBF ≥ 8000 h, task completion ≥ 90% in ≤ 60 s.
5. Table format
PDF extractors agree on tables far more reliably than prose. Put one requirement per row.
Things that crowd out the reviewer
The reviewer reads a fixed window of text. Anything before your first requirement consumes that budget.
| Pattern | Why it hurts | Fix |
|---|---|---|
| Long Table of Contents | Pushes your requirements past the window | Page-break before the requirements section, or omit the TOC |
| Front-matter table (Document / Project / Version / Date) | Same | Keep it short; one line if possible |
| Glossary before requirements | Same; also: the word "MoSCoW" in the glossary confuses our trim heuristic | Move the glossary to an appendix |
| ASCII / box-drawing diagrams | Consume the budget with no semantic content | Use figures (the caption is enough) |
| Long narrative intro between heading and first requirement | Same | Put context in a separate "Background" section before the requirements heading |
| Narrow-column PDF tables | Wrap IDs across lines (e.g. FR-S03) |
Widen the ID column so FR-S03 stays on one line |
How big is too big?
| Spec size | What happens |
|---|---|
| 5–30 requirements | Full coverage; best feedback |
| 30–80 requirements | Most reviewed; you may get a coverage warning |
| 80+ requirements | Only the first 15–25 fit. You'll get a clear warning ("17 of 183 reviewed") with a recommendation to split |
For large specs: split by domain (e.g. "Sensing", "Actuation", "Configuration") and submit each as its own document. Each submission gets a focused review of its section.
Language
English or Dutch both work. Dutch headings like "Functionele eisen" are recognized. Use the same ID prefixes above (FR-01 etc.), not Dutch-specific schemes like FA1 or Eis 1.
Why this style is also industry-standard
The structure above is the same one ISO/IEC/IEEE 29148 §5.2 recommends, and most regulated industries (automotive ISO 26262, medical IEC 62304, aerospace DO-178C) require in some form. Practicing this format isn't just about better vmodel.eu feedback — it's the same habit you'll need in your first engineering job.