KIT206/506 Case Study: Human Resource Information System — Requirements Document
KIT206/506 Case Study: Human Resource Information System — Requirements Document
1/3
Human Resource Information System
1. Introduction
The ICT Discipline within the School of Technology, Environments and Design requires the
Human Resource Information System. The objective of the system is to provide easy access
for front desk staff to critical (but public) information about each staff member so they can
answer student queries easily. This information includes phone, room location and the units
they teach. The information, which includes both textual data and staff photos, is to be
presented via a Windows 10 desktop application.
2. Existing Systems
Currently this information is available via a disparate set of webpages. The new system will
operate in parallel to these webpages. On the School website on the People page there are
generated staff lists that give phone and location details:
https://www.utas.edu.au/technology-environments-design/people/information-and-
communication-technology
Timetable information, is available at:
https://student-timetable.utas.edu.au/#Search
There also currently exists an administration system that allows the support staff to enter all
the required information into the database to be displayed. This project does not include the
redevelopment of this administration system.
3. Platform
The Human Resource Information System must operate within the Standard Operating
Environment (SOE) of School desktop machines, which are a mixture of Dell and Apple
products that all run Windows 10. The information that the system will display is currently
stored in a MySQL database, named the “School Database”, and this database content and
structure cannot be changed. As this system does not include redevelopment of the
administrative entering system that facilitates input of the information into the database, the
new system must work with the existing database.
The final system is to be developed using C# and the sources shared with technical staff from
Information Technology Resources so that they may maintain it into the future.
4. Users
Administrative and technical support staff will use the new system. Both groups will have
access to the same features, so there will be no need to differentiate between users.
5. Components
The Human Resource Information System will consist of two main components: staff lists and
unit timetable display. These may be enhanced by the addition of another component: activity
heat maps.
5.1 Staff Lists
The user shall be able to view an interactive list of staff employed by the School. The list will
be accessed by selecting a tab labelled ‘Staff’, and should be visible upon application start up.
This list should display names in the format ‘Family Name, Given Name (Title)’, as in ‘Einstein,
Albert (Dr)’, ordered alphabetically by family name and then given name. Ideally this list
should be visually compact.
https://www.utas.edu.au/technology-environments-design/people/information-and-communication-technology
https://www.utas.edu.au/technology-environments-design/people/information-and-communication-technology
https://student-timetable.utas.edu.au/%23Search
KIT206/506 Case Study: Human Resource Information System — Requirements Document
2/3
The Staff List view should be able to filter the displayed staff based on their category. The user
should be able to list all staff, academic, technical, administrative, and casual. The School has
a large number of staff and being able to restrict the list in this fashion will allow the user to
find people quickly.
It would enhance the system’s utility if the user could also filter the list by entering part of a
staff member’s name. The list contents would be restricted to show only those staff whose
given name or family name contains the text entered by the user, ignoring case.
When the user selects a name in the list the system will show more details about the staff
member (referred to as the Staff Details view), which should include:
• Name
• Campus
• Phone Number
• Room Location
• Email Address
• Photo
• Consultation hours
• Table of units he or she is involved with in the current semester
It would enhance the software if selecting a unit code in the table of units takes the user to
the timetable view (described below). It would also be useful for each staff member’s current
availability to be displayed: ‘teaching’ (with details of the unit code and room) if they are in a
timetabled class; ‘consulting’ if it is during their consultation times; ‘free’ otherwise. This
would allow front desk staff to direct enquiries appropriately, given a staff member’s
availability.
It would enhance the Staff Details view if the staff member’s activity (classes and consultation
times) across a week could be displayed in a colour-coded grid. This grid should be toggled
(displayed or hidden) via a button on the Staff Detail view. The grid should have days of the
week (Monday through Friday) as columns and hours of the day (9am until 4pm) as rows, with
each cell’s colour indicating the kind of activity at that time, but no other details shown. Free
time should be shown in white, while teaching and consultation times should be shaded in
distinct colours that are distinguishable by those with common forms of colour blindness.
5.2 Timetable display
The system should be able to generate a list of the units under the control of the School,
ordered alphanumerically. Selecting a unit from this list should bring up a list of classes for
that unit, ordered chronologically. This view should be tabular, showing the following
information about the selected unit in each column:
• day
• start and end time in 24-hour format, such as ‘12:00–14:00’ or ‘12:00–13:50’
• type (Lecture, Tutorial, Practical, Workshop)
• room location
• campus
• staff member
It would enhance the software if it is possible to go from a timetable entry to the Staff Detail
view for the relevant staff member, just as if selecting that person in the Staff List.
KIT206/506 Case Study: Human Resource Information System — Requirements Document
3/3
The user will be able to filter the timetable so that it displays information for a single campus.
This feature should make it easier for staff to access information relevant to their location.
5.3 Class and Consultation Heat Maps
It would enhance the application’s utility if it could generate ‘heat maps’ of activity across the
week. It should be possible to generate two different heat maps, one for unit classes and
another for consultation times. It must be possible to generate different heat maps for all ICT
Discipline classes, and those only occurring in Hobart or Launceston. All heat maps shall be
accessed via a menu or buttons on a dedicated tab.
Each heat map will be displayed as a grid of coloured cells, with columns for each day of the
work week (Monday through Friday) and rows for the starting hours 9am through 4pm. Each
cell in which zero activities occur should be blank, while cells representing one or more
activities should contain the number of co-occurring activities. The shading of each cell should
indicate the number of events occurring at that time, with white indicating no events and a
solid colour indicating the greatest number of events within the set of events being displayed.
Intermediate values should be assigned a colour intermediate between white and the selected
solid colour. It would be nice to allow the user to select the primary colour of the heat map.
5.4 Class and Consultation Clashes
It would further enhance the application’s utility if it could generate a variant of the heat map
that shows clashes between a unit’s classes and the consultation time of staff involved in
teaching that unit. This would be accessed via a button on the Unit Timetable view, and use
data for the currently displayed classes and staff who teach them (that is, both campuses,
Hobart only or Launceston only). The cells in the grid should use the following colour scheme:
white if no class or staff consultation occurs on that hour and day; bright green if that time
contains either a class or consultation, but not both; and red if it contains both consultation
and a class. Cells representing clashes should also include the text ‘clash’.
6. Manual
The system will need to have an associated technical manual. This manual should explain the
system development so that the system can be maintained by School Technical Staff.
7. Addendum
The list of units shall be formatted as ‘UnitCode UnitTitle’, as in ‘KIT206 Software Design and
Development’. It would enhance the system’s utility if the user could also filter the list of units
by entering part of a unit code or title. The list contents would be restricted to show only those
units whose code or title contains the text entered by the user, ignoring case. Search queries
including both code and title do not need to be supported.
Human Resource Information System
1. Introduction
2. Existing Systems
3. Platform
4. Users
5. Components
5.1 Staff Lists
5.2 Timetable display
5.3 Class and Consultation Heat Maps
5.4 Class and Consultation Clashes
6. Manual
7. Addendum