Requirements and discovery is the stage where a business decides what a system needs to do before anyone writes a line of code. Get this wrong and the resulting application will solve the wrong problem, arrive late, or cost far more than necessary. Get it right and every subsequent decision — from architecture to acceptance testing — has a stable foundation.
This guide covers how to gather requirements, run discovery workshops, interview stakeholders, prioritise features, write a brief, choose between user stories and use cases, manage changing requirements, involve end users and define what success actually looks like.
| Start here | What the section helps you decide | Practical outcome |
|---|---|---|
| How to Gather Business Software Requirements | The most common mistake in requirements gathering is starting with a list of features rather than a clear description of the problem. | A business owner who says "we need a dashboard" is describing a solution. |
| How to Run a Discovery Workshop for a Web Application | A discovery workshop brings the right people into a room (or a video call) for a focused session designed to extract, challenge and organise requirements. | The output should not be a finished specification but a shared understanding of the problem space and a clear list of open questions. |
| Stakeholder Interviews for Software Projects | Workshops are efficient for shared processes, but some requirements only emerge in one-to-one conversations. | A finance director may not disclose regulatory reporting constraints in a group setting. |
| How to Prioritise Software Features | If every requirement is marked as critical, nothing is. | Prioritisation forces the business to make explicit trade-offs, which is precisely what makes it uncomfortable and therefore valuable. |
How to Gather Business Software Requirements
The most common mistake in requirements gathering is starting with a list of features rather than a clear description of the problem. A business owner who says "we need a dashboard" is describing a solution. The requirement underneath might be "the operations director needs to see which orders are overdue without calling the warehouse." Those two statements lead to very different systems.
Start with the current process. Walk through what happens today, step by step, including the workarounds people have invented to cope with gaps in existing tools. Note where data is re-entered, where approvals stall, and where errors appear. These friction points are the raw material for requirements.
Separate three categories clearly:
- Functional requirements — what the system must do (validate an order, send a notification, generate a report).
- Data requirements — what information the system holds, where it comes from, how long it is kept and who can see it.
- Non-functional requirements — performance, availability, security constraints and integration points with other systems.
Non-functional requirements are the ones most often omitted, and they are frequently the source of disputes later. If the system must respond within two seconds, or must be available during a specific peak window, or must store data within a particular jurisdiction, say so at this stage rather than during testing.
Document assumptions explicitly. If you assume the new system will use the existing customer database structure, write that down. Assumptions that remain unspoken become disagreements when a supplier builds something different.
How to Run a Discovery Workshop for a Web Application
A discovery workshop brings the right people into a room (or a video call) for a focused session designed to extract, challenge and organise requirements. The output should not be a finished specification but a shared understanding of the problem space and a clear list of open questions.
Who should attend
Include people who understand the current process, people who will use the new system, and someone with authority to make decisions about scope and trade-offs. Avoid the temptation to fill the room with observers — every attendee should either contribute knowledge or approve decisions. A typical workshop for a CRM or portal project might include an operations manager, two or three frontline users, a finance representative if billing is involved, and a decision-maker from the business side.
Preparation
Circulate a brief agenda at least a few days in advance. Include the goals of the session, the process steps you intend to walk through, and any pre-work such as "bring a screenshot of the current spreadsheet you use for this task." Without preparation, the workshop will spend its first hour on context that could have been gathered beforehand.
Structure
Open with the business objective: what problem the project is trying to solve and what outcome would constitute improvement. Then walk through each major process or user journey. For each one, capture the happy path, the common exceptions and the edge cases that people hesitate to mention because they assume they are too specific. Those edge cases — a customer with two accounts, an order that skips a step, a document that needs approval from two directors — are where requirements get expensive if they surface late.
Close by reviewing what you have captured, flagging open questions and agreeing who will answer them and by when.
What to avoid
Do not allow the workshop to become a design session. Discussing button placement or colour schemes at this stage consumes time without clarifying requirements. Do not let one vocal stakeholder dominate. If two departments disagree about how a process should work, note the disagreement and assign it to a decision-maker rather than attempting to resolve it in the room with no authority present.
Stakeholder Interviews for Software Projects
Workshops are efficient for shared processes, but some requirements only emerge in one-to-one conversations. A finance director may not disclose regulatory reporting constraints in a group setting. A customer-support team leader may describe workaround scripts that the operations manager has never seen.
Structure each interview around the interviewee's daily work. Ask them to talk through a real recent task — not a hypothetical one — and explain where they encountered friction, delay or error. People describe their actual behaviour more accurately than they predict their ideal behaviour.
Listen for implicit requirements. If someone says "I always export the data to Excel and sort it by region," the requirement is not an export button — it is the ability to view data filtered by region within the application. If someone says "I keep a separate notebook because the system doesn't remember the last time I spoke to the client," the requirement is a chronological interaction history.
After each interview, write up the findings and send them to the interviewee for confirmation. This step catches misunderstandings while the conversation is still fresh and gives the stakeholder a sense that their input has been heard — which matters when you later ask them to participate in testing.
Handling conflicting requirements
Different stakeholders will describe the same process differently. A sales manager may say leads are assigned automatically; a salesperson may say they pick their own from a shared pool. Both may be describing local practice rather than official policy. When conflicts arise, document both versions, identify who has the authority to resolve the discrepancy, and escalate rather than guessing.
How to Prioritise Software Features
If every requirement is marked as critical, nothing is. Prioritisation forces the business to make explicit trade-offs, which is precisely what makes it uncomfortable and therefore valuable.
The MoSCoW framework — Must have, Should have, Could have, Won't have — is widely used because it is simple to explain. In practice, its effectiveness depends on enforcing the definitions rigorously:
- Must have: the system does not solve the core problem without this. If it is missing, the project fails.
- Should have: important but there is a workable workaround for the initial release.
- Could have: desirable, adds value, but can be deferred without significant consequence.
- Won't have: explicitly excluded from this release. Recording these prevents them from reappearing later as "we assumed that was included."
A common failure mode is placing too many items in "Must have." If more than roughly half of your features are marked as must-haves, the prioritisation exercise has not worked. Push back by asking: "If this feature were not ready on launch day but arrived four weeks later, would we delay the entire launch?" If the answer is no, it is not a must-have.
Also prioritise by risk. A feature that depends on an unproven integration or a third-party API with limited documentation carries more uncertainty than a feature that operates entirely on your own data. Flagging high-risk requirements early allows the discovery phase to investigate feasibility before the project commits to a timeline.
How to Write a Software Brief
A brief is not a specification. A brief communicates the business context, the problem, the constraints and the desired outcome at a level of detail sufficient for a supplier to decide whether they can help and to propose a discovery or scoping process. A specification, by contrast, defines exactly what the system must do in enough detail for a developer to build it.
A useful brief includes:
- Business context: what the organisation does, why this project matters now, and what business outcome it needs to achieve.
- Current state: what tools or processes exist today, what works and what does not.
- Users: who will use the system, roughly how many, and their level of technical comfort.
- Core requirements: the main things the system must do, expressed as outcomes rather than features.
- Integrations: other systems the new application must connect to, and what data flows in each direction.
- Constraints: fixed deadlines, regulatory requirements, data-residency rules, technology preferences or restrictions.
- What is out of scope: explicitly stating what the project will not cover prevents scope creep later.
- Success criteria: how the business will judge whether the project has delivered value.
The most common omission is the "what is out of scope" section. Without it, suppliers will make different assumptions about boundaries, and their proposals will be impossible to compare fairly.
Keep the brief concise. Five to ten pages of clear, specific prose is more useful than thirty pages of vague description. A supplier reading the brief should be able to identify whether the project is within their capability and what questions they need to ask before proposing an approach.
User Stories vs Use Cases: What Business Owners Should Know
Both user stories and use cases are ways of describing what a system should do from the perspective of the people who use it. They serve different purposes, and choosing the wrong format can create confusion between a business and its development team.
User stories
A user story follows a simple structure: "As a [type of user], I want to [do something] so that [I achieve a goal]." The strength of this format is that it keeps the focus on the user's purpose rather than on a prescribed solution. It also leaves room for the development team to propose the best technical approach.
User stories work well when the system is being built iteratively and the detailed behaviour will be defined through conversation and acceptance criteria during development. They are less effective when a business needs a fixed-price contract with clearly defined deliverables, because the stories alone do not contain enough detail to prevent interpretation disputes.
Use cases
A use case describes a complete interaction between a user and the system, including the starting conditions, the main flow of events, alternative paths and the end state. It is more detailed than a user story and more prescriptive about how the interaction should work.
Use cases are useful for complex processes with multiple branches — for example, an order-approval workflow where the path depends on the order value, the customer's credit status and the approver's response. They give a supplier less room to interpret requirements differently from what the business intended.
Which to use
For most business-system projects — CRMs, portals, internal tools — a combination works well. User stories for straightforward features, use cases for processes with significant branching logic. What matters is that the format is agreed before the contract is signed, so that both sides have the same expectation about the level of detail in the requirements document.
How to Handle Changing Requirements Mid-Project
Requirements change. A competitor launches a feature, a regulator updates a rule, or the business simply learns more about its own process once it sees an early version of the software. Treating all change as a problem guarantees either a rigid system that does not fit or a project that descends into blame.
The practical question is not whether change will happen but how it will be managed. A change-control process does not need to be bureaucratic. It needs to answer three questions for every proposed change:
- What exactly is being added, removed or modified? — described clearly enough that a developer could estimate the work.
- What is the impact on timeline and cost? — even a rough indication allows the business to make an informed decision.
- Who approves the change? — a single named decision-maker, not a committee.
Common mistakes include allowing developers to accept changes directly from stakeholders without recording them (which makes the project untrackable), and taking so long to approve changes that the business loses the opportunity the change was meant to address.
Some changes are not changes at all — they are requirements that should have been captured during discovery. If the same type of change request appears repeatedly, the root cause is likely a gap in the original requirements process rather than stakeholder indecision. Investigate the pattern rather than just processing each request individually.
For projects working under a fixed-price contract, the change-control mechanism should be defined in the contract itself, including how estimates for changes will be produced and how they will affect the delivery schedule. Without this, every change becomes a negotiation.
How to Involve End Users in Requirements Gathering
End users are the people who will interact with the system daily. They are not the same as stakeholders. A stakeholder might be a director who sponsors the project; an end user is the person processing orders, answering customer queries or generating reports. Both perspectives are necessary, but they reveal different requirements.
End users are particularly valuable for identifying:
- Workarounds: informal processes they have developed to compensate for limitations in current tools.
- Sequence dependencies: the order in which they actually perform tasks, which may differ from the official procedure.
- Context-switching: how often they move between systems to complete a single task, which indicates where integration would reduce effort.
- Error patterns: the mistakes they make most often and what causes them.
The risk of involving end users is scope creep. A user who has struggled with a poor tool for years may produce an extensive wish list that reflects frustration rather than genuine requirement. Mitigate this by focusing conversations on the task, not the tool. Ask "what are you trying to accomplish?" rather than "what should the new system do?"
Practical methods include shadowing — observing a user as they work through a real task without interrupting — and structured walkthroughs where the user describes each step of a process while you capture it. Group sessions with end users can work but require careful facilitation to prevent the loudest voice from setting the agenda.
Involve a representative sample rather than every user. If you have twenty people doing the same role, interviewing four or five will typically capture the common requirements and the main variations. Beyond that, diminishing returns set in quickly.
How to Define Success Criteria for a Software Project
Success criteria are the conditions that must be met for the business to consider the project delivered. Without them, "done" is a matter of opinion, and handover becomes a negotiation.
Good success criteria are specific, measurable and tied to the original business problem. "The system is easy to use" is not a success criterion. "A new user can complete a standard order entry without training in under five minutes" is.
Include criteria in these categories:
- Functional completeness: every must-have requirement works as described in the acceptance criteria.
- Data accuracy: data migrated from the previous system matches the source to an agreed threshold, and new data entered through the system is stored and retrieved correctly.
- Integration verification: data flows to and from connected systems produce the expected results in both directions.
- Performance: the system meets the response-time and concurrency requirements defined during discovery.
- User acceptance: a defined group of end users has tested the system against real tasks and confirmed it is fit for purpose.
Agree success criteria before development begins and include them in the project documentation. If a supplier proposes vague criteria such as "the system meets the client's reasonable expectations," push for specificity. "Reasonable" means different things to different people, and that ambiguity will work against the business at handover.
Also define what happens if criteria are partially met. If the system passes on functionality and data accuracy but fails on one integration, is that a blocking issue or something that can be resolved in a post-launch support period? Establishing these thresholds in advance prevents the final weeks of a project from turning into a dispute over whether the work is finished.
Finally, distinguish between project success criteria — the conditions for accepting the delivered software — and business success criteria — the measures that will determine whether the investment was worthwhile over time. The first set belongs in the contract. The second set should be defined before the project starts but reviewed months after launch, once the system has been in real use long enough to produce meaningful data.