WITH REQUIREMENTS SPECIFICATION, SOLUTION DESCRIPTION / MARCH 2017
Competitive procedure with negotiation
regarding
for
delivery and implementation of an IT solution for course and examination planning at Aarhus University
Contents
1 Scope and background for the Contract 5
1.1 Target and key success factors 5
1.2 Key success criteria for the Solution 5
2 Place of delivery 6
3 General requirements for the Solution 6
4 Requirements for role and rights management 8
5 Requirements for searches, sorting and display 10
6 Note field for each activity 18
7 Ad hoc bookings 19
8 Time slots 21
9 Core processes 22
9.1 K01 – Planning Data 22
9.2 K02 – Activity basis – teaching 26
9.3 K03 – (Auto) timetabling 29
9.4 K04 – Quality checks – Teaching 40
9.5 K05 – Publication of plans – Teaching 41
9.6 K06 – Handling changes – Teaching 43
9.7 K07 – Planning data – Exams 44
9.8 K08 – Activity basis – Exams 49
9.9 K09 – (Auto) exam planning 52
9.10 K10 – Quality check – Exams 63
9.11 K11 – Publication of exam plans 63
9.12 K12 – Handling changes – Exams 66
10 Operational Processes 67
10.1 D01 – Self-service 67
10.2 D02 – Logging 72
11 Support Processes 73
11.1 S01 – Sandbox 73
11.2 S02 – Exam supervisors 73
11.3 S03 – Co-examiners 74
11.4 S04 – Export of data and reports 75
11.5 S05 – Accelerated updating of individual data transfers 77
12 Non-functional requirements 78
12.1 Architecture 78
12.2 Integration 80
12.3 IT security 93
13 Service Deliveries 101
14 Logical and system interfaces 103
14.1 Instructions for reading the diagram 103
15 Overview diagram showing business objects 105
Instructions for Tenderer
Handling of requirements in the negotiation situation
Section 5.2 of the ITT holds a detailed description of the Contracting Authority’s handling of the various requirements in the negotiation phase, just as sections 5 and 6 of the ITT describes the individual phases of the tender process.
Minimum requirements and requirements
The tender documents use the following terminology regarding minimum requirements and requirements:
- Requirements that must be met in order to participate in the tender are referred to as minimum requirements (MR).
- If just one minimum requirement (MR) is not met, when submitting the final tender, the tender is non-compliant and the Customer is obligated to reject the tender.
- The Supplier must not reserve any rights in respect of the minimum requirements in its final tender.
- Nor is the Supplier allowed to offer alternative products or solutions which do not meet the minimum requirements.
- When submitting the final tender, the Supplier must tick that all minimum requirements are met.
- High-priority requirements (R1) and lower-priority requirements (R2) do not have to be met in order to participate in the tender.
- R1 and R2 requirements can thus be fully met, partially met or not met at all, without the tender being non-compliant.
The Supplier’s description of the degree and/or method of fulfilment of the Customer’s requirements (R1 and R2) will be considered as part of the Customer’s evaluation of the Criterion ‘Quality of The Solution’ section 8.2.9 of the ITT.
If the solution offered by the Supplier only partially satisfies an R1 or R2 requirement, the Supplier must highlight the specific requirement in the requirements specification and describe the partial fulfilment
The Customer’s evaluation of each requirement described in this Contract Appendix is further explained below and in section 8.2.9 of the ITT.
The requirements in this Contract Appendix 3 will be presented as follows – the Supplier is obliged to follow the structure:
Requirement no. / Requirement heading / Requirement typeCustomer’s specification of the requirement
Fulfilment of the requirement
The Supplier must state whether the requirement has been fulfilled by ticking the relevant box. / No / Yes / Partially
Supplier’s response to the requirement
Requirement no. – A sequential number for identification of the requirement
Requirement type – The following requirement types are used:
Minimum Requirement (MR)
Requirement 1 – high-priority requirement (R1)
Requirement 2 – lower-priority requirement (R2)
Evaluation point – included in the evaluation
Requirement heading – Brief outline of the requirement
Customer’s description of the requirement – Customer’s description of the requirements and any expectations regarding fulfilment.
The Supplier’s solution description will be used in connection with the Customer’s evaluation of the tenders with a view to assessing the degree to which the requirements have been satisfied.
The tenderers are therefore urged to provide as detailed an account of each requirement as possible (simple yes/no answers may result in a low score).
When responding to the requirements (both R1 and R2), the Tenderer must indicate whether they are met using Standard Software or Customised Software.
Please note that minimum requirements (MR) are compulsory and must be satisfied by the Supplier for the tender to be considered, whereas R1 or R2 requirements do not need to be satisfied for a tender to considered.
The Customer’s evaluation of the tenders will take into account the degree to which the requirements have been satisfied.
Please note that failure to satisfy a high-priority requirement (R1) may have a negative impact on the evaluation and result in a considerably lower score.
The requirements in the requirements specification are grouped under headings referring to the following categories of system processes:
- Core processes – the daily operational actions (K01-K12)
- Operational processes – provide the operational basis for carrying out the core processes (D01-D02)
- Support processes – a series of actions that are not directly included in the daily operations, but that support the daily operations and core processes (S01-S05)
Please also see the Contract Appendix 3A - Terminology List, which contains definitions of key and central concepts in this appendix. The Terminology List is useful for understanding the various concepts and the contexts in which they occur.
This section under the heading "Instructions to Tenderers" will not form part of the final Contract.
1 Scope and background for the Contract
As part of the consolidation strategy on the most business critical IT-systems at Aarhus University, it is very important for the Customer to stabilize and realize the business requirements and processes for a common planning solution to execute the planning of courses and examination. The goal in the implementation is to prioritize a strong focus on quality, usability and end-user satisfaction by keeping it simple and intuitive.
The solution shall meet the aim of consistency of the core work processes, general common overview, reusability of data, smooth data exchange between the administration and the teaching environment, process optimization and availability of personalized information and notifications.
1.1 Target and key success factors
The attractive solution for the Customer shall basically include functionality to support the following goals:
- Increase of user satisfaction for teacher, student and the administrative staff.
- A more personalized login and look and feel so the user easily can find and access the significant and individual information and notifications.
- Increased self-management through overview of free facilities and the possibility of booking necessary facilities with controlled rights.
- Optimization of the administrative staff member’s workflow and processes by improving consistency and validation according to conflicts in the planning work.
- Delivering possibilities for more automatic control on recurrent activities in the academic life cycle.
- Ensuring more transparency in the use of rooms for courses and examination activities enabling a continuous optimization of the planning.
1.2 Key success criteria for the Solution
- User satisfaction for all end users
- Creating a framework for facility optimization and increased auto planning, reporting and statistic.
- Easier and quicker availability, self-service and reliability of updated information at the individual level.
- Contribution to simple and healthy principles for architecture, development and maintenance of the total solution.
Under the Customer’s IT strategy, standard systems based on a ‘best of breed’ principle are preferred. The Customer therefore prefers a solution based on a standard product with a minimum of special development. One consequence of the ‘best of breed’ principle is that a number of integrations must be established between the standard systems that are part of the Total Solution. A solution based on standard integrations is also preferable here, as far as possible.
The tender covers an IT system solution in line with the requirements specifications, implementation of the Solution for – and in cooperation with – the Customer, and the subsequent operation and maintenance of the Solution.
2 Place of delivery
The Delivery must be delivered to
Aarhus University
Nordre Ringgade 1
DK-8000 Aarhus C
During the clarification phase it will be decided where meetings, workshops, training etc. must be held, and where the installation of the Delivery must be performed.
3 General requirements for the Solution
This requirement is a general requirement that applies across all other functional and non-functional requirements specified for the Solution.
The assessment of each requirement will focus on how user friendliness is handled in the Supplier’s Solution.
Requirement no.K-3.1 / User interface language / Requirement type
R1
The user interface language, including menus, error messages etc., must be Danish. It must also be possible to choose an English user interface. It must be possible to switch between the languages while working.
Fulfilment of the requirement
The Supplier must state whether the requirement has been fulfilled by ticking the relevant box. / No / Yes / Partially
In the Supplier’s response to the requirement, emphasis will be placed on the Supplier’s ability to explain how it will be ensured that the user interface is 100% Danish and 100% English, and that all user actions can be performed using both user interfaces.
Requirement no.
K-3.2 / General ease of use / Requirement type
Evaluation point
An interface and layout is desired with a focus on ease of use, intuitive solutions, shortcut keys, response times, auto-complete, the option to undo user actions, saving facilities and the number of clicks.
Fulfilment of the requirement
The Supplier must state whether the requirement has been fulfilled by ticking the relevant box. / No / Yes / Partially
The Supplier should demonstrate how user-friendly the Solution is, for example using mock-ups, screenshots and descriptions of ease of use in general and on specific points.
The Supplier will be assessed on ease of use for the various user groups.
4 Requirements for role and rights management
This group of requirements relates to the options in the Solution for creating, maintaining and deleting users.
The requirements relate to the management of individual users, the definition and management of user groups and the assignment of rights to these users and user groups.
Requirement no.K-4.1 / Creating and deleting users / Requirement type
MR
It must be possible via integration to create and delete users.
Fulfilment of the requirement
The Supplier must state whether the requirement has been fulfilled by ticking the relevant box. / No / Yes / Partially
Supplier’s response to the requirement
Requirement no.
K-4.2 / Maintenance of user roles / Requirement type
R1
It must be possible to define and maintain user roles and associated rights for users and user groups in the Solution.
Fulfilment of the requirement
The Supplier must state whether the requirement has been fulfilled by ticking the relevant box. / No / Yes / Partially
The Supplier should describe the parameters which can be varied for user roles. For example, but not limited to:
- Access to booking specific (groups of) rooms (also as the primary user)
- Access to planning teaching and/or examinations at different levels
- Access to changing the configuration of the Solution
- Access to searching, sorting and displaying data for various user groups
- Access to creating and changing constraints and rules at various levels
- Access to manually creating data elements
- Access to creating attributes
5 Requirements for searches, sorting and display
This group of requirements relates to the options for searching, sorting and displaying data from the Solution for the various user groups.
The described functionalities must support the various user groups at AU being able to precisely search for the data they need in their work or studies. The functions’ user interfaces must also support the various user groups’ need for data, information and timetables.
Requirement no.K-5.1 / Searches for data elements / Requirement type
R1
It must be possible to search on all data elements, ad hoc bookings, attributes, combinations of data elements and scheduled and non-scheduled activities.
Fulfilment of the requirement
The Supplier must state whether the requirement has been fulfilled by ticking the relevant box. / No / Yes / Partially
Supplier’s response to the requirement
The Supplier must describe which data elements and attributes for data elements can be searched on, including but not limited to:
- Data elements (such as teacher, course activities, students etc.)
- Attributes (such as the number of seats in a room, students’ educational level, enrolment status in the programme administration system etc.)
The Supplier must also describe how data elements can be searched on and combined in a search.
The Supplier must also describe the ease of use of the search function, for example searching using wildcards.
Requirement no.
K-5.2 / Sorting of data elements / Requirement type
R1
It must be possible to sort all data elements, ad hoc bookings, attributes, combinations of data elements and scheduled and non-scheduled activities.
Fulfilment of the requirement
The Supplier must state whether the requirement has been fulfilled by ticking the relevant box. / No / Yes / Partially
Supplier’s response to the requirement
The Supplier must describe which data elements and attributes for data elements can be sorted, including but not limited to:
- Data elements (such as teacher, course activities, students etc.)
- Attributes (such as the number of seats in a room, students’ educational level, enrolment status in the programme administration system etc.)