Requirements Management
The client knows what they want. The developers know how to build it. The problem is that these two groups speak different languages - and without someone to translate between them, the project goes in the wrong direction before a single line of code is written.
What this engagement covers
Functional requirements are the document that sits between a business need and a working system. They describe how the system should behave from the user’s perspective: what goes in, what comes out, who does what, in what sequence, under what conditions.
The most common failure mode in software projects is not technical - it is that the requirements were never properly captured in the first place. The client assumed things were obvious. The developers assumed they understood. Neither assumption was correct.
There are two reasons this happens. First, the people who know the process best - the ones doing the work every day - assume that anyone can see what they see. The details that seem self-evident to them are invisible to an outside developer with different experience and a different mental model. Second, when those same people are asked to write down what they want, they treat it as an interruption to their real work and produce something minimal and incomplete.
The solution is a dedicated person from outside the organisation, for whom this documentation work is the primary task - not a distraction from one. Someone who asks the questions that feel obvious to the client but are not obvious to the developer. Who structures the answers into a document that works for both sides. Who validates that what is written matches what was meant.
The output is a functional requirements document - not a technical specification with variables and data structures, but a precise description of how the system should work from the user’s point of view. Supported, where useful, by process diagrams, interface sketches, data format tables, and worked examples.
How it works
Trade equipment management system - functional requirements for a retail chain
A retail company operating a network of stores needed to build a web-based system to manage the lifecycle of trade equipment - the furniture, fixtures and inventory used in stores. The process involved six participant groups, four IT systems, and five distinct sub-processes: supplier ordering, delivery, stock accounting, returns and inter-store transfers. None of this had been formally described as system requirements. The project was to document what the system needed to do, in enough detail that a development team could build it.
The requirements document covered the full equipment lifecycle. For the ordering sub-process alone: the document specified the exact data fields and format of the order table, the sequence of approvals and who triggers each, the automatic notifications at each stage (with recipients, timing and conditions), the supplier confirmation flow via a web link, the status progression in the order register, and the logic for handling new articles not yet in the ERP system. Similar detail was produced for each of the five sub-processes. The document included process diagrams for each flow, a status reference table for both order status and document status (treated as two independent state machines), role and access definitions for all six participant groups, notification trigger logic, and worked examples for exception cases - including partial deliveries, price corrections, and equipment returns.
Each process module was structured identically: a BPMN process diagram, a narrative description of each step, a status transition table, a notification rules table (trigger, recipient, timing, content), and a list of edge cases and exception handling rules. The document was validated with all six participant groups before sign-off and handed directly to the development team as the basis for technical specification and development scoping.
