SCP expertise / Tools and techniques
Turn agreed requirements into a reviewed design and controlled change.
Requirements into a buildable solution
Building on the BRD or equivalent agreed requirements, SCP can help write a functional specification for an internal development team, or review a provider’s proposed specification with the client. We connect the business requirements to a design that the delivery team can implement and the business can assess.
We would agree the required documents, authors, reviewers and approval authority at the outset. The descriptions below are a proposed SCP structure; document names and boundaries vary between organisations. They may be separate specifications or controlled sections of one design record.
Functional specification
Describe roles, workflows, business rules, inputs, outputs, data validation, permissions, exceptions and user interactions. Link each function to the approved requirement, story or use case and its acceptance criteria.
Review focus: completeness, business meaning, consistency, testability and unresolved assumptions. Include or reference performance, security, accessibility and other quality requirements.
High-level design / HLD
Describe the system boundary, main components, external systems, integrations, information flows, deployment approach and architectural decisions.
Review focus: fit with the client’s systems, security boundaries, capacity, resilience, supportability, dependencies and material trade-offs. Allocate requirements to the components that will satisfy them.
Low-level design / LLD
Define component behaviour, interface contracts, field mappings, data structures, calculations, validation, error handling, retries, access controls and configuration as relevant.
Review focus: enough unambiguous detail for implementation and testing, consistent with the functional specification and HLD. The development provider or internal technical team normally owns this detail.
Design approval authorises a defined development baseline. It does not establish that the built solution works, and it does not replace integration testing, UAT or the later acceptance and release decisions.
Keep the requirements hierarchy ending in acceptance criteria. Link functional-specification sections, HLD components and LLD details to the requirements they implement. Link test cases and execution evidence separately to the relevant criteria and design version.
Illustrative link: a planner’s requirement to identify missing supply dates → functional rule for an explicit missing-input state → HLD order/supply interface → LLD date-validation and exception handling. Agreed Gherkin criteria define the expected outcome; integration and UAT results show whether that version meets it.
Use process or swimlane maps for workflows, decision tables for business rules, wireframes and prototypes for user interaction, and context, data-flow, sequence and data-model diagrams where they clarify interfaces and behaviour. Maintain a requirement-to-design traceability record, review-comment log and design-decision record in the client’s agreed repository, linked to Jira or Azure DevOps work items and tests.
References: IIBA: requirements and designs ↗; SEBoK: detailed design ↗; NASA: requirements traceability and change control ↗. Reviewed 17 October 2026. These inform the principles; the document structure, roles and example are SCP proposals.
Testing, requirements and change control
When a test or UAT session produces an unexpected result, record the observation and investigate it against the agreed requirement, acceptance criteria and tested version. Check the test, data and environment too. An unexpected result is not automatically a software bug.
Record a defect with the expected and actual results, reproduction steps, impact and evidence. Link it to the requirement, criterion and test; assess priority and confirm the correction through retesting.
Raise a change request to clarify or amend the requirement and assess the proposed solution change. The need may have been missed, captured incorrectly or changed since approval. A requirements defect and a change request can be linked; the labels are not always mutually exclusive.
Investigate the test case, data, configuration and environment before changing the solution. Retain the original result, record the reason for any correction and rerun the relevant tests.
A controlled document or tracked system record should include a unique ID, requester, date, owner, business reason, current behaviour and proposed change. Link the originating test, UAT observation or defect, the affected requirements and acceptance criteria, and the version assessed.
Record options and impacts on scope, benefits, cost, schedule, resources, dependencies, data, security, operations and testing as relevant. Include the decision, approving authority, conditions, delivery priority and closure evidence. A separate downloadable document is not necessary when the agreed delivery system holds this record.
Keep the original criteria and test results. A request being approved does not turn an earlier failed test into a pass. Revised criteria define what the changed solution must meet; new test and UAT evidence support the later acceptance decision.
Illustrative example: the agreed rule sends an alert when an order is less than 24 hours from its promised date. During UAT, a planner identifies that a customer group needs 48 hours to arrange recovery. If the solution correctly applies the agreed 24-hour rule, record the unmet business need and raise a change request. Assess the effect on alert volumes, workload and service, then approve and version the customer-specific rule and its Gherkin criteria before implementation and retesting. This does not alter the rules in our separate synthetic worked example.
In Waterfall, Agile and hybrid delivery: use the agreed level of change control. An Agile team may capture and assess the request through its backlog, but changes affecting authorised scope, funding, contractual commitments or release criteria still need the appropriate decision.
Jira and Confluence, or Microsoft Azure DevOps and Test Plans, can hold linked requests, requirements, decisions, delivery items and test evidence using the client’s agreed configuration. Keep change control distinct from the wider work of preparing people for organisational change.
Reference: APM: change control ↗. Reviewed 17 October 2026. The triage guidance and example above describe SCP’s proposed application.
Open a technique for when to use it, its output and related service links.
Which feasible option best meets agreed criteria?
Transparent option appraisal.
Compare feasible network, equipment or packaging options against agreed criteria.
When a missing, incorrect or changed business requirement needs an assessed and authorised solution change.
A linked change record, impact assessment, decision, revised requirements and acceptance criteria, and verification evidence.
During UAT, assess a request to change an agreed order-alert rule before updating the rule, Gherkin criteria and linked tests.
Apply change control throughout delivery, including when testing reveals a gap in the agreed requirements.
Explore the change-request process →
When an internal team or solution provider needs agreed functional behaviour before developing a change.
A versioned specification linked to requirements, acceptance criteria, review comments and approval.
Specify the planner workflow, missing-input handling and permitted actions, then resolve review comments before development.
Explore the approach and review responsibilities →
When architecture, system boundaries, components and integrations need to be agreed.
A reviewed architecture and interface design, requirement allocation and recorded design decisions.
Agree how orders and supply information connect to the exception workflow and its security boundaries.
Explore the approach and review responsibilities →
When developers need implementation detail consistent with the approved solution design.
Detailed component, data-mapping, interface and error-handling definitions linked to the design baseline.
Define date validation, interface field mappings, duplicate-event handling and audit records before coding that scope.
Explore the approach and review responsibilities →
Explore how these techniques could support your operation, with the scope and depth agreed around your needs.