What is the user requested business functionality provided by IVR systems?

The functionality provided by IVR systems can vary considerably in type and complexity. Simple IVR systems act as queue managers, receiving and transferring calls to human operators.

More sophisticated systems deliver standard application functionality by permitting the user to complete business transactions in a similar fashion to other electronic funds transfer systems. These transactions include Account Balance Enquiries and Funds Transfer transactions. These types of IVR systems act as front-end systems to back-end hosts, often not interfacing directly, but via host interfacing software which reformats and standardises requests from multiple sources.

Front-end IVR systems enquire upon information held in host system files. Typically in response to the first enquiry made, a 'packet' of data is returned to the IVR to be temporarily stored. (In some situations the data is stored permanently.) This data is used to satisfy subsequent enquiries thereby minimising the number of calls that need to be made upon host systems.

1. Only functions customised or custom built by the developer will be included within the scope of the function point count.
2. Functions from the two software layers are counted separately.
3. IVR functions must satisfy the standard IFPUG uniqueness criteria. In applying these criteria the functions will be viewed from the perspective of the IVR system processing only. For example, an IVR system can be used to Enquire Upon Account Balance for five different types of accounts. If the IVR processing stages (security check, account validation, 'voicing' etc) involved in each of these types of enquiries is identical, the transaction is identical. It can be argued that the Account Balance Enquiries reference different host systems and host system files, and therefore satisfy IFPUG uniqueness criteria. This would be the correct view if the IVR interacted directly with the Host. It is however the 'host interfacing' software that interfaces with the individual host systems. The host systems ultimately access their own files and send responses back to the interfacing software.
4. The input of data by a customer, IVR validation of data, request/response interface to host (via host interfacing software) and the voicing of a result to a customer are all sub-processes of the one elementary process, Enquire on Account Balance. All of these sub-processes must occur for the process to be 'self contained' and leave the business of the system in a consistent state. These sub-processes should not be counted as separate EI and EO transactions.
5. Data retrieved from the Host and stored temporarily within the IVR system for the duration of the customer session does not constitute an ILF. The data is transient. Only persistent data is counted as logical file.
6. Results for the two software layers will be recorded in the one FPW count. Transactions must be assigned to separate branches and files clearly identified as to the layer they belong to.

The following counting guidelines present a generic solution to the FPA issues related to IVR Systems.

Functionality that exists within the Technical Administrative Layer includes:

• Security - for example Small Business IVR maintains a Client Id File that is referenced by particular functions.
• System Configuration - for example, opening and closing hours of call centres, operator extensions. The business information in the configuration file is treated like reference table data.
• Call Event Records/System Statistics
• Messages/IVR Vocabulary/Voice Recording - The actual voice/message recording is performed in a recording studio and this functionality is considered to lie outside the IVR boundary. IVR functions commence when the voice message is imported. Voice message transactions include:
  1. Import Voice Message
  2. Edit/Modify Voice Message
  3. Delete Voice Message
  4. List Messages
  5. View message text

  DT2 is a programming language used for IVR development. It is used to develop the above functions.

  The actual playing/voicing of the message is considered to be a sub-process of the main business process. Voicing the message provides the user interface to the IVR business functions much in the same way as displaying a query response on a screen provides a user interface. The retrieval of information and subsequent display of information on the screen do not satisfy the conditions of unique elementary processes. The business of the transaction is not complete, and the system is not considered to be in a consistent state, until both sub-processes are complete. The same principles should apply to the voicing of IVR messages.

• Transfer/Routing Details - This information may be hard coded or stored within a file. If hardcoded, this will be reflected in the count for the business functions for which this code provides the underlying processing. A file with associated maintenance functions may be counted, if it exists and the functions were custom built. This guideline applies regardless of whether the file maintenance is performed by an administrative user or a developer on behalf of a user.
• Reporting

• Files associated with the functions identified above, for example, security file/s, voice message files, statistics files.
• In each category of functionality there may be more than one file, for example, multiple call event files if different events require different attributes. Uniqueness criteria must be applied.

Files in this layer are typically independent files with few shared relationships ie there is no relationship between the data in the security files and the voice message file.

• Maintenance functions on the above files but only if customised or custom built
  

• Log On functions, if they are independently triggered.
• Reporting/enquiry functions on the above files but only if customised or custom built
  

Functionality that exists within the Business Applications Layer includes:

• Call transfers
• Business functions for which IVR acts as the front end. For example, Account Balance Enquiries, Funds Transfers, Exchange Rate Enquiries etc
• Reporting
• Reference data. For example - Biller Codes File

• Host system files - Generally the developers of the IVR have no knowledge of the Host system files that their transactions eventually reference or update. At least one HOST system file should be counted to represent these files. Name the file according to the logical business data being referenced or updated, for example ACCOUNT file, POLICY file etc. Attach a Note to the file in FPW to explain that the actual file is not known, and that the file counted represents a host system logical file. This is either an EIF or ILF depending upon the type of IVR transactions.
• Reference Table files. For example, Biller Codes.

• Transactions that input data for the purpose of updating IVR and/or host system files. For example, Funds Transfer and Bill Payment functions. Uniqueness criteria must be established from the perspective of the IVR system.
• Maintenance functions for Reference Table files.

• Call transfers to different destinations (human operators) are counted as EO or EQ functions depending upon whether a file is updated as part of the transfer process. Separate transactions may be counted for each destination if the attributes transferred with the call are different, or different logical processing can be demonstrated for example, different FTR's referenced.
• Enquiry functions upon host system files. For example, Account Balance Enquiry.
• Other Reporting functions but only if customised or custom built