Proposed University Attendance Monitoring System

TABLE OF CONTENTS

Team Outline, Contribution Form & Project Minutes ………………………..2

Project Plan…………………………………………………….3

Project PLan Writeup…………………………………………….4-5

Chapter 1: System Introduction ………………………………………6

1.1 System Background ……………………………………………6

1.2 Problem Statement …………………………………………..6-7

1.3 Overview of The Current System ……………………………………7

1.3(a) Objectives of the Current System………………………………..7

1.3(b) Issues With the Current System………………………………….7

1.3(c) Means of Improvement………………………………………7

1.4 Alternate Solutions …………………………………………….8

Chapter 2: System Requirements………………………………………8

2.1 Methodology………………………………………………8-10

2.2(a) Waterfall Model……………………………………………9

2.2(b) Spiral Model……………………………………………9-10

2.2(c) Prototyping……………………………………………..10

2.2 Fact Finding………………………………………………11-13

2.2(a) Questionnaires……………………………………………11

2.2(b) Fact Finding Results……………………………………..11-13

2.2(c) Interview……………………………………………….13

2.3 Functional & Non Functional Requirements………………………….13-14

2.3(a) Functional Req………………………………………….13-14

2.3(b) Nonfunctional Req…………………………………………14

Chapter 3: System Specifications…………………………………..14-16

3.1 Narrative Description…………………………………………..14

3.2 Data Flow Diagram (Context Level) …………………………………15

3.3 Data Flow Diagram (Level One) ……………………………………15

3.4 Entity Relationship Diagram………………………………………16

Chapter 4: The Proposed System …………………………………….17

4.1 System Storyboard………………………………………….17-22

4.2 Design Decisions Explained………………………………………23

4.3 System Output Explained………………………………………..23

4.4 System Output Explained……………………………………..23-24

Bibliography …………………………………………………..25

Appendix…………………………………………………..25-26

Project Roles & Meetings Outline –

Initial Project Meeting (23/11/17) Project Minutes:

Final Group Meeting (07/12/17)

• Reviewed Inputs/Inputs of the system
• Performed collaboration on the functional/non-functional requirements
• Finalised both the Entity Relationship and Data Flow Diagrams (Level 1 and Contextual)
• Reviewed all previous pieces of work for the final document
• Discussed an order for the overall document as well as styling/design.
• Filled in group contribution form for each individual task
• Began work on formatting several documents into a singular file.
• Discussion of system background info
• Analysing the issues associated with the current system
• Debating the apparent costs and needs of a new system
• Assignment of tasks and rolls to individual group members
• Proposed an approximate project completion time
• Agreement over weekly meeting dates and times

Group Meeting 1 (29/11/17)

• Reviewed problem statement contents
• Reviewed fact finding techniques
• Finalised Microsoft Project plan
• Discussed appropriate methodologies
• Discussed distribution of student survey
• Presented alternate ideas and several solutions for the system
• Finalised system specifications

Group Meeting 2 (1/12/17)

• Looked over project GANTT chart
• Reviewed methodologies
• Made alterations to the problem statement
• Reviewed alternate solutions and other possibilities
• Discussed Interview Findings
• Analysed Fact Finding Questionnaire Results
• Established and distributed final work pieces between members

Microsoft Project Outline:

Microsoft Project Write-up:

Chapter 1: System Introduction

1.1 System Background

The proceeding acts as an analysis of requirements for the Ulster University Attendance Monitoring System. This document acts to inform on the limitations of the current paper based operating system and needs of the proposed electronic one, in addition to the means of its implementation. Within this specification we will identify issues plaguing the current monitoring model via our fact finding methods and what features would most improve on the University’s current system. Above all else system’s own aims are to offer an easy method for the university to both record and monitor student attendance ratings, comparing each student against the policies in place by the university itself and informing module co-ordinators of this discrepancy.

1.2 Problem Statement

The University’s desire for both a monitoring policy and coinciding system arises from a need to identify students, whose attendance falls below a particular threshold, allowing further arrangements to be made to discuss notable absence or exceptional circumstances. Additionally it offers a means of denoting students that fail to reach the minimum attendance to progress onto the following year of their studies.

The current system works of a paper based model in which each student of a lecture, tutorial or practical notes their participation in the form of a signature. This information is then passed onto the acting Module Co-ordinator and inevitably stored via the Game Enhanced Learning (GEL) System manually by the staff member, a system which has been in active use for over 2 years, making use of the csv file located in the school office to amend and maintain course and student details. The program also facilitates the creation of sign in sheets and statistic based models. The responsibility of identifying clashes with University policy falls upon each individual Co-ordinator themselves, as does the proceeding meetings with students, unless in the instance of exceptional circumstance, in which the college board themselves assess the nature of the situation.

The issues of this format exist in the form of inaccuracies, user manipulation and data loss. The method of each student offering a signature opens up the possibility of forgery, as without a unique identifier to denote each student’s attendance, data manipulation becomes increasingly probable. Currently there is no means of identifying falsified information due to the method by which these signatures are taken. Likewise the current model opens a means by which harassment and bullying become possible, allowing unnecessary input from students beyond the system’s intended purpose.

The paper based system was initially created as a simple affordable means of implementing the department’s attendance policy. Hence while the initial application of the system offers an economically feasible solution, the likelihood of loss or misplacement is increased via both transportation and from being passed across the respective class or lecture hall itself. Coinciding with this, the system has no such means of noting attendance across the length of the class itself, providing no data on whether students remained for the duration of the session or merely until attendance was marked. As a result the data itself can be seen as an inaccurate representation of each student’s yearlong attendance.

On the side of data stores, notable issues arise in relation to the Data Protection Act and who should have access to attendance records. Under the current system students have no access their attendance ratings, hence a possible solution may be to introduce an attendance section to the Ulster Portal, providing students with access to their participation across individual session, entire modules and the course in its entirety. Furthermore attendance ratings of students crossing over from other school’s such as business must be manually provided to their respective college manually.

The objectives of the proposed system follow the University’s desire for an electronic format by which to both record, and store, user input and student attendance itself, centralising it from the School Office. The proposed solution’s own objectives are to offer not only a more streamlined form of data entry, but to also lessen the likelihood of falsified data associated with the paper based nature of the current system.

The solution itself come in the form of unique swipe in cards, based off the University’s unique B Number identifiers for each student. Upon both entry and exit, each student swipe their unique Student ID card or alternatively manually type in their Banner ID; with the system making a log of the students own information via the GUI database, the particular lecture they attended as well as to the time they both enter and leave the session.

Above all else this lessens the possibility of data manipulation, requiring the students own sign in ID card rather than a generic and unidentifiable signature. Additionally it effectively rules out any form of unnecessary input from the student body, eliminating the possible issue of student harassment via sign-in sheets.  Likewise with attendance being noted at two separate stages the system allows for greater accuracy and a clearer image of participation throughout the entire duration of class time, while also removing the present issue of misplacement and distraction from the session at hand.

The constraints associated with this come in providing each individual student with a means of noting attendance in addition to the economic feasibility of both implementing and maintaining the proposed system. With the need for unique identifiers each individual student will require a sign in card by which to record their participation; in effect we are depending on each student to bring their card to each and every one of their respective lectures, or alternatively remember their ID Number off hand.

The issue also remains that each classroom and lecture hall will require its own form of card reader from which to record this data regardless of size or usage time. This then begs the feasibility of the proposed system in face of the large number of teaching facilities within the campus’ and Computing and Engineering Department itself. The implementation of this system will also require staff and or training to maintain the functionality of the system and to assure correct data entry across every reader. Likewise this will also allow a greater level of automation in identifying students whose attendance has cause for concern, sending automatic emails to lecturers in cases where students are failing to adhere to school policy.

1.3 Overview of Current System

In analysing the state of the current system we can deduct where the current system aims to succeed and where it meets problems within its current architecture. Therefore to make improvements we must not only identify these issues, but actively work in producing solutions to them. Coinciding with this we must produce a system that offers additions and new features which serve to further the functionality of the system in achieving its objectives.

1.3(a) Objectives of the Current System

• To record daily attendance of each student within the college
• Offer a means to pinpoint failing attendance
• Accommodate meetings between lectures and students over attendance
• Assess students for exceptional circumstances or student support
• Denote students failing to meet the baseline attendance rating to pass the academic year
• Allow staff to maintain student records in the system
• Provide a means of producing models based on attendance records
• Allow for the maintenance of course, year or student attendance records

1.3(b) Issues with the Current System

• It’s paper based and easily lost or destroyed
• Ability to input unnecessary user input from students
• Non-immediate  style of inputting data into University database
• Opens itself up to falsified data with the use of signatures
• Only records student entry, not exit
• No tangible search functions for students using Banner ID Numbers
• Students have no access to their attendance

1.3(c) Means of Improvement

• Switching to a digital format, making data entry immediate
• Removing the signature based model, reducing the potential for falsified data
• Recording data via student cards at entry & exit allows for more accurate data representation
• Offer a greater array of charts and spreadsheets in relation to attendance data
• Giving students access to their attendance rating via the Student Portal

1.4 Alternative Solutions to an Electronic Register System

Biometrics

One alternative solution is to use new and emerging Biometrics technology.  This is any technology that uses an individual’s biological traits as an input which uniquely identifies them, including finger print scanners, retina detection or voice recognition. The most practical and cost effective form of Biometric technology is a fingerprint scanner, which would be placed at the entrance of a classroom or lecture hall for the student to simply place their finger on at arrival.

Pros:

• One major benefit of this is that it offers a completely unique identifier that completely removes the possibility of falsified information
• Only takes a second to touch a finger down on scanner and so is very fast.

Cons:

• High volumes of users continuously using them year round could cause damage to the scanner which would lead to the System being down until necessary maintenance has be achieved.
• It could take several minutes to initially set up a user’s fingerprint to be recognised by the scanner. This could therefore be very time consuming to set up for thousands of students.
• A small minority of users might not feel comfortable supplying biological identification.

Keypad/Pin System

Another solution is to have a pin system. Similarly to the biometric scanner a pin pad would be placed at the entrance of a classroom or lecture hall for the student to enter their unique pin at arrival and also at exit.

Pros:

• Students B number could be used a way of helping user to remember their pin.
• Pin could be changed if necessary, or if the user has forgotten it.

Cons:

• Students could easily have trouble remembering their code and if entered wrong could sign another person in.
• May be time consuming for each individual to enter a code while hundreds are coming in at once.
• User might give pin to another as a way of signing them in.

Online registration

• A third alternative is an online system, which a user will log into and sign in using a password provided at the class/lecture. This could be linked in with the users blackboard account and would be accessed by using the universities free Wi-Fi.

Pros:

• Students are already familiar with use of blackboard.
• Student can only change attendance if they have the unique password

Cons:

• Students may send each other the password
• Internet may not be reliable for a range of devices

Chapter 2: System Requirements

2.1 Methodologies and Rationale

A system development methodology refers to the groundwork that is used to plan, structure and maintain the process of developing an information system. A wide variety of such frameworks have improved and enhanced over the years, each with its own recognised strengths and weaknesses. There are a variety of methodologies as one system development methodology will not necessarily suit the needs by all projects. Therefore, we must analyse a variety of models and establish which best fits the needs of the current project.

2.1(a) Waterfall Model

The waterfall model is a development process which centres on planned work and is best suited to projects where the requirements can be clearly defined. It is the most commonly used of the traditional system development life cycle methods. This model has distinct goals for each phase of development. The waterfall model itself has many stages that must be completed one by one meaning the first section of the task must be fully finished before moving onto the next. Once a phase of development is completed, the development proceeds to the next phase and it is very difficult to turn back and make any changes.

Image Source: http://www.umsl.edu/~hugheyd/is6840/waterfall.html

Advantages

The main advantage of waterfall development is that it allows for departmentalisation and managerial control. It can be beneficial to create a schedule with deadlines for each stage of the development process. The development moves from requirements, through design, implementation, verification and finally finishes at operation and maintenance. The phases of development progresses in a strict order, without any tasks overlapping and being completed simultaneously which then leads onto the disadvantages.

Disadvantages

The disadvantage of waterfall development is that it does not allow for tasks to be completed simultaneously therefore creating a schedule is crucial to balance your workload. It also does not give the user much time to reflect or make any changes. Once a project is in the testing stage, it is very hard to go back and change something that was not carefully constructed and produced in the planning stage.

2.1(b) Spiral Model:

In comparison to the waterfall model, the spiral model is different in the way that it focuses on the exact needs of the user. This model allows for changes to be made easier later after receiving customer feedback. This method is extremely beneficial for the user as it is first produced with the main requirements and then improved with the support and feedback from customers. The Spiral method has four major stages which include planning, risk analysis, testing, and evaluation. Each cycle starts with a planning stage to determine the main objectives, limitations and alternatives of a project. The next phase is the risk analysis, which examines and determines the alternate attempts to identify and solve potential risks. The third part of creating the project comes in the development and testing stage which includes, prototyping, developing and testing the products to find and identify any errors that must be resolved before finalising the product. Finally, comes the customer evaluation phase when the client assesses products and provides feedback to which the developer can act on and enhance the current system.

Image Source: https://onlinedigitaltechnology.com/software-development-risk-aspects-and-success-frequency-on-spiral-model/

Advantages

The main advantage of spiral lifecycle model which separates it from the waterfall model is that it allows new elements and ideas, supplied by customers, to be added into the product to provide a greater experience. This means that constant feedback can be received from customers which allows a more enhanced system to be created that fully meets the needs and requirements of users.

Another positive aspect of this method is that the spiral model immediately involves users and interacts with them from the very beginning of the system development process.

Disadvantages

However, it takes a very strict and careful decisions when developing products as there is a risk of running the spiral in a never-ending loop. This method can be very time consuming and distressing as you are trying to meet the needs of every user which can cause some confliction. The main disadvantage to using the spiral model is that it is a lot less easy to follow, meaning that since there are multiple iterations of the same parts, a lot of people can get lost in what section they are at and it can be the case that it is very difficult to meet a deadline or to meet a budget if there are sections that are constantly looping round repeatedly.

The extent of taking suggestions and requests from user feedback is very important to develop and deploy the product successfully as it is extremely important that the user is satisfied otherwise they will not use the system.

2.1(c) Prototyping

The Prototype model can be extremely useful and is a favourite for many developers as they can view a rough idea of the final system. Multiple prototypes can be produced before creating the final system so any errors can be identified and resolved early. Developing a prototype allows the client to get an “actual feel” of the new system, since the interactions with prototype will be similar to the final product and can enable the client to gain a better understanding of the desired system.

Prototyping is a beneficial method that a lot of developers will use for large and complex systems that have no similar existing system to help determine the main requirements needed to be successful. The prototype model is essentially a trial-and-error process that takes place between the developers and the users to gain feedback to make improvements and enhanced the system to provide users with the best possible experience.

The prototype model provides the developer the opportunity to identify errors, receive customer feedback and explore alternative solutions before creating and finalising a product. This is less likely to involve any problems which means the development stage can run smoothly. Users should also be satisfied with the final system as the developer has considered the feedback provided by customers in the testing stage and implemented these suggestions into the product.

Image Source: https://medium.com/omarelgabrys-blog/software-engineering-software-process-and-software-process-models-part-2-4a9d06213fdc

Advantages

The main advantage of this model is that users are actively involved in the development stage by testing the draft product and providing feedback to the developer. Also, due to this methodology a working model of the system is provided meaning the users get a better understanding of the system being developed. As previously mentions, errors can be detected much earlier and resolved in time for the final product.

Missing functionality can be identified easily and any confusing or difficult functions can be identified and solved for users.

Disadvantages

The prototyping model leads to implementing the requests of many users which may cause some confliction. This methodology may also increase the complexity of the system as the constant changes to the system may expand beyond original plans which will factor on many aspects such as the budget.

Another disadvantage is that users can begin to think that a prototype, intended to be thrown away, is the final complete system. This can lead them to expect the prototype to work accurately and correctly in their business which can lead to disappointed and frustration. Finally, users may also become attached to features that were included in a draft prototype but were then later removed from the specification for a final system due to the demand of other users.

2.2 Fact Finding Methods

Fact finding is a very important tool within Systems analysis. Many fact-finding techniques exist which the analyst can employ in the investigation process. No one technique can be described as better than the others as their reason to be chosen depends purely on the area under analysis. It is common that several different techniques are used to get the correct result. The techniques we decided to use for our investigation were questionnaires and interviews.

2.2(a) Questionnaires

A questionnaire is a research instrument consisting of a series of questions and other prompts to gather information from respondents. Although they are often designed for statistical analysis, this is not always the case.

One of the main reasons as to why we chose to use questionnaires was the fact that massive amounts of information can be collected from a large number of people in a short period of time and in a relatively cost-effective way. They can be carried out by any member of our team with limited affect to its validity and reliability. The results of the questionnaires can then be quickly and easily quantified by either a member of our team or through the use of a software package. This will then allow us to display our results in a way that will make it easier for us to spot patterns or specific reoccurring answers to do with the subject area. The fact that a software package can be used to analyse the results would also save us a lot of time during the assignment.

We as a team designed a questionnaire which we thought would get the most information possible about the current system, we then used these questionnaires to find out what the students within the COM178 Systems Analysis & Design class thought about the current attendance monitoring system and what they thought could be done to improve it. We distributed 50 questionnaires to different students within the class and asked for them to be returned as quickly as possible so that we could go through the questionnaires and analyse them in detail. *Questionnaire located in Appendix A*

2.2(c) Fact Finding Results

From making use of our questionnaires across the Computing school we were able to identify not only a sense of dissatisfaction with the current system, but that students were both willing and able to see the implementation of a new system. This assists us in identifying where new additions can be made and where the current system requires either improving or removal.

Answers	Responses
One	3
Two	7
Three	7
Four	10
Five	9
Six	6
Seven	4
Eight	3
Nine	1
Ten	0
Total	50

Fig1:  As visible in the results above, 36 out of 50 students rated the current attendance system with a ‘five’ or below. These figures show that well in excess of 50% of these students are discontent with how the current attendance system functions on a day to day basis, a staggering quantity in light of its frequent use on a day to day basis. Hence we can deduce that there are issues with the very core elements of the attendance system.

Answers	Responses
Never	13
Sometimes	27
Frequently	10
Total	50

Fig.2: From the results, 54% of the students, ‘sometimes’ ran into problems and 20% of the students, ‘frequently’ run into issues. This means that 74% of students encounter issues with merely marking attendance. As a result it’s imperative the new system is consistent and easily understood.

Answers	Responses
Yes	37
No	13
Total	50

Fig 3: 74% of the students would like to see to new attendance system put in place within Ulster University. In effect this is further proof that the students are not only unhappy with the state of the current system, but also believe that it could be improved into a more streamlined and accessible model.

Fig.4: As you can see from the results, 78% of the students answered, ‘all the time’ to bringing their student card with them. 12% ‘sometimes’ and 10% never bring their student card. As our proposed system requires each student to have their ID card consistently, this was an important question. Only 5 of the 50 answered ‘never’ to bringing their card, however we will be able to remedy this marginal amount through allowing the use of ID Banner numbers to indicate attendance.

Answers	Responses
Never	5
Sometimes	6
Frequently	39
Total	50

Answers	Responses
Yes	37
No	13
Total	50

Fig 5: 94% of the students said that they would like to see a system where they could scan their student card when they enter the class and it would sign them in. This signifies that our proposed system would be easily and openly integrated into the student body with minimal backlash.

2.2(d) Interview

An interview was one of the methods we decided as a group would be best for getting detailed information about the current attendance system, some of the reasons why we chose this method can be seen below.

Interviewing to most people is the most effective form of fact-finding as it provides in-depth, valid information. Its main strength is that because it is conducted on a one-to-one basis, interviews provide a condition where the analyst can conduct the interview in a flexible manner in response to the answers he or she receives. Interviews allow more detailed questions to be asked and they usually achieve a high response rate. Also during an interview, it is possible to deviate from the main area of investigation if the respondent mentions something which the interviewer feels may be relevant. This is not possible in, for example, questionnaires where the format of the fact-finding exercise is pre-defined and fixed. This is one of the main reasons in why we decided to use interviews in conjunction with the questionnaire method. *Interview Located in Appendix B.  However in our findings we were able to unearth a need to redesign the current user interface with lecturers and staff in mind. The mere fact that attendance entry is done manually by the module co-coordinator is a time sink which we felt must be remedied in our digitally based system. Hence we deducted that the new system must not merely be digitally based, but also automated with a speed and ease of use that allows staff to maintain records with efficiency 24/7.

2.3 Functional Requirements & Non-Functional Requirements

The functional requirements are functions which are described as a set of different inputs, the behaviour from these inputs and the outputs which are given.

2.3(a) Functional Requirements

The non-functional requirements are functions which refer to any requirements which specific how the system will perform a certain function on a mechanical level.

• The system should ensure that every student’s details are within the system so it recognises every student upon ID scan, therefore preventing mishaps and wasted University time.
• The system should be updated to keep correct tracks of student details. The details of each student should be updated each semester to ensure that the details are correct.
• The system should ensure that after each student scans or swipes their student card, it is then reset back to the main screen showing a message ‘Please scan or swipe card to clock in’. This will ensure that the students know what to do if they are clocking into class or the lecture.
• The system should be backed up every hour to keep track of what students are attending the classes or the lectures.
• If there are regular occurrences of students not attending classes this should then the students name should be flagged under the record system.
• The system should load within a few seconds to ensure there are no delays, otherwise this could cause latencies for meetings and the possibility of exceptional circumstance
•  The system should save the student information within 5 seconds to ensure that it is ready for another student to scan or swipe their card, this will make sure that there are no delays and that the system is running as expected.
• If in any instance the system goes down, it should be able to reboot within a minute to assure the session is not delayed.
• The system should be available to all members of University of Ulster with an account 24/7, this means that all members of the University will be able to clock in to their classes at any time during the week, and consistently monitor and maintain attendance across their respective classes.
• The system should be able to be used simultaneously, for example the system should be able to clock in different students from different buildings at the same time if they were to swipe at the same time. The exact timing could occur frequently, hence why it’s imperative that  the system is instant and should update each student on whether they are attending or not.
• In an instance of late arrival the system will offer several options to denote the student’s reasoning. This data itself will be recorded, providing useful statistics for analysing student behavioural patterns.
• The system should be available in different languages to cater any foreign students or for any students studying a language. This will ensure that the students understand the system, and for students that are learning different languages while possibly studying abroad, this will sufficiently accommodate their needs.
• The system should give feedback, presenting the users name to denote correct entry.

2.3(b) Non Functional Requirements

The functional requirements are functions which are described as a set of different inputs, the behaviour from these inputs and the outputs which are given.

• The system should be safe and secure covering the data protection act – the system should have records of each student of the university, meaning that when they clock-in to a lecture, their data shouldn’t be at any risk and it should automatically check off the student’s attendance and be available for viewing on their Ulster Portal.
• The system should hold details of each student which include their name, gender, mobile number, university email address and their date of birth – these details should be organised with a view of the students attendance record shown in a percentage, this percentage will be calculated from clocking into each class or lecture.
• The system should perform effectively – for the system to work effectively, the system must be very quick to prevent any problems. For example, if a student scanned or swiped their university card and it took a few seconds to process rather than doing it instantly, this can lead to huge problems if multiple students are clocking into class meaning that this can cost a lot of time.
• The system should be reliable and shouldn’t be at any risk – the system should be to a fully working order to where it doesn’t need any maintenance. For example, it should have any card scanning issues, and should offer an option to where if it does then it should allow the student to enter their university number on a keypad to ensure they are clocked in properly.
• The system should allow students to choose to either swipe their card, or scan it via the barcode – the system should be versatile with no faults or problems, meaning that if the student prefers to scan their card rather than to swipe it then this will be available to them.
• The system should have an easily understood interface that ensures simple and efficient interaction.

Chapter 3: System Specifications

3.1 Narrative Description

The newly proposed system will be digitally based, making use of student ID cards. Each class or lecture hall will be fitted with a card reader, displaying both the current 24h time and sign in/out options. Upon entry students will select ‘Sign In’ and swipe their card. This will record not only the time of arrival, but also information such as the scheduled lecture/class as well as matching it with the data located in their attendance data. The UI will present the input student name to assure the data has been entered, before quickly returning to the main menu.

The reader will compare time of entry against the start time of the class and denote whether student was late and if so, the length of the discrepancy. This will be notified to the user in the form of requiring the user to provide a reasoning for late arrival. Upon exit each student will again be required to denote their exit, allowing the system to calculate the length of participation. This will above all else allow for a more accurate representation of lecture to lecture participation. The system will then automatically update the student’s record to accommodate this new data, calculating an attendance percentage for the module, as well as the course, then reviewing it against the university’s 3 week policy and yearly attendance policy.

For staff they can log into the system using their own unique Staff ID number and accompanying password. In the event the system detects a failure to meet attendance standards, it will denote it on the system with a red tinged backing colour on their respective row. Additionally the system will review whether the yearly participation of any student fails to exceed the minimum yearly requirement, if which found to be true will proc the system to email the respective course co-ordinator. The system will accommodate lecturers in allowing the maintenance and creation of additional attendance records, for either students, or entire modules. Coinciding with this they can make amends to current data or completely delete obsolete or falsified data. Otherwise it will also accommodate an attendance record search function. Allowing lecturers and staff to even search by individual classes, students and even attendance rating percentage

3.2 Data Flow Diagram (Context Level)

3.3 Data Flow Diagram (Level 1)

attendance_models

3.4 Entity Relationship Diagram

1..1

1..*

Attendance System

Scans Card

Classroom ID {PK

Student ID

Time of Entry

Time of Exit

Date

Module No.

0…*

1…1

1…*

Provides Feedback

1…1

1…1

1…*

Inputs Data Into

1…*

1…1

Produces Reports

Chapter 4: Proposed System –

4.1 System Storyboard:

Start-Up Screen:

Field name	Information to enter/Action to do	Type
Sign in	Tap a button	Interactive touchscreen button
Sign out	Tap a button	Interactive touchscreen button
Late	Tap a button	Interactive touchscreen button

Sign In/Out Screen:

Field name	Information to enter/Action to do	Type
B-code	The students B-code	Text box

Late Screen:

Field name	Information to enter/Action to do	Type
Reason	Click (touch) on drop down arrow	Drop down box
‘Slept-in’	Click (touch) on radio button	Radio button
‘Medical appointment’	Click (touch) on radio button	Radio button
‘Family bereavement’	Click (touch) on radio button	Radio button
‘Traffic’	Click (touch) on radio button	Radio button
‘Other’	Click (touch) on radio button	Radio button

Sign-In Screen after Late Screen

Field name	Information to enter/Action to do	Type
B-code	The students B-code	Text box

Attendance Login Screen:

Field name	Information to enter/Action to do	Type
Username	The user’s username	Text box
Password	The user’s password	Text box
Login	Click on the login button	Interactive button
Forgot password	Click on the forgot password button	Interactive button

Create Reports Page

Field name	Information to enter/Action to do	Type
Course (x3)	Click on the drop-down box and select the course from the list or type in the name of the course in the text box below it	Drop down box & Text box
Module (x3)	Click on the drop-down box and select the module from the list or type in the name of the module in the text box below it	Drop down box & Text box
Student	Click on the drop-down box and select the student from the list or type in the B-code of the student in the text box below it	Drop down box & Text box
Threshold	Click on the drop-down box and select the threshold from the list or type in the threshold in the text box below it	Drop down box & Text box
Create (x3)	Click on the create button to create a report	Interactive button
Home	Click on the home button to return to the first page	Interactive button
Logout	Click on the logout button to logout of the system	Interactive button

Run Student Attendance Report

Field name	Information to enter/Action to do	Type
Home	Click on the home button to return to the first page	Interactive button
Logout	Click on the logout button to logout of the system	Interactive button

Run Class Attendance Report

Field name	Information to enter/Action to do	Type
Home	Click on the home button to return to the first page	Interactive button
Logout	Click on the logout button to logout of the system	Interactive button

Run Attendance Records

Field name	Information to enter/Action to do	Type
Home	Click on the home button to return to the first page	Interactive button
Logout	Click on the logout button to logout of the system	Interactive button
Attendance threshold	Click on the drop-down box and select the threshold from the list	Drop-down box

Maintenance

Field name	Information to enter/Action to do	Type
Home	Click on the home button to return to the first page	Interactive button
Logout	Click on the logout button to logout of the system	Interactive button
Add student	Click on the Add new student button to add a new student	Interactive button
Edit student	Click on the drop-down box and select the student from the list to edit the student’s details	Drop-down box
Delete student	Click on the drop-down box and select the student from the list to delete them	Drop-down box

4.2 Design Decisions Explained

Our first set of decisions came in the form of the student to system interaction. We knew that student ID card based data would be the core of our system, however we introduced the alternative of entering the Banner ID number when during out Fact Finding Results that a margin of students didn’t bring their card in on a daily basis. Coinciding with this was the addition of a latency reason query. During instances that a student is late for a particular session we offer several options as a ‘reasoning’ for this occurrence’, feeling the data could be used in assessing the issues that cause non-participation in the first place. Finally the use of signing out during lectures, while time consuming, will offer a more accurate portrayal of attendance across courses and particularly individual student attendance.

As for our staff side of the system, it felt essential that usernames would match staff ID numbers and their accompanying passwords to avoid confusion. But above all else we felt strongly that an automated red backing on student with faltering attendance and a search function which included a search by ‘Attendance Rating’ function would be essential. As taking what we learned from our interview with staff member Martin Doherty *See Appendix B* that the manual nature of the current system was an unneeded use of time for lecturers on a day to day basis, hence providing as much automation in this new system was a key objective.

Finally we felt it was necessary to maintain the system’s current ability to maintain, delete and create attendance records, be them module or students. This was particularly pertinent in regards to functionality for module co-ordinators, allowing a greater level of functionality, providing automated e-mails and data models in regards to elements such as failing attendance on a weekly and yearly basis.

4.3 System Output Explained

Student Input	The students input includes each student being able to scan or swipe their university card on the system. There will also be an option available to the student which allows them to enter their ID number if the swipe or scan system were to ever break down and need maintenance.
University Staff Input	The staff input portion of the system includes the lecturer being able to access the system to keep track of student’s attendance record, as well as any patterns to get to know of why the student isn’t attending class. The teacher inputs through a log-in via their username and password, this is very strict and they must not give these details to anyone else as this can fall under as putting the student data at risk.
Maintenance Input	The maintenance portion of the system includes the maintenance team keeping track of the system and how it works. For example, if there were an issue with the mechanical side of the card readers. The maintenance of the system also includes the database part of the system where regular checks can be carried out to ensure everything is running properly.

4.4 System Input Explained

Attendance Update	The attendance update is a very important output for the system. This update will be carried out every time a student scans their card, swipes their card or enters their ID number to represent that they have attended the class/lecture. The attendance update will go through a process ticking off whether the student had scanned, swiped or entered their ID number within the time frame of the class; showing up as late if the student isn’t on time, or showing as not attended if the  student hasn’t clocked in.
Student Details	The student details will be another output from the system, these details will be shown to the teacher when the student has clocked into the class/lecture. The student details will be automatically updated each time they clock in, along with their attendance record to ensure that the data held for each student is correct.
Option to Search	Another output from the system is they option to search, once the teacher is in the system they will be given the option to search for a student via their name or their student number. With this information, the teacher will be presented with a list of the student details if they need to be contacted, as well as a list of the student’s attendance record to show if there are any patterns of absence.
Attendance Reports for Individual Courses	Attendance reports is another output which the system offers, this allows the teachers to open attendance reports for their class showing which students have been off, and if there are any patterns. With these reports, this will allow the teachers to have a cause for concern with any students to ensure that they try not to miss another day.
Feedback	Feedback from the system is another output which will be given to the student, the teacher as well as anyone in regards to maintenance. The feedback given out to the student from the system will include messages such as ‘Please scan or swipe card to clock in’, ‘Please try again’ or ‘Clocking accepted’. The feedback given to the teacher will be showing that they have logged in successfully, which will also be shown to the maintenance person.
Monitoring System	A monitoring system will be another output of the system, this system will allow teachers to monitor over students’ attendance record. If any student gives any concern to a teacher; they will have the option to star this student to keep a closer eye on their attendance meaning that if they miss another day in the future; they may be interviewed.
Flagged students which didn’t attend the class/lecture	The system will have an output of the students which didn’t attend the class or lecture. This will be calculated through the inputs of each student, with each student clocking into class, this will allow the system to have a note of all of the students which haven’t clocked in for that class. The attendance of both the students that attended, and the students that didn’t attend will automatically be sent to the database, which then will allow the teachers to look over the students that haven’t attended very easily.
Change of Language option	Changing of language is another output from the system. This will be important and helpful for foreign students, or any students that study another language. If the students want to live day to day studying another language, this is a great way for them as well as helping foreign people understand what the system is for.

Bibliography

Textbooks

Systems Analysis & Design By Kenneth E. Kendall, Julie E. Kendall

Systems Analysis & Design (2^nd Ed) By Alan Dennis & Barbara Haley Wixom

User Interface Design for Programmers By Joel Spolsky

Educational Essays/ Summaries

http://istqbexamcertification.com/what-is-prototype-model-advantages-disadvantages-and-when-to-use-it/

http://www.itinfo.am/eng/software-development-methodologies/

https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.html

Appendices

Appendix A:  Attendance Monitoring System: Student Questionnaire:

Name: ____________________

Date: _____________________

1. Out of 10, how would you rate the current attendance monitoring system? 1 being the lowest, 10 being the highest.

2. Do you ever encounter problems with the current system in place? Please circle 1.

Never         Sometimes             Frequently

3. If you do encounter problems, please explain below?

_______________________________________________________________________________________________________________________________________________________________________________________________________________

4. Would you like to see a new system put in place? Please circle YES or No.

YES      NO

5. How often do you bring your student card to campus with you? Please circle 1.

Never        Sometimes          All the time

6. Would you like to see a system where scanning your student card once you enter the class signs you in?

YES      NO

7. What do you believe is the biggest problem with the current system?

Appendix B: Interview w/ Com. Science Dep Lecturer Martin Doherty

Q. How is data input from the manual paper based to system to the database in which it is stored?

A. There are two routes for smaller groups the lecturers will do it themselves and in larger groups the attendance sheet is handed into the administrator of the general system and she puts them in.

Q. Where is the data stored thereafter?

A. There is a database that was created by Michael Callahan, its local and is stored in one of our own severs.

Q. If a student is failing to attend lectures, how is this spotted by the lecturer themselves, how are they notified if a student’s attendance is dropping below certain percentage?

A. You can see from the reports that are already there, you can see the percentage of the attendance as well. In most cases the course director will pick this up first and consult the lecturer or if a lecturer has a concern with a student they may consult the course director. The course director will see statistics of all modules across the course but the lecturer of a specific module will only see the statistics for their module.

Q. Is this feedback monthly or how frequently would this feedback be presented?

A. You can take out the reports as often as you want.

Q. How can these patterns analysed? What output are produced?

A. It’s just statistics as of now but I know Michael had plans for various charts, but I certainly haven’t used them myself. As modules are added to the gel you will get a graphic display as well.

Q. If multiple sign in sheets are used, how is all of the data then compiled?

A. There’s no way of compiling them. If you have multiple sheets used it awkward for the person putting it in as you have to go through each sheet. It’s a tick list at the moment as they have to use one sheet and tick off everyone in on that one and the do the same for the next sheet and so on, this is time consuming and is why for larger classes this is done by the administration staff.

Q. Is there a data backup and if so where is it?

A. I’m sure there is and it would be held elsewhere (off campus). There are multiple servers here, the server at the moment SCAS6, so there a lot more servers than that.

Q. What is the action taken about poor attendance?

A. Students are brought in and if they don’t come in they can even be written to at their home or university address and every effort is made to contact the student. There are certain restrictions, as adults we can’t contact their parents but if we keep sending letters to the home address that’s the best we can do.

Q. How is data kept secure and what laws have to be taken into consideration when holding data on students?

A. I would assume that data has to comply with the Data Protection Act. Data would not be passed on to third-party companies.

Q. Is that backed up by the fact that only certain members of staff have data on student attendance and other data like that?

A. Only the administrator has the license to manipulate student data held in the database, all the lecturing staff have is the ability to enter the student’s attendance but not to manipulate existing data.

Q. If we were to implement a new system what features in the current systems would you like to retain?

A. The reports in the current system seem quite effective. Going back to who’s responsible as the course director Marian would be the one who would make the biggest demand on what sort of reports and when. From the lecturers point of view they can see what problems they are having and can talk to the students. If you introduce something like a missing for three in a rows that’s easy to spot but if someone has a very irregular or erratic attendance pattern then the lecturer could be talking to them themselves and not just the course director.

Q. What improvements would you like to see in the up and coming system?

A. To get away from the paper based system, use the card to scan in attendance and leave the responsibility with the student. As it is now a student could say they missed the attendance sheet being passed around. There has to be a regulation where by the attendance is set up and it’s the students responsibility to sign in. That would have to be done in agreement with the student and that’s why they have to be consulted as well, which is essentially what the system is doing.