Question bank — Requirements — functional vs non-functional, user stories, acceptance criteria

False — the number is a hint, not a rule. "The system shall let a user add up to 10 items" is a functional rule (a behaviour with a limit); "results in under 2 seconds" is non-functional because the number constrains a quality, not what the system does.

False — an NFR constrains how well an existing behaviour runs (speed, security), so it has no meaning without the verb it modifies; it is an adverb with no verb of its own.

True for functional requirements specifically — a functional requirement asks only does the behaviour exist and produce the right output? The system can then still fail its non-functional requirements (too slow, insecure), which is a separate check.

False — the story states who wants what and why and is deliberately negotiable/imprecise; the acceptance criterion is the precise, pass/fail contract that makes the story testable. One story usually has several criteria.

False — usability is a quality of interaction ("a new user completes checkout in ≤ 3 clicks"), so it is non-functional. The functional part is merely that a checkout button exists and works.

False in spirit — without the benefit you lose the value/prioritisation filter and can't judge whether the feature is worth building; INVEST's "Valuable" fails, so it is a task, not a proper story.

False — the same structure describes edge and negative cases by putting an empty/invalid/boundary state in the Given (e.g. "Given an empty cart, When I remove, Then I see an error").

False — Small means it fits comfortably in one iteration and is easy to estimate; a small slice can still deliver real value. Small is about scope, not importance.

True by definition of "done" for that story — but only if the criteria were written well (covering edge cases and any NFR thresholds). Weak criteria mean "all pass" still hides bugs.

It smuggles the solution (Redis) into the story. A story owns the problem space; rewrite as "...I want pages to load quickly, so I don't abandon the site" and let design choose Redis, a CDN, or nothing.

It is not measurable, so it can't be tested or verified — "friendly" is an opinion. Give it a threshold: "a first-time user completes signup in under 60 seconds without help."

"It works" is not a pass/fail outcome, and there is no boundary/negative case. Most bugs live at boundaries (empty cart, out-of-stock, no network), so each happy path needs a matching invalid-input case.

The role is "the system", not a real human user — this exposes an implementation task disguised as a story. Name a real user whose goal justifies the cost, or track it as a technical task instead.

"Reasonably" and "most" have no numbers, so no test can decide pass/fail. Fix: "reset email arrives within 5 seconds for 99% of requests."

A one-off manual demo isn't a repeatable, objective check. Testable means it could be automated and re-run forever with fixed inputs and an unambiguous expected output.

Because the precise, non-negotiable details belong in the acceptance criteria; keeping the story open lets the team discuss the best way to deliver the goal instead of locking in a premature solution.

Each later stage builds more code, tests, and documentation on top of the wrong assumption, so undoing it means unwinding everything layered above — the deeper the layer, the more must be rewritten.

Without a measurable threshold, "fast" or "secure" stays an opinion that no test can confirm; the number turns a quality into an objective pass/fail target with its own kind of test (load, benchmark, pen-test).

The benefit states the value delivered, so comparing benefits across stories lets you rank them by payoff — the 80/20 filter for deciding what to build first.

A missing feature fails a functional requirement and is caught by a feature test; a present-but-slow feature passes that test yet fails a non-functional requirement, needing a separate benchmark or load test. Splitting them forces both checks.

So the definition of "done" is objective and re-runnable — the same fixed inputs and expected outputs verify the story on every future change, catching regressions a one-time human check would miss.

Removing the last item, so the cart reaches the empty state — this tests the boundary (0 items) where the total, messaging, and layout often break.

A persistence criterion: "Given a removed item, When I refresh, Then it is still absent." Removal in the UI only, without saving, is a classic boundary bug the happy path never reveals.

Not quite — it needs the conditions under which it holds: the load ("with 10,000 products / concurrent users") and the percentile ("for the 95th-percentile request"), otherwise the target is untestable in a meaningful worst case.

A wrong-password / invalid-input case: "Given an incorrect password, When I submit, Then I see an error and am not logged in." Negative paths are where security and error-handling bugs hide.

The boundary itself (exactly 1,000), just under it (999, must succeed), and just over it (1,001, must fail gracefully) — boundaries above/below/at the limit are where off-by-one and overflow bugs appear.