A clear requirements brief is the single best way to get accurate quotes and avoid misunderstandings. You do not need technical knowledge. You need to explain who will use the system, what they must do and what it must connect to.
Section 1: Background
Describe your company, what you do and the problem the software should solve. Explain how the process works today and what goes wrong.
Section 2: Goals and success measures
List what should improve and how you will measure it. For example: "Reduce time to prepare a quotation from two days to two hours" or "Eliminate re-typing of orders into the ERP".
Section 3: Users and roles
List each type of user, roughly how many there are and what they need to do.
| Role | Number | Key tasks |
|---|---|---|
| Sales rep | 15 | Create quotations, check stock, track orders |
| Sales manager | 3 | Approve discounts, view pipeline |
| Customer | 500+ | Place orders, download invoices |
| Admin | 2 | Manage users, prices and settings |
Section 4: Key features
Write features as user stories: "As a sales rep, I want to create a quotation from a price list so that I can send it to the customer quickly." Mark each as must-have, should-have or nice-to-have.
Section 5: Data
What information does the system hold? Customers, products, prices, orders, documents. Where does it come from today, and how much is there?
Section 6: Integrations
List systems it must connect to: ERP, accounting, CRM, payment gateway, SMS, email, ZATCA e-invoicing, maps or government platforms.
Section 7: Reports and dashboards
Which reports do managers need, how often and in what format?
Section 8: Languages and design
Arabic, English or both? Any brand guidelines? Must it work on mobile?
Section 9: Security and compliance
Who can see what? Are there audit, data protection or hosting requirements? See our PDPL guide.
Section 10: Constraints
Budget range, deadlines, preferred technologies and anything already decided.
Section 11: Examples
Screenshots or links to software you like or dislike, with reasons.
Tips
- Focus on what, not how. Let developers propose the solution.
- Keep it short and clear; a few pages is often enough.
- Prioritise ruthlessly. Version one should solve the core problem.
Send your brief to our software development team and receive a fixed written quote within 48 hours. Also read the custom software buyer's guide.