Most software problems start with unclear requirements. You don't need to be technical to write good ones – you need to describe what people should be able to do and how you'll know it works.
Start with goals
Before features, write down why the project exists: "Reduce time to create a quote from 45 to 10 minutes" or "Let customers book appointments online 24/7."
Describe users and roles
Who will use the system? Sales staff, warehouse workers, customers, administrators. Each role has different needs and permissions.
Use user stories
A simple format: "As a [role], I want [action] so that [benefit]."
Example: "As a technician, I want to see today's jobs on my phone so that I don't need to call the office."
Add acceptance criteria
How do we know the story is done? For the example above:
- Jobs are sorted by appointment time
- Each job shows address, customer contact and task description
- The list works without internet connection
- New jobs appear within 5 minutes after the office assigns them
Don't forget non-functional requirements
- Performance: pages load in under 2 seconds
- Security: two-factor login for admins
- Availability: system available during business hours with backups
- Compliance: GDPR, GoBD for financial documents
- Usability: usable on tablets with gloves, in German and English
Prioritise
Mark each requirement as Must, Should, Could or Won't (for this phase). A clear MVP keeps budget and timeline realistic.
Include examples and data
Real documents, screenshots of current tools, sample data and edge cases help developers understand faster than long descriptions.
German terminology
In Germany you'll hear Lastenheft (what the client needs) and Pflichtenheft (how the supplier will implement it). In agile projects these become a product backlog that evolves.
Let us help
Our AI project assistant asks the right questions for your field and turns your answers into a structured brief – a great first version of your requirements.