Requirements
導入済み
語彙
| English | 意味 |
|---|---|
| requirements engineering | Finding, analysing, agreeing and managing what a software system must provide. |
| functional requirement | A statement of a behaviour or service the system must provide. |
| non-functional requirement | A constraint or quality requirement, such as response time, availability or security. |
| use case | A description of interactions by which an actor achieves a goal using a system. |
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}
実践
Search answers within 2 seconds is —
難易度 1/5 · 100 コイン + 今日初回達成時の小ボーナス
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}
実践
A requirement is testable when —
難易度 1/5 · 100 コイン + 今日初回達成時の小ボーナス
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}
実践
A commit that closes FR-2 must say so because —
難易度 1/5 · 100 コイン + 今日初回達成時の小ボーナス
The auditable chain is what makes the history trustworthy.