Week 3: quality attributes and security goals
Goal: make architectural requirements precise enough to guide design choices.
In the practical session
- refine the Week 1 driver list;
- record 5-8 business goals in the Mission goals section of
/docs/drivers.adocand add an Out of scope section with 5 items; - list 10-15 quality attributes, constraints, and security-relevant requirements;
- mark the top 5 drivers as architecture-critical;
- prioritize the most important drivers;
- write 3-5 quality attribute scenarios with stimulus, stimulus source, environment, artifact, response, and response measure;
- define initial security goals and the first trust-boundary assumptions;
- update the risk register where new requirements reveal new risks.
Deliverables due before Week 4
/docs/quality_attributes.adoc;/docs/qa_scenarios.adoc;/docs/security_goals.adoc;- updated
/docs/drivers.adoc; - updated
/risk/risk_register.adoc.
Minimum expected content in quality_attributes.adoc
- prioritized list of 10-15 quality attributes, constraints, or NFRs;
- top 5 marked as architecture-critical;
- explicit trade-offs between at least three important attributes.
Minimum expected content in qa_scenarios.adoc
- 3-5 quality attribute scenarios;
- QA means quality attribute; each scenario makes a quality requirement measurable or testable;
- for each scenario: scenario name, linked business goals, and relevant quality attributes;
- stimulus: the event or trigger;
- stimulus source: who or what initiates the event;
- environment: the operating conditions or system state;
- artifact: the affected part of the system or engineering process;
- response: the expected behavior;
- response measure: the measurable target used to assess that behavior;
- questions and issues: unresolved questions and known issues, or explicitly state that there are none;
- at least one scenario about availability/resilience;
- at least one scenario about security/auditability;
- at least one scenario about modifiability/evolution.
Minimum expected content in security_goals.adoc
- 8-12 security goals written as properties the system must preserve;
- each goal tied to an asset and a threat category;
- initial trust-boundary list;
- important data categories, for example citizen profile data, requests/cases, documents, audit records, and service-provider data;
- initial attacker/abuse assumptions;
- mapping from security goals to at least five risks in the risk register.
Questions to answer
- What does "available enough" mean for this portal?
- What does "auditable" mean: who needs evidence, and about which actions?
- What privacy properties must hold even when many organizations are integrated?
- Which security goals conflict with usability, observability, cost, or evolvability?
- Which goals need measurable response criteria?
Quality bar
- a quality attribute scenario should be testable or reviewable;
- "system is secure" is not a security goal;
- each security goal should say what is protected, from whom or what, and under which conditions.
Resources and examples
- SEI: Quality Attribute Workshops, Third Edition - scenario refinement and an example template in Appendix A.
- SEI: Quality Attribute Workshop collection - identifying and prioritizing quality attributes from business goals.
- OWASP: Threat Modeling Cheat Sheet - background for assets, threats, and trust boundaries. A full threat model is not required this week.
The examples below are illustrative, not additional deliverables or fixed requirements. Choose and justify goals and measurable targets for your team's design.
Example quality attribute scenario: unauthorized document access
- Scenario name: deny access to another resident's document.
- Business goal: let residents manage public-service documents while protecting their privacy.
- Relevant quality attributes: security (confidentiality and authorization) and auditability.
- Stimulus: a request to download another resident's document without a valid delegation or other authorization.
- Stimulus source: an authenticated resident attempting unauthorized access.
- Environment: normal operation, with no authorized relationship between the requester and the document owner.
- Artifact: the portal's document download interface and authorization enforcement.
- Response: deny the request, disclose no document content or protected metadata, and record the denied attempt for audit.
- Response measure: all requests in a defined unauthorized-access test set are denied; zero protected document content or metadata is returned; each attempt has an audit record containing the requester, action, time, and outcome within 5 seconds, without recording document content.
- Questions: which roles and delegations authorize access, and who may read the audit records?
- Issues: the example covers normal operation; behavior when authorization or audit services are unavailable still needs a separate decision.
Example security goal
- Goal: resident documents and protected metadata must not be disclosed to a requester unless ownership, a valid delegation, or an explicitly authorized staff role permits that access.
- Asset: resident documents and their protected metadata.
- Threat category: information disclosure through unauthorized access.
- Assumption: authentication identifies the requester, but does not by itself authorize document access.
- Related risk: if document access checks rely only on login status or a supplied document identifier, a resident may access another resident's documents.