@kudusov.takhir/ba-toolkit 3.5.0 → 3.7.0

package/skills/references/templates/nfr-template.md

@@ -1,97 +1,203 @@
 # Non-functional Requirements: [PROJECT_NAME]
 
+**Version:** 0.1
+**Status:** Draft
 **Domain:** [DOMAIN]
 **Date:** [DATE]
 **Slug:** [SLUG]
 **References:** `02_srs_[SLUG].md`, `00_principles_[SLUG].md`
+**Standard:** ISO/IEC 25010:2011 Software Quality Model
+
+> Every NFR maps to one of the 8 ISO 25010 characteristics: Functional Suitability, Performance Efficiency, Compatibility, Usability, Reliability, Security, Maintainability, Portability. Project-specific extensions (Compliance, Localisation, Observability) are marked as such and reference the parent ISO characteristic.
 
 ---
 
-## NFR-001: Performance
+## Performance Efficiency (ISO 25010)
 
-| Attribute | Requirement | Measurement Method |
-|-----------|------------|-------------------|
-| [Page / operation] | [Target, e.g. < 2s p95] | [Lighthouse / load test / APM] |
+### NFR-001: [Sub-characteristic — Time behaviour]
 
-**Rationale:** [Why this target matters for this project.]
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Time behaviour |
+| **Description** | [Page / operation / endpoint] response time target |
+| **Metric** | p95 latency in milliseconds |
+| **Acceptance threshold** | < 300ms p95, < 800ms p99 |
+| **Verification** | Load test (k6 / Locust) running [scenario], measured by APM (Datadog / New Relic / Grafana) |
+| **Source** | NFR-baseline from `00_principles_[SLUG].md` §5 / FR-NNN constraint / regulatory requirement |
+| **Rationale** | [Why this target — competitive benchmark, user-perception threshold, contractual SLA] |
+| **Priority** | Must |
+| **Linked FR** | FR-[NNN] |
 
 ---
 
-## NFR-002: Scalability
-
-| Attribute | Requirement | Measurement Method |
-|-----------|------------|-------------------|
-| Concurrent users | [N at peak] | [Load test scenario] |
-| Data volume | [N records, N GB] | [Capacity model] |
+### NFR-002: [Sub-characteristic — Capacity]
 
-**Rationale:** [Expected growth, peak events.]
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Capacity |
+| **Description** | Concurrent users / requests per second the system supports |
+| **Metric** | Concurrent users at peak; sustained RPS |
+| **Acceptance threshold** | [N concurrent users; N RPS sustained for 30 min without error rate > 0.1%] |
+| **Verification** | Load test scenario [name], pass / fail at the threshold |
+| **Source** | [Brief goal G-N or stakeholder] |
+| **Rationale** | [Expected growth, peak events — Black Friday, end-of-quarter, exam day] |
+| **Priority** | Should |
+| **Linked FR** | FR-[NNN] |
 
 ---
 
-## NFR-003: Availability & Reliability
+## Reliability (ISO 25010)
+
+### NFR-003: [Sub-characteristic — Availability]
+
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Availability |
+| **Description** | Service uptime target |
+| **Metric** | Uptime % over rolling 30-day window |
+| **Acceptance threshold** | 99.9% (8.76 hours downtime/year) |
+| **Verification** | Status page measurement, third-party uptime monitor |
+| **Source** | [SLA contract / regulatory requirement] |
+| **Rationale** | [Customer-facing SLA, internal commitment] |
+| **Priority** | Must |
+| **Linked FR** | All customer-facing FRs |
+
+### NFR-004: [Sub-characteristic — Recoverability]
+
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Recoverability |
+| **Description** | Disaster-recovery RTO / RPO |
+| **Metric** | RTO (Recovery Time Objective) in hours; RPO (Recovery Point Objective) in minutes |
+| **Acceptance threshold** | RTO < 4h, RPO < 15min |
+| **Verification** | Documented runbook, tested via DR drill quarterly |
+| **Source** | [Compliance / business continuity policy] |
+| **Rationale** | [Cost of downtime, regulatory requirement] |
+| **Priority** | Must |
 
-| Service | SLA | Maintenance Window |
-|---------|-----|--------------------|
-| [Service name] | 99.9% | [Sun 02:00–04:00 UTC] |
+---
 
-**RTO:** [Recovery Time Objective, e.g. < 4h]
-**RPO:** [Recovery Point Objective, e.g. < 1h]
+## Security (ISO 25010)
+
+### NFR-005: [Sub-characteristic — Confidentiality]
+
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Confidentiality |
+| **Description** | Encryption at rest and in transit |
+| **Metric** | Encryption algorithm + key length |
+| **Acceptance threshold** | TLS 1.2+ in transit; AES-256 at rest |
+| **Verification** | TLS scan, infrastructure config review, pen-test |
+| **Source** | [SOC 2 / PCI DSS / HIPAA / GDPR] |
+| **Rationale** | Regulatory baseline + customer trust |
+| **Priority** | Must |
+
+### NFR-006: [Sub-characteristic — Authenticity / Accountability]
+
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Authenticity, Accountability |
+| **Description** | Authentication strength, audit trail per user action |
+| **Metric** | MFA coverage, audit log completeness |
+| **Acceptance threshold** | MFA mandatory for admin role; every PII access logged with actor + timestamp |
+| **Verification** | Audit log inspection, security review |
+| **Source** | [SOC 2 CC6.1, regulatory requirement] |
+| **Rationale** | Compliance + incident-response capability |
+| **Priority** | Must |
 
 ---
 
-## NFR-004: Security
+## Compatibility (ISO 25010)
 
-| Control | Requirement |
-|---------|-------------|
-| Authentication | [e.g. JWT, OAuth 2.0, MFA for admin] |
-| Authorisation | [e.g. RBAC, row-level security] |
-| Data in transit | [TLS 1.2+] |
-| Data at rest | [AES-256] |
-| [Other control] | [requirement] |
+### NFR-007: [Sub-characteristic — Interoperability]
 
-**Compliance standard:** [PCI DSS / HIPAA / GDPR / none]
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Interoperability |
+| **Description** | Data-exchange formats with external systems |
+| **Metric** | Supported formats |
+| **Acceptance threshold** | JSON over REST + CSV export + webhook OUT |
+| **Verification** | Integration tests with each external system |
+| **Source** | [Stakeholder name / partner contract] |
+| **Rationale** | [Why these formats — partner constraints] |
+| **Priority** | Must |
 
 ---
 
-## NFR-005: Maintainability
+## Usability (ISO 25010)
 
-| Attribute | Requirement |
-|-----------|-------------|
-| Code coverage | [≥ 80% unit test coverage] |
-| Deployment | [CI/CD, zero-downtime deployments] |
-| Logging | [Structured JSON logs, retained N days] |
-| Alerting | [P1 alert → on-call within 5 min] |
+### NFR-008: [Sub-characteristic — Accessibility]
+
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Accessibility (Usability sub-characteristic in ISO 25010) |
+| **Description** | WCAG conformance level |
+| **Metric** | WCAG 2.1 conformance level |
+| **Acceptance threshold** | WCAG 2.1 AA on all customer-facing surfaces |
+| **Verification** | Automated (axe-core) + manual testing with NVDA, JAWS, VoiceOver |
+| **Source** | [Section 508 / EN 301 549 / domain reference] |
+| **Rationale** | Legal requirement (EU public sector, US federal) + customer base inclusion |
+| **Priority** | Must |
 
 ---
 
-## NFR-006: Usability & Accessibility
+## Maintainability (ISO 25010)
+
+### NFR-009: [Sub-characteristic — Testability]
 
-| Attribute | Requirement |
-|-----------|-------------|
-| Accessibility | [WCAG 2.1 AA] |
-| Browser support | [Chrome, Safari, Firefox — latest 2 versions] |
-| Mobile | [Responsive, iOS 15+, Android 10+] |
-| Language | [EN / RU / other] |
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Testability |
+| **Description** | Automated test coverage target |
+| **Metric** | Unit + integration test coverage % |
+| **Acceptance threshold** | ≥ 80% line coverage on core domain modules |
+| **Verification** | CI report on every PR |
+| **Source** | [Internal engineering standard] |
+| **Rationale** | Catch regressions, support refactoring |
+| **Priority** | Should |
 
 ---
 
-## NFR-007: [Additional Category]
+## Portability (ISO 25010)
 
-| Attribute | Requirement | Measurement Method |
-|-----------|------------|-------------------|
-| [attribute] | [requirement] | [method] |
+### NFR-010: [Sub-characteristic — Adaptability]
 
-<!-- Add or remove NFR sections based on project needs. Numbering: NFR-001, NFR-002, ... -->
+| Field | Value |
+|-------|-------|
+| **Sub-characteristic** | Adaptability |
+| **Description** | Browser / OS / device support matrix |
+| **Metric** | Supported browser × OS × device combinations |
+| **Acceptance threshold** | Latest 2 major versions of Chrome, Safari, Firefox, Edge; iOS 15+, Android 10+ |
+| **Verification** | Cross-browser test suite |
+| **Source** | [User analytics on existing audience] |
+| **Rationale** | Coverage of 95%+ of expected user base |
+| **Priority** | Should |
+
+<!-- Add NFR sections as needed. Every NFR maps to an ISO 25010 characteristic. -->
 
 ---
 
-## Priority Summary
+## FR → NFR Coverage Matrix
+
+Forward traceability from each Functional Requirement in `02_srs_[SLUG].md` §3 to the NFRs that govern its quality. A Must-priority FR with no linked NFR is flagged — every customer-facing Must FR should have at least one Performance, Reliability, or Security NFR attached.
+
+| FR ID | FR Title | Linked NFRs | Coverage Status |
+|-------|----------|-------------|-----------------|
+| FR-001 | [title] | NFR-001, NFR-003, NFR-005 | ✓ |
+| FR-002 | [title] | NFR-001, NFR-005 | ✓ |
+| FR-003 | [title] | (uncovered) | ✗ |
+
+---
 
-| ID | Category | Priority |
-|----|----------|---------|
-| NFR-001 | Performance | Must |
-| NFR-002 | Scalability | Should |
-| NFR-003 | Availability | Must |
-| NFR-004 | Security | Must |
-| NFR-005 | Maintainability | Should |
-| NFR-006 | Usability | Should |
+## Priority Summary by ISO 25010 Characteristic
+
+| ISO 25010 Characteristic | NFRs | Must | Should | Could |
+|--------------------------|------|------|--------|-------|
+| Performance Efficiency | NFR-001, NFR-002 | 1 | 1 | 0 |
+| Reliability | NFR-003, NFR-004 | 2 | 0 | 0 |
+| Security | NFR-005, NFR-006 | 2 | 0 | 0 |
+| Compatibility | NFR-007 | 1 | 0 | 0 |
+| Usability | NFR-008 | 1 | 0 | 0 |
+| Maintainability | NFR-009 | 0 | 1 | 0 |
+| Portability | NFR-010 | 0 | 1 | 0 |
+| Functional Suitability | (covered by FRs) | — | — | — |

package/skills/references/templates/risk-template.md

@@ -1,188 +1,89 @@
-# Risk Register: {PROJECT_NAME}
+# Risk Register: [PROJECT_NAME]
 
-**Domain:** {DOMAIN}
-**Date:** {DATE}
-**Slug:** {SLUG}
-**Sources:** {list of artifacts scanned}
+**Version:** 0.1
+**Status:** Draft
+**Domain:** [DOMAIN]
+**Date:** [DATE]
+**Slug:** [SLUG]
+**Risk tolerance:** Low / Medium / High
+**Standard:** ISO 31000 + PMI PMBOK 7
+**Sources:** [list of artifact files scanned]
 
 ---
 
 ## Summary
 
 | Priority | Count |
-|---------|-------|
-| 🔴 Critical | 1 |
-| 🟡 High | 2 |
-| 🟢 Medium | 3 |
-| ⚪ Low | 1 |
-| **Total** | **7** |
+|----------|-------|
+| 🔴 Critical | [N] |
+| 🟡 High | [N] |
+| 🟢 Medium | [N] |
+| ⚪ Low | [N] |
+| **Total** | **[N]** |
 
 ---
 
 ## Risk Register
 
-| ID | Title | Category | Probability | Impact | Score | Priority | Status |
-|----|-------|----------|:-----------:|:------:|:-----:|---------|--------|
-| RISK-01 | Third-party data source rate limits unclear | External | 4 | 5 | 20 | 🔴 Critical | Open |
-| RISK-02 | GDPR data-processing agreement unsigned | Compliance | 3 | 4 | 12 | 🟡 High | Open |
-| RISK-03 | Columnar query performance under concurrent load unproven | Technical | 3 | 3 | 9 | 🟡 High | Open |
-| RISK-04 | Scope creep from stakeholder wish list | Business | 3 | 2 | 6 | 🟢 Medium | Open |
-| RISK-05 | OIDC / SSO library breaking changes | External | 2 | 3 | 6 | 🟢 Medium | Open |
-| RISK-06 | Data model changes after /datadict | Technical | 2 | 3 | 6 | 🟢 Medium | Open |
-| RISK-07 | Development team unfamiliar with analytics domain | Business | 2 | 1 | 2 | ⚪ Low | Open |
+| ID | Title | Category | P | I | Score | V | Priority | Treatment | Owner | Review | Status |
+|----|-------|----------|:-:|:-:|:-----:|:-:|----------|-----------|-------|--------|--------|
+| RISK-01 | [Short title] | Technical / Business / Compliance / External | 4 | 5 | 20 | Days | 🔴 Critical | Reduce | [Owner] | Monthly | Open |
+| RISK-02 | [Short title] | [Category] | [1–5] | [1–5] | [P×I] | [Velocity] | [Priority] | [Avoid / Reduce / Transfer / Accept] | [Owner] | [Cadence] | Open / In Progress / Closed |
 
----
-
-## Risk Details
-
-### RISK-01 — Third-party data source rate limits unclear
-
-**Category:** External
-**Probability:** 4 / 5 — Likely
-**Impact:** 5 / 5 — Critical
-**Score:** 20 🔴 Critical
-**Status:** Open
-**Source:** `07a_research_{slug}.md`
-
-**Description:**
-The product depends on timely event delivery from third-party integrations (Segment and warehouse connectors). The published rate limits do not guarantee sustained throughput at the projected MVP event volume. If a critical integration is rate-limited or breaks its contract, dashboards will show stale or incomplete data and user trust erodes quickly.
-
-**Mitigation:**
-Run a sustained-throughput test against each integration in sprint 0. Negotiate higher quotas with the providers before launch. Add per-source ingestion lag as a monitored NFR metric with an alert threshold.
-
-**Contingency:**
-Enable an ingestion backpressure queue and surface a workspace-level banner when a source is lagging more than 5 minutes behind real-time. Prioritise critical event streams over low-value ones until the lag recovers.
-
-**Owner:** Tech Lead
+> Columns: P = Probability (1–5), I = Impact (1–5), Score = P × I, V = Velocity (Years / Months / Weeks / Days / Immediate). Treatment: Avoid / Reduce / Transfer / Accept. Review: Monthly / Quarterly / Ad hoc.
 
 ---
 
-### RISK-02 — GDPR data-processing agreement unsigned
-
-**Category:** Compliance
-**Probability:** 3 / 5 — Possible
-**Impact:** 4 / 5 — Major
-**Score:** 12 🟡 High
-**Status:** Open
-**Source:** `01_brief_{slug}.md`
-
-**Description:**
-The product collects first-party user-behavioural events from EU workspaces. The Brief listed the GDPR data-processing agreement (DPA) with the selected cloud provider as an assumption. If the DPA is delayed or blocked by legal review, the EU launch date will slip regardless of development readiness.
-
-**Mitigation:**
-Engage legal counsel early to track DPA status. Decouple development milestones from the legal timeline so that technical readiness does not block on paperwork. Draft the workspace-level privacy controls (PII redaction, data residency) independently of the final DPA text.
-
-**Contingency:**
-Launch in non-EU regions first (US, CA, APAC) while the EU DPA is pending. Gate EU workspace signups behind a feature flag tied to DPA status.
-
-**Owner:** Product Manager
-
----
-
-### RISK-03 — Columnar query performance under concurrent load unproven
-
-**Category:** Technical
-**Probability:** 3 / 5 — Possible
-**Impact:** 3 / 5 — Moderate
-**Score:** 9 🟡 High
-**Status:** Open
-**Source:** `07a_research_{slug}.md`
-
-**Description:**
-The ADR for the analytics query layer chose ClickHouse as the primary store. This setup has not been load-tested for the projected 200 concurrent dashboard viewers reading against a 10 M-event dataset. If query throughput assumptions are wrong, dashboards will exceed the 500 ms p95 NFR target and degrade UX.
-
-**Mitigation:**
-Run a load-test spike in the first development sprint against the reference dataset. Define a caching fallback (5-minute materialised query cache) if raw query throughput does not meet targets.
-
-**Contingency:**
-Enable the query cache globally and mark cached dashboards with a "last refreshed" timestamp. Communicate the change as a phased rollout feature.
-
-**Owner:** Tech Lead
-
----
-
-### RISK-04 — Scope creep from stakeholder wish list
-
-**Category:** Business
-**Probability:** 3 / 5 — Possible
-**Impact:** 2 / 5 — Minor
-**Score:** 6 🟢 Medium
-**Status:** Open
-**Source:** `01_brief_{slug}.md`
-
-**Description:**
-Several features were marked out of scope during the Brief interview but stakeholders indicated they "might be needed later." Without a change control process, these may be re-introduced mid-development, inflating the MVP scope.
-
-**Mitigation:**
-Establish a formal change request process referenced in the Handoff document. All scope additions must go through `/stories` and be re-estimated.
-
-**Contingency:**
-Freeze scope at the start of each sprint. Defer any mid-sprint scope additions to the next sprint backlog.
-
-**Owner:** Product Manager
-
----
-
-### RISK-05 — OIDC / SSO library breaking changes
-
-**Category:** External
-**Probability:** 2 / 5 — Unlikely
-**Impact:** 3 / 5 — Moderate
-**Score:** 6 🟢 Medium
-**Status:** Open
-**Source:** `07a_research_{slug}.md`
-
-**Description:**
-The product uses a third-party OIDC / SAML library for workspace SSO. Similar libraries have released breaking changes in previous majors without long deprecation windows. If the library releases a breaking change after development, sign-up and SSO flows may require rework.
-
-**Mitigation:**
-Pin the library version used in development. Monitor the library changelog and security advisories. Abstract SSO calls behind a thin adapter layer so a future swap to a different provider is isolated to one module.
-
-**Contingency:**
-Allocate a 3-day buffer in the release plan for library compatibility fixes.
-
-**Owner:** Frontend Lead
-
----
-
-### RISK-06 — Data model changes after /datadict
+## Risk Details
 
-**Category:** Technical
-**Probability:** 2 / 5 — Unlikely
-**Impact:** 3 / 5 — Moderate
-**Score:** 6 🟢 Medium
-**Status:** Open
-**Source:** `07_datadict_{slug}.md`
+### RISK-01 — [Short title]
+
+| Field | Value |
+|-------|-------|
+| **Category** | Technical / Business / Compliance / External |
+| **Probability** | [1–5] — [Very unlikely / Unlikely / Possible / Likely / Very likely] |
+| **Impact** | [1–5] — [Negligible / Minor / Moderate / Major / Critical] |
+| **Score** | [P × I] [🔴/🟡/🟢/⚪ priority] |
+| **Velocity** | [Years / Months / Weeks / Days / Immediate] — [reaction-time implication] |
+| **Treatment strategy** | Avoid / Reduce / Transfer / Accept |
+| **Status** | Open / In Progress / Closed |
+| **Source** | [artifact file + section] |
+| **Owner** | [Single accountable role — e.g. Tech Lead, Product Manager, Compliance Officer] |
+| **Review cadence** | Monthly / Quarterly / Ad hoc |
 
 **Description:**
-The Data Dictionary was finalised before the API Contract was fully detailed. Late-stage entity or field changes discovered during API design may require cascading updates across the SRS, Stories, and AC artifacts.
+[Full description of the risk and the conditions under which it materialises. State the condition and the consequence — "If X happens, then Y will occur."]
 
-**Mitigation:**
-Run `/trace` after `/apicontract` to detect any new cross-artifact inconsistencies. Address CRITICAL gaps before handoff.
+**Mitigation:** *(actions taken before the risk materialises — Reduce strategy)*
+[Steps to lower the probability or impact. Required for all Reduce-strategy risks. Optional for Avoid (mitigation = the avoidance action itself), Transfer (mitigation = the transfer mechanism), and Accept (mitigation = N/A by definition).]
 
-**Contingency:**
-Use `/revise` on affected artifacts to propagate changes. Document the delta in the Handoff open items list.
-
-**Owner:** Business Analyst
+**Contingency:** *(actions taken after the risk materialises despite mitigation)*
+[Steps to take if the risk fires anyway. Required for High and Critical risks regardless of treatment strategy.]
 
 ---
 
-### RISK-07 — Development team unfamiliar with analytics domain
-
-**Category:** Business
-**Probability:** 2 / 5 — Unlikely
-**Impact:** 1 / 5 — Negligible
-**Score:** 2 ⚪ Low
-**Status:** Open
-**Source:** `01_brief_{slug}.md`
+### RISK-02 — [Short title]
+
+| Field | Value |
+|-------|-------|
+| **Category** | [Category] |
+| **Probability** | [1–5] |
+| **Impact** | [1–5] |
+| **Score** | [P × I] |
+| **Velocity** | [Velocity] |
+| **Treatment strategy** | [Strategy] |
+| **Status** | Open |
+| **Source** | [artifact + section] |
+| **Owner** | [Owner] |
+| **Review cadence** | [Cadence] |
 
 **Description:**
-The engineering team has limited prior experience with columnar analytics storage. Domain-specific concepts (event schemas, funnel aggregation, cohort joins) may be misunderstood during implementation, leading to query correctness bugs on edge cases.
+[Description.]
 
 **Mitigation:**
-Include a domain onboarding session as part of sprint 0. Reference the SaaS domain glossary in the Handoff document.
+[Mitigation steps.]
 
 **Contingency:**
-Schedule a BA review checkpoint after the first feature is implemented end-to-end.
+[Contingency steps.]
 
-**Owner:** Product Manager
+<!-- Repeat RISK block for each risk. Numbering: RISK-01, RISK-02, ... -->

package/skills/references/templates/scenarios-template.md

@@ -1,9 +1,11 @@
 # Validation Scenarios: [PROJECT_NAME]
 
+**Version:** 0.1
+**Status:** Draft
 **Domain:** [DOMAIN]
 **Date:** [DATE]
 **Slug:** [SLUG]
-**References:** `03_stories_[SLUG].md`, `05_ac_[SLUG].md`, `09_wireframes_[SLUG].md`, `08_apicontract_[SLUG].md`
+**References:** `02_srs_[SLUG].md`, `03_stories_[SLUG].md`, `05_ac_[SLUG].md`, `06_nfr_[SLUG].md`, `08_apicontract_[SLUG].md`, `09_wireframes_[SLUG].md`
 
 ---
 
@@ -19,13 +21,17 @@
 
 ## SC-001: [Scenario Title]
 
-**Persona:** [Name and role — e.g. "Alex, a returning customer"]
+**Persona:** [Name and role — e.g. "Alex, a returning customer in DE who buys 4–6 times per year"]
 **Type:** Happy path | Negative | Edge case | Performance | Security
 **Priority:** P1 (critical) | P2 (important) | P3 (nice to have)
+**Frequency:** [How often this scenario runs in production — "every login", "once per month per user", "twice per year per admin"]
+**Stakes:** [Cost of failure — "data loss", "lost revenue ~€X per failed run", "regulatory breach", "reputation"]
 **Entry point:** [Where the scenario starts — e.g. "Home screen, not logged in"]
 **Platform:** Web | iOS | Android | API
-**Linked Stories:** US-[NNN], US-[NNN]
-**Linked AC:** US-[NNN] Scenario [N]
+**Source — Linked Stories:** US-[NNN], US-[NNN]
+**Source — Linked FR:** FR-[NNN]
+**Source — Linked NFR:** NFR-[NNN]  *(if scenario validates a quality attribute)*
+**Linked AC:** AC-[NNN]-[NN], AC-[NNN]-[NN]
 
 ### Steps
 
@@ -82,12 +88,16 @@
 
 | Artifact | Covered | Not Covered |
 |---------|---------|------------|
-| User Stories | [N] / [Total] | US-[NNN], … |
-| Acceptance Criteria Scenarios | [N] / [Total] | |
+| User Stories (Must) | [N] / [Total] | US-[NNN], … |
+| Functional Requirements (Must) | [N] / [Total] | FR-[NNN], … |
+| Non-functional Requirements | [N] / [Total] | NFR-[NNN], … |
+| Acceptance Criteria | [N] / [Total] | AC-[NNN]-[NN], … |
 | API Endpoints | [N] / [Total] | `[endpoint]`, … |
 | Wireframe screens | [N] / [Total] | WF-[NNN], … |
 
 **Happy path scenarios:** [N]
 **Negative scenarios:** [N]
 **Edge case scenarios:** [N]
+**Performance scenarios:** [N]
+**Security scenarios:** [N]
 **Total scenarios:** [N]