Requirements Gathering for Business Software

How to gather software requirements that hold up: observe the work, ask for examples, map the process, define acceptance criteria and confirm in writing.

Most software that disappoints was built correctly from the wrong requirements. The request said one thing, the need was another, and nobody noticed until the demo. Requirements gathering is the cheapest place to fix that. This is the approach I use when a department asks for a new system or a change.

Find the problem behind the request

Requests arrive as solutions: we need a new report, add an approval step, build an app. Ask what happens today, what goes wrong and what it costs. Often the real need is smaller or different. A team asking for a new report may need one extra column on an existing one.

Watch the work being done

People describe the official process. They perform the real one, with its spreadsheets, phone calls and workarounds. Sit beside someone for an hour while they do the task. The workarounds show you exactly where the current system fails them.

Ask for examples, especially the awkward ones

General statements hide the difficult cases. Ask for a real document from last month, then ask what happens when it is wrong.

• What if the customer returns half the order?
• What if the approver is on leave?
• What happens at month end, or when the price changes mid-day?
• Who can correct a mistake, and until when?

Draw the process

A simple flow diagram with roles as lanes and steps as boxes exposes gaps faster than pages of text. Show it to the people involved and ask what is missing. They will correct a picture more readily than a document.

Write requirements that can be tested

A requirement such as the system should be user friendly cannot be built or checked. State who does what, under which rule, with what result, and attach acceptance criteria.

As a territory manager
I want to approve discount requests above the standard limit
So that exceptional discounts are controlled

Acceptance criteria
- Requests within the standard limit are approved automatically
- Requests above it appear in my pending list with customer and amount
- I can approve, reject or send back with a comment
- The requester is notified of my decision

These criteria later become the scenarios for user acceptance testing, which closes the loop.

Capture what is not a feature

• Volumes: how many users, documents per day, years of history.
• Performance: what response time is acceptable in the field.
• Access: who may see and change what.
• Integration: which other systems send or receive the data.
• Reports: what numbers management expects at the end.

Prioritize and confirm in writing

Not everything is needed on day one. Agree with the business what is essential for the first release and what can follow. Then write the agreed scope in plain language, walk through it together and get it confirmed. That document is not bureaucracy. It is what lets you tell a defect from a change request six weeks later.

Expect change, and manage it

Requirements will change as people see the software. That is healthy. Record each change, estimate its effect on time and decide together whether it goes into this release or the next. Moving from writing code to owning this conversation was the biggest shift when I went from developer to project manager.