A after a few weeks we had determined our official software requirements. Along with a requirements glossary which would be carried over to nearly all of our follow up documents.

Notes

This page actually contains less information than our original Software Requirements document contained. With the reason behind that being that I did not want this page to be a complete copy paste from the original document.

Images that contain identifiable information are also redacted. Though the student names will not be as they where random names used for display purposes only.

Requirements Glossary

Our requirements glossary was relatively simple. And while it likely could have been expanded it defined everything that we felt could be in question.

Word/Terminology Definition
QR Code A graphical encoding of information that is machine-readable similar to a barcode and can be scanned with a camera.
OAuth An open standard that is used to allow users to give other sites access to certain information without using a username and password. Can be used for account creation as well as sign-in. Examples of this include the sign-in with Google feature seen on many websites
CSV File A kind of text file that contains values separated with commas and new line characters. Can be opened and edited as a text file with many spreadsheet applications also providing the ability to edit them in a table format

User Requirements

To determine the final requirements our team met with the client as well as went over the document provided by the previous team. And in doing so it was determined we had the following requirements.

User Authentication

This requirement was specifically requested by the client. And will allow the professor’s information to be stored to an online account in a database. And in doing so it would allow allow the client and future professors using the app to use the app and the same records across multiple devices.

Creating and Viewing Semesters

It was also determined that to better organize the classes that a professor might host we would need to provide a method of dividing the classes into different semesters. Allowing “duplicate” classes to exist in different semesters.

Creating, Viewing, and Interacting with Classes

A pivotal part of the project through was that a professor will need to be able to create, view, and interacting with classes. Which will contain a list of students. This requirement also requires the professor to be able to import student lists. As well as export student attendance records. Then allowing the professor to email the QR codes to students. While also allowing students within a class to be marked as present manually if the QR code scanning fails.

Counting Students for Attendance

During normal operation though students should be able to scan the QR codes they received in their email to mark themselves as present. While also providing an error output to notify the student haven’t been marked as present. So they can either try again or be manually marked by the professor.

Exporting Attendance and Attendance Reports

The professor will also need to be able to view the attendance records of the students within a class. As well as export it in the form of a CSV. Allowing them to transfer that information into other programs.

User Cases

We also determined the following use case diagram. With there being two actors that interact with the app in question. The main user or Professor who interacts with the app the most. As well as the student who will at most scan their QR code using the Professor’s device as a kiosk.

System Requirements/Flow

We also developed a state diagram showing where specific functionality would be found in the app. With there being different requirements for the system at each state.

Sign-in and Authentication

Login Screen Prototype

Login Screen Prototype

Login Selection

Login Selection

When the professor or user first opens the app they will be presented with the first screen and prompted to log in. With login being handled through Google OAuth.

Semester List and Class List

List of Semesters

List of Semesters

Add Semester

Add Semester

Once the user is logged in they will then be presented with their list of semesters. Which will be blank for a new user. Otherwise they will have the option to add a new semester or select and existing one.

List of Classes

List of Classes

Add Class

Add Class

Once a semester is selected they will then be able to add a class an select one in a similar manor to within the semesters list.

Student List

Empty Class List

Empty Class List

Selecting a file to import

Selecting a file to import

Populated class list

Populated class list

Mark as present

Mark as present

Once the user selects a class they will then be able to perform a variety of actions within a class. Including importing a class list, scanning QR codes, adding student individually or marking them as present manually.

Non-functional Requirements

It was also determine that the project had the following nonfunctional requirements.

Scalable

So that the project can be later deployed it needs to be easily scalable to handle more users. While also being able to handle more student information that will result from their being more users.

Reliable

The project also needs to reliable compared to the system it is replacing. Otherwise it will cause more problems than it solves.

This means it will need to be possible to use the app to take attendance if for some reason the QR codes fail to scan. Among other issues.

Maintainable

The project will also need to be maintainable in order for future teams to be able to add more features. With this being achieved through documentation that will allow future teams to quickly be able to work with the project.

Usable

While currently the app will have a single user being the client. The intend is that other professors at the University will be able to use the app. Meaning that the functionality will need to be easily understood and used by more than just a single user.

Manageable

The project will also need to be manageable well after all the development teams are gone. In order to simply provide more benefits.

Tablet Platform

The project will also be used most often on a Android tablet and needs to developed in a manner that allows it to function well on a tablet as requested by the client.

Android Application

Again according to the clients requirements it will need to be an android application.

Java

With the Java requirement being the same as the requirement for it to be an Android Application where it was requested by the client.

Technical Requirements

For this project our group made use of an online Database as well as other development tools in Android Studio. With the version control system being used being Git with GitHub as the host.

Project Risks

With all projects there are some risks involved. And for this project our group determined that the main risk would be that we could fail to meed our goals in the alloted time. We will also be using 3rd party libraries that are subject to possible change. Either in implementation or in the cost they are to use.