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;
- define 5-8 business goals and 5 out-of-scope 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, 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/business_goals.adoc;/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;
- for each scenario: stimulus, environment, artifact, response, response measure;
- 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.