Requirements

Actors
In this system there are two kinds of user.

Glossary
What we mean.

Word Description
System Neverlate as a whole: the entirety of the structure that we are trying to build with this project.
Ping Notifications sent by professor to his students.
User Any kind of person which uses NeverLate, both students and professors.
Notification The means used by the smartwatch to warn you that you should head out to the classroom. It will primarily be a text message on the screen.
User main interface The smartwatch. It will be the main interface that the user will face in everyday usage.
User settings interface It’s a web-page with login. It will be the interface for adding several settings as calendar and preferences.
Highest priority is 1

Functional Requirements

#
Functional Areas
Requirements
1 Basic Functions
  • 1. Travel time evaluation
    The system must be able to evaluate the travel time between different areas of the Politecnico campus by assuming the user will choose the shortest path.
    Priority 1
  • 2. On time notification
    The system must notify the user on time when he has to head out for his next lecture, according to travel time estimation and his timetable.
    Priority 1
2 Interactions with the user main interface
  • 1. Smartwatch notification
    The user must be notified with a text message on the screen, telling also where he have to go. The notification is customizable, according to FR 3.3
    Priority 1
  • 2. Remaining time
    Possibility for the user to read on the screen how much time is left before the next notification (and therefore how much time is left before he has to go to the classroom).
    Priority 2
  • 3. “Do not disturb” mode
    The smartwatch would give the possibility to the student to disable all the notification as long as this mode is activated.
    Priority 5
3 Features of the user’s settings interface
  • 1. Calendar Customization
    Possibility for the user to add classes on a digital calendar.
    Priority 1
  • 2. Notification time preferences
    Possibility for the users to customize how early he wants to arrive in the classroom. The system will adapt notification time according to this preference.
    Priority 3
  • 3. Notification style preferences
    Possibility for the user to specify if he wants to add vibration and/or audio to his notification style.
    Priority 4
  • 4. Integration with Portale della Didattica
    The user will be able to add classes choosing from the official Polito timetables.
    Priority 2
4 Additional features for teachers
  • 1. Additional features for teachers
    Possibility for the teacher to ping his students via the main interface. Ping gives the possibility to the teacher to specify that the lesson will start in X minutes. The notification system for the students would change accordingly.
    Priority 2
  • 2. Schedule update notification
    If the professor, in the settings interface, delete or update one calendar entry already existent, his students’s timetables will change accordingly.
    Priority 3

Non-Functional Requirements

# Non-Functional Areas Requirements
1 Portability User interface
The system needs to be compatible with Pebble smartwatch. In particular the system must be able to send notification to Pebble and should react to user inputs.
2 Portability Mobile support
The system must rely on a smartphone running Android OS to provide connection between the user, the environment and the central intelligence.
3 Portability User settings interface
The website with the user settings interface must be acceptably viewable from any general purpose browser (also for mobile devices). The system will be developed to optimally work with all the most popular current generation browsers (Google Chrome, Mozilla Firefox, Safari, Internet Explorer)
4 Efficiency and usability User settings interface
The maximum acceptable delay for automatic notifications, due to elaboration time, is 1 minute compared to the computed notification time. Average delay time should not be higher than 30 seconds.
5 Portability Response time to direct user inputs
The system must rely on a smartphone running Android OS to provide connection between the user, the environment and the central intelligence.
6 Efficiency Localization accuracy
The system must be able to recognize the proximity of the user to a specific area of the campus. Areas of the campus must be dimensioned so that the time to cross them is less than 1 minute walk. The maximum acceptable positioning error is that the user is localized in an area adjacent to the one the the user is in. The system should avoid to erroneously localize a student in a wrong floor.
7 Efficiency Time travel estimation
The system must estimate the travel time between areas with a maximum error of 1 minutes.
8 Efficiency Localization attempts frequency
Unless the function is not directly called by the user or by a professor ping (see FR 2.2 or FR 4.1), the system will update the position of the user (and so the estimated travel time) every 1 minute starting from 30 minutes before the next lecture.
9 Interoperability Calendar support
The system has to be compatible with Google Calendar.
10 Usability Languages
Menus and all user interfaces will be available in english.
11 Reliability Localization and time travel estimation malfunctioning
If the user cannot be localized, or his travel time cannot be estimate, the watch assumes by default 15 minutes time travel for the destination until the system doesn’t start to run properly again.
12 Reliability Network malfunctioning
If for some reasons there is no internet connection on the user interface, the system will signal it. As there is a local calendar accessible on the device (google calendar app) the system will still send notification using the default value specified in NFR 11.