1. Introduction (Bård)
1.1 Purpose
The University of Oslo has for a long time had a system for sending SMS to our employees and students. This system has been developed locally, and is currently in use as a joint service for Universities and Colleges in Norway.
The service is normally used to inform about changes or cancellations of lectures and other teaching activities. The service is also used as a general information channel to people affiliated with the individual institutions.
A sub-component of this system is a link to an external telecom operator for the actual sending of the SMSs. For us, it is important to have a predictable agreement with a supplier who can offer a stable and secure service so that we can meet our needs.
Our end users are people with origins from all countries of the world, and thus with private mobile phones connected to operators from all over the world. Therefore, it is also important that the supplier has good contact with other operators in the market to be able to more easily access any discrepancies.
1.2 Intended use/Scope
The primary object for this tender is to have the opportunity to send SMS from our local system, but we also want to have the opportunity to develop the service and are therefore interested in other nearby services we may be offered as well. Other services around SMS is also of interest.
2. Overall description (Bård)
2.1 User needs
Today's solution is a locally developed system that through various interfaces receives text messages for sending, generated from the various local systems the different institutions have. Primarily here is 'Felles Studentsystem', FS, which is the study administration system used by all institutions in Norway.
<insert figure>
Another key user of this local service is our monitoring systems so that alarms and other important information can be sent out from there.
To support this system we need a provider to take our messages and send them out as SMS.
2.2 Assumptions and dependencies (Rune/Nina)
GDPR-compliance
Documentation on how the requirements of GDPR are complied with in the solution, must be provided.
The documentation should in particular include:
- Built-in privacy, describe storage and information security in the solution (integrity and confidentiality)
- How the service complies with the data subjects' rights, such as the possibility to delete personal data in the service and the opportunity to provide access to personal data.
Data processing agreement
Since the assignment is to process personal data on behalf of the customer, the supplier is obliged to enter into a data processing agreement with the customer in accordance with privacy legislation. Personal data shall not be transferred to countries outside the EEA area without agreement and documentation proving that the conditions of the agreement have been met. US subcontractors shall not be used, who have access to, or process personal data.
3. System features and Requirements (Sverre)
3.1 External interface and functional requirements
A standard REST API is preferred for sending and receiving messages. The communication must be secured in a satisfactory way.
Please describe your API with functions and what it offers. This must also include how security is handled, like authentication, encryption, etc.
This is the minimum of functions needed:
- Sending sms
- Receiving sms
- Get status - sms delivered, not delivered, failed, etc
- Sending from standard 8 digit numeric number
- Sending from alfanumeric number
- Sending from short 4 digit number like 2080
- Change sender / from number individually on each sms
- Receiving sms sent to a short 4 digit number like 2080 starting with a keyword
- Receiving sms sent to a standard 8 digit number
- Sending long sms up to minimum 800 characters
- Support for UTF-8 or other character sets including norwegian letters
- Support for MMS ???
3.2 Additional features / functionality
For future use it is interesting to know what other functions, products and solutions you offer for sms. We have a very basic use today but this may change in the feature. A documentation of what you can offer is desired.
3.4 Non-functional requirements (Rune/Nina)
Service availability
Service availability for the service provided should be???
Planned maintenance
Bla bla
Support
The supplier must provide documentation of their support service.
The solution provided by the supplier should include a Support Service, where it is possible to contact the supplier, for example by e-mail or telephone in normal working hours, monday to friday between 08:00 and 16:00 (Norwegian time).
The supplier should also be able to provide payable support services between 16:00 and 08:00 on public holidays in Norway or on weekends (?)
Disaster and continuity plan
Bla bla
IT-security
Bla bla
Auditing and supervision
Bla bla