Requirements Methods

Three families of method dominate practice, and they answer different questions: a specification says what the product must do in auditable form, a user story is a unit of work and a promise to talk, and a scenario describes the work in context. Most projects use more than one.

1. Quick comparison

Dimension Specification (29148) User stories Scenarios
Purpose Complete, auditable statement of requirements Planning and collaboration units Understanding work and context; driving design and tests
Form Structured document plus a traceability matrix “As a … I want … so that …” plus acceptance criteria Narrative with context, paths and outcomes
Validation Review against the quality criteria; traceability Acceptance criteria, often Given–When–Then Walkthroughs, usability testing, architecture evaluation
Strengths Completeness and traceability Speed, value focus, testability Empathy, context, edge cases, discovering quality requirements
Main cost Heavy to write and to keep current Vague without the conversation and the confirmation Not a specification on its own; needs translating
Best when Regulated or contract work, complex interfaces Evolving scope, frequent delivery Early discovery, interaction design, architecture evaluation

2. Specification: cite 29148, not 830

ISO/IEC/IEEE 29148:2018 is the current standard [1]. It supersedes IEEE Std 830, which was withdrawn in 2011 — worth knowing because almost every SRS template in circulation descends from 830’s outline, and course materials still cite it as current. Its substance on the design boundary, the project boundary and verifiability is reproduced in 29148.

A typical structure: introduction (purpose, scope, definitions) → overall description (users, constraints, assumptions) → specific requirements (functional, interfaces, quality, design constraints) → appendices. For example, a quality requirement in that form reads: “search shall return results within 200 ms at the 95th percentile for a catalogue of 10 million items.”

Use it where an auditor, a regulator or a contract will read the result.

3. User stories

“As a <user>, I want <capability> so that <benefit>.” Ron Jeffries framed the 3Cs — Card, Conversation, Confirmation [2] — and Bill Wake’s INVEST gives the quality checks: Independent, Negotiable, Valuable, Estimable, Small, Testable [3]. The checkable, thirteen-criterion version is on documenting requirements [4].

In practice: write acceptance criteria, prefer Given–When–Then [5], slice vertically, and keep the conversation rather than the card as the artefact.

Example. As a shopper, I want to save items to a wishlist so that I can buy them later. Given I am logged in, when I click Save, then the item appears in My Wishlist.

4. Scenarios

A scenario is a narrative task description — actor and goal, context, preconditions, the main success path, alternatives and exceptions, postconditions [6]. It is worth distinguishing from a use case: a use case describes outwardly visible behaviour, and a scenario is “a particular path through a use case” [7].

Definition of Ready and Definition of Done, either side of a sprint The completeness check moved; it did not go away. [8]

Example. On a crowded train with intermittent mobile data, Aisha opens the app to show her QR ticket; when offline, the pass must still render and validate. That one sentence surfaces an availability requirement no feature list would have produced.

The same form specifies quality attributes, with a response measure attached — which is where scenarios stop being narrative and become requirements [9]. See requirement statements.

5. Choosing between them

The honest position is that the form should not be discernible afterwards: “downstream maintainers should not be able to discern the life cycle used in earlier development from the form of those requirements alone” [8]. Agile does not remove requirements work; it redistributes it.

So the choice is driven by who must read the result and how stable the scope is — not by methodological preference. The failure mode of each is predictable: a specification goes stale, a backlog of stories loses the properties only visible across the whole set, and a scenario reads well and specifies nothing until a measure is attached.

How solid is this?

  • Where it comes from. A current standard, two practitioner articles that report no study, a design-methods handbook chapter, and one empirical paper on user-story quality.
  • What is contested. Nothing compares these methods’ outcomes against each other — no source here shows that any one produces better software.
  • What we do not hold. IEEE 830 is withdrawn, so anything citing it as current is describing a template’s ancestry rather than a standard in force.

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [10] on software project management.

References

  1. ISO/IEC/IEEE,
    ISO/IEC/IEEE 29148:2018 — Systems and Software Engineering — Life Cycle Processes — Requirements Engineering. International Organization for Standardization, 2018. [Online]. Available: https://www.iso.org/standard/72089.html
  2. R. Jeffries,
    “Essential XP: Card, Conversation, Confirmation.” 2001. [Online]. Available: https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
  3. B. Wake,
    “INVEST in Good Stories, and SMART Tasks,” XP123.com, Aug. 2003, [Online]. Available: https://xp123.com/invest-in-good-stories-and-smart-tasks/
  4. G. Lucassen, F. Dalpiaz, J. M. E. M. van der Werf, and S. Brinkkemper,
    “Improving Agile Requirements: The Quality User Story Framework and Tool,” Requirements Engineering, vol. 21, no. 3, pp. 383–403, Sept. 2016, doi: 10.1007/s00766-016-0250-x.
  5. Cucumber,
    “Gherkin Reference.” 2025. [Online]. Available: https://cucumber.io/docs/gherkin/reference
  6. M. B. Rosson and J. M. Carroll,
    “Scenario-Based Design,” in The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications, J. Jacko and A. Sears, Eds., Lawrence Erlbaum Associates, 2002, pp. 1032–1050. [Online]. Available: https://ocw.tudelft.nl/wp-content/uploads/2_RossonCarrollSBDforHandbook2002.pdf
  7. B. Nuseibeh and S. Easterbrook,
    “Requirements Engineering: A Roadmap,” in Proceedings of the Conference on The Future of Software Engineering (ICSE ’00), ACM, May 2000, pp. 35–46. doi: 10.1145/336512.336523.
  8. IEEE Computer Society, Ed.,
    “Guide to the Software Engineering Body of Knowledge (SWEBOK Guide).” IEEE Computer Society, Oct. 15, 2024.
  9. M. R. Barbacci, R. Ellison, A. J. Lattanze, J. A. Stafford, C. B. Weinstock, and W. G. Wood,
    “Quality Attribute Workshops (QAWs),” Software Engineering Institute, Carnegie Mellon University, CMU/SEI-2003-TR-016, Aug. 2003.
  10. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

This site uses Just the Docs, a documentation theme for Jekyll.