# Requirements Trawling

**In short:** Requirements trawling means gathering requirements with several techniques, expecting that you will not find them all. Some requirements are overlooked and some only appear during building, so teams look actively and early.

## Explanation

Requirements trawling treats requirements gathering like fishing with nets. You do not "capture" a fixed catch. You cast several times with different techniques, and you accept that some requirements stay out of reach.

**Known and overlooked requirements.** Users tell you about some requirements. These are the known ones. Other requirements are overlooked, yet they matter just as much. Gathering therefore has to go beyond what users say. Teams must actively look for the overlooked ones.

**Emergent requirements.** Some requirements only surface while the team builds the product. No up-front technique can find them. This is one reason you never find all requirements in advance. The advice is to look for them as early as possible, with working product in users' hands.

**Combining techniques.** One technique is rarely enough. Typical techniques include:

- user interviews,
- questionnaires,
- observation,
- workshops, such as a story-writing workshop,
- open-ended questions.

A story-writing workshop works on current high-priority backlog items. It makes immediate progress and leaves the team a reusable example.

**No complete specification first.** However carefully a team prepares requirements, they will not be perfect, complete or static. Change is expected. Some approaches therefore do not require finding every requirement and writing a complete specification before work proceeds.

For how gathered needs are written down as stories, see the User Story article.

## Example

A team builds an ordering app for a bakery. They interview the owner and send a short questionnaire to regular customers. They also watch staff at the counter during the morning rush. Staff never mentioned a daily paper list of special orders, but the team sees it in use. That is an overlooked requirement. After the first release, customers ask for pickup-time slots. Nobody could have named that earlier, so the team treats it as an emergent requirement and keeps looking.

## Trade-offs

Using several techniques costs more time than a single round of interviews. It also never gives certainty: emergent requirements stay hidden until the team builds something and puts it in front of users. The gain is fewer overlooked requirements and an early start on work, because the team does not wait for a complete specification.



## Checks

- The document shows that requirements were gathered with more than one technique, such as interviews, observation, questionnaires or workshops.
- The document looks beyond what users stated and notes how overlooked requirements were sought.
- The document accepts that requirements are incomplete and will change, and does not claim a complete specification.
- The document states how emergent requirements will be found early, for example with working product in users' hands.

## Related

- [User Story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md)
- [Working with Functional Requirements (method phase)](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md)
- [Requirement Types and Documents (Wiegers/Beatty)](https://arc.fuet.ch/concepts/functional-requirements/requirement-types-and-documents.md)
- [Requirements Difficulty and Customer Engagement](https://arc.fuet.ch/concepts/functional-requirements/requirements-difficulty-and-customer-engagement.md)
- [Stakeholder](https://arc.fuet.ch/concepts/vision-stakeholders/stakeholder.md)
- [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md)
- [Story Mapping](https://arc.fuet.ch/concepts/functional-requirements/story-mapping.md)
- [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md)

## Sources

- [Agile Requirements Gathering: Three Types of Requirements - Mountain Goat Software](https://www.mountaingoatsoftware.com/agile/the-three-types-of-requirements) — mountaingoatsoftware.com, accessed 2026-11-09
- [User Stories Applied - Mountain Goat Software](https://www.mountaingoatsoftware.com/books/user-stories-applied) — mountaingoatsoftware.com, accessed 2026-11-09
- [Interview and Book Excerpt: Mastering the Requirements Process - InfoQ](https://www.infoq.com/articles/mastering-requirements-process/) — infoq.com, accessed 2026-11-09
- [The 6 Most Important Requirements Practices](https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/6074/The-6-Most-Important-Requirements-Practices.aspx) — modernanalyst.com, accessed 2026-11-09
- [Story Writing Workshop - Mountain Goat Software](https://www.mountaingoatsoftware.com/services/story-writing-workshop) — mountaingoatsoftware.com, accessed 2026-11-09