“We want to manage purchase requests in one place” is a useful starting point, but it leaves a supplier with a lot to guess. Who submits a request? Who can return it? What happens after approval? Software requirements analysis turns the request into a scope that different suppliers can estimate on the same basis.
If you are still deciding whether to buy a tool, adapt your current system or commission development, start with the differences between custom software and ready-made products. Once the development need is clearer, use the following six preparations to work toward a quote. If the current process runs in Excel, separate problems a better workbook process can solve from rules that need an application before adding features to the brief.
1. Define the Business Problem Before the Features
Describe the work that is going wrong before asking for a dashboard. Imagine a purchasing team that handles requests by email. Missing product details arrive in separate messages, and employees cannot tell who is holding up an approval. A useful starting goal is to make each request’s status and current owner visible.
Ask the people doing the work to walk through a few recent examples. Where did a request wait? Which detail was missing? Who had to step in? If you have no baseline, avoid promising to halve approval times. First decide how you will record current delays and their causes.
The GOV.UK guidance on understanding user needs separates what people need to achieve from proposed solutions. Applied to a business project, that means checking management’s assumptions against the experience of the people who actually perform the task.
2. Map the Usual Path and the Exceptions
A first sketch of the purchasing workflow might read: submit, review, approve. Make it more useful by asking what happens when a product code is missing, the approver is away or an approved request needs changing. Unresolved handoffs can introduce more work than the initial screen list suggests.
Put a role beside each transition. A requester, reviewer and approver might sometimes be the same person, but the permissions still need to be described separately. If a manager should only see requests from their own department, say so before the scope is estimated.
Bring a sample request form with personal and commercially sensitive information removed, plus a walkthrough of a difficult case. Concrete material gives the delivery team something to discuss when you ask for software that is easy to use.
3. Turn Requests into Requirements You Can Check
A requirement describes an expectation the software must meet. Functional requirements concern behavior, such as returning a request with a reason. Nonfunctional requirements concern qualities or constraints, such as response time, accessibility or recovery after an interruption. “Fast and secure” leaves both the implementation and the review open to interpretation.
| Initial Request | Detail Needed for the Quote |
|---|---|
| People should see their own work | Requesters see their own records; department managers see requests within their responsibility. Agree how access changes when a person changes roles. |
| Send incomplete requests back | The reviewer adds a reason. The requester can read it, correct the record and resubmit it for review. |
| Reports must load quickly | Agree which report, dataset size, concurrent user load and response-time target the team will assess. |
| Keep a history | Store the time, actor and explanation for status changes. Define who can read the history and how long it is retained. |
Describe permissions beyond the buttons people can see. Hiding an approval button does not, by itself, stop the same action through another route. The OWASP authorization guidance recommends checking permissions on every request. Your contribution as the business owner is to explain who should be able to do what, and to which records.
Give performance expectations a context as well. A demonstration with a handful of records may tell you little about a busy working day. Microsoft’s guidance on performance targets ties measurable targets to the workload. Agree suitable thresholds for your operation instead of copying numbers from another project.
4. Identify Data and External Connections
Break “connect it to accounting” into specific exchanges. Will the accounting system supply product records? Should an approved request create a purchase order? Which system holds the authoritative record? If a value can change in both places, the team needs a rule for resolving conflicting updates.
An API is an interface through which software exchanges data under defined rules. An existing API does not necessarily support every operation you need. The technical team should check permissions, supported fields, usage limits and a way to test the connection. Use five API integration planning questions to define the records being transferred and responsibility for failures. When a subscription service is involved, understanding the responsibilities of a SaaS provider and its customer can help you frame the questions.
- Which old records will move, and which will remain in an archive?
- Who will clean up missing values or duplicate records?
- How often does the information need to move?
- What will users see if the connection fails, and who will follow it up?
For the first discussion, prepare product names, versions and available technical documentation rather than production account passwords. If the team needs sample data, begin with a sanitized example and agree the conditions for reviewing real data separately.
5. Set the First Release Boundary
The initial release should let people complete a useful task from beginning to end. In the purchasing example, that might include submitting, reviewing, returning and approving requests, with status tracking throughout. Advanced spending forecasts or supplier scoring could wait. Removing an approval permission that the workflow depends on, however, may leave a smaller scope that cannot do its job.
Label each need as part of the first release, a later phase or an open decision. Give open decisions an owner and a date. The Atlassian product requirements template offers useful places for assumptions, open questions and exclusions. Use those prompts to organize decisions rather than treating a completed template as proof that the analysis is finished.
If a critical integration has not been shown to be feasible, do not list it as a confirmed part of delivery. Define the technical investigation separately and explain how its findings could change the development decision or the assumptions behind the quote.
6. Agree Acceptance Expectations and Quote Assumptions
An acceptance criterion describes an observable result that must be present before a feature is accepted. For a returned purchase request, changing the status may not be enough: the requester should see the reason, the corrected request should re-enter review and the previous history should remain available. Business and delivery teams need to agree which outcomes the workflow requires.
Microsoft’s user story guidance connects clear expectations with acceptance tests. You do not need every test case written before requesting a quote, but the supplier should understand what a successful critical workflow looks like.
Send suppliers the same dated scope. Ask which version their quote covers, what they have assumed, what they need from you and how later requests will be assessed. An early estimate based on unresolved questions does not offer the same certainty as a quote tied to agreed deliverables.
Requirements can develop as the team learns. The Scrum Guide describes the product backlog as an evolving list of work. The aim is to make changes deliberately: agree their effect on scope, schedule and budget before acting on them. When reviewing the fee for a change, revisit the scope uncertainties affecting the software quote as well.
Let’s Turn Your Software Idea into a Workable Scope
You can start a conversation with the tools you use, the process that causes trouble and the first task you want to improve. At Metazen, we build the software plan around users, workflow and data. Meet the team behind our software and integration work, then explore how our custom software service takes a project from requirements analysis to a working first release.
