zwitschi
77e43a6a38
- Created .gitignore to exclude unnecessary files - Added README.md with project description and core features - Introduced CONTRIBUTING.md for development guidelines - Established documentation files for architecture, quality requirements, and technical risks
143 lines
5.3 KiB
Markdown
143 lines
5.3 KiB
Markdown
# Quality Requirements
|
||
|
||
Content
|
||
|
||
This section contains all relevant quality requirements.
|
||
|
||
The most important of these requirements have already been described in
|
||
section 1.2. (quality goals), therefore they should only be referenced
|
||
here. In this section 10 you should also capture quality requirements
|
||
with lesser importance, which will not create high risks when they are
|
||
not fully achieved (but might be _nice-to-have_).
|
||
|
||
Motivation
|
||
|
||
Since quality requirements will have a lot of influence on architectural
|
||
decisions you should know what qualities are really important for your
|
||
stakeholders, in a specific and measurable way.
|
||
|
||
Further Information
|
||
|
||
- See [Quality Requirements](10_quality_requirements.md) in the
|
||
arc42 documentation.
|
||
|
||
- See the extensive [Q42 quality model on
|
||
<https://quality.arc42.org>](https://quality.arc42.org).
|
||
|
||
## Quality Requirements Overview
|
||
|
||
Content
|
||
|
||
An overview or summary of quality requirements.
|
||
|
||
Motivation
|
||
|
||
Often we encounter dozens (or even hundreds) of detailed quality
|
||
requirements. In this overview section you should try to summarize, e.g.
|
||
by describing categories or topics (as suggested by [ISO
|
||
25010:2023](https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-2:v1:en)
|
||
or [Q42](https://quality.arc42.org))
|
||
|
||
If these summary descriptions are already precise, specific enough and
|
||
measurable, you may skip section 10.2.
|
||
|
||
Form
|
||
|
||
Use a simple table in which each line contains a category or topic and a
|
||
short description of the quality requirement. Alternatively, you may use
|
||
a mindmap to structure these quality requirements. In literature, the
|
||
idea of a _quality attribute tree_ has also been described, which puts
|
||
the generic term "quality" as the root and uses a tree-like refinement
|
||
of the term "quality". \[Bass+21\] introduced the term "Quality
|
||
Attribute Utility Tree" for this purpose.
|
||
|
||
## Quality Scenarios
|
||
|
||
Content
|
||
|
||
Quality scenarios make quality requirements concrete and allow to decide
|
||
whether they are fulfilled (in the sense of acceptance criteria). Ensure
|
||
that your scenarios are specific and measurable.
|
||
|
||
Two kinds of scenarios are especially useful:
|
||
|
||
- _Usage scenarios_ (also called application scenarios or use case
|
||
scenarios) describe the system’s runtime reaction to a certain
|
||
stimulus. This also includes scenarios that describe the system’s
|
||
efficiency or performance. Example: The system reacts to a user’s
|
||
request within one second.
|
||
|
||
- _Change scenarios_ describe the desired effect of a modification or
|
||
extension of the system or of its immediate environment. Example:
|
||
Additional functionality is implemented or requirements for a quality
|
||
attribute change, and the effort or duration of the change is
|
||
measured.
|
||
|
||
Form
|
||
|
||
Typical information for detailed scenarios include the following:
|
||
|
||
In short form (favoured in the Q42 model):
|
||
|
||
- **Context/Background**: What kind of system or component, what is the
|
||
envirionment or situation?
|
||
|
||
- **Source/Stimulus**: Who or what initiates or triggers a behaviour,
|
||
reaction or action.
|
||
|
||
- **Metric/Acceptance Criteria**: A response including a _measure_ or
|
||
_metric_
|
||
|
||
The long form of scenarios (favoured by the SEI and \[Bass+21\]) is more
|
||
detailed and includes the following information:
|
||
|
||
- **Scenario ID**: A unique identifier for the scenario.
|
||
|
||
- **Scenario Name**: A short, descriptive name for the scenario.
|
||
|
||
- **Source**: The entity (user, system, or event) that initiates the
|
||
scenario.
|
||
|
||
- **Stimulus**: The triggering event or condition the system must
|
||
address.
|
||
|
||
- **Environment**: The operational context or condition under which the
|
||
system experiences the stimulus.
|
||
|
||
- **Artifact**: The building-blocks or other elements of the system
|
||
affected by the stimulus.
|
||
|
||
- **Response**: The outcome or behavior the system exhibits in reaction
|
||
to the stimulus.
|
||
|
||
- **Response Measure**: The criteria or metric by which the system’s
|
||
response is evaluated.
|
||
|
||
Examples
|
||
|
||
See [the Q42 quality model website](https://quality.arc42.org) for
|
||
detailed examples of quality requirements.
|
||
|
||
Further Information
|
||
|
||
- Len Bass, Paul Clements, Rick Kazman: "Software Architecture in
|
||
Practice", 4th Edition, Addison-Wesley, 2021.
|
||
|
||
## Project-Specific Scenarios
|
||
|
||
| Quality | Scenario | Priority | Current Gap |
|
||
| ---------------- | --------------------------------------------------- | -------- | ----------------------------------------- |
|
||
| Availability | Bot must handle 100+ concurrent users during events | High | Not yet load-tested |
|
||
| Responsiveness | Slash commands respond within 2s | High | Baseline OK; need perf testing under load |
|
||
| Data consistency | Mileage not lost on crash or restart | High | Write-ahead logging not yet implemented |
|
||
| Security | No token leakage via logs or error messages | Critical | Pass — tokens env-only |
|
||
| Extensibility | Add new content source in ≤2 days work | Medium | Adapter pattern defined, not yet coded |
|
||
|
||
## Nice-to-Have
|
||
|
||
| Quality | Scenario |
|
||
| ------------------ | -------------------------------------------- |
|
||
| Localization | Embeds and messages in multiple languages |
|
||
| Accessibility | Dashboard UI meets WCAG 2.1 AA |
|
||
| Offline resilience | Bot caches last hour of events on local disk |
|