Software Architecture Design Document
8 weeks · 0 milestones
Produce a software architecture document for a real or realistic system covering: a component diagram showing at least 4 logical components with named interfaces, an interface specification for each inter-component communication (message format, protocol, error handling), documented architectural decisions with at least 3 alternatives considered per major decision and explicit trade-off rationale, and a quality attribute analysis (how the architecture addresses 2 chosen quality attributes such as scalability, fault tolerance, or security). Diagrams produced using draw.io (free), Lucidchart free tier, or PlantUML (free, text-based). Proof artifacts: the architecture document with diagrams (design artifact) and a documented trade-off rationale for the primary architectural decisions (documentation artifact). Accessible: draw.io and PlantUML are fully free; no hardware or software license required. Verification: a senior software engineer or architect challenges 'why did you choose this component boundary?' and 'what breaks first when load doubles?' — you must answer in terms of the specific system, not general principles.
Milestone map
Milestone map
3 milestones
Identify the architectural drivers for a real or realistic software system: functional requirements that drive architectural decisions, quality attributes (performance, scalability, security, maintainability, availability), and constraints (technology stack mandates, team size, regulatory requirements, budget). For each quality attribute, define a quality attribute scenario in the format: stimulus → system response → measurable response measure. These scenarios are the testable criteria that your architecture must satisfy — an architecture without quality attribute scenarios is untestable.
Proof required
Submit your architectural drivers document (≥600 words): the system context (what the software does and who uses it), ≥5 functional requirements that drive architectural decisions, ≥4 quality attribute scenarios in stimulus/response/measure format, and ≥2 architectural constraints.
What gets checked
- Quality attribute scenarios are in stimulus/response/measure format — not statements like 'the system should be fast'
- ≥4 quality attributes are addressed — not all performance, at least 3 different quality dimensions
- Constraints distinguish between technology mandates (must use) and preferences (prefer to use)