Styles for Toyota, Schneider, Scrum and Kanban
Requirements engineering has a tooling gap. The canonical standards — ISO/IEC/IEEE 29148, Volere, SysML, EARS — are rigorous. The artifacts most teams actually ship — Word documents, Confluence pages, Jira tickets, Excel traceability matrices — are not. They have no schema, no diff, no compiler, no CI gate. They decay the moment nobody is looking.
@frenchexdev/requirements closes that gap. Requirements become typed artefacts in the repository — .spec.json files validated by JSON Schema, TypeScript classes narrowed at compile time, Markdown rendered for humans. The four-tier chain is explicit and enforced:
Requirement (the why) → Feature (the what) → Acceptance Criterion (the observable) → Test (the evidence)
Every AC must be @Verifies'd by a test; every Feature must @Satisfies a Requirement; every Requirement must carry a fitCriterion. Miss any link and requirements compliance --strict fails the build.
But which ontology fits your domain? A Schneider Electric integrator assembling a SIS package for a refinery does not want "User Story" and "Story Points" — they want safety-function statements, SIL 1-4 risk levels, and a SafetyApproval gate. A Toyota kaizen facilitator does not want EARS — they want kaizen-hypothesis, gemba-walk sources, and a PDCA workflow. A Scrum team wants INVEST-enforced user stories with Given-When-Then acceptance criteria. A Kanban service team wants Anderson's Classes of Service as types, not labels.
That's why the package ships Styles: composable presets — vocabulary, validators, templates, reporter — that rewire the DSL around a specific domain. Five are built in; a sixth guide shows how to build your own.
The five Styles
- Default Style — ISO/IEC/IEEE 29148 + Volere + EARS + SysML. The 90% preset for first-time adopters.
- Industrial Style — IEC 61508 / 61511 / 62443, ISA-88 / 95 / 18.2, 21 CFR Part 11. From HAZOP to FAT without leaving
git. - Lean Style — Ohno, Shingo, Womack, Poppendieck, Ries, Rother. A3 / PDCA / Gemba / VSM / Kaizen as typed artifacts.
- Agile Style — Cohn, Wake (INVEST), North (BDD), Beck (XP), Leffingwell (SAFe). Your backlog is source code.
- Kanban Style — Anderson's Classes of Service as types, not labels. Cost-of-Delay made mechanical.
Build your own
Nothing matches your domain? How to create your own Style walks from decision guide to published npm package in about thirty minutes, with a worked LegalStyle for Catala-flavoured deontic engineering.
Reference
The Glossary is the shared vocabulary across every Style — each term cited with its source standard (29148 / Volere / SysML / EARS / project-internal).
Source
- npm:
@frenchexdev/requirements - GitHub: github.com/frenchexdev/frenchexdev — MIT licensed
- Dogfooded: every Feature and AC in the package itself is declared in its own DSL, and the test suite uses
@FeatureTest/@Verifiesexclusively (nodescribe/it)