Functional & non-functional requirements

As a specialist in the contact centre sector we read many RFPs and RFIs, and too many lack the detail needed to cost a solution accurately. Contact centre functional requirements and non-functional requirements are what close that gap. To receive an accurate costing, a specification needs a complete set of user stories describing how the solution must work in every use case; coverage of every area of the solution and every type of user; business, functional and non-functional requirements; and a full description of how you will run your business functions, operations and workflows in future. Anything left unsaid becomes an assumption, and assumptions are where costs and risks hide.

Most enterprises describe what they do in today's contact centre very well. The difficulty comes when a team has limited experience of multichannel operation, or of the real differences between an on-premises call centre platform and a cloud service. Then it is easy to miss things out: digital channel behaviour, callback and in-queue experience, data residency, browser and network prerequisites, or the effect of continuous releases on change control. We help you before you publish to the wider vendor market, so you are not left at risk of a strategic platform decision made on an incomplete brief.

Functional requirements are the features and functions the solution must provide so your employees can do their work efficiently and your customers are served well. They should cover authentication and identity, roles, permissions and divisions, compliance with laws and regulations, external interface contracts to your existing systems, routing and the handling of workflows and transactions, every channel and media type, self-service and virtual agents, recording and quality management, workforce management, and reporting and analytics. For each channel we describe the use cases and the user stories behind them, from the customer's first contact to the agent's wrap-up and the supervisor's view of the outcome.

Good functional requirements share a few habits. Each states one need, in the language of the business, without prescribing a configuration. Each has a unique identifier, an owner and a MoSCoW priority, so must-haves are separated from aspirations before costs are compared. Each describes the unhappy paths as well as the happy one: what happens when a customer cannot be identified, a backend system times out or a queue overflows. And each carries acceptance criteria – usually in Given/When/Then form – so there is no debate later about what was asked for. These habits turn a wish list into a specification that can be designed, built and tested.

Non-functional requirements describe the general properties of the solution: its reliability, availability, security, redundancy, performance, scalability, service levels, certifications, accreditations and standards compliance. They are often the least well written part of a specification, yet they drive architecture, licensing and operating cost. A useful NFR names the quality, the metric, the threshold and how it will be measured. An availability requirement, for example, should say which functions must be available, over what period and how outages are counted, rather than simply asking for a percentage.

On Genesys Cloud CX, NFRs must also reflect how the service actually works. The Genesys service level agreement defines uptime around the functions needed for real-time interactions and excludes problems with your own network, internet connection and directly contracted telecoms, so your requirements should allocate those responsibilities explicitly. Data residency depends on which AWS core region hosts your organisation. Genesys publishes client system requirements for browsers, desktop apps and virtual desktops, and network readiness guidance for sites and carriers. Features are released weekly, so supportability requirements should cover how releases are assessed and adopted.

We help you set NFRs that are ambitious but honest about where accountability sits. Platform qualities that Genesys commits to are referenced rather than restated. Qualities that depend on your design – such as how a flow behaves when a data action fails, how many concurrent interactions a peak hour brings, or how quickly agents can be added – are written as testable requirements on the solution itself. Qualities that depend on your estate, such as bandwidth, quality of service, carrier resilience and endpoint standards, are written as dependencies with named owners. That separation makes the eventual acceptance discussion objective and fair.

We write all functional and non-functional documentation to three standards. It is clear and understandable to the business and technical readers who must sign it. It is specific, accurate and complete, with no hidden assumptions and no requirement that means two different things to two different people. And it is testable by both of us once the solution has been built and configured. A requirement that cannot be tested cannot be accepted, so testability is checked while the requirement is written, not discovered when the test pack is drafted. Our Systems Integration Tester and User Acceptance Test Lead review the specification for exactly this reason.

Every requirement is entered in the Requirements Traceability Matrix. From there it is traced to the high-level design, the low-level design or build book and, for integrations, the interface control document. On the testing side it is traced to systems integration test cases, negative and failure-path tests, performance and volume tests for the relevant NFRs, and the business scenario scripts used in user acceptance testing. The matrix shows at a glance which requirements are designed, built, tested and passed, and it becomes the reference document set you use to qualify your acceptance of the solution at the right time.

If you engage us to build, integrate and deliver your Genesys Cloud CX contact centre, we take full responsibility for completing the functional and non-functional requirements, because they ensure the solution is correctly engineered and configured. We muster a multidisciplinary squad from our own bench: a Senior Business Consultant / Business Analyst to lead definition, a Solution Architect to test each requirement against design options, an IT Systems, Telecoms & SIP Engineer for network and carrier NFRs, and testers who check that every statement can be proved. The work is backed by the whole practice, including peer review against our Senior Platform Practice Lead's standards.

The specification closes the Define stage at a formal requirements baseline. After that, change control protects scope and every change is assessed for its impact on design, build and test before it is approved. Because the same team carries the requirements through design authority review, build, systems integration testing, user acceptance testing and go-live, nothing is lost between documents or between people. Whether we are helping you define requirements for an RFP or delivering a Genesys Cloud CX programme you have already chosen, the documentation is enterprise grade, and it is written by people who will stand behind it.