Requirements
Introduzido
Vocabulário
| English | Significado |
|---|---|
| requirements engineering | requirements engineering |
| functional requirement | functional requirement |
| non-functional requirement | non-functional requirement |
| use case | use case |
English
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}
Prática
Search answers within 2 seconds is —
Dificuldade 1/5 · Moedas 100 + pequeno bônus na primeira conclusão hoje
It constrains how well the searching works, not what exists.
English
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}
Prática
A requirement is testable when —
Dificuldade 1/5 · Moedas 100 + pequeno bônus na primeira conclusão hoje
Observable outcome = a verdict exists: pass or fail.
English
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}
Prática
A commit that closes FR-2 must say so because —
Dificuldade 1/5 · Moedas 100 + pequeno bônus na primeira conclusão hoje
The auditable chain is what makes the history trustworthy.