How to Explain What You Need Your Software to Do

Explain one task from beginning to end

• What starts the task?
• What should be ready when it is finished?

Choose something staff do regularly, such as preparing a quote, booking a job or recording a delivery. Describe where the request arrives, who picks it up, which information they use and what they produce.

For a quote, that might mean receiving measurements by email, selecting materials from a price list, calculating labour, checking the total and sending a document to the customer. Mention where staff stop to ask a question or copy information into another program.

Then explain what you would like to improve. You might want the same customer details to carry through each step, or the price to update when the measurements change.

Bring examples of the work

A completed form, sample spreadsheet or quote is often easier to understand than a long list of features. Show what each part means, which details staff enter and which results the software should calculate.

Include an ordinary example and one that needed extra attention. A job with a discount, a changed delivery date or several delivery addresses can reveal requirements that a straightforward order would miss.

Use sample records or remove personal and confidential information before sharing files. If real records are needed later, agree on how they will be shared and who can access them.

Describe the rules people use

Business rules are the decisions the software needs to follow. These may already be written down, built into a spreadsheet or known by an experienced member of staff.

For example, a discount above a certain amount might need a manager’s approval. A job might require both an available installer and a particular vehicle. Explain the rule and show an example of the correct result.

If staff use different rules, record the difference and decide which should apply. It is fine to leave a question open at first, provided everyone knows it still needs an answer.

Explain who will use it and where

The person preparing a quote may need different information from the person carrying out the job. Describe each person’s tasks and what they should be allowed to view or change.

Include the conditions they work in. An office employee may use a large monitor, while a driver checks details on a phone. A workshop may need a barcode scanner, a shared workstation or a way to work when the internet connection drops.

List the programs and equipment you want to keep. Include their names and what information the new software should securely access or update; the developer can investigate the available connections.

Describe what a successful result looks like

• A broad requestMake quoting easier for staff.
• A result you can checkStaff can enter the measurements once, calculate the price, save changes, and send the final quote to the customer.

Both statements are useful, but the second gives you something to try during a demonstration. Add the details that matter: whether the price includes tax, who can change it and whether an earlier version must remain available.

Ask the developer to explain the proposed approach back to you. You should recognize your work in the explanation, even if some steps are being improved.

Separate the first release from later ideas

Keep a short list of what must work when staff start using the software. Keep other useful ideas beside it, with a reason for doing them later. This helps everyone discuss the size of the project without losing good suggestions.

The guide to choosing an MVP explains how to make the first version useful on its own. Once that is clear, it becomes easier to discuss cost and a delivery schedule.

Your next step

Write a one-page description of one task: what starts it, who takes part, the information they need, the rules they follow and the result you want. Attach a sample and list the questions you have not answered yet. That is enough to begin a useful planning conversation.