A new system needs rules: who approves a purchase, which tasks must finish before a new starter is ready, and when a customer enquiry can be closed. Leaving those decisions until configuration forces the delivery team to fill in the gaps.
A business process map puts decisions alongside the activities and people involved. These three illustrative examples show how to translate that picture into software requirements. Adapt the roles and rules to your organisation.
Start with the process as it works today
Identify the event that starts the process and the outcome that ends it. Keep activities at a comparable level of detail: a map showing approval responsibilities has little use for individual mouse clicks.
A flowchart shows sequence and decisions. In a swimlane layout, activities sit in lanes for the people or teams performing them, exposing hand-offs between departments.
Keep current practice separate from proposed improvements, a distinction made in the Improvement Service’s mapping guidance. A map agreed with the people doing the work supports IT project management by giving the delivery team explicit workflow rules and responsibilities on which to base requirements.
1. Purchase approval: make decision rules visible
Take an internal request to buy equipment. This process begins when an employee submits the request and ends when an approval or rejection is recorded and communicated. Equipment delivery belongs to a later process.
Example flow:
Request submitted → information complete?
No → return to requester → correct and resubmit.
Yes → select authorised approver → approve or reject → record decision and notify requester.
The requester supplies the description, estimated cost and business reason. The approver assesses the request within their spending authority. Show how that person is selected: a request above their limit needs routing to a different authorised approver.
An incomplete request returns for correction; a rejected request closes with a recorded decision. Keep those outcomes distinct.
Translate the map into a required-field check before approval routing. Test it by submitting a request without an estimated cost. The system should identify the missing field and offer a correction route before passing the request to an approver.
2. Employee onboarding: show dependencies and ownership
Some onboarding tasks depend on approval. Others can proceed alongside it.
Example flow:
HR confirms starter → manager approves role and access needs → IT provisions approved access → manager confirms readiness.
Parallel branch: HR confirms starter → IT prepares equipment → manager confirms readiness.
HR provides the start date and employment details. The manager specifies the access needed for the role, and IT fulfils the approved request. The readiness check brings the branches together: both equipment and approved access need to be ready.
If role information is incomplete, the access request returns to the manager for clarification. Equipment planning can continue while the manager supplies the details.
Write the dependency into the software requirement: access provisioning remains blocked until role information and approval are complete. When testing an incomplete request, check that the access task waits while independent equipment preparation remains available.
3. Customer enquiries: clarify routing and resolution
Assignment, response and resolution are separate milestones. A box labelled “respond to customer” conceals the decisions between them.
Example flow:
Enquiry received → classify → assign handler → investigate and respond → resolved?
Yes → record outcome and close.
No → named handler continues investigation → respond again and reassess resolution.
The receiving team classifies the enquiry and assigns someone to progress it. In this workflow, closure requires an agreed resolution; sending an email alone leaves that question open.
Add an exception for incorrect routing. If a billing enquiry reaches technical support, the handler reassigns it to the appropriate team. The original message and previous correspondence travel with it.
For the replacement system, specify that reassignment preserves the enquiry history and identifies the new handler. Move a sample enquiry between teams and confirm that the receiving handler can read the original message and previous exchanges.
Check the map before writing requirements
Walk through a recent case with the people who performed the work. Compare the map with the request, messages and recorded outcome. Follow a straightforward case and an exception, noting where the actual route differed from the documented procedure.
Check every hand-off for a receiving person or team. At each decision, confirm the rule and trace every outcome. Leave unanswered questions visible until someone can resolve them.
Then describe the system behaviour precisely. Replace “improve approvals” with a requirement stating what the system must accept, block, route or retain. Give each test defined inputs and an expected result, including the route taken when information is incomplete.
Agree which existing rules to retain, change or remove. Use those decisions to revise the map before configuring the replacement system.