Non-Functional Requirements (NFR)
1.1 NON-FUNCTIONAL REQUIREMENTS
1.2.1 Standard product warranty is requested. Indicate their scope and period and criteria for care.
1.2.2 Possibility of high availability with recovery and failover capability.
1.2.3 Overall end-user response times must be’reasonable’: 5 seconds on average for a page update.
1.2.4 Dates and time parameters are displayed in the local time zone depending on the user’s location, but are stored as epoch for consistency.
1.2.5 Highly restricted data must be encryptable. In addition, any email coming from the tool must be encrypted.
1.2.6 The system must scale to hundreds of thousands of records.
1.2.7 This section should detail the activities for implementing the solution.
– Review of current situation
– Development of the implementation plan that reflects all the tasks required to deploy the solution.
– Integration with external elements (Remedy, ICARO, Excel,…)
– Implementation of the procedures, the service catalogue, integration with other systems such as those that make up an input, integration with other systems that represent an output.
– Testing phase in which the system will undergo a period of 3 months to identify deficiencies in the processes.
– Correction and tuning phase. Implementation / re-implementation of those deficiencies identified.
2 The solution must use English as the primary language. The ability to use Spanish and Portuguese will be an asset.
|Infrastructure||Is the solution able to run on UBS infrastructure and UBS operating system builds (Win server 2012, Redhat 5.5)|
|Infrastructure||Does the solution provide Heartbeat functionality including CPU, memory and disk space utilization at intervals of 5 min or less|
|Access Controls||How does the platform authenticate users or groups; LDAP, account and password etc.|
|Access Controls||Does the solution have role based access control|
|Access Controls||Can the default Administrator account be de-activated or password changed|
|Access Controls||Does the solution enforce Superior Strong Two-Factor Authentication (2FA) for users based on tamper resistant hardware (RSA or Gemalto)|
|Access Controls||What mechanism can be used to authenticate non-personal (technical or service) users? Does it allow for:|
A.) Kerberos-based authentication
B.) Certificate-based authentication
C.) Storage of certificate within a hardware security module?
|Logging||Does the solution provide user action logging|
|Backup||How often can the configuration backup be configured and what is the recovery procedure?|
|BCM||How can the solution be integrated in a resilient way, so that the service can perform without interruption and with minimal maintenance / change windows?|
|Fault handling||1. Does the application provide automated handling of potential faults and exceptions related to disruption of service, lack of capacity, processing failure and deviation from scheduled processing?|
2. If the application cannot handle the exception automatically, does it allow for generation of an alert that can be subsequently forwarded to the central event monitoring system?
|Credential storage||Can you confirm that application fulfills the following requirements:|
1. Never including credentials (i.e. passwords) in clear text within the source code, configuration files, batch files, login scripts, software macros or binaries
2. Not caching the ‘Administrator’ credentials or other super-user type privileged accounts data
3. Allowing storage of credentials either within a file or database, only if access to such credentials is protected or that the credentials are encrypted or obscured.
|Reporting||Does the solution allow the creation of custom reports?|
Can report summaries be sent via email weekly?
|Upgrading and Versioning|
|Implementation & Installation Support|
|Training and Documentation|
|Company organisation and background|