What should be included in a requirements specification?

What belongs in it

Current situation

How does it work today? Which systems, which tables, which forms?

Goal

What should be different afterwards – preferably measurable. "Less effort" is not a goal. "Reducing quotation creation time from 40 to 10 minutes" is.

Processes with special cases

The normal case is easy to describe. The costs are in the exceptions: What happens in a cancellation? In a partial delivery? In a customer without a tax number? Answering these questions early is the greatest lever for a reliable estimate.

Affected systems

Which systems need to be integrated, who operates them, is there a documented interface?

Data volume

How many data records, how many users, how many processes per day? This decides the architecture.

Framework conditions

Deadlines, budget, legal requirements, where the data may be stored.

What does not belong in it

Technical specifications without reason. "Must be developed in PHP" is only meaningful if you plan to maintain it yourself. Otherwise, it restricts without benefit.

Solution descriptions instead of requirements. "A button that does X" does not reveal which problem X solves – and prevents someone from suggesting a better solution.

If you cannot write a requirements specification

This is not a barrier. Often, it is more useful to jointly conduct a requirements analysis – one or two meetings where the process is documented and organized. The result is better than a document created on the fly.