The Functional Requirement Questionnaire (FRQ) is a document that details information about the AS IS process and environment which could be relevant to the design and operation of a TO BE automated solution. A template FRQ can be found at the bottom of this page.
The FRQ is used to capture the metrics, the controls and the execution and data management requirements of the manual process. This information is vital when designing an automated process and it can be captured as part of an interview with the client by asking simple questions such as:
- What days of the week does the process work?
- Does the process start at the same time every day?
- How many people work the process?
- Are there any periods during the year when the workload is higher?
- Does the process operate within a defined Service Level Agreement (SLA)?
The FRQ is not used to design the automation, its purpose is to expose the requirements an automated solution design will need to cater for - requirements such as inputs, outputs, environmental factors, schedules, SLAs and reporting needs. The FRQ does not repeat the detail in the Process Definition Document (PDD), instead it supplements the PDD with the expectations of how the process needs to perform and be managed.
Why is it needed?
- Enables the Business to define the current requirements of the manual process
- Enables the delivery team to find out what would be expected from an automated version
- Helps define and agree the automation scope and to prevent scope creep
- Informs the designer of what the solution design should include
- Reduces the risk and consequences of new questions arising late on in the delivery phase
- As a basis for testing and UAT, so test plans can ensure each requirement is met
- For operational planning, for example scheduling the Digital Workforce and planning for peak demand
What makes a good FRQ?
- Enables the client to say what they require of the business process, irrespective of whether it is worked manually or automated
- Supplements the AS IS definition and inform the TO BE design
- Does not detail the AS IS procedure or explain how the TO BE solution will be
- Identifies requirements that are not in scope as well as those that are in scope
- Detailed yet clear and easy to understand
Blue Prism provides FRQ templates and a completed example as part of the Lifecycle Orientation training. New FRQ documents can be based on these.
Sometimes it can be difficult to capture FRQ information and issues may include some of the following:
- Problem: There are differences between the documented requirements and the way the process is operated, or disagreement within the operational team as to what the requirements are.
- Solution: Document and report all conflicting requirements to the process owner. Make it clear that implementation cannot proceed, and testing cannot be planned, until all discrepancies are addressed and corrected.
- Problem: The manual process is new and detail of how it should be performed and managed is not defined.
- Solution: A new process should not be planned for automation until all decisions about how it is to be performed have been agreed.
Where to gather information?
Undoubtedly the best source of up to date information are the Subject Mater Experts (SMEs) - the staff currently owning, managing, working and maintaining the process. Recommendations when talking to SMEs are as follows.
- Question the process and explore and expand as much as possible, to ensure information is accurate and contextual
- Document assumptions, requirements, SLAs, and technical elements in as much detail as possible
- Where relevant, include samples of input and output files, reports, log entries, and alert/error messages in the FRQ
- Before finalizing the FRQ, confirm the document's detail with the SMEs
Existing functional and technical documentation can also be a very good source of information to prepare for an FRQ, although interpretations or assumptions taken from documentation must be verified during the FRQ interview and ultimately and signed off. It's highly likely that documentation alone won't provide all the information needed and the following are the kind of issues that could be found.
- Outdated: the process or its operation may have changed over time and the documentation is no longer accurate
- High-level: the documentation may not have the required level of detail
- Unclear: the documentation may be vague, difficult to understand or contradict what the SMEs have said
And although requirements may change during the implementation project, they should all either be mapped to a requirement or to an explanation why they are no longer relevant.
Business Decision and Sign-Off
Requirements should be agreed and signed off by the Business to ensure they are correct, and once this is done, the Design phase can commence.
Sign off is an important step because it ensures all parties are aware of the requirements, scope, and expectation, and indicates the operational requirements an automated solution will need to meet.
Blue Prism’s Success Accelerator program combines various levels of mentorship and access to our Expert Services, Technology Ecosystem and Certified Partners based on the size and maturity of your digital workforce operations.