Requirements
Introduced
Vocabulary
| English | Meaning |
|---|---|
| requirements engineering | requirements engineering |
| functional requirement | functional requirement |
| non-functional requirement | non-functional requirement |
| use case | use case |
What and how well
- Requirements engineering: a functional requirement says what the system does ("a member can borrow up to 5 books"); a non-functional requirement says how well ("search answers within 2 s"). A use case walks one goal end to end with its actors.
{exercise:uni-cs1201-kinds}
Practice
Search answers within 2 seconds is —
Difficulty 1/5 · 100 coins + a small bonus on first completion today
It constrains how well the searching works, not what exists.
Testable phrasing
- "Easy to use" cannot fail a test. "A new member completes first borrow in under 3 minutes without help (measured with 5 first-time users)" — now pass/fail exists.
- The course list: FR-1 limit 5 (sixth borrow rejected); FR-2 due = date + 21; FR-3 one reminder per overdue day; NFR-1 search p95 under 2 s on 10 000 titles. Each maps to an acceptance test by name.
{exercise:uni-cs1201-testable}
Practice
A requirement is testable when —
Difficulty 1/5 · 100 coins + a small bonus on first completion today
Observable outcome = a verdict exists: pass or fail.
The trace to code
- Requirement $\to$ acceptance test $\to$ red test $\to$ next commit's reason: the chain is auditable — a commit that closes FR-2 says so.
- Watch for the mistakes: solution inside requirements ("use Redis" — the need, not the means); unmeasurable adjectives; silent assumptions (the 21-day period is a named constant, not folklore).
{exercise:uni-cs1201-trace}
Practice
A commit that closes FR-2 must say so because —
Difficulty 1/5 · 100 coins + a small bonus on first completion today
The auditable chain is what makes the history trustworthy.