代写KIT206/506、代做System、代写SQL程序设计、SQL语言代做

日期：2020-09-28 11:20

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-andcommunication-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.

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.