Week 1: project setup and discovery
Goal: form the team, understand the scenario, and start from architectural drivers rather than solution ideas.
In the practical session
- form a team of 2-3 students;
- fork the course project starter repository on GitHub;
- invite all team members and instructors (
edurbrito-cyber,margusf,ao-cyb,martoruaascyber,ahtotruu) as collaborators; - create the basic project structure:
/docs/,/diagrams/,/adrs/,/risk/,/api/,/ops/; - add a short repository
READMEwith team name, members, and current status; - review the official project workflow;
- review the Citizen Services Portal scenario;
- review the starter files and templates;
- identify stakeholders, architectural drivers, assumptions, and open questions;
- choose the team's current number-one driver and biggest unknown.
Deliverables due before Week 2
- completed
/docs/team_contract.adoc; /docs/drivers.adocwith goals, quality attributes, constraints, assumptions, stakeholders, and open questions;- GitHub fork with team members and instructors added as collaborators;
- project repository skeleton committed to the fork.
Minimum expected content in drivers.adoc
- 5-8 business or mission goals;
- 8-12 quality attributes or constraints;
- stakeholder list with at least citizens, service providers, administrators/helpdesk, auditors, and external registries/agencies;
- 5-10 assumptions that may later need validation;
- 5-10 open questions.
Questions to answer
- What is the system supposed to achieve for citizens?
- Which stakeholders can make the architecture fail if their needs are ignored?
- Which data is sensitive, regulated, or operationally critical?
- Which external systems or organizations must the portal depend on?
- What are the most important uncertainties today?
Quality bar
- drivers should explain why the architecture must be shaped a certain way;
- avoid listing only features such as login, upload, or notifications;
- unknowns should be written as questions or risks, not hidden as assumptions.