Systems analysis and requirements documentation
We map the procedure as it is actually practised — in the committee, in the budget — then write it as a requirements document (SRS) any team can build from without guesswork.
We sit with the people who practise the procedure daily, not with those who describe it from a distance, and we map it as it actually runs: who submits, where it stalls, who signs, and what sends it back. Then we write it as a document to be signed before a single line is written.
What we write
- A map of the procedure as it is practised, with its checkpoints, roles and states.
- A requirements document (SRS): every screen, every field, and every rule governing a transition.
- A list of the decisions to settle before building, and who has the authority to settle them.
- Exception cases: what happens when a request is rejected, exceeds its deadline, or the approver is away.
- Acceptance criteria: how you will know that what was delivered matches what was agreed.
For
An organisation about to commission a system, or one with an in-house technical team that needs a document to build from.
What you get
- A map of the procedure as actually practised, with its roles and checkpoints
- A requirements document any team can execute
- A list of open decisions to settle before building.
We start on paper, before the code
- We understand the procedure
- We document it
- We build
- We hand over and run a trial
- We support and operate
Questions about this service
We have a developer in-house — what is the document for?
Your developer knows the organisation and its people, and that's an advantage we don't have. But what usually stalls these projects isn't the programming: it's getting the procedure written down as it is actually practised, settling who owns changing it, and producing the document that gets signed before building begins — work that is hard for someone inside the organisation who is party to its procedures.
Are we then committed to building with you?
No. The document belongs to your organisation and can be implemented by any team you choose. That is the whole point of it: that competing proposals are measured against one written specification rather than against scattered promises.
How long does it take to write?
It depends on the number of workflows and on the availability of the people who practise them for sessions. The timeline is set out in the proposal for each project.
We work with organisations across all regions of Saudi Arabia and the Gulf — remotely, with site visits when needed.