Complete study guide — everything you need for Quiz 2 (very detailed)
How to use this guide
1. Read the concept + example for each section.
2. Do the practice questions at the end under time constraints (10–12 minutes).
3. Use the cheat-sheet at the end for quick last-minute review.
1 — Functional Requirements (FRs)
What they are
Functional requirements describe what the system must do: specific behaviors, functions, operations, or
services. They map to user-visible features or system actions.
Characteristics of good FRs
•
Clear and unambiguous (no room for multiple interpretations).
•
Testable (you can verify with a test).
•
Necessary (trace to stakeholder needs).
•
Atomic / granular — one requirement = one behavior.
•
Prioritized (must / should / could / won’t).
Examples (for an online bookstore)
•
Bad FR: “The system should have a good search.” (vague)
•
Good FR: “The system shall allow users to search for books by title, author, ISBN, or keyword and
return a result list sorted by relevance.”
How FRs relate to user stories and use cases
•
A user story often expresses one or more FRs at a high level.
•
A use case describes a FR in procedural form (flows, alternate flows).
Writing checklist for an FR
•
Is it actionable?
•
Is it testable? (Yes → put acceptance criteria)
•
Does it have a stakeholder/owner?
•
Is it atomic? (Split if necessary)
2 — User Stories
Definition & format
A compact requirement capturing user need from the user’s perspective, typically:
As a <role>, I want <goal/desire> so that <reason/value>.
INVEST — what makes a good story
•
Independent — can be developed/tested independently.
•
Negotiable — not a contract, discussable.
•
Valuable — delivers value to user/stakeholder.
•
Estimable — small enough to estimate.
•
Small — fits in a sprint.
•
Testable — acceptance criteria exist.
Acceptance Criteria
Make stories testable: list conditions that must be true for the story to be “done.” Use
GIVEN/WHEN/THEN for clarity.
Example story (password reset):
As a registered user,
I want to reset my password,
so that I can regain access if I forget it.
Acceptance criteria:
- GIVEN that I am on the login page AND I click "Forgot password",
WHEN I enter my registered email and submit,
THEN the system sends a password reset link to that email within 2 minutes.
- The reset link expires after 24 hours.
- If email is not registered, system shows "If an account exists, you'll receive an email." (no disclosure).
Splitting stories
If a story is too big (epic), split by:
•
workflow steps (login → 2FA → profile)
•
user roles (admin vs user)
•
acceptance criteria grouped by priority
Common mistakes
•
Writing implementation details (e.g., “Use MySQL to store...”) — avoid unless needed for nonfunctional constraints.
•
Vagueness: “improve performance” with no metric.
3 — Use Cases (detailed)
Definition
A use case describes a specific interaction between an actor (user or another system) and the system to
achieve a goal. It includes the main flow and alternative flows.
Key parts of a use case
•
Use case ID / Name (e.g., UC-01: Place Order)
•
Primary actor (who initiates)
•
Secondary actors (who provides services)
•
Goal / Brief description
•
Preconditions (what must be true before start)
•
Trigger (what starts the use case)
•
Main success scenario (Flow of Events) — numbered, step-by-step
•
Extensions / Alternative flows — what happens on exceptions or choices
•
Postconditions / Guarantee (success/failure outcomes)
•
Special requirements (security, performance relevant to the use case)
•
Frequency / Priority / Owner (optional but good for exams)
Use Case Diagram basics (UML)
•
Actors: stick figures (or named boxes) outside the system boundary.
•
System boundary: rectangle containing use cases (ellipses).
•
Lines connect actors to use cases they participate in.
•
<<include>> relationship: use case A always uses B.
•
<<extend>> relationship: B extends A only at certain extension points.
•
Generalization: one actor or use case can inherit from another.
Simple ASCII example:
[User] ------ (Login)
[User] ------ (Browse Catalog)
[User] ------ (Place Order) <--- (Verify Payment) <<include>>
Example full use case: UC-02: Withdraw Cash (ATM)
•
Primary actor: Customer
•
Goal: Customer withdraws cash from their account.
•
Preconditions: Customer holds a valid card and account; ATM online.
•
Trigger: Customer inserts card and chooses “Withdraw”.
•
Main flow:
1. Customer inserts card and enters PIN.
2. System validates PIN.
3. Customer selects withdrawal amount.
4. System checks account balance.
5. System dispenses cash and prints receipt.
6. Customer takes card, cash, and receipt; session ends.
•
•
Extensions / alternative flows:
o
2a: PIN invalid → prompt retry up to 3 times → if fail, retain card and end.
o
4a: Insufficient funds → show message and offer lower amount or cancel.
o
5a: Cash jam / dispenser error → cancel transaction and notify bank; card returned.
Postconditions: Money debited from account (or rolled back if failure).
Include vs Extend (short)
•
Include: mandatory sub-scenario used by multiple use cases (e.g., Verify Payment).
•
Extend: optional/additional behavior triggered under some conditions (e.g., Offer Discount when
coupon exists).
4 — Actor–Goal Tables (task-level goals)
What it is
A simple table mapping actors to their task-level goals — helps find requirements and use cases.
How to build
Columns: Actor | Role/Description | Task-level goals (1..n) | Priority
Example (e-commerce):
Actor: Customer
Goals: Browse products; Search products; Add to cart; Checkout; Track orders.
Actor: Payment Gateway (secondary)
Goals: Authorize payment; Refund transactions.
Actor: Admin
Goals: Manage inventory; View reports; Process returns.
Why useful
•
Quick way to identify primary use cases and user stories.
•
Helps spot missing actors or goals.
5 — Primary vs Secondary Actors
Primary actor
•
Initiates the interaction and has the main goal. Usually a user or external system that triggers the
use case.
•
Example: Customer in “Place Order”.
Secondary actor
•
Supports the system by supplying services or resources; does not initiate.
•
Example: Payment Gateway, Shipping Service, Database.
How to identify
•
Ask: Who wants something to happen? → Primary.
•
Who helps the system complete that goal? → Secondary.
6 — Preconditions, Triggers, Flow of Events, Extensions (how to write)
Preconditions
•
Conditions that must be true before the use case runs (e.g., user logged in, card present).
•
Write them as concrete verifiable states.
Triggers
•
Event that starts the use case (e.g., user clicks “Checkout”, message received from sensor).
Flow of Events (Main success scenario)
•
Numbered, simple steps describing what happens in the ideal path.
•
Keep steps at system/user action granularity — not low-level implementation.
•
Each step should lead clearly to the next.
Extensions / Alternative flows
•
For each step that might fail or branch, list extension(s) with unique labels (e.g., 3a, 3b).
•
Describe the condition and the steps for that alternative path.
•
Ensure extension either returns to the main flow at a clear point or ends with a postcondition.
Tip: In exams, write a clear main flow of ~6–12 steps and 3–4 common extensions (errors, invalid input,
external service fail).
7 — Non-Functional Requirements (NFRs)
What they are
Constraints or qualities the system must have — how well the system does things (performance,
reliability, security, usability, etc.), not what it does.
Functional vs Non-functional (short)
•
Functional: “The system shall allow users to upload files.”
•
Non-functional: “Uploads of files up to 100 MB shall complete within 10 seconds 95% of
attempts.”
Valid vs Invalid NFRs (examples)
•
Invalid / Vague: “The system should be fast.”
•
Valid / Good: “Under normal load (≤200 concurrent users), 95% of search queries shall return
results within 2 seconds.” — measurable, testable, environment defined.
•
Invalid / Out-of-scope / Impossible: “System must process 100,000 transactions per second on
current hardware” (maybe impossible — needs measurable constraints or hardware
assumptions).
How to write a good NFR — template
[Condition/Context]; [Measure/Metric]; [Target/Threshold]; [When / Under what load]; [How measured].
Example: Under normal operating load of up to 500 concurrent users, 95% of API requests shall have a
response time <= 1.5 s (measured at the entry point load-balancer) during business hours.
Common types of NFRs (with examples)
•
Performance: latency, throughput, response time.
o
•
Reliability / Availability: uptime, redundancy, failure handling.
o
•
Example: “New users shall complete registration without assistance in ≤ 3 minutes on
average.”
Security: authentication, authorization, encryption, audit logs.
o
•
Example: “System availability shall be ≥ 99.9% (excl. scheduled maintenance).”
Usability: learnability, error rate, accessibility.
o
•
Example: “95th percentile API latency < 300 ms under 1k RPS.”
Example: “All sensitive data in transit and at rest shall be encrypted with industry-standard
algorithms.”
Maintainability: modularity, code complexity targets, upgrade time.
o
Example: “Average time to deploy a patch shall be ≤ 30 minutes for hotfixes.”
•
Scalability: ability to scale horizontally/vertically.
•
Interoperability: APIs, data formats compatibility.
•
Portability: supported platforms/environments.
•
Legal / Regulatory / Compliance: e.g., GDPR, local laws.
•
Localization / Internationalization: language, format support.
Writing checklist for NFRs
•
Is it measurable? (If not, add a metric.)
•
Is context defined? (Load, environment, user group)
•
Is the target realistic? (Check feasible thresholds.)
•
How to test/monitor it? (Define measurement method.)
8 — Reliability Metrics: what they are (NO calculations required)
Your lecture explicitly said: know what they are — not how to calculate them. Here are plain-language
definitions and intuitive examples.
MTTF — Mean Time To Failure
•
What it is: The average time a non-repairable component or system operates before it fails.
•
When used: For devices/components that aren’t repaired (e.g., lightbulbs, disposable sensors).
•
Intuition: If MTTF = 10,000 hours, on average the part works that long before failing.
MTBF — Mean Time Between Failures
•
What it is: The average time between consecutive failures for repairable systems (includes
operating time between repairs).
•
When used: For systems that are repaired/restarted (servers, machines).
•
Intuition: If an enterprise server fails, gets repaired, and runs again — MTBF is the average time
you expect between those failures.
AVAIL (Availability)
•
What it is: The proportion of time the system is operational and able to serve requests (often
expressed as a percentage like 99.9%).
•
When used: To express how continuously available a service is (e.g., “99.99% availability”).
•
Intuition: Higher availability = less downtime; critical services often target “four nines” (99.99%)
or similar depending on SLA.
POFOD — Probability Of Failure On Demand
•
What it is: The probability that the system will fail when it is demanded to perform (used for
systems that are invoked occasionally, like emergency shutdown systems).
•
When used: Safety-critical, on-demand systems (e.g., fire suppression that must operate on
demand).
•
Intuition: A small POFOD (e.g., 0.001) means very small chance of failing when requested.
ROCOF — Rate Of Occurrence Of Failures
•
What it is: How frequently failures occur over time — essentially the failure rate (failures per unit
time).
•
When used: To understand how often failures happen and plan maintenance or redundancy.
•
Intuition: Higher ROCOF → more frequent failures → more maintenance or better design needed.
9 — Traceability & Mapping (how FRs, stories, use cases, and NFRs connect)
Traceability matrix (simple idea)
•
Rows: user stories / use cases
•
Columns: functional requirements, NFRs, tests, owner, priority
•
Purpose: ensure every requirement / story is covered by tests and design.
Mini example table (conceptual):
Use Case: Place Order
→ FRs: Accept payment, Create order record, Send confirmation
→ NFRs: Payment API latency < 2s, Transaction must be ACID
→ Tests: Payment success path, Payment fail path, Timeout
10 — Templates & Quick Writing Helpers
User story template
As a <role>,
I want <goal>,
so that <reason>.
Acceptance criteria:
- GIVEN <context> WHEN <action> THEN <expected result>.
Use case template (short)
UC-ID: UC-__
Name:
Primary actor:
Goal:
Preconditions:
Trigger:
Main flow:
1.
2.
...
Extensions:
2a: ...
Postconditions:
Special requirements:
NFR template
Context / Trigger; Metric; Target; Measurement method; Frequency.
11 — Common exam pitfalls & quick tips
•
Don’t confuse FR vs NFR. If it’s an action the system does → FR. If it constrains how → NFR.
•
Make NFRs measurable. Never write “system must be secure” without criteria.
•
For use cases, give a clear main success scenario (~6–12 steps) plus 2–4 extensions (error
conditions).
•
Label actors clearly: primary vs secondary.
•
When asked for definitions, be concise and give an example.
•
If asked to write a user story, always include acceptance criteria.
•
Use the INVEST checklist to check story quality.
12 — Practice questions + model answers (short)
Q1 — Write a user story (and acceptance criteria) for resetting a forgotten password.
Model answer: (See User Stories section example earlier.)
Q2 — Give a valid NFR for API performance and an invalid one; explain why.
Model answer:
•
Invalid: “The APIs should be fast.” (vague)
•
Valid: “Under normal load ≤ 1000 RPS, 95% of API requests shall return within 300 ms as
measured at the load balancer during peak hours.” (measurable, context, metric)
Q3 — For an ATM Withdraw Cash use case, list 3 extensions (alternatives).
Model answer:
•
PIN invalid 3 times → card retained.
•
Insufficient funds → show message & cancel or offer lower amount.
•
Cash dispenser error → cancel transaction, log incident, notify bank.
Q4 — What is the difference between primary and secondary actor? Give examples.
Model answer: Primary initiates the goal (Customer). Secondary supports/provides service (Bank,
Payment gateway).
Q5 — Explain AVAIL in plain words.
Model answer: The percent of time the system is up and able to serve requests. Example: 99.9%
availability means little downtime over a year.
Q6 — Create an actor–goal table entry for "Delivery Service" in an e-commerce system.
Model answer:
Actor: Delivery Service — Goals: Pick up package; Update tracking status; Confirm delivery; Provide
proof-of-delivery.
Q7 — Write a short use case main flow for “Search Book” in an online library.
Model answer:
1. User opens search page.
2. User enters search term and clicks Search.
3. System queries index and returns ranked results.
4. User selects book for details.
5. System shows book details and availability.
Q8 — Give a valid NFR for security.
Model answer: “All passwords shall be stored hashed with a recognized algorithm (e.g., bcrypt) and
salted; password must be at least 10 characters.” (measurable & specific)
Q9 — What is POFOD used for?
Model answer: It gives the probability that a system will fail when it is demanded to perform — used for
on-demand, safety-critical systems.
Q10 — How would you check that a use case is complete?
Model answer: Ensure main success scenario reaches the goal, list preconditions, triggers,
postconditions, and relevant extensions for common failures. Map to actors and NFRs.
13 — Quick cheat-sheet (last-minute scan)
•
User story format: As a X, I want Y, so that Z. + acceptance criteria.
•
INVEST → Independent, Negotiable, Valuable, Estimable, Small, Testable.
•
Use case must include: Actor, Preconditions, Trigger, Main Flow, Extensions, Postconditions.
•
Primary actor initiates; Secondary supports.
•
NFRs must be measurable and include context (load, when).
•
Common NFR types: Performance, Reliability, Usability, Security, Maintainability, Portability.
•
Reliability metrics (what they are): MTTF (avg time to fail), MTBF (avg time between failures),
AVAIL (uptime %), POFOD (probability of failure on demand), ROCOF (failure rate over time).
14 — Exam strategy & time allocation (suggested)
•
1–2 min: read question carefully (identify FR/NFR or use case).
•
If a use case: spend 1–2 minutes listing actors/goals & preconditions, 6–8 minutes writing main
flow and 2–3 minutes writing extensions.
•
If asked to write user stories: give 1–2 complete stories with acceptance criteria (2–4 minutes
each).
•
Save 3–5 minutes for quick review.