Foundations · Module 1
Discovery and requirements
Learn to identify what you're building and what could go wrong.
Previously
Start with Software Architecture Foundations
Start from what architecture is for, and how to think about components, boundaries and responsibilities in small systems.
This module
Discovery and requirements
Learn to identify what you're building and what could go wrong.
Next
Architecture and design
Document and communicate architectural decisions using C4 models, Architecture Decision Records, API contracts, and security by design principles.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
Covers user journeys, non-functional requirements, threat modelling fundamentals with STRIDE, and abuse cases mapped to OWASP Top 10.
What you will be able to do
- 1 Explain discovery and requirements in your own words and apply it to a realistic scenario.
- 2 Good requirements come from understanding journeys, risks, and constraints before design starts.
- 3 Check the assumption "The problem is explicit" and explain what changes if it is false.
- 4 Check the assumption "Non-functional needs are named" and explain what changes if it is false.
Before you begin
- No previous technical background required
- Read the section explanation before using tools
Common ways people get this wrong
- Building the wrong thing. If discovery is weak, teams build the wrong system very efficiently.
- Hidden constraints. Hidden constraints appear later as incidents and delays.
Learn to identify what you're building and what could go wrong. Covers user journeys, non-functional requirements, threat modelling fundamentals with STRIDE, and abuse cases mapped to OWASP Top 10.
We start with what the system is for and who it serves. Without that, every later decision is guesswork and your risks are invisible.
Mental model
Discovery to requirements
Good requirements come from understanding journeys, risks, and constraints before design starts.
-
1
Journey
-
2
Needs
-
3
Constraints
-
4
Requirements
Assumptions to keep in mind
- The problem is explicit. If the problem is unclear, design becomes decoration and rework.
- Non-functional needs are named. Performance, security, and reliability are requirements, not afterthoughts.
Failure modes to notice
- Building the wrong thing. If discovery is weak, teams build the wrong system very efficiently.
- Hidden constraints. Hidden constraints appear later as incidents and delays.
Key terms
- Non-Functional Requirement (NFR)
- A quality attribute constraint such as latency, availability, security, or maintainability that describes HOW the system behaves, not WHAT it does. For example, "the checkout page must load in under 300ms for 95% of users" is an NFR.
- Architecture Decision Record (ADR)
- A document that captures an important architectural decision along with its context, the options considered, and the rationale for the choice. ADRs help future team members understand why the system is built the way it is.
- Threat Modelling
- A structured approach to identifying potential security threats by thinking like an attacker, so you ask "what could go wrong?" before writing code rather than after release.
- OWASP
- The Open Web Application Security Project, a non-profit organisation that produces freely available security guidance, tools, and documentation. Their Top 10 list of web application security risks is widely referenced.
- Site Reliability Engineering (SRE)
- An engineering discipline that applies software engineering principles to infrastructure and operations. SRE focuses on reliability, automation, and learning from incidents.
- The Ilities
- Quality attributes that typically end in "-ility" such as availability, scalability, maintainability, and security. These are the qualities you must actively design and operate for.
Check yourself
Quick check. Discovery and requirements
0 of 6 opened
What is a non functional requirement
A quality constraint such as latency, availability, security, or maintainability that describes how the system behaves.
Scenario. A product says 'it must be fast'. What is the minimum you add to make it testable
A measurable threshold and scope, such as p95 latency under 300 ms for a named endpoint under a named load.
What does STRIDE help you do
Prompt threat thinking by checking spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
What is an abuse case
A realistic way a feature can be misused or attacked, written so it can be tested and defended against.
Why do a journey map early
It reveals handovers, hidden assumptions, and failure points before the design hardens them into the product.
Scenario. Password reset can be spammed. Name one preventive control and one detective control
Preventive is rate limiting and anti automation checks. Detective is logging and alerting on abnormal reset volume and patterns.
Artefact and reflection
Artefact
A short module note with one key definition and one practical example
Reflection
Where in your work would explain discovery and requirements in your own words and apply it to a realistic scenario. change a decision, and what evidence would make you trust that change?
Optional practice
User journeys, NFRs, threat modelling, and abuse cases