refactor(i18n): rename vorlagen/ -> templates/, *-vorlage -> *-template
Final German naming cleanup in dev-process: - vorlagen/ -> templates/ - vorlagen-word/ -> templates-word/ - tools/generate_word_vorlagen.sh -> tools/generate_word_templates.sh - *-vorlage.md / *-vorlage.docx -> *-template.md / *-template.docx - Review-Protokoll-vorlage.* -> Review-Minutes-template.* - angebot-vorlage.* -> quote-template.* - angebot-beispiel.html -> quote-example.html All references in README.md, toolstack/toolstack.md, build_word_template.py, and generate_word_templates.sh updated. The master Word style template (slohmaier-doc-template.docx) was already English-named. The dev-process repo is now fully English in both content and structure.
This commit is contained in:
Stefan Lohmaier
@@ -0,0 +1,76 @@
|
||||
# MISRA Deviation Permit
|
||||
|
||||
| Field | Value |
|
||||
|------------------|--------------------------------|
|
||||
| Permit ID | PER-[XXX] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Author | [Name] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Rule
|
||||
|
||||
| Field | Value |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Rule number | [e.g. Rule 11.3] |
|
||||
| Category | [Required / Advisory] |
|
||||
| Rule text | [Exact text of the MISRA rule] |
|
||||
| Standard | [MISRA C:2012 / MISRA C:2023] |
|
||||
|
||||
## 2. Scope
|
||||
|
||||
This permit applies to:
|
||||
|
||||
| Aspect | Scope |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Code area | [e.g. src/hal/*.c — all hardware-abstraction-layer files] |
|
||||
| Module / component| [e.g. HAL, CAN driver] |
|
||||
| Context | [e.g. register access to memory-mapped I/O] |
|
||||
|
||||
**Limitation:** This permit applies exclusively to the scope defined above. Deviations outside this scope require a separate deviation record or a separate permit.
|
||||
|
||||
## 3. Rationale
|
||||
|
||||
[Why is deviation from this rule acceptable in the defined context?]
|
||||
|
||||
Example: "Rule 11.3 forbids casts between pointer types. In the HAL, casts from `uint32_t*` to register structs are necessary because the hardware is accessed via memory-mapped I/O. The register addresses and layouts are defined in the datasheet and are static. A rule-compliant alternative does not exist."
|
||||
|
||||
**Rationale:** [Fill in here]
|
||||
|
||||
## 4. Risk assessment and alternatives
|
||||
|
||||
### Risk assessment
|
||||
|
||||
| Aspect | Assessment |
|
||||
|---------------------------|-----------------------------------------------|
|
||||
| Safety relevance | [None / Low / Medium / High] |
|
||||
| Fault potential | [Description] |
|
||||
| Mitigation | [e.g. unit tests verify correct register access, code review required for HAL code] |
|
||||
| Residual risk | [Assessment] |
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
| Alternative | Assessment |
|
||||
|--------------------------|------------------------------------------------|
|
||||
| [e.g. generic accessor functions] | [e.g. not practical due to hundreds of registers] |
|
||||
| [e.g. compiler extension] | [e.g. not portable] |
|
||||
|
||||
## 5. Approval
|
||||
|
||||
| Field | Value |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Approved by | [Name, role] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Evidence | [Gitea issue / wiki link / signature] |
|
||||
|
||||
## 6. Validity
|
||||
|
||||
| Field | Value |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Valid from | [YYYY-MM-DD] |
|
||||
| Valid until | [YYYY-MM-DD or "until revoked"] |
|
||||
| Revocation trigger | [e.g. re-evaluate if the target platform changes] |
|
||||
|
||||
---
|
||||
|
||||
*This permit is stored in the Gitea wiki under MISRA-Deviation-Permits and referenced from deviation records.*
|
||||
@@ -0,0 +1,70 @@
|
||||
# MISRA Deviation Record
|
||||
|
||||
| Field | Value |
|
||||
|------------------|--------------------------------|
|
||||
| Deviation ID | DEV-[XXX] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Author | [Name] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Rule
|
||||
|
||||
| Field | Value |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Rule number | [e.g. Rule 11.3] |
|
||||
| Category | [Required / Advisory / Mandatory] |
|
||||
| Rule text | [Exact text of the MISRA rule] |
|
||||
| Standard | [MISRA C:2012 / MISRA C:2023] |
|
||||
|
||||
## 2. Location
|
||||
|
||||
| Field | Value |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| File | [e.g. src/drivers/watchdog.c] |
|
||||
| Line(s) | [e.g. 142-145] |
|
||||
| Function | [e.g. wdg_set_timeout()] |
|
||||
| Git commit | [commit hash] |
|
||||
| Gitea reference | [PR link or issue link] |
|
||||
|
||||
## 3. Rationale
|
||||
|
||||
[Why is the deviation technically acceptable in this specific case?]
|
||||
|
||||
Possible rationales:
|
||||
- Hardware access requires type conversion
|
||||
- Compiler-specific behaviour is defined and tested
|
||||
- Alternative implementation would be disproportionately complex
|
||||
- Rule is not safety-relevant in this context
|
||||
|
||||
**Specific rationale:** [Fill in here]
|
||||
|
||||
## 4. Risk assessment
|
||||
|
||||
| Aspect | Assessment |
|
||||
|---------------------------|-----------------------------------------------|
|
||||
| Safety relevance | [None / Low / Medium / High] |
|
||||
| Fault potential | [Description of potential faults] |
|
||||
| Mitigation | [Which tests / measures cover the code] |
|
||||
| Residual risk | [Assessment of the residual risk] |
|
||||
|
||||
## 5. Reference to deviation permit
|
||||
|
||||
| Field | Value |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Permit exists | [Yes / No] |
|
||||
| Permit ID | [PER-XXX or "n/a"] |
|
||||
|
||||
If no permit exists: this deviation is a single-case approval.
|
||||
|
||||
## 6. Approval
|
||||
|
||||
| Field | Value |
|
||||
|-------------------|----------------------------------------------------|
|
||||
| Approved by | [Name, role] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Evidence | [Gitea PR approval / signature] |
|
||||
|
||||
---
|
||||
|
||||
*This record is kept in the repository under `docs/misra/` or as a Gitea issue.*
|
||||
@@ -0,0 +1,79 @@
|
||||
# Non-Conformity Report
|
||||
|
||||
| Field | Value |
|
||||
|------------------|--------------------------------|
|
||||
| NC ID | NC-[XXX] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Author | [Name] |
|
||||
| Status | [Open / In progress / Closed] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Reference
|
||||
|
||||
| Field | Value |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Kind | [Process deviation / Product deviation] |
|
||||
| Affected process | [e.g. SWE.4 Implementation, SUP.1 QA] |
|
||||
| Affected work product | [e.g. module XY, requirement SWR-042, test plan] |
|
||||
| Gitea reference | [Issue link / PR link / wiki page] |
|
||||
| Discovered in | [Review / audit / test / CI pipeline] |
|
||||
|
||||
## 2. Description of deviation
|
||||
|
||||
[What exactly deviates? Describe concretely. Reference the standard or process specification.]
|
||||
|
||||
## 3. Severity
|
||||
|
||||
| Severity | Definition |
|
||||
|--------------|------------------------------------------------------------------|
|
||||
| [ ] Critical | Safety-relevant or complete absence of a required work product |
|
||||
| [ ] Major | Significant deviation that affects quality or compliance |
|
||||
| [ ] Minor | Minor deviation, no direct effect on safety or function |
|
||||
|
||||
**Assigned severity:** [Critical / Major / Minor]
|
||||
|
||||
## 4. Root-cause analysis
|
||||
|
||||
[Why did the deviation occur? Possible categories:]
|
||||
- Process not known / not trained
|
||||
- Process not applicable / unrealistic
|
||||
- Oversight / human error
|
||||
- Tool error
|
||||
- Time pressure / lack of resources
|
||||
- Requirement unclear
|
||||
|
||||
**Description:** [Specific cause]
|
||||
|
||||
## 5. Corrective action
|
||||
|
||||
| Field | Value |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Action | [What is done to fix the deviation] |
|
||||
| Responsible | [Name] |
|
||||
| Due | [YYYY-MM-DD] |
|
||||
|
||||
### Preventive action (optional)
|
||||
|
||||
[What is done so that this type of deviation does not occur again?]
|
||||
|
||||
## 6. Effectiveness check
|
||||
|
||||
| Field | Value |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Verified by | [Name] |
|
||||
| Verification date | [YYYY-MM-DD] |
|
||||
| Action effective | [Yes / No] |
|
||||
| Evidence | [Gitea issue link / commit / review] |
|
||||
|
||||
## 7. Closure
|
||||
|
||||
| Field | Value |
|
||||
|-----------------------|-----------------------------------------------|
|
||||
| Status | [Closed / Reopened] |
|
||||
| Closed by | [Name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
|
||||
---
|
||||
|
||||
*This report is kept as a Gitea issue (label: `non-conformity`).*
|
||||
@@ -0,0 +1,92 @@
|
||||
# Project Initiation Document (PID)
|
||||
|
||||
| Field | Value |
|
||||
|-----------------|-------------------------------|
|
||||
| Project name | [Name] |
|
||||
| Client | [Company / contact person] |
|
||||
| Contractor | Stefan Lohmaier |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Approved] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Project goal
|
||||
|
||||
[What is to be achieved? One to three sentences.]
|
||||
|
||||
## 2. Scope
|
||||
|
||||
### In scope
|
||||
|
||||
- [Deliverable 1]
|
||||
- [Deliverable 2]
|
||||
|
||||
### Out of scope
|
||||
|
||||
- [What is explicitly not included]
|
||||
- [Boundary to other sub-projects]
|
||||
|
||||
## 3. Constraints
|
||||
|
||||
| Constraint | Description |
|
||||
|--------------------------|------------------------------------------|
|
||||
| Target platform | [e.g. ARM Cortex-R5, Renesas RH850] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
| Standards | [ASPICE 4.0, ISO 26262:2018] |
|
||||
| Programming language | [C / C++ / Rust] |
|
||||
| Coding standard | [MISRA C:2012 / MISRA C:2023] |
|
||||
| Runtime environment | [Bare-metal / AUTOSAR Classic / Linux] |
|
||||
| Customer requirements | [Specific customer requirements] |
|
||||
|
||||
## 4. Deliverables
|
||||
|
||||
| No. | Deliverable | Format | Due |
|
||||
|-----|-----------------------------------|---------------------|-------------|
|
||||
| 1 | Software Requirements Specification | Gitea Issues | [Date] |
|
||||
| 2 | Architecture documentation | Gitea Wiki | [Date] |
|
||||
| 3 | Source code | Git repository | [Date] |
|
||||
| 4 | Unit tests + coverage report | CI artifact | [Date] |
|
||||
| 5 | MISRA compliance report | CI artifact | [Date] |
|
||||
| 6 | Test report | Markdown / PDF | [Date] |
|
||||
| 7 | Release package | Git tag + artifacts | [Date] |
|
||||
|
||||
## 5. Milestones
|
||||
|
||||
| Milestone | Date | Criterion |
|
||||
|--------------------------|-------------|--------------------------------------------|
|
||||
| Project start | [Date] | PID approved |
|
||||
| Requirements complete | [Date] | All requirements reviewed |
|
||||
| Architecture complete | [Date] | Architecture reviewed and approved |
|
||||
| Code complete | [Date] | Implementation finished, tests green |
|
||||
| Verification complete | [Date] | Coverage targets met, MISRA compliant |
|
||||
| Release | [Date] | All exit criteria met |
|
||||
|
||||
## 6. Risks (initial)
|
||||
|
||||
| ID | Risk | Probability | Impact | Action |
|
||||
|------|----------------------------------|-------------|---------|---------------------------------|
|
||||
| R-01 | [Risk description] | [H/M/L] | [H/M/L] | [Mitigation] |
|
||||
| R-02 | [Risk description] | [H/M/L] | [H/M/L] | [Mitigation] |
|
||||
|
||||
## 7. Roles involved
|
||||
|
||||
| Role | Person / organisation | Responsibility |
|
||||
|--------------------------|------------------------|-----------------------------------|
|
||||
| Project manager | Stefan Lohmaier | Overall responsibility |
|
||||
| Software developer | Stefan Lohmaier | Implementation, unit tests |
|
||||
| QA responsible | [Name / external] | QA activities, audits |
|
||||
| Safety responsible | [Name / external] | ISO 26262 compliance |
|
||||
| Reviewer | [Name / external] | Code and document reviews |
|
||||
| Client | [Name] | Requirements, acceptance |
|
||||
|
||||
## 8. Approval
|
||||
|
||||
| Role | Name | Date | Signature / Gitea reference |
|
||||
|---------------------|---------------------|-------------|-------------------------------|
|
||||
| Contractor | Stefan Lohmaier | [Date] | |
|
||||
| Client | [Name] | [Date] | |
|
||||
|
||||
---
|
||||
|
||||
*Changes to this document are versioned in the Gitea wiki.*
|
||||
@@ -0,0 +1,75 @@
|
||||
# Project Management Plan (PM Plan)
|
||||
|
||||
| Field | Value |
|
||||
|-----------------|--------------------------------|
|
||||
| Project | [Project name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Released] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Project organisation
|
||||
|
||||
[Describe organisation, roles, escalation path. Distinct from the role section in the PID — here you go into more detail on day-to-day collaboration.]
|
||||
|
||||
## 2. Work packages
|
||||
|
||||
| WP-ID | Work package | Owner | Effort (PD) | Due | Status |
|
||||
|-------|------------------------|----------------|-------------|-----------|--------|
|
||||
| WP-01 | [name] | [Name] | [n] | [Date] | [open] |
|
||||
| WP-02 | [name] | [Name] | [n] | [Date] | [open] |
|
||||
|
||||
## 3. Schedule
|
||||
|
||||
| Phase | Start | End | Result |
|
||||
|--------------------------|-------------|-------------|-------------------------------|
|
||||
| Concept | [Date] | [Date] | PID released |
|
||||
| Requirements | [Date] | [Date] | SRS released |
|
||||
| Architecture | [Date] | [Date] | Architecture document |
|
||||
| Implementation | [Date] | [Date] | Code complete |
|
||||
| Verification | [Date] | [Date] | Test report |
|
||||
| Release | [Date] | [Date] | Release package |
|
||||
|
||||
## 4. Change management
|
||||
|
||||
- Changes go through change requests (CR)
|
||||
- CR ID: `CR-XXX`, tracked in Gitea Issues
|
||||
- For ASIL-relevant changes: re-run impacted reviews (architecture, code, tests)
|
||||
- Re-baselining via git tag (see CM Plan)
|
||||
|
||||
## 5. Communication
|
||||
|
||||
| Channel | Use | Frequency |
|
||||
|-----------------|--------------------------------------|-------------|
|
||||
| Gitea Issues | Tickets, bugs, change requests | as needed |
|
||||
| Gitea PRs | Reviews, approval, audit trail | per change |
|
||||
| Status report | Project status update | weekly |
|
||||
| Standup | Quick alignment | daily |
|
||||
| Review meeting | Architecture / design / code reviews | per CR |
|
||||
|
||||
## 6. Risk management
|
||||
|
||||
See `RM Plan` (separate document). Top-level summary here:
|
||||
|
||||
| ID | Risk | Status |
|
||||
|------|----------------------------------|-------------|
|
||||
| R-01 | [Top risk] | [Mitigated] |
|
||||
| R-02 | [Top risk] | [Open] |
|
||||
|
||||
## 7. Reporting
|
||||
|
||||
- **Weekly status:** email to client with progress + open items
|
||||
- **Audit report:** at project closure, PDF from Doorstop + Word plans
|
||||
- **CI artefacts:** updated on every push (coverage, MISRA, traceability)
|
||||
|
||||
## 8. Closure
|
||||
|
||||
The project is considered closed when:
|
||||
- All success criteria from the PID are met
|
||||
- A `v1.0.0` git tag is set
|
||||
- The release package has been delivered to the client and accepted
|
||||
|
||||
---
|
||||
|
||||
*Changes to this plan are versioned in the Gitea wiki.*
|
||||
@@ -0,0 +1,68 @@
|
||||
# Quality Assurance Plan (QA Plan)
|
||||
|
||||
| Field | Value |
|
||||
|-----------------|--------------------------------|
|
||||
| Project | [Project name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Released] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Quality goals
|
||||
|
||||
- [Goal 1, e.g. "100% MISRA Required compliance"]
|
||||
- [Goal 2, e.g. "Statement coverage ≥ 90% for ASIL-D"]
|
||||
- [Goal 3, e.g. "Zero critical static-analysis findings on release"]
|
||||
|
||||
## 2. Quality measures
|
||||
|
||||
| Measure | Tool / Method | Frequency | Owner |
|
||||
|--------------------------|------------------------------|------------------|----------|
|
||||
| Traceability check | `doorstop check` | every push | dev |
|
||||
| MISRA check | Cppcheck + MISRA addon | every push | dev |
|
||||
| Static analysis | Cppcheck, clang-tidy | every push | dev |
|
||||
| Unit tests | CppUTest | every push | dev |
|
||||
| Coverage | gcov / lcov | every push | dev |
|
||||
| Peer review | Gitea PRs | every change | reviewer |
|
||||
| Architecture review | Technical review | on changes | TL |
|
||||
|
||||
## 3. Review obligations
|
||||
|
||||
| Artefact | Review type | Min. approvers |
|
||||
|--------------------------------|---------------------|-----------------|
|
||||
| Requirements | Technical review | 1 |
|
||||
| Architecture element | Technical review | 2 |
|
||||
| Code (QM / ASIL-A/B) | Peer review | 1 |
|
||||
| Code (ASIL-C/D) | Technical review | 2 |
|
||||
| Plans and reports | Peer review | 1 |
|
||||
| MISRA deviation permit | Technical lead | 1 |
|
||||
|
||||
## 4. Non-conformity management
|
||||
|
||||
Deviations from plans or requirements are documented as a non-conformity (NC):
|
||||
|
||||
- Path: `docs/non-conformities/NC-XXX.docx`
|
||||
- Severity: Critical / Major / Minor
|
||||
- Corrective action and verification tracked
|
||||
- Closure criterion: corrective action verified
|
||||
|
||||
## 5. Audit preparation
|
||||
|
||||
Audit readiness is maintained continuously:
|
||||
|
||||
- Git history is the audit trail (no direct push to `main`)
|
||||
- Documents are versioned in the repo
|
||||
- Traceability matrices are generated on every CI run
|
||||
- MISRA records and deviation permits are stored under `misra/`
|
||||
- Test and coverage reports are stored as CI artefacts
|
||||
|
||||
## 6. Improvement measures
|
||||
|
||||
- Lessons-learned note at each sprint closure under `docs/lessons-learned/`
|
||||
- Quarterly retrospective with the team
|
||||
- Updates to this plan are versioned and reviewed
|
||||
|
||||
---
|
||||
|
||||
*Changes to this plan are versioned in the Gitea wiki.*
|
||||
@@ -0,0 +1,74 @@
|
||||
# Review Minutes
|
||||
|
||||
| Field | Value |
|
||||
|-------------------------|------------------------------------------|
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Review type | [Peer review / Technical review / Inspection] |
|
||||
| Moderator | [Name] |
|
||||
| Minute keeper | [Name] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Participants
|
||||
|
||||
| Name | Role | Present |
|
||||
|---------------------|--------------------------|----------|
|
||||
| [Name] | Moderator | Yes / No |
|
||||
| [Name] | Author | Yes / No |
|
||||
| [Name] | Reviewer | Yes / No |
|
||||
| [Name] | Reviewer | Yes / No |
|
||||
|
||||
## 2. Reviewed work product
|
||||
|
||||
| Field | Value |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Work product | [e.g. architecture documentation, module XY, requirements SWR-040 to SWR-060] |
|
||||
| Version / commit | [Version or git commit hash] |
|
||||
| Gitea reference | [PR link / wiki page / issue numbers] |
|
||||
|
||||
## 3. Review preparation
|
||||
|
||||
| Reviewer | Preparation time (h) | Preparation complete |
|
||||
|-------------------|-----------------------|----------------------------|
|
||||
| [Name] | [X] | Yes / No |
|
||||
| [Name] | [X] | Yes / No |
|
||||
|
||||
## 4. Findings
|
||||
|
||||
| ID | Description | Severity | Responsible | Due | Status |
|
||||
|------|---------------------------------|-------------------|----------------|-------------|-------------|
|
||||
| F-01 | [Finding description] | Critical / Major / Minor | [Name] | [Date] | Open |
|
||||
| F-02 | [Finding description] | Critical / Major / Minor | [Name] | [Date] | Open |
|
||||
| F-03 | [Finding description] | Critical / Major / Minor | [Name] | [Date] | Open |
|
||||
|
||||
### Severities
|
||||
|
||||
- **Critical:** Safety-relevant or functionally wrong. Must be fixed before release.
|
||||
- **Major:** Significant defect or gap. Must be fixed but may be scheduled.
|
||||
- **Minor:** Improvement suggestion, style, readability. Fix recommended.
|
||||
|
||||
## 5. Decision
|
||||
|
||||
| Decision |
|
||||
|-----------------------------------------------------------|
|
||||
| [ ] Approved |
|
||||
| [ ] Conditionally approved (after fixing Critical/Major findings) |
|
||||
| [ ] Not approved (re-review required) |
|
||||
|
||||
**Conditions for conditional approval:**
|
||||
[If applicable: which findings must be fixed, who verifies the fix]
|
||||
|
||||
## 6. Signatures / evidence
|
||||
|
||||
| Role | Name | Date | Evidence |
|
||||
|----------------------|---------------------|-------------|------------------------------|
|
||||
| Moderator | [Name] | [Date] | [Signature / Gitea PR approval] |
|
||||
| Reviewer 1 | [Name] | [Date] | [Signature / Gitea PR approval] |
|
||||
| Reviewer 2 | [Name] | [Date] | [Signature / Gitea PR approval] |
|
||||
| Author | [Name] | [Date] | |
|
||||
|
||||
**Gitea PR link:** [URL to the pull request, if applicable]
|
||||
|
||||
---
|
||||
|
||||
*These minutes are kept in the Gitea wiki under review-minutes/.*
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
active: true
|
||||
level: 1.0
|
||||
links:
|
||||
- SYS-XXX: [hash]
|
||||
---
|
||||
|
||||
# SA-XXX: [Element name]
|
||||
|
||||
> **System Architectural Design Element (ASPICE SYS.3).**
|
||||
> Describes a system architecture element and its mapping to system requirements.
|
||||
|
||||
| Field | Value |
|
||||
|----------|--------------------------------|
|
||||
| Project | [Project name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Released] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
| Author | [Name] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Responsibility
|
||||
|
||||
[What does this element do? One or two sentences. Its purpose in the overall system.]
|
||||
|
||||
## 2. System context
|
||||
|
||||
[PlantUML diagram: this element in relation to neighbouring systems / environment.]
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
!define COMPONENT(x) component "x" as x
|
||||
COMPONENT([Element])
|
||||
[Element] --> [Neighbour A] : interface X
|
||||
[Neighbour B] --> [Element] : interface Y
|
||||
@enduml
|
||||
```
|
||||
|
||||
## 3. Allocation
|
||||
|
||||
| Requirement | Allocated to | Notes |
|
||||
|---------------|------------------|------------------------------|
|
||||
| SYS-XXX | this element | [full / partial] |
|
||||
| SYS-YYY | this element | [Rationale] |
|
||||
|
||||
Allocation rule: every linked system requirement must be unambiguously mapped to HW, SW, or mechanics.
|
||||
|
||||
## 4. External interfaces
|
||||
|
||||
| Interface | Direction | Type | Notes |
|
||||
|---------------|---------------|-----------------------|-------------------------|
|
||||
| [Name] | in / out / io | [CAN / SPI / GPIO / ...] | [Protocol reference] |
|
||||
|
||||
## 5. Subcomponents / breakdown
|
||||
|
||||
[If this system element consists of subcomponents: short list with references to other SA or SWA elements.]
|
||||
|
||||
| Subcomponent | Realisation | Reference |
|
||||
|---------------|--------------------|-------------------|
|
||||
| [Name] | [HW / SW / mechanics] | SWA-XXX / SA-YYY |
|
||||
|
||||
## 6. Dynamic behaviour
|
||||
|
||||
[PlantUML sequence or state diagram for critical flows.]
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
actor User
|
||||
User -> [Element]: request
|
||||
[Element] -> [Neighbour]: forward
|
||||
[Neighbour] --> [Element]: response
|
||||
[Element] --> User: result
|
||||
@enduml
|
||||
```
|
||||
|
||||
## 7. Non-functional properties
|
||||
|
||||
| Aspect | Requirement / target value |
|
||||
|---------------------|------------------------------|
|
||||
| Worst-case timing | [e.g. < 10 ms reaction time] |
|
||||
| Memory footprint | [e.g. < 64 KB flash] |
|
||||
| Power draw | [e.g. < 200 mA at 12 V] |
|
||||
| Environment | [Temperature, EMC] |
|
||||
| Safety goal | [Reference to SG-XXX, if any] |
|
||||
|
||||
## 8. Design decisions
|
||||
|
||||
| Decision | Alternatives | Rationale |
|
||||
|--------------|--------------|-----------|
|
||||
| [What] | [What else was considered] | [Why this choice] |
|
||||
|
||||
## 9. Verification
|
||||
|
||||
| Requirement | Verification method | Test ID |
|
||||
|-------------|---------------------------|-------------------|
|
||||
| SYS-XXX | [Review / test / analysis] | TST-SYS-XXX |
|
||||
|
||||
Every system requirement listed in `links` must have at least one verification method.
|
||||
|
||||
---
|
||||
|
||||
*Changes to this architecture element go through a PR with at least 2 technical-review approvals (see SWE Plan).*
|
||||
@@ -0,0 +1,147 @@
|
||||
---
|
||||
active: true
|
||||
level: 1.0
|
||||
links:
|
||||
- SWE-XXX: [hash]
|
||||
---
|
||||
|
||||
# SWA-XXX: [Component name]
|
||||
|
||||
> **Software Architectural Design Element (ASPICE SWE.2).**
|
||||
> Describes a software component and its mapping to software requirements.
|
||||
|
||||
| Field | Value |
|
||||
|----------|--------------------------------|
|
||||
| Project | [Project name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Released] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
| Author | [Name] |
|
||||
| Parent | [SA-XXX, if applicable] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Responsibility
|
||||
|
||||
[One or two sentences: what does this component do? Where is the boundary to neighbouring components?]
|
||||
|
||||
## 2. Static view
|
||||
|
||||
### 2.1 Component diagram
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
package "[Component name]" {
|
||||
[Submodule A]
|
||||
[Submodule B]
|
||||
}
|
||||
[Submodule A] --> [Submodule B]
|
||||
[Component name] ..> [Neighbour component] : uses
|
||||
@enduml
|
||||
```
|
||||
|
||||
### 2.2 Embedded / used components
|
||||
|
||||
| Component | Reference | Use |
|
||||
|---------------|-----------|---------------------------|
|
||||
| [Name] | SWA-YYY | [for what] |
|
||||
|
||||
## 3. Interfaces
|
||||
|
||||
### 3.1 Provided interface
|
||||
|
||||
```c
|
||||
/**
|
||||
* @brief [Short description]
|
||||
* @param [name] [Meaning, value range]
|
||||
* @return [Status / value]
|
||||
* @pre [Precondition]
|
||||
* @post [Postcondition]
|
||||
*/
|
||||
Status component_init(const Config* cfg);
|
||||
```
|
||||
|
||||
| Function | Purpose | Pre-condition | Post-condition |
|
||||
|------------------|--------------------|-----------------------|------------------------|
|
||||
| component_init | Initialisation | cfg != NULL | Component ready |
|
||||
| component_send | Send data | initialised | Data in TX buffer |
|
||||
|
||||
### 3.2 Required interface
|
||||
|
||||
| Interface | Provided by | Purpose |
|
||||
|-------------------|--------------------|---------------------|
|
||||
| ILogger::log() | LoggerComponent | Diagnostics / tracing |
|
||||
| IClock::now() | ClockComponent | Timestamps |
|
||||
|
||||
## 4. Dynamic behaviour
|
||||
|
||||
### 4.1 Sequence diagram (critical flow)
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
participant App
|
||||
participant "[Component]" as C
|
||||
participant HW
|
||||
App -> C: init(cfg)
|
||||
C -> HW: configure
|
||||
HW --> C: ok
|
||||
C --> App: STATUS_OK
|
||||
@enduml
|
||||
```
|
||||
|
||||
### 4.2 State diagram (if applicable)
|
||||
|
||||
```plantuml
|
||||
@startuml
|
||||
[*] --> Uninitialized
|
||||
Uninitialized --> Ready : init()
|
||||
Ready --> Busy : send()
|
||||
Busy --> Ready : tx_done
|
||||
Ready --> Error : fault
|
||||
Error --> Ready : reset()
|
||||
@enduml
|
||||
```
|
||||
|
||||
## 5. Resource demand
|
||||
|
||||
| Resource | Worst case | Method of determination |
|
||||
|-------------------|--------------|------------------------------|
|
||||
| Stack | [e.g. 256 B] | [Measurement / static analysis] |
|
||||
| Heap | [e.g. 0 B] | [No heap use] |
|
||||
| Flash | [e.g. 4 KB] | [Linker map file] |
|
||||
| RAM (static) | [e.g. 128 B] | [Linker map file] |
|
||||
| CPU load | [e.g. < 1%] | [Measurement on target] |
|
||||
| Worst-case timing | [e.g. 200 us / call init()] | [HiL measurement] |
|
||||
|
||||
## 6. Failure behaviour
|
||||
|
||||
| Failure case | Detection | Reaction |
|
||||
|-----------------------|-------------------|---------------------------|
|
||||
| Invalid config | Parameter check | Status STATUS_EINVAL |
|
||||
| HW timeout | Timer | Retry, then STATUS_TIMEOUT |
|
||||
| Buffer full | Pre-write check | STATUS_NOSPACE |
|
||||
|
||||
## 7. Design decisions
|
||||
|
||||
| Decision | Alternative(s) | Rationale |
|
||||
|------------------------|------------------|----------------------------|
|
||||
| [e.g. static allocation] | [Heap] | [Deterministic, MISRA] |
|
||||
| [Locking strategy] | [Mutex / lock-free] | [Rationale] |
|
||||
|
||||
## 8. Mapping to requirements
|
||||
|
||||
| Requirement | How covered | Verification test |
|
||||
|---------------|-----------------------------------------------|----------------------------|
|
||||
| SWE-XXX | [which part of this component fulfils it] | TST-UNIT-XXX, TST-INT-YYY |
|
||||
| SWE-YYY | [...] | TST-UNIT-YYY |
|
||||
|
||||
Every SWE requirement listed in `links` must have an entry in this table.
|
||||
|
||||
## 9. Detailed design
|
||||
|
||||
Detailed design (ASPICE SWE.3) is maintained separately under `arch/swd/SWD-XXX.md` from ASIL-C upwards. For ASIL-A/B and QM, code plus header comments are sufficient.
|
||||
|
||||
---
|
||||
|
||||
*Changes to this architecture element go through a PR with at least 2 technical-review approvals (see SWE Plan).*
|
||||
@@ -0,0 +1,132 @@
|
||||
# Software Development Plan (SWE Plan)
|
||||
|
||||
| Field | Value |
|
||||
|------------------|--------------------------------|
|
||||
| Project | [Project name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Released] |
|
||||
| ASIL | [QM / A / B / C / D] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Development method
|
||||
|
||||
[Describe the approach: iterative, V-model aligned, or hybrid.]
|
||||
|
||||
The base structure follows the V-model (ISO 26262 Part 6):
|
||||
- Left side: requirements → architecture → detailed design → implementation
|
||||
- Right side: unit test → integration test → system test
|
||||
- Iterations within phases are possible
|
||||
|
||||
Changes are managed via change requests (see PM Plan).
|
||||
|
||||
## 2. Programming language and standards
|
||||
|
||||
| Aspect | Decision |
|
||||
|---------------------|-----------------------------------------------------|
|
||||
| Language | [C (C99/C11) / C++ (C++14/17) / Rust] |
|
||||
| Coding standard | [MISRA C:2012 / MISRA C:2023 / MISRA C++:2023] |
|
||||
| Project guidelines | [Reference to coding guidelines in the wiki] |
|
||||
| Naming convention | [e.g. snake_case for functions, UPPER_CASE for macros] |
|
||||
|
||||
### MISRA handling
|
||||
|
||||
- All Required and Mandatory rules are observed
|
||||
- Advisory rules: list of applied rules documented in the wiki
|
||||
- Deviations are documented per MISRA deviation record
|
||||
- Project-wide deviations are approved via MISRA deviation permit
|
||||
- MISRA check runs automatically in the CI pipeline
|
||||
|
||||
## 3. Build environment
|
||||
|
||||
| Component | Tool / Version |
|
||||
|--------------------|-----------------------------------------------------|
|
||||
| Build system | [CMake X.Y / SCons X.Y / Make] |
|
||||
| Compiler | [GCC ARM X.Y / Clang X.Y] |
|
||||
| Target platform | [e.g. ARM Cortex-R5, Cortex-M4] |
|
||||
| Host platform | [Linux x86_64 / macOS ARM64] |
|
||||
| CI runner | [Gitea Runner, Docker image: ...] |
|
||||
|
||||
The build environment is reproducible: either via a Docker image or via a documented toolchain installation.
|
||||
|
||||
## 4. Branching strategy
|
||||
|
||||
```
|
||||
main — stable, released state
|
||||
develop — current development state
|
||||
feature/SWE-XXX — feature branch per requirement
|
||||
bugfix/BUG-XXX — bug-fix branch
|
||||
release/vX.Y — release preparation
|
||||
hotfix/vX.Y.Z — critical fixes after release
|
||||
```
|
||||
|
||||
- Feature branches are taken off `develop`
|
||||
- Merge to `develop` only via PR with approval
|
||||
- `main` and `release/*` are protected (no direct push)
|
||||
- Branch name includes the issue number
|
||||
|
||||
Details: see `gitea-aspice-setup.md`.
|
||||
|
||||
## 5. Review obligations
|
||||
|
||||
| Artefact | Review type | Min. approvals |
|
||||
|-----------------------------|--------------------|-----------------|
|
||||
| Source code (PR) | Peer review | 1 |
|
||||
| Safety-relevant code | Technical review | 2 |
|
||||
| Architecture document | Technical review | 2 |
|
||||
| Requirements | Technical review | 1 |
|
||||
| Test cases | Peer review | 1 |
|
||||
|
||||
Every PR must be reviewed and approved before merge. Self-merges are not permitted (exception: 1-person project with documented self-review).
|
||||
|
||||
## 6. Definition of Done
|
||||
|
||||
A feature / requirement is "Done" when:
|
||||
|
||||
- [ ] Code is implemented and compiles without errors
|
||||
- [ ] MISRA check in CI is green (no new violations)
|
||||
- [ ] Static analysis (Cppcheck, clang-tidy) has no new findings
|
||||
- [ ] Unit tests are written and green
|
||||
- [ ] Coverage target is reached (see section 8)
|
||||
- [ ] PR is reviewed and approved
|
||||
- [ ] Requirement is linked to a test (traceability)
|
||||
- [ ] Documentation is updated (if affected)
|
||||
|
||||
## 7. Integration and test strategy
|
||||
|
||||
| Test level | Owner | Environment | Automation |
|
||||
|--------------------|----------------|---------------|------------------|
|
||||
| Unit test | Developer | host (x86) | CI pipeline |
|
||||
| Integration test | Developer | host / SiL | CI / manual |
|
||||
| System test | Test / QA | SiL / HiL | partial |
|
||||
| Acceptance test | Client | HiL / vehicle | manual |
|
||||
|
||||
- Unit tests run on the host platform (cross-compilation for x86 testing)
|
||||
- Integration tests verify module interaction
|
||||
- System tests verify against system requirements
|
||||
- HiL tests are provided by the client or jointly defined
|
||||
|
||||
## 8. Coverage targets
|
||||
|
||||
| ASIL | Statement coverage | Branch coverage | MC/DC |
|
||||
|------|--------------------|-----------------|----------|
|
||||
| QM | ≥ 80% recommended | — | — |
|
||||
| A | ≥ 80% | recommended | — |
|
||||
| B | ≥ 80% | ≥ 80% | — |
|
||||
| C | ≥ 90% | ≥ 80% | recommended |
|
||||
| D | ≥ 90% | ≥ 90% | ≥ 80% |
|
||||
|
||||
Concrete target values for this project:
|
||||
|
||||
| Metric | Target |
|
||||
|---------------------|------------|
|
||||
| Statement coverage | ≥ [X]% |
|
||||
| Branch coverage | ≥ [X]% |
|
||||
| MC/DC | ≥ [X]% (where applicable) |
|
||||
|
||||
Coverage is measured in CI and archived as an artefact. Deviations from the target are justified and documented in the QA report.
|
||||
|
||||
---
|
||||
|
||||
*Changes to this plan are versioned in the Gitea wiki.*
|
||||
@@ -0,0 +1,69 @@
|
||||
# Test Plan
|
||||
|
||||
| Field | Value |
|
||||
|-----------------|--------------------------------|
|
||||
| Project | [Project name] |
|
||||
| Date | [YYYY-MM-DD] |
|
||||
| Version | [1.0] |
|
||||
| Status | [Draft / Released] |
|
||||
|
||||
---
|
||||
|
||||
## 1. Test strategy
|
||||
|
||||
[Describe the approach: e.g. test-first, requirement-based, risk-based.]
|
||||
|
||||
Each requirement has at least one test (`@reqs` tag in the test). Coverage targets as in the SWE Plan section 8.
|
||||
|
||||
## 2. Test levels
|
||||
|
||||
| Level | Scope | Tool | Environment | Status |
|
||||
|---------------|----------------------|------------|-------------|---------------|
|
||||
| Unit | Functions / modules | [CppUTest] | host x86 | [planned] |
|
||||
| Integration | Module interaction | [CppUTest] | host / SiL | [planned] |
|
||||
| System | End-to-end | [manual] | SiL / HiL | [planned] |
|
||||
| Acceptance | Client acceptance | [manual] | HiL / vehicle | [planned] |
|
||||
|
||||
## 3. Test management
|
||||
|
||||
- Tests live in `tests/unit/`, `tests/integration/`, ...
|
||||
- Each test file carries `@reqs` tags pointing to the covered requirements
|
||||
- Tests run automatically in CI on every push
|
||||
- Coverage report is published as a CI artefact
|
||||
|
||||
## 4. Test selection per component
|
||||
|
||||
| Component | ASIL | Test file | Method |
|
||||
|--------------------|------|----------------------------------|---------------------------------|
|
||||
| [Component A] | [D] | tests/unit/test_componentA.c | Equivalence classes + boundary + MC/DC |
|
||||
| [Component B] | [B] | tests/unit/test_componentB.c | Equivalence classes + boundary |
|
||||
| [Component C] | [QM] | tests/unit/test_componentC.c | Equivalence classes |
|
||||
|
||||
## 5. Entry and exit criteria
|
||||
|
||||
**Entry to test execution:**
|
||||
- Code compiles
|
||||
- Doorstop check is green
|
||||
- Static analysis has no critical findings
|
||||
|
||||
**Exit:**
|
||||
- All tests green
|
||||
- Coverage target reached
|
||||
- Test report archived
|
||||
|
||||
## 6. Defect handling
|
||||
|
||||
- Test failure = blocking issue
|
||||
- Issue raised via Gitea Issues, referenced in the PR
|
||||
- Severity classification per QA Plan section 4
|
||||
|
||||
## 7. Reporting
|
||||
|
||||
Test reports are generated automatically:
|
||||
- Console output of the test framework (TAP / JUnit XML)
|
||||
- Coverage HTML from lcov
|
||||
- Both as CI artefacts under `tests/results/`
|
||||
|
||||
---
|
||||
|
||||
*Changes to this plan are versioned in the Gitea wiki.*
|
||||
@@ -0,0 +1,67 @@
|
||||
# Traceability Matrix
|
||||
|
||||
## Principle
|
||||
|
||||
The traceability matrix ensures end-to-end traceability from requirement to test:
|
||||
|
||||
```
|
||||
System requirement → Software requirement → Architecture element → Implementation (PR/file) → Test case → Test result
|
||||
```
|
||||
|
||||
Each level must be traceable in both directions:
|
||||
- **Forward:** requirement → has it been implemented and tested?
|
||||
- **Backward:** test case → which requirement does it verify?
|
||||
|
||||
## Table structure
|
||||
|
||||
| Sys-Req | SW-Req | ASIL | Arch element | Implementation | Test case | Test result | Status |
|
||||
|---------|---------|------|--------------|----------------------|-----------|---------------|--------------|
|
||||
| SYR-001 | SWR-010 | B | MOD-Timer | PR !23, timer.c | TC-010 | Pass (v1.2) | Complete |
|
||||
| SYR-001 | SWR-011 | B | MOD-Timer | PR !23, timer.c | TC-011 | Pass (v1.2) | Complete |
|
||||
| SYR-002 | SWR-020 | A | MOD-CAN | PR !31, can_driver.c | TC-020 | Pass (v1.2) | Complete |
|
||||
| SYR-003 | SWR-030 | B | MOD-Watchdog | — | — | — | Open |
|
||||
| — | SWR-040 | QM | MOD-Diag | PR !35, diag.c | TC-040 | Fail (v1.1) | Finding open |
|
||||
|
||||
## Column explanation
|
||||
|
||||
| Column | Description |
|
||||
|------------------|----------------------------------------------------------------|
|
||||
| Sys-Req | System requirement ID (Gitea issue with label `req::system`) |
|
||||
| SW-Req | Software requirement ID (Gitea issue with label `req::software`) |
|
||||
| ASIL | Assigned ASIL level |
|
||||
| Arch element | Architecture module or component |
|
||||
| Implementation | Pull request and/or file |
|
||||
| Test case | Test case ID (Gitea issue with label `test::*`) |
|
||||
| Test result | Pass/Fail with version/date |
|
||||
| Status | Complete / Open / Finding open |
|
||||
|
||||
## Gap analysis
|
||||
|
||||
The matrix makes gaps visible:
|
||||
|
||||
- **Requirement without test:** row without test-case entry → test missing
|
||||
- **Requirement without implementation:** row without PR → not implemented
|
||||
- **Test without requirement:** test case not assigned to any requirement → verify
|
||||
- **Fail without finding:** failed test without a documented finding → rework
|
||||
|
||||
## Automatic generation from Gitea
|
||||
|
||||
The matrix can be generated automatically from Gitea issues:
|
||||
|
||||
1. A Python script reads all issues with `req::*` labels via the Gitea API
|
||||
2. It follows issue links to architecture issues, PRs, and test issues
|
||||
3. It reads CI-pipeline results (JUnit XML) for test outcomes
|
||||
4. It produces the matrix as a Markdown table or CSV
|
||||
|
||||
**Precondition:** issues are correctly linked and labelled (see `gitea-aspice-setup.md`).
|
||||
|
||||
**Output formats:**
|
||||
- Markdown (for wiki / documentation)
|
||||
- CSV (for import into customer systems)
|
||||
- HTML (for reporting)
|
||||
|
||||
An example script lives at `tools/traceability-report.py` in the project repository.
|
||||
|
||||
---
|
||||
|
||||
*The current traceability matrix is updated on every release and stored in the wiki.*
|
||||
@@ -0,0 +1,144 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>Quote: Accessibility Audit – slohmaier Engineering</title>
|
||||
<style>
|
||||
:root {
|
||||
--text: #111417;
|
||||
--text-light: #525c69;
|
||||
--border: #d0d5dd;
|
||||
--bg: #ffffff;
|
||||
color-scheme: light dark;
|
||||
}
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--text: #f0f2f4;
|
||||
--text-light: #9ca3af;
|
||||
--border: #2a2e33;
|
||||
--bg: #111417;
|
||||
}
|
||||
.logo-light { display: none !important; }
|
||||
.logo-dark { display: block !important; }
|
||||
}
|
||||
@media (prefers-color-scheme: light) {
|
||||
.logo-dark { display: none !important; }
|
||||
.logo-light { display: block !important; }
|
||||
}
|
||||
body {
|
||||
font-family: Aptos, Inter, -apple-system, Helvetica Neue, Arial, sans-serif;
|
||||
font-size: 16px;
|
||||
line-height: 1.65;
|
||||
color: var(--text);
|
||||
background: var(--bg);
|
||||
max-width: 820px;
|
||||
margin: 0 auto;
|
||||
padding: 48px 40px;
|
||||
}
|
||||
.logo img { width: 280px; height: auto; margin-bottom: 32px; display: block; }
|
||||
h1 { font-size: 2rem; font-weight: 700; margin-top: 0; }
|
||||
h2 { font-size: 1.2rem; font-weight: 600; border-bottom: 1px solid var(--border); padding-bottom: 6px; margin-top: 40px; }
|
||||
h3 { font-size: 1rem; font-weight: 600; margin-top: 24px; }
|
||||
hr { border: none; border-top: 1px solid var(--border); margin: 32px 0; }
|
||||
table { width: 100%; border-collapse: collapse; font-size: 0.95rem; }
|
||||
th { text-align: left; border-bottom: 2px solid var(--border); padding: 8px 12px; font-weight: 600; }
|
||||
td { border-bottom: 1px solid var(--border); padding: 8px 12px; color: var(--text-light); }
|
||||
p { color: var(--text); }
|
||||
ul { color: var(--text-light); }
|
||||
strong { color: var(--text); }
|
||||
ol li { margin-bottom: 4px; }
|
||||
.meta { color: var(--text-light); font-size: 0.95rem; }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<div class="logo">
|
||||
<img src="https://slohmaier.com/branding/logo-doc-light.svg" alt="slohmaier" class="logo-light" />
|
||||
<img src="https://slohmaier.com/branding/logo-doc-dark.svg" alt="slohmaier" class="logo-dark" />
|
||||
</div>
|
||||
|
||||
<hr>
|
||||
|
||||
<h1>Quote: Accessibility Audit</h1>
|
||||
|
||||
<p class="meta">
|
||||
<strong>Date:</strong> 2026-04-03
|
||||
<strong>Version:</strong> 1.0<br>
|
||||
<strong>Project:</strong> Accessibility review – DemoApp v2.3<br>
|
||||
<strong>Client:</strong> Acme GmbH, Berlin
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<h2>Summary</h2>
|
||||
<p>This quote describes the scope and terms of an accessibility audit for the Windows desktop application DemoApp v2.3, focused on NVDA screen-reader compatibility.</p>
|
||||
|
||||
<h2>Content</h2>
|
||||
|
||||
<h3>1. Goal</h3>
|
||||
<p>Verify the application is operable with NVDA (Windows) and identify and document specific accessibility defects with recommended actions.</p>
|
||||
|
||||
<h3>2. Scope</h3>
|
||||
<ul>
|
||||
<li>Complete walk-through of all main dialogs and workflows with NVDA</li>
|
||||
<li>Check the UIA tree and correct roles / names / descriptions</li>
|
||||
<li>Documentation of all findings with reproduction steps and severity</li>
|
||||
<li>Prioritised recommendations</li>
|
||||
</ul>
|
||||
<p><strong>Not included:</strong> implementation of fixes, regression testing after fixes.</p>
|
||||
|
||||
<h3>3. Requirements</h3>
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>No.</th><th>Requirement</th><th>Priority</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>1</td><td>Full NVDA operability of all workflows</td><td>Must</td></tr>
|
||||
<tr><td>2</td><td>UIA-compliant naming of all controls</td><td>Must</td></tr>
|
||||
<tr><td>3</td><td>Keyboard navigation without mouse</td><td>Must</td></tr>
|
||||
<tr><td>4</td><td>Logical focus order</td><td>Should</td></tr>
|
||||
<tr><td>5</td><td>Contrast at least WCAG 2.1 AA</td><td>Should</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h3>4. Approach</h3>
|
||||
<ol>
|
||||
<li>Set up test environment (Windows 11, NVDA 2024.4)</li>
|
||||
<li>Manual test of all main dialogs and workflows</li>
|
||||
<li>UIA dump analysis with dumpUIA</li>
|
||||
<li>Documentation of findings</li>
|
||||
<li>Delivery of audit report as PDF</li>
|
||||
</ol>
|
||||
<p>Estimated duration: <strong>3 working days</strong></p>
|
||||
|
||||
<h3>5. Open points</h3>
|
||||
<ul>
|
||||
<li>Provision of a test build of the application</li>
|
||||
<li>Access to test data for representative workflows</li>
|
||||
</ul>
|
||||
|
||||
<h3>6. Deliverable</h3>
|
||||
<p>Audit report (PDF) with:</p>
|
||||
<ul>
|
||||
<li>Summary and overall assessment</li>
|
||||
<li>Full list of findings with severity, screenshot, reproduction steps</li>
|
||||
<li>Prioritised recommendations</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<h2>Terms</h2>
|
||||
<p>
|
||||
Day rate: on request<br>
|
||||
Payment due: 14 days after invoice<br>
|
||||
Valid until: 2026-04-17
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<p><strong>Stefan Lohmaier</strong><br>
|
||||
slohmaier.com · stefan@slohmaier.de</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,76 @@
|
||||
<!-- slohmaier Engineering – Quotation template -->
|
||||
<!-- Use: replace {{ ... }} placeholders, then export with pandoc -->
|
||||
<!-- Export: pandoc angebot.md -o angebot.html --standalone -->
|
||||
<!-- Example: angebot-beispiel.html -->
|
||||
|
||||
<div class="logo">
|
||||
<img src="https://slohmaier.com/branding/logo-doc-light.svg" alt="slohmaier" class="logo-light" />
|
||||
<img src="https://slohmaier.com/branding/logo-doc-dark.svg" alt="slohmaier" class="logo-dark" />
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# Quotation: {{ title }}
|
||||
|
||||
**Date:** {{ date }}
|
||||
**Version:** 1.0
|
||||
**Project:** {{ project name }}
|
||||
**Client:** {{ client }}
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
{{ Short description of what is being offered }}
|
||||
|
||||
---
|
||||
|
||||
## Content
|
||||
|
||||
### 1. Goal
|
||||
|
||||
{{ What is to be achieved? }}
|
||||
|
||||
### 2. Scope
|
||||
|
||||
{{ What is included? List of services }}
|
||||
|
||||
**Not included:** {{ What is explicitly excluded? }}
|
||||
|
||||
### 3. Requirements
|
||||
|
||||
| # | Requirement | Priority |
|
||||
|-----|-------------|------------|
|
||||
| 1 | ... | Must |
|
||||
| 2 | ... | Should |
|
||||
| 3 | ... | Could |
|
||||
|
||||
### 4. Approach
|
||||
|
||||
1. {{ Step 1 }}
|
||||
2. {{ Step 2 }}
|
||||
3. {{ Step 3 }}
|
||||
|
||||
Estimated duration: **{{ duration }}**
|
||||
|
||||
### 5. Open items
|
||||
|
||||
- [ ] {{ Precondition 1 }}
|
||||
- [ ] {{ Precondition 2 }}
|
||||
|
||||
### 6. Deliverable
|
||||
|
||||
{{ What is delivered at the end? Format, scope }}
|
||||
|
||||
---
|
||||
|
||||
**Terms**
|
||||
|
||||
Day rate: on request
|
||||
Payment terms: 14 days from invoice date
|
||||
Valid until: {{ date + 14 days }}
|
||||
|
||||
---
|
||||
|
||||
**Stefan Lohmaier**
|
||||
slohmaier.com · stefan@slohmaier.de
|
||||
Reference in New Issue
Block a user