How to Write Software Requirements Without Being Technical

Introduction

A seven-year, five-hundred-million-euro project was cancelled not because the software was bad, but because nobody could clearly explain what it needed to do. That is what happened to Lidl, one of the largest supermarket chains in the world. The project was built on SAP, a system used without this kind of problem by thousands of other companies. The failure was not in the technology. It was in how the business explained what it needed built. The same mistake repeats itself, on a smaller scale, every time a non-technical manager tries to describe a system, an app or a feature to a development team. This article teaches you how to write software requirements with a five-question method that requires no coding knowledge at all.

Why poorly written requirements cost so much: the Lidl case

A study by BCG interviewed executives across twenty-five different industries to understand why technology projects run late and over budget. BCG is a global strategy consulting firm. The answer was not a lack of good technology. It was a lack of alignment between the people asking for the system and the people building it. When the business objective is not clear from the start, the technical team fills the gaps the only way it can: with assumptions. And assumptions in a software project have another name, one every manager has felt firsthand: rework.

That is exactly what happened at Lidl. Each internal team interpreted the requirements its own way, because the business rules were never documented in a unified form. Without that alignment, the project kept accumulating customization on top of customization until nobody could control what the system was actually supposed to do anymore. Seven years later, the solution was to cancel the project entirely.

The good news for anyone reading this is that most managers do not need to learn how to code to avoid this scenario. They need to learn how to describe what they want with enough clarity that the technical team does not have to guess. That is the core of any solid software requirements gathering process, and it is a skill built through practice, not through a programming course.

The most common mistake: describing the solution instead of the problem

The most common mistake that shows up when a client comes in with a software request is this: describing the solution they imagined instead of the problem they need to solve. It is one of the most expensive mistakes in writing a good software requirement, because the request sounds clear when it actually hides a set of unanswered questions.

The classic example is the request: "I need a button that generates a PDF report." It sounds specific, but it is not. Which report? With what data? For whom? How often? What does this person do with the PDF once it is generated? Without those answers, the technical team only has two options: ask everything again, or build exactly what was requested, even if it does not solve the real problem.

Maybe the right answer to that request is not even a button that generates a PDF. Maybe it is a dashboard that shows the information in real time, with nothing to generate at all. That only surfaces when someone asks what problem sits behind the request, instead of accepting the ready-made solution the client already had in mind. Describing the problem is what gives the technical team room to find the best path forward, and it is almost never the first path that came to the requester's mind.

When you describe the solution you imagined, you limit the technical team's options. When you describe the problem, you make room for the best solution to appear.

How to write software requirements: the five questions that organize any requirement

There is a simple method to avoid that mistake, and it works in practice as a software requirements guide for non-technical managers to use before any scoping meeting. Every time you need to describe a feature, a system or an app to a development team, you can run through the five questions below. The answers do not need to be perfect. They need to be honest, and that is what turns a vague request into a software project brief that any team can execute without guessing.

• 1What problem am I trying to solve? Not what the system should do, but what pain exists today. "My team spends four hours a day consolidating sales data in manual spreadsheets" is a clear problem any technical team can attack.
• 2Who is going to use this day to day? An operations manager has different needs than a financial analyst. Describe what this person does today, step by step, to solve the problem without the system: that changes completely how the solution should be designed.
• 3What already exists today? Which system, spreadsheet or manual process is currently in use. A software project almost never starts from zero, and mapping this from the beginning avoids the surprise of an integration nobody planned for.
• 4How will I know if it worked? "The system needs to be fast" is not a success criterion. "The report needs to generate in under three seconds" is. Defining what done means before starting avoids the endless cycle of adjustments where nobody ends up satisfied.
• 5What absolutely cannot happen? Sometimes it is easier to define the boundaries than the destination. "The system cannot approve a request without the manager's signature" protects a business rule that cannot be broken, and constraints like this matter as much as any new feature.

How to apply the method in practice: the case of a healthcare clinic chain

A few months ago, the operations director of a healthcare clinic chain came in asking for "an app for patients," in his own words. Running the five questions in that first meeting completely reshaped the project's scope.

The real problem was not a missing app: it was that patients were calling the clinic to confirm appointments, reschedule times and ask for test results, and the front desk could not keep up with the volume. The real user was not just the patient either. It was the receptionist, who needed a dashboard to manage all of this in one place. The system also needed to integrate with the electronic health record the clinic already used, because building a parallel patient registry would have created more problems than it solved.

The success criterion defined was cutting incoming front desk calls by at least forty percent. The non-negotiable constraint was that no patient data could be stored outside the clinic's own servers. It came straight out of the question about what absolutely could not happen.

With those answers in hand, the scope was clear before a single line of code was written, and that is exactly what lets you define a software project's scope with real predictability. The project was delivered on time and the clinic hit its call-reduction target by the second month of operation, without the development team having to guess anything along the way.

Business requirements vs technical requirements: what is the difference

The answers to the five questions form what is called a business requirement: the problem and the context the manager describes, without needing any technical vocabulary. This is the material any operations director, product owner or founder can produce alone, in a meeting or a simple document.

From there, the technical team's job begins: translating that business requirement into functional and non-functional requirements. A functional requirement describes what the system must do. A non-functional requirement describes how the system must behave while doing it, such as response time, data security level or service availability.

Understanding this difference avoids a common trap: managers trying to write functional and non-functional requirements without the technical vocabulary for it, ending up with a confusing document that blends the two. The job of a non-technical person is to deliver a solid business requirement. Translating it into engineering terms is the development team's job, not the job of the manager who opened the project.

How to turn the answers into a document your technical team understands

After answering the five questions for each feature, the next step is organizing those answers into a software requirements document for non-technical managers that does not depend on anyone re-explaining everything on a call. The most common mistake here is mixing everything into a single block of text, where it becomes hard to tell which answer belongs to which feature.

1. 1Separate by featureTreat each feature, screen or flow as an independent block, with its own five answers, instead of describing the whole system at once.
2. 2Structure every block the same wayProblem, user, current context, success criterion and constraint, always in that order, so the technical team knows exactly where to look for each piece of information.
3. 3Use plain languageWrite with the same words you would use in a conversation, without forcing technical vocabulary that not even the manager fully commands. A concrete example is worth more than an abstract definition.
4. 4Share it before the scoping meetingSend the document to the technical team ahead of time. Follow-up questions come more targeted when everyone has already read the same material.

This requirements mapping, by the way, is exactly the starting point of the Agence methodology, which organizes every project from requirements gathering through continuous delivery, instead of treating this step as one more bureaucratic document at the start of the project.

When it is worth calling a consultancy to help with requirements gathering

Not every requirements gathering process needs outside help, but a few signs suggest it is worth getting specialized support before opening the project. Projects that involve integration with several existing systems tend to hide business rules that only surface when someone experienced asks in the right places. That is common in integrations with an ERP or an electronic health record, for example. Teams that have never run a structured requirements gathering process before also benefit from a proven method, instead of learning by trial and error in the middle of a real project, especially in web development projects that need to connect to legacy systems without repeating past mistakes.

A recent history of rework is another clear sign that it is worth getting help to avoid scope creep in software projects. The same goes for past projects that blew past deadlines due to a lack of upfront alignment. Tight deadlines and budgets make this even more pressing, because the cost of a poorly written requirement only shows up after development has already started. When there is nobody available to run this gathering process internally, an IT outsourcing team can take on the requirements mapping alongside the rest of the development work, whether for web or mobile projects.

Frequently asked questions about software requirements

Start your project with a clear scope, before the first technical meeting

The five-question method is the same requirements mapping Agence uses as the first step in web development, app development and IT outsourcing projects. If you are planning a system, an app or a new feature, talk to our specialists before opening the project.

Talk to a specialist