# Requirements Specification — <your project name>

> Replace every `<placeholder>` with your own content. Delete this guidance block before submitting. Export to PDF and upload at https://vmodel.eu.

---

## 1. Project Goal

State the goal of the project as a single SMART statement. Each row gives one piece of the goal — keep the answers short (one line, with a number or threshold where possible).

| SMART | Your goal |
|---|---|
| **S**pecific — *what is being built, for whom?* | <e.g. A wearable fall-detector for elderly users living independently at home.> |
| **M**easurable — *what number tells you it works?* | <e.g. Detects at least 90% of real falls; ≤1 false alarm per 24 h of normal activity.> |
| **A**chievable — *what evidence makes this realistic in your project's scope?* | <e.g. Builds on an existing 9-DoF IMU prototype; classifier trained on the public SisFall dataset.> |
| **R**elevant — *who benefits, and why does it matter?* | <e.g. 30% of people over 65 fall each year; faster alerting reduces "long lie" complications.> |
| **T**ime-bound — *deadline or operating window?* | <e.g. Working prototype by end of semester (week 20); detection latency ≤ 5 s.> |

---

## 2. Functional Requirements

One requirement per row. Use a supported ID style (`FR-01`, `FR-S01`, `F1`, etc.). Each requirement needs a MoSCoW priority and a measurable pass/fail criterion.

| ID | Requirement | Priority | Pass/Fail Criterion |
|---|---|---|---|
| FR-01 | The system shall <observable behaviour>. | Must | <measurable threshold, e.g. response within 200 ms p95> |
| FR-02 | The system shall <observable behaviour>. | Must | <measurable threshold> |
| FR-03 | The system shall <observable behaviour>. | Should | <measurable threshold> |
| FR-04 | The system shall <observable behaviour>. | Could | <measurable threshold> |

Optional groupings — replace `S`, `A`, `C` with your own category letters:

| ID | Requirement | Priority | Pass/Fail Criterion |
|---|---|---|---|
| FR-S01 | <Sensing requirement> | Must | <criterion> |
| FR-A01 | <Actuation requirement> | Must | <criterion> |
| FR-C01 | <Configuration requirement> | Should | <criterion> |

---

## 3. Non-Functional Requirements

Same format as above — use `NFR-01`, `NF1`, etc. Cover the qualities your goal demands (performance, reliability, safety, usability, security, maintainability).

| ID | Requirement | Priority | Pass/Fail Criterion |
|---|---|---|---|
| NFR-01 | The system shall <quality attribute>. | Must | <measurable threshold, e.g. MTBF ≥ 8000 h> |
| NFR-02 | The system shall <quality attribute>. | Should | <measurable threshold> |

---

## How this template maps to the standards

- The **SMART goal** in §1 is what Agent 4 (alignment) compares your requirements against. A vague goal produces vague alignment feedback.
- **Individual requirements** in §2 and §3 are reviewed against ISO/IEC/IEEE 29148 §5.2.4 (necessary, verifiable, unambiguous, complete, singular, feasible). The MoSCoW + pass/fail-criterion columns give the reviewer what it needs to score those.
- For more on formatting choices that affect extraction (TOC, glossary placement, table widths, spec size), see the [style guide](https://vmodel.eu/style-guide.html).