Requirements
Introducido
Vocabulario
| 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áctica
Search answers within 2 seconds is —
Dificultad 1/5 · 100 monedas + un pequeño bono en el primer intento de hoy
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áctica
A requirement is testable when —
Dificultad 1/5 · 100 monedas + un pequeño bono en el primer intento de hoy
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áctica
A commit that closes FR-2 must say so because —
Dificultad 1/5 · 100 monedas + un pequeño bono en el primer intento de hoy
The auditable chain is what makes the history trustworthy.