B202 Non-Functional Requirements v1.1 - Western Cape ... · PDF fileother IT personnel to...

Document: B202 Non-Functional Requirements v1.1 Date: 28th January 2010 Version: 1.1 Status: Final METRO EMS Confidential of 23

B202

B202 Non-Functional Requirements

Provincial Government of the Western Cape (PGWC) Medical Emergency Transport and Rescue Organisation (METRO) Emergency Medical Services (EMS)

METRO EMS Confidential


B202

Document History

Revision History

Revision Number

Revision Date

Summary of Changes Changes marked

1.0 2009-12-14

Final No

Approvals

This document requires following approvals. Name Title Dr. Cleeve Robertson Director – Emergency Medical Services

Distribution

This is the intended distribution list for this document: Name Title Dr. Krish Vallabhjee Chief Director EMS - Provincial Government of the Western Cape

(Sponsor) Dr. Cleeve Robertson Director – Emergency Medical Services Dr Shaheem de Vries Deputy Director - Emergency Medical Services Johan Schoombee Project Manager – Emergency Medical Services Dr Paul von Zeuner Information Management - Provincial Government of the Western CapeSteve Hurwitz Centre of e-Innovation - Provincial Government of the Western Cape Dr. Alan MacMahon Deputy Director - HealthNET A printed copy and soft copy on CD media will be handed to Dr Shaheem de Vries for further distribution within EMS and PGWC.


B202

Contents 1. Introduction........................................................................................................................... 4

1.1 Identification...................................................................................................................... 4 1.2 Document Context ............................................................................................................. 4 1.3 Document Description....................................................................................................... 4 1.4 Purpose .............................................................................................................................. 5 1.5 References.......................................................................................................................... 5 1.6 Definitions ......................................................................................................................... 5

2. Overview of Requirements ................................................................................................... 6 2.1 Solution Requirements ...................................................................................................... 7

2.1.1 Availability and Reliability......................................................................................... 7 2.1.2 Scalability.................................................................................................................... 8 2.1.3 Performance .............................................................................................................. 10 2.1.4 Capacity .................................................................................................................... 11 2.1.5 Usability .................................................................................................................... 14 2.1.6 Configurability .......................................................................................................... 14 2.1.7 Maintainability .......................................................................................................... 15 2.1.8 Flexible Modular Design .......................................................................................... 16 2.1.9 Security ..................................................................................................................... 16 2.1.10 Archiving .................................................................................................................. 17

2.2 IT Architecture Requirements ......................................................................................... 18 2.2.1 Layered Application Architecture............................................................................. 18 2.2.2 Composability ........................................................................................................... 18 2.2.3 Portability.................................................................................................................. 19 2.2.4 Extensibility .............................................................................................................. 19 2.2.5 Uniform Technologies .............................................................................................. 19 2.2.6 Multiple Communication Channels .......................................................................... 19 2.2.7 Access and integration with Third Parties ................................................................ 19

2.3 Support Requirements ..................................................................................................... 19 2.3.1 Local Expertise ......................................................................................................... 20 2.3.2 Monitoring ................................................................................................................ 20 2.3.3 Phased Migration ...................................................................................................... 20

2.4 Financial Consideration................................................................................................... 20 2.4.1 Ownership ................................................................................................................. 20 2.4.2 Maintenance and Enhancement Cost ........................................................................ 21 2.4.3 Escrow Agreement.................................................................................................... 21


B202

1. Introduction This chapter identifies the document and the business to which it relates, describes the contents of the document, and states its purpose.

1.1 Identification

This document describes the Non-Functional Requirements for the Emergency Medical Services (EMS) core operational processes. This Project is a Requirements Specification Phase for Provincial Government of the Western Cape (PGWC) METRO EMS in preparation for a Tender for Services.

1.2 Document Context

Stakeholders and Roles (A101)

Organisational Structure (A102)

Information Requirements (B301)

Business Architecture

“To Be” Processes (A104)

Application Architecture Information Architecture

Solution Architecture Overview (B401)

Technical Architecture

Application Features (B201)

Non-Functional Requirements (B202)

Requirements Specification

1.3 Document Description

The Non-Functional Requirements identify and define those aspects of the anticipated “To-Be” solution that, while not directly affecting the functionality as seen by the users, can have a profound effect on how it is accepted by both the users and the people responsible for the support.


B202

There is a distinction between these non-functional requirements and functional requirements, which describe the behaviours (functions or services) of the system that support user goals, tasks or activities. The functional requirements are not described in this document they are described as features in another document [1].

1.4 Purpose

The general non-functional requirements are to be used by architects, product managers, developers, and other IT personnel to guide decisions about buying, developing and supporting the future EMS solution. The Non-functional requirements are used: To define requirements and constraints on the solution. As a basis for sizing and estimates of cost. To assess the viability of the proposed solution. To drive detailed design of the architecture.

1.5 References

This document is based on and refers to the following documents: [1] B201 Features Description v1.1 [2] B401 Solution Architecture Overview v1.1 [3] B301 Information Requirements v1.1

1.6 Definitions

An “application” is the software that will be used by users to perform their tasks. A “system” includes both the hardware and software required for the user to perform their task. A “solution” encompasses all the elements required by the client to perform their tasks. It includes the hardware, software, the procedures, the data and the communication mechanisms that will be used.


B202

2. Overview of Requirements There are different types of requirements. Sometimes a trade-off between the different requirements is necessary. Because non-functional requirements, by their very nature, can be contradictory, it is the responsibility of the decisions makers to subjectively interpret these requirements to find the “best fit” solution for each product. They should make sure that the most important things are given the correct attention. Therefore, the non-functional requirements must be prioritised. We have tried not to fall into the trap of expressing every possible requirement or constraint as being of the same priority for the future solution.

Non Functional Requirements

Product Requirements

IT Architecture Requirements

Commercial Requirements Service Requirements

Archiving

Security

Integration 3 rd parties

Uniform Technologies

Maintenance cost/skills

Client Variability

Flexible product assembly

Non Functional Requirements

Solution Requirements IT Architecture Requirements

Financial Consideration Support Requirements

Availability/Reliability

Scalability

Performance

Usability Integration 3rd Parties

Composability

Portability

Maintenance/Enhancement Cost

Extensibility

Multiple Communication Channel Ch l

Monitoring

Phased migration

Ownership

Capacity

Flexible Modular Design

Layered Application Architecture

Local Expertise

Maintainability

Configurability


B202

2.1 Solution Requirements

In order to have a properly designed and efficient system, non- functional requirements relating to ‘how’ the system should operate needs to be considered. Key non-functional requirements are listed and explained below.

Availability and Reliability Scalability Performance Capacity Usability Internationalization Maintainability Security Archiving History Printing

2.1.1 Availability and Reliability

The Availability and Reliability requirement addresses the below: End User Availability (complement of Planned Outages) Failure Rate or Unplanned Outages Operational Continuity

2.1.1.1 End User Availability (complement of Planned Outage)

The end user availability relates to the time that the system is expected to be available to the users. This requirement includes planned outages but not failures. Due to the nature of the EMS process, the real-time application needs to be available to the users 24 hours x 7 days over 365 days. The target up time for the resource management, communications and computer aided dispatching (CAD) components of the system is 99.9% availability whilst the integration with third parties component needs 95% availability. The dashboards and the management platforms components need to be available for 90% of the time. Planned outages window is also necessary for regular system maintenance and a back up server might be required during that time.


B202

2.1.1.2 Failure Rate

The failure rate or unplanned outages relates to the reliability of the system and measures how often it is acceptable for the system to fail during the 24 hours x 7 days x 365 days period. Due to the nature of the EMS process, minimal failure rate is essential for some of the components to minimize disruption to the service. Acceptable failure rate for the communications and CAD components of the system is 0.1% of the time whilst the integration with third parties acceptable failure rate is 5% of the time. Acceptable failure rate for the dashboards and the management platforms is 10% of the time. The resource management component has an acceptable failure rate of 0.1% of the time. For instance mirrored disks can be used to minimise failures, a UPS (uninterrupted power supply) can be used to minimise outages due to power failure.

2.1.1.3 Operational Continuity

Operational continuity relates to unplanned outages, system downtime and how quickly can the system recover from these failures. Due to the nature of the EMS process, any disruption to normal operations needs to be resolved quickly to restore the system to normal running condition. Each component of the EMS process needs to have its own recoverability requirements and based on those requirements the system needs to be able to recover easily from the failure of any of the components. During an unplanned outage, recovery time for the communications and CAD components of the system is sub-ten minutes whilst the integration with third parties acceptable recovery time is sub-one hour. The dashboards component needs to be recovered within 12 hours whilst for the management information platform component acceptable recovery time is 48 hours. Operational continuity for the resource management is also important and recovery time needs to be sub-ten minutes.

2.1.2 Scalability

The Scalability requirement addresses the need for the system to satisfy: Deployment Increase/Decrease in Calls volumes

2.1.2.1 Deployment

Deployment relates to whether the solution will be deployed on a large or small scale. Firstly, the solution will be deployed on a small scale in the districts offices where the system will be used by a small number of users. The system should not be cumbersome for them to administer. On a larger scale, the solution will be deployed at the metropole control centre in Tygerberg campus where the number of staff using the system is higher. The activity level will also be significantly higher in this centre due to the higher number of events that they handle compared to the districts. Since all the EMS resources are mobile, a ‘LITE’ version of the solution might also be deployed to accommodate those resources. For instance only certain functions such as access to SOPs will be available.


B202

Also at incident scene, a mobile incident command vehicle is used to perform the functions of a control centre. A ‘LITE’ version also needs to be deployed in this case. In all three cases, the solution should be scalable without influencing application performance. The table below shows the current number of resources for each region. These figures do not include HealthNET or TransMETRO. These figures are to be added by EMS at a later stage.

USER NUMBERS MAX C. KAROO EDEN WINELANDS

WEST COAST OVERBERG

CAPE TOWN

Vehicles

Response units 15 30 41 26 25 106

MDT ‐ Driver 15 30 41 26 25 106

MDT ‐ ECP 15 30 41 26 25 106

Radio 15 30 41 26 25 106

Emergency Control Centre

Call Taker 4 7 7 7 4 16

Dispatcher 4 7 7 7 4 16

HealthCare Facilities

Emergency centre 4 7 5 8 4 19

Trans METRO

HealthNET

Managerial

Operations Centres 4 12 10 11 6 9

Managers 5 13 11 12 7 22

2.1.2.2 Increase/Decrease in Call Volumes

Increase/Decrease in call volumes relates to the amount of transactions that the system needs to be able to process. In the districts the transactions rate will be lower compared to the metropole due to the high volume of calls received in the metropole control centre. Also during major events such as Cape Argus Cycle Tour or the FIFA 2010 World Cup, the system needs to anticipate an increase in processing due to potential larger volume of calls during those events. The system needs to be able to satisfy the increases and decreases in processing without influencing application performance.


B202

2.1.3 Performance

The Performance requirement addresses: Latency Utilisation

2.1.3.1 Latency

Latency time is the time required for the application to complete a task and present the information to the user. The user needs to be able to launch the application quickly and log into the application with minimal latency, sub 1 second. This is important during change of shifts where the call handlers and dispatcher need to log off and allow the next shift to log into the application. Also due to the nature of the EMS services, minimal latency of sub 1 second for on screen navigation, information capture and information upload and transfer is critical. The latency of the user interface should never exceed 2 seconds for these activities. For instance, the call handler should be able to navigate from one field to the other within 2 seconds. Once caller and event information has been captured, the call handler should be able to transfer the information to a dispatch desk within 2 seconds. Retrieving information, for instance for a repeat call, also needs to be minimal. Latency for complex transactions such a determining and designating a healthcare facility also needs to be minimal. Latency needs to be minimal for users who are using the interactive application, however for batch processing, for instance to create a schedule from the advanced booking request received, the latency required might be different as it is not an emergency and done in advance. The minimum latency for the function groups below are sub-one second and the maximum is sub-two seconds. The features related to these function groups can be found in the features document [1]. Resource Management Demand Forecasting Scheduling Operational Readiness Control Centre Management Client Communication Directing Emergency Resources Directing Non-Emergency Resources Incident Command and Control Healthcare Facilities Interaction The interaction between the application and the external services such as health facilities or the solution services such as telephone communication should be sub 1 second. The maximum is listed in the table below: External Services Maximum Latency a) Medical Aid (Both direction) within 5 minutes


B202

b) Healthcare facility (Both direction) Emergency within 1 minute Non Emergency within 5 minutes Prognostic within 5 minutes c) Telecommunication service provider within 2 seconds d) External Call centres ( Both direction) within 2 seconds e) 3rd Parties EMS (both direction) within 2 seconds f) Metropole Traffic within 2 seconds Solution Services g) Telephone Communication (Both direction) within 1 second h) Radio Communication (Both direction) within 1 second i) Vehicle Tracking within 1 second j) Resource Management within 5 minutes

2.1.3.2 Utilisation

Utilisation is the maximum load of the components on the system, for instance CPU, network, database. Utilisation parameters need to be defined and monitored to ensure that the system performs at its best at all times. For instance CPU usage needs to be monitored to ensure that system resources are used efficiently. EMS peak period is estimated to be 8 hours out of a 24 hours period and the system is expected to accommodate the load during those 8 hours and take appropriate corrective actions proactively to stay within utilisation parameters.

2.1.4 Capacity

The Capacity or throughput requirement measures the workload that the system is expected to process during a certain time. It addresses:

Number of Users Concurrent Users Transaction Volume Prioritisation of Tasks

2.1.4.1 Number Users

Number of users is the total number of users that is expected to connect and use the application. It is important to take into consideration this figure to prevent unpredictable peak usage if an unexpected number of users try to connect and use the application. Since the users of the application can have different roles with different access types(create/read/update) attached to their sign on, this might also


B202

have a direct impact on the system causing unpredictable peaks if they sign on to several roles at the same time. The table below indicates the current number of users for each region. These figures do not include HealthNET or TransMETRO. These figures are to be added by EMS at a later stage.

USER NUMBERS MAX C. KAROO EDEN WINELANDS

WEST COAST OVERBERG

CAPE TOWN

Vehicles

Response units 15 30 41 26 25 106

MDT ‐ Driver 15 30 41 26 25 106

MDT ‐ ECP 15 30 41 26 25 106

Radio 15 30 41 26 25 106

Emergency Control Centre

Call Taker 4 7 7 7 4 16

Dispatcher 4 7 7 7 4 16

HealthCare Facilities

Emergency centre 4 7 5 8 4 19

Trans METRO

HealthNET

Managerial

Operations Centres 4 12 10 11 6 9

Managers 5 13 11 12 7 22

2.1.4.2 Concurrent Users

Concurrent users is the total number of users that will be accessing the application at the same time during peak and off-peak periods The number of concurrent users needs to be known as it will have an impact on the performance of the system as they will be accessing the system resources simultaneously causing a constraint on the system resources if complex transactions are performed simultaneously. Current number of concurrent users can be determined and best solution proposed. However further assessment might be required to determine the most efficient way of handle concurrent users.

2.1.4.3 Transaction Volumes

The volume of on-line transactions expected to be processed per day is important as it has an impact on the performance and scalability of the system.


B202

Due to the nature of EMS services, it is difficult to predict the volume of transactions processed per day as the peaks are different every day. The type of transactions will also differ per day. An estimate of the distribution needs to be made for a longer period of time instead of a day. Current transaction volumes can be determined and best solution proposed. However further assessment might be required to determine the most efficient way of handle the volumes. The table below provides an indication of the transaction volumes. These figures do not include HealthNET or TransMETRO. These figures are to be added by EMS at a later stage. MAX INCIDENT DELTA P1 P2 ADVANCED

C. KAROO

No. of Calls 2000+/‐

No. of Incidents 1063 0 227 836 53?

No. of Dispatches 1141 0 258 883 53?

EDEN


No. of Incidents 5756 10 830 4926 81?

No. of Dispatches 6202 6 922 5280 81?

WINELANDS


No. of Incidents 3329 0 441 2888 103?

No. of Dispatches 3430 0 489 2941 102?

WEST COAST


No. of Incidents 3290 3 541 2749 ?

No. of Dispatches 3502 0 596 2906 ?

OVERBERG


No. of Incidents 2488 0 653 1835 10?

No. of Dispatches 2685 0 787 1898 14?

CAPE TOWN

No. of Calls 50000 +/‐

No. of Incidents 26995 6 8058 18937 2605?

No. of Dispatches 18680 1 5792 12888 1926?


B202

2.1.4.4 Prioritisation of Tasks

The system administrator should be able to set priority by function types to ensure performance standards are met. For example if the archiving process is set to run during a certain period but at the same time the system is experiencing unexpected peak, the archiving process should be given a lower priority.

2.1.5 Usability

The Usability requirement addresses: User Interaction System Navigation

2.1.5.1 User Interaction

User Interaction is how easy it is for the user to interact with the application to perform required transactions. This requirement also covers learnability whereby the user needs to be able to use the application without extensive training, typically 2 or 3 days training.

2.1.5.2 Application Navigation

Application navigation is how easy it is for the user to navigate within the application. It is important for the user to be able to access the various information they require in a quick, consistent and intuitive way. For instance drop down lists and predictive text need to be available to identify case types and incident types. The user needs to be able to navigate swiftly between the information received, the various maps and liaising with a supervisor for instance. Colour code properties need to be available to identify mandatory fields and to differentiate between the information being processed. For instance a priority 1 dispatch should have a different colour from a priority 2 dispatch to highlight the emergency. The user needs to be able to perform functions in the application via a menu or for more experienced users using short cuts commands or keys.

2.1.6 Configurability

The Configurability requirement addresses: Workflow Internationalization Client Variability Adaptability


B202

2.1.6.1 Workflow

It is important to that the solution follows the EMS operations process or can be configured to do so if required. However, if the solution proposes a better workflow than the one defined by EMS, this will be adopted.

2.1.6.2 Internationalization

The internationalization requirement specifies what language will be used by the application and the locales it must support. A locale defines user preferences for instance for currency, date format, number format etc. The language support by the application will only be English and reports need to be prepared based on South Africa standard time.

2.1.6.3 Client Variability

The application needs to be customised to include features specific to each EMS control centre. The EMS logo needs to be included on the interfaces and the reports for all the control centres. Each control centre needs to have a customised identity in the application whereby the interfaces and reports will reflect the control centre’s name for instance.

2.1.6.4 Adaptability

The ability to change the solution when and where appropriate is essential. In addition to implementation configuration which is performed at the initial stages and parameter settings based on user preferences, the solution needs to support rule based configuration. The solution should not be rigid and need to accommodate both business and technical changes.

2.1.7 Maintainability

The Maintainability requirement addresses: System Administration and Maintenance Customisation Back Up/Recovery/Restoration

This requirement is supported by the scalability as well as the availability and reliability requirements.

2.1.7.1 System Administration and Maintenance

System administration and maintenance is the need for the system to be easily maintainable with minimal disruption to the system. Both the core system and subsequent add-ons needs to be easily maintainable. For instance, it should be easy for the system administrator to add, delete or update users’ profile.


B202

2.1.7.2 Customisation

Customisation is the need for the application to be easily customisable if required. Functions can be added or modified with minimal disruption to the application. Fields can be added or moved and reports created or reformatted if required. The client would like to keep the degree of customisation to an optimum level in line with the maintenance and enhancement cost.

2.1.7.3 Back up/Recovery/Restoration

Back up/Recovery/Restoration is the need for the system’s functions and data to be backed up and readily restored when required. Back ups are important to ensure that historical data is kept as per legal requirements. Also in the case of major disasters, it is essential that if a control centre cannot operate, another control centre can take over that centre’s functions and data for operational continuity. As part of the disaster recovery plan, there will be another site in the metropole where the back ups will be stored. Information from all 6 control centres will be stored at this site and will be access if need be.

2.1.8 Flexible Modular Design

The application should ideally consist of different modules integrated on a common platform. This will provide a wide choice of expandable functional options to the client. It should be easy to upgrade, customise or replace the various modules.

2.1.9 Security

The Security requirement addresses: Authentication Authorisation Information Security Auditing Security Management and System Administration

The Solution Architecture Overview [2] document provides further information on this requirement.

2.1.9.1 Authentication

Authentication is the ability for the application to identify if a user is allowed to access the system. A biometric sign on facility for instance is required to uniquely identify a user. The single sign on facility should be available to allow a user to first connect to the network and then to the application if required.


B202

2.1.9.2 Authorisation

Authorisation is the ability for the application to control the functionalities that the user are authorised to use. Each user will have a sign on and each sign on will have a list of roles associated to it. For each role, access control rules will be defined to restrict the user to the functions that they are authorised to perform under that role. For instance when signed on as a call handler, a user will be able to view the EMS resources but will not be able to dispatch an EMS resource. If this user is allowed to change his/her role to a dispatcher, s/he will then be allowed to dispatch resources when required.

2.1.9.3 Information Security

Being a solution that deals with the medical information about patients, the solution needs to comply to the organization’s security standards and with the industry’s best practice. Only authorised users should be allowed to access the information. Relevant national guidelines and legislation needs to be adhered to so as to ensure secure transmission and storage of data.

2.1.9.4 Auditability

Auditing is the ability for the application to track changes performed by users. The application needs to keep a log of activities performed by the users for instance capturing information about a call, augmenting the event information with additional information etc. the log needs to include a timestamp and user identity. This forms the basis for an audit trail of each event. Further information is available in the Information Requirement document [3]. The information can also be used for application usage trends if required. It becomes a key part of providing information for a report of an event.

2.1.9.5 Security Management and System Administration

The system needs to allow users with system administration rights to remotely log in to perform system maintenance and configuration if required. Users with system administration rights need to be able to define new users and their roles, update access to functions etc remotely. The support of the system could be outsourced. In such an event the system should provide the features that will facilitate this.

2.1.10 Archiving

The archiving requirement means that copies of the online data need to be kept in offline storage as per legal requirements. Patient documentation is kept for 10 years and other legal documents for 5 years. The system must keep the data in the archives in a format that is acceptable by legal entities. The data needs to be in online storage for a determined period of time if it needs to be accessed quickly but will then be moved to the offline storage after that period.


B202

The archived records need to be retrievable at will, over a period of time as per legal requirements. A change in database during that period should not affect data retrieval. The information needs to be viewable through current application. As per the prioritisation of tasks requirement, the archiving process needs to have a lower priority to ensure that it does not affect system performance during peak periods.

2.2 IT Architecture Requirements

The Solution Architecture Overview [2] document provides further information about the architecture requirements of the system. For the purpose of this document, it is important to have an overview of the non-functional requirements relating to the IT architecture of the system. Key non-functional requirements are listed and explained below.

Layered Application Architecture Composability Portability Extensibility Uniform Technologies Multiple communication Channels Integration with Third Parties

2.2.1 Layered Application Architecture

The application architecture should be layered. The core functionality should consist of the code directly under the control of the software supplier. The second layer should consist of the functionality that allows customisation to the local conditions of a legal, cultural or economic nature. This layer should be under the control of the local distributor of the software. The final layer should consist of all the aspects that the client organisation can and should control. Typically this may include organisational details, business rules, and user interface preferences. The main idea being that new releases of the software by the software supplier can easily be migrated to and that the impacts can be easily determined and are being minimised, while the customisation investment is protected.

2.2.2 Composability

This requirement should give the client organisation optimum flexibility in how the application can be composed for deployment on the proposed technical architecture. Whether the application is staged centrally or distributed, communication uses two or multiple technologies, for example, it should operate equally well.


B202

2.2.3 Portability

The ease with which the system can be migrated from one technical environment to another needs to be considered. The migration should be transparent to the users with minimal disruption to daily operations.

2.2.4 Extensibility

The solution needs to be designed so that it can be extended in future to cater for growth. New functionalities and modification of existing functionalities should be carried out with minimal disruption and re-development of the system that was initially implemented.

2.2.5 Uniform Technologies

The technologies used for the solution needs to conform to industry standards and adaptable so that they can work together seamlessly. The system will go via VPNC which is the agreed protocol used by the EMS network service provider. The constraint that needs to be noted is that the bandwidth is set to 115 Kbps. The database used needs to conform to industry standards. A relational database is required and needs to be standardised whereby all modules/components of the system use the same database.

2.2.6 Multiple Communication Channels

The technical environment should provide for the secure transmission of messages over all the standard communication channels, including GPRS, SMS, 3G, Tetra, UHF and VHF. The automated routing between the used channels should be based on cost and availability.

2.2.7 Access and integration with Third Parties

There is a need for a controlled environment through which all third parties can access the system if required. Confidentiality and privacy laws need to be taken into consideration to ensure that third parties do not have access to patient information. Third parties to which EMS will provide information are for instance healthcare facilities but EMS also needs to get information from for instance external call centres.

2.3 Support Requirements

The support requirements once the solution has been implemented are an important factor as it will ensure business continuity in the long run. Key non-functional requirements are listed and explained below.

Local Expertise Monitoring Phased Migration


B202

2.3.1 Local Expertise

It is important that the solution is easily maintainable and that the skills to maintain the solution are readily available locally. This will reduce the maintenance cost and there will be no need to get a resource from overseas. Also it will be easier and quicker for a local resource to perform the maintenance causing minimal disruption to the daily operations of the control centres.

2.3.2 Monitoring

Because of the mission critical nature of the operations, the client requires real-time centralised monitoring of all technical components responsible for the connectivity and processing. Automated alerts are triggered in the case of a detected breakdown. This requirement is supported by the maintainability requirement whereby regular back ups are required to ensure data recovery in case of technical component failure.

2.3.3 Phased Migration

The client has a requirement to take on more functionality over time. It is therefore a requirement that the modules, or even functions within a module, can be activated or deactivated in a controlled manner to allow for a phased implementation of the application over time. This is required to avoid a big bang implementation approach. This requirement is also supported by the scalability requirement whereby the migration of the legacy system to the new system needs to be done in metropole before migrating the data and information to the smaller control centres.

2.4 Financial Consideration

The financial consideration non-functional requirements are listed and defined below. Ownership Maintenance and Enhancement Cost

2.4.1 Ownership

It should be explicitly agreed whether the client buy the software for its own use or whether they only acquire the rights to use the software. This is an important consideration in business continuity planning. It is expected that the financial cost of ownership makes business sense over the expected life of the solution. Thus the cost of the acquisition, customisation, implementation, operation and maintenance can be justified in terms of comparative local industry operational costs. All customisation are owned by the client and part of the intellectual property of the client.


B202

2.4.2 Maintenance and Enhancement Cost

The need for maintenance on the solution should be minimised. As per support requirements, local expertise is required to further minimize cost involved in maintaining the solution. While regular updates of the software is generally desirable, the client will only want to pay for those enhancements which they find useful and commits to put into production. Also an agreement needs to be put in place to cater for on going increase in customisation costs.

2.4.3 Escrow Agreement

The client would require an escrow agreement whereby the source code is available to the client if the software provider is not able to operate anymore. The source code can then be used by another software provider to ensure that the client can continue its operations.


B202

Annexure A – Non-Functional Requirements Priority Matrix All the non functional requirements described in this document are required but they have been prioritised as per the list herewith. For each requirement a priority was identified as follows:

- Priority 1 - Highest priority - Priority 2 - High priority - Priority 3 - Low priority - Priority 4 - Lowest priority

2.1 Solution Requirements Priority today

Priority Future

2.1.1 Availability and Reliability 2.1.1.1 End User Availability (complement of Planned Outage) 1 1 2.1.1.2 Failure Rate 2 1 2.1.1.3 Operational Continuity 2 1 2.1.2 Scalability 2.1.2.1 Deployment 2 2 2.1.2.2 Increase/Decrease in Call Volumes 3 2 2.1.3 Performance 2.1.3.1 Latency 1 1 2.1.3.2 Utilisation 2 2 2.1.4 Capacity 2.1.4.1 Number Users 2 2 2.1.4.2 Concurrent Users 2 2 2.1.4.3 Transaction Volumes 2 2 2.1.4.4 Prioritisation of Tasks 2 2 2.1.5 Usability 2.1.5.1 User Interaction 1 1 2.1.5.2 Application Navigation 1 1 2.1.6 Configurability 2.1.6.1 Workflow 1 1 2.1.6.2 Internationalization 2 2 2.1.6.3 Client Variability 3 2 2.1.6.4 Adaptability 1 1 2.1.7 Maintainability 2.1.7.1 System Administration and Maintenance 2 2 2.1.7.2 Customisation 1 1 2.1.7.3 Back up/Recovery/Restoration 1 1


B202

2.1.8 Flexible Modular Design 2 2 2.1.9 Security 2.1.9.1 Authentication 2 2 2.1.9.2 Authorisation 2 2 2.1.9.3 Information Security 1 1 2.1.9.4 Auditability 1 1 2.1.9.5 Security Management and System Administration 2 2 2.1.10 Archiving 2 2

2.2 IT Architecture Requirements 2.2.1 Layered Application Architecture 2 1 2.2.2 Composability 2 2 2.2.3 Portability 3 2 2.2.4 Extensibility 2 2 2.2.5 Uniform Technologies 1 1 2.2.6 Multiple Communication Channels 1 1 2.2.7 Access and Integration with Third Parties 1 1

2.3 Support Requirements 2.3.1 Local Expertise 2 2 2.3.2 Monitoring 1 1 2.3.3 Phased Migration 2 2

2.4 Financial Consideration 2.4.1 Ownership 1 1 2.4.2 Maintenance and Enhancement Cost 2 2 2.4.3 Escrow agreement 1 1

B202 Non-Functional Requirements v1.1 - Western Cape ... · PDF fileother IT personnel to...

Documents

Transcript of B202 Non-Functional Requirements v1.1 - Western Cape ... · PDF fileother IT personnel to...