Creating a software requirements specification: step by step

If new software is to be introduced, replaced or extended, the next step is usually to obtain reliable quotes. That is exactly what a requirements specification is for: it describes goals, requirements and constraints from the client’s perspective. If this is your first time writing such a document, it does not need to sound perfect. Above all, it should be useful for follow-up questions, comparability and decision-making.

This article shows you the practical approach to writing one, not the technical details for developers. If you are looking for a complete outline instead, you will find the right structure in the requirements specification template with structure and contents.

Why a requirements specification is worth it before requesting quotes

Without clearly described requirements, quotes are often difficult to compare. The reason is simple: each provider fills in different gaps, focuses on different aspects and calculates on the basis of different assumptions. That makes decisions harder from the very start.

A requirements specification therefore makes the following clear before the first discussions:

• what the software is meant to achieve,
• what is included in the project scope,
• what expectations there are regarding the outcome and the collaboration.

This reduces misunderstandings early on. At the same time, the document also helps internally: the specialist department, IT and decision-makers are all working from the same understanding of the project. Especially for projects involving custom software and operations, this is a major advantage.

One important point: it is not just about functions. User groups, interfaces, data, reports, access rights and future operations also affect the quote request. And even if not every detail has been decided yet, it is still worth writing the document. Open points can and should be explicitly marked as open in the requirements specification.

If you initially only need a rough indication of cost, you can use the cost calculator for an initial range first. For the actual request, the article on software tendering is also helpful.

Step by step: how to write your requirements specification

When writing, do not start with functions. Start with your project. That way, you end up with a document that is genuinely useful for quotes and follow-up questions. If you would also like to see a practical sample, the example of what to include in a requirements specification is helpful too.

Step 1: Record the goals

Start by writing down which problem is to be solved. Is the aim to simplify an existing process, replace an old solution or extend an existing one? State the reason briefly and clearly: new development, replacement or extension.

Three simple questions can help here:

• What problem exists today?
• What benefit should the new software provide?
• How would you recognise internally that the project has been successful?

Goals like these make your requirements specification clearer. Instead of simply stating that “a new application is required”, it is better to describe what should improve from a business perspective, for example less duplicate data entry, faster approvals or a consistent data set.

Step 2: Describe users and roles

The next step is to record who will work with the software and in what way. Do not think only of the people entering data. There are often also users who only review, approve, analyse or administer the application.

A role groups together similar rights and tasks, so that requirements do not have to be described for each individual person.

Typical roles might include, for example:

• Case handlers
• Team leads
• Business approval
• Analysis or controlling
• Administration

This distinction will later help you describe access rights and processes clearly. It makes your requirements specification much more robust, especially when several departments are involved.

Step 3: Document the current process

Now briefly describe how the task is handled today. A few paragraphs or a simple sequence of steps is often enough. What matters is not a perfect presentation, but a realistic picture of the current situation.

In particular, note down:

• where Excel spreadsheets are used,
• which information is passed on by email,
• where data is entered more than once,
• where queries, waiting times or media discontinuities occur.

This current process is important because providers can use it to identify risks, simplification opportunities and sensible priorities. Many later changes arise not because functions were missing, but because the existing process was described too broadly at the start. If you want to explore this topic further, the article on subsequent changes to requirements provides a helpful overview.

Step 4: Formulate the functional requirements

Only after that should you write down the actual requirements for the software. Functional requirements are the specific capabilities the software should provide.

For first-time authors, a simple format is especially practical:

• As a [role], I want [goal], so that [benefit].

Examples might be:

• As a case handler, I want to create cases so that enquiries are recorded centrally.
• As a team lead, I want to approve entries so that changes can be reviewed and traced.
• As an analyst, I want to export reports so that I can reuse the data.

This format does not require detailed technical knowledge, but it still makes requirements tangible. If your requirements specification is later meant to become an implementation plan, the functional specification example shows what the next step can look like. And if you want structured feedback with open questions based on your draft, the project check is a useful next step.

Who should be involved and how to organise the work

If possible, do not write a requirements specification on your own. It makes sense to involve the specialist department, IT, the project owners and the people ultimately responsible for goals, priorities and approvals.

Each of these groups contributes a different perspective:

• Specialist departments know the processes, special cases and practical day-to-day obstacles.
• IT knows the existing systems, interfaces and technical constraints.
• Decision-makers ensure that goals, priorities and scope fit together.

Clear responsibility is important here. One person should collect the content, structure it and consolidate it into a single coherent document. Otherwise, you can easily end up with a collection of individual contributions containing gaps, contradictions or duplication.

In practice, a simple approach works well: first clarify the goals and the current process in one meeting. Then consolidate the requirements in writing. In a second round, review open points, missing priorities and unclear terms in a focused way.

Use concrete day-to-day examples, such as typical cases, forms, lists or reports. Documents like these often make requirements easier to understand than abstract descriptions.

Experience shows that early alignment helps reduce later change requests. A change request is a subsequent change to requirements during the project. For more complex projects, an early prototype can also make sense in order to sharpen processes before implementation.

Requirements specification and functional specification: who writes what?

The requirements specification describes what is needed and why, from the client’s perspective. In other words, it records the business goals, requirements and constraints.

The functional specification is the provider’s response based on that. It describes how the requirements are to be implemented and what the concrete project approach will look like.

This distinction is useful because the business perspective initially remains clear and independent of any technical solution. Only in the next step are implementation, structure and approach worked out in more detail.

Important for first-time authors: a good requirements specification does not need to anticipate the technical architecture. So you do not need to know every implementation decision in advance.

If providers ask follow-up questions, that is not a sign of a poor requirements specification, but part of the refinement process. The functional specification example shows how the two documents work together.

Common gaps in a requirements specification – and how to close them

Typical gaps do not arise only from missing functions, but often much earlier in the way the project is thought about. If you want to plan software properly, these points are especially helpful:

• Solution too early instead of the problem: first describe the business goals and the current process before defining individual functions or technologies.
• Unclear terms: define key terms such as case, customer, site or measure briefly and consistently.
• Missing priorities: long wish lists without weighting make quotes harder to compare.
• Forgotten constraints: think about user login, the existing Microsoft 365 environment, data migration, reports, documents or mobile use.
• Undescribed interfaces: connected systems often have a major impact on effort and risk.
• Lack of testability: add acceptance criteria to important requirements, i.e. specific characteristics by which fulfilment can be recognised.
• No thought given to growth: sustainably planned software makes later extensions easier and helps avoid technical debt. Technical debt means additional future effort caused by short-term solutions that are not sufficiently robust.

At ballmüller solutions, projects such as a web platform for managing sewer networks, conditions and measures or a CRM repeatedly show that clear requirements make later coordination much easier.