FR & NFR · SMART · Software Architectures · Why architecture matters for testers
→ next slide | ESC overview
Last lesson you wrote down 3 sentences on what quality means to you.
Quality is hard to define but easy to notice when it's missing.
1. Software Requirements — what they are, FR vs NFR, user stories vs requirements
2. SMART Requirements — Specific, Measurable, Achievable, Realistic, Timely
3. Software Architectures — Monolith vs Microservices vs Layered & more
4. Why Architecture Matters — where data flows = where things break
Requirements are documented needs that a product or service must satisfy.
Source: BABOK — International Institute of Business Analysis
User stories express intent. Functional requirements specify that behaviour.
| Bad ❌ | Good ✅ |
|---|---|
| The system should allow users to post jobs. | Employers can post job listings with: job title, description, location, salary range, and job type (full-time / part-time / contract). |
| Users should be able to search for jobs. | Users can search by keywords and filter by location, salary range, and job type. Results display in a list sortable by relevance, date posted, or salary. |
| Bad ❌ | Good ✅ |
|---|---|
| The system must respond quickly. | Each request must be processed within 3 seconds with 10,000 concurrent users on a standard server setup. |
| The system should be secure. | All user data must be encrypted in transit using TLS 1.2+. Passwords must be hashed with bcrypt (cost factor ≥ 12). CVs accessible only to authorized personnel. |
A requirement that isn't SMART can't be tested.
NFR example
FR example
If you can't write a test case for a requirement — the requirement isn't good enough.
Read the "bad" requirement below. Rewrite it in SMART format in the chat.
Bad requirement to rewrite:
"Users should be able to register quickly and the system should handle errors."
Software architecture describes the structure of a system — how components are arranged and how they communicate.
Good architecture ensures scalability, maintainability, and adaptability.
Monolithic
┌─────────────────────┐
│ UI (Front) │
├─────────────────────┤
│ Backend (all logic)│
├─────────────────────┤
│ Database │
└─────────────────────┘Microservices
Browser Mobile App
└────────┘
│
┌──────-───────────-┐
│ API Gateway │
│ auth·route·limit │
└──┬──-─-─┬──────┬──┘
│ │ │
[User] [Order] [Pay]
DB DB Stripe
│ (async)
═══ Message Bus ═══
│ │
[Notify] [Search]
Email·SMS DBFor testing:
monolith = one system to test
microservices = each service needs its own tests + integration/contract tests
Knowing how data flows tells you where things break.
Ask developers: "Where does data go after this step?" — that single question reveals more bugs than any checklist.
A Software Requirements Specification (SRS) is a document that describes what a system must do and how well it must do it — before anyone writes a single line of code.
We won't build the full SRS in this course, but you need to know what goes in it and be able to write the requirements section.
📄 SRS Example 1 · 📄 SRS Example 2 · 📝 SRS Template (.docx)
Use your own project or cvkeskus.ee if you don't have one yet.
If using cvkeskus.ee, focus on the job search functionality (search bar, filters, results list).
Write the requirements for the project:
Architecture:
Submit to Teams assignments.