# Requirements Difficulty and Customer Engagement

**In short:** Deciding exactly what to build is the hardest part of software work, and clients cannot specify it fully up front. Frequent customer contact, such as reviews and daily collaboration, corrects direction early.

## Explanation

Brooks calls deciding precisely what to build the hardest single part of building a software system. He adds that no other part cripples the finished system as badly when done wrong. Errors here are also the hardest to fix later.

Clients cannot state their requirements completely at the start. Brooks therefore asks for extensive iteration between client and designer. The two sides go back and forth many times.

**Why regular contact matters**

Each contact point lets the customer see something and react. Each reaction corrects the direction. Without such contact, the team works from its own reading of the requirements, and nobody checks that reading.

The Agile principles take a similar view:
- Early and continuous delivery of valuable software is the highest priority.
- Late changes to requirements are welcome.
- Business people and developers work together daily, not only at the start or the end.

**Common practices**

- **Sprint Review.** In Scrum, the team shows its latest working result (the Increment) to stakeholders. The goal is to get feedback and encourage collaboration. The Product Owner invites the key stakeholders.
- **Product Owner.** This person is the single channel for priority change requests.
- **On-site customer.** In Extreme Programming (XP), a business-side person sits with the developers. They answer questions and decide what a feature is worth. This role is often filled by a team rather than one person.

Fowler says interactive communication avoids much of the misunderstanding that documents or intermediaries cause.

**Risks**

- If the customer side is not representative, the team gets a partial view. XP notes that the customer is more commonly a team than one person.
- If developers only see customers through intermediaries or documents, their motivational link to the users breaks.

See also Iterative and Incremental Development for the wider working style.

## Example

A team builds an internal booking tool. Every two weeks it shows working screens to the people who will use it. In the second review, a user points out that bookings often change after confirmation. The team had not known this. It adjusts its plan before building more on the wrong assumption. Had the team waited until the end, the gap between what users needed and what existed would have been much larger.

## Trade-offs

Frequent contact takes time from both customers and developers. Daily collaboration needs a customer side that is available and speaks for the real users. A Product Owner as single channel gives clear priorities, but it can become a proxy that hides the real users from the team.

The belief that requirements errors cost most when found late is widely cited. However, a 2016 empirical study found no evidence for a delayed issue effect. So the cost argument is contested. Brooks's argument about the difficulty of specifying requirements up front does not depend on it.

Each customer contact point corrects the direction of the work.

```mermaid
flowchart LR
  A[Build a small increment] --> B[Show it to the customer]
  B --> C[Collect feedback]
  C --> D[Adjust requirements and plan]
  D --> A
```

## Checks

- The document names how and how often the team gets feedback from customers or users, such as sprint reviews or an on-site customer.
- The customer representatives are named, and the document states whether they represent the wider customer side.
- The document states who invites stakeholders to reviews and who receives priority change requests.
- The document does not rely on the claim that late requirements errors always cost more as the only reason for early feedback.

## Related

- [Iterative and Incremental Development](https://arc.fuet.ch/concepts/fundamentals/iterative-and-incremental-development.md)
- [Stakeholder](https://arc.fuet.ch/concepts/vision-stakeholders/stakeholder.md)
- [Stakeholder Identification](https://arc.fuet.ch/concepts/vision-stakeholders/stakeholder-identification.md)
- [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md)
- [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md)
- [Agile Architecture](https://arc.fuet.ch/concepts/fundamentals/agile-architecture.md)
- [Requirements Trawling](https://arc.fuet.ch/concepts/functional-requirements/requirements-elicitation.md)
- [Working with Functional Requirements (method phase)](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md)

## Sources

- [No Silver Bullet](https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet) — cgl.ucsf.edu, accessed 2026-11-09
- [Principles behind the Agile Manifesto](https://agilemanifesto.org/principles.html) — agilemanifesto.org, accessed 2026-11-09
- [Onsite Customer](https://martinfowler.com/bliki/OnsiteCustomer.html) — martinfowler.com, accessed 2026-11-09
- [Pleasing The Customer](https://www.martinfowler.com/bliki/PleasingTheCustomer.html) — martinfowler.com, accessed 2026-11-09
- [Scrum Guide 2017 | Scrum Guides](https://scrumguides.org/scrum-guide-2017.html) — scrumguides.org, accessed 2026-11-09
- [Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle](https://arxiv.org/html/1609.04886v1) — arxiv.org, accessed 2026-11-09