USC Android App Requirements

version 1, 09/07/2010

1. Introduction
This document contains the functional as well as the system and user requirements for the USC
Android Application project. This list of requirements has been compiled from research, brainstorming,
knowledge of similar applications, and trial and error.

1.1 Document Purpose

This document is intended to give a user friendly outline for the requirements and functionality
that needs to be implemented in order for this project to succeed. This document will go through several
versions that will reflect the progress of the project as well as our developing understanding of the inner
workings of the application and its components.

1.2 Product Scope

The University of South Carolina in Columbia is a very large University with many goings on.
Not only does the school boast a very active theatre and music group, it also has a world class football
team. The school is centered around downtown Columbia, which is a very industrialized and confusing
area to navigate on foot. The school also has a very large student population. With all of these factors
coming into play together, wouldnt it be nice if there was a simple and yet mobile way to keep track of
events, get directions, as well as contact students?

1.3 Business Case

The University of South Carolina is a top flight university that prides itself on being at the
forefront of research and development. New students have a daunting task of integrating themselves into
this hectic environment. This application would allow all people affiliated with the USC the ability to
easily track the events going on at USC, the sports teams and their records, find their way around the
campus as well as program a daily schedule in, and make contacting students extremely convenient

1.4 Requirements Overview

The requirements of the project can be easily broken down into sections based upon their
generalized area.

User and System Requirements

Reporting Requirements
Security Requirements
User Interface Requirements
Technology Architecture
Customer Support

2. Project Description
This section of the document includes information including: why the project was created, what
functionality it will have, who will use it, constraints we encountered, and any assumptions we make.

2.1 Product Origination

This project was originally conceived as a CSCE 492 project under the supervision of Dr. Vidal.
The idea was stumbled upon after viewing the android application developed by University of Texas
students as their software project. The project is to be developed with the backbone of being a useful app
for all people associated with USC and will be donated to the university at the end of development.

2.2 Functionality
The product will have four distinctive areas. It will have a section devoted to locating buildings
on the USC campus as well as programming your schedule in. This will allow the app to notify you of
upcoming classes and meetings, tell you what building you need to be in, and give you directions to it.
The next section of the application will allow the user to look up students and staff members phone
numbers via the directory in order to facilitate communication. The next part of the application will be a
calendar of events that allows the user to keep track of upcoming events in the area, their location, and
even add them to their own personal android calendar. The final part of the application will keep track of
the sports records, upcoming games, and their broadcast information so the user will never miss their
favorite games.

2.3 Users
The expected user for this application will be new and continuing students at the University of
South Carolina as well as staff members.

2.4 Constraints
The major constraints the project faces are:

Short time for development

Lack of knowledge of the android infrastructure
Staying within the boundaries of the androids capabilities
Collecting data needed for the application

2.5 Dependencies
The application is heavily dependent on data that will be derived from USC website pages.
Should one of these websites go down it could potentially crash the application or render it useless until
the pages are restored. The USC website has a track record for being reliable, but countermeasures must
be taken care of in order to insure data integrity as well as error and crash prevention.

3. Specific Requirements
This section lists the specific functionality as well as the requirements for all aspects of the USC
Android Application project. Requirements are divided into the following sections:

User and System Requirements

Reporting Requirements
Security Requirements
User Interface Requirements
Technology Architecture
Customer Support

3.1 User and System Requirements

Main Screen
1. Description:
1.1 All screens will have the top toolbar and then the rest of the screen below. The top
toolbar will contain a menu button, a back button, and the name of our application.
2. User Tasks:
2.1 Select one of the four parts of the application (Map, Calendar, Sports, Directory)
2.2 Close the app menu button
2.3 Return to menu Menu button on the top toolbar
2.3.1 Included on all screens!
2.4 Go back a screen back button on the top toolbar
2.4.1 Included on all screens!
Calendar
1. Main Screen
1.1 Description:
1.1.1 The main screen will be a calendar that shows the whole month and allows
you to select a specific day. You can also change the month you are looking
at or go straight to a date.
1.2 User Tasks:
1.2.1 Change month back or forth arrow buttons forward and back
1.2.2 Select a day off the calendar click on the date on the calendar
1.2.3 Search for event via keyword text entry
1.2.4 Go to date selector the allows you to put in the month, day, year and go to
that date
2. Day Screen
2.1 Description:
2.1.1 The day screen will just be a list of the events that are on that day in
chronological order. The user will be able to select any event to get more
details.
2.2 User Tasks:
2.2.1 Select event click on the event you want to open
2.2.2 Scroll up and down through events scroll bar
3. Event Screen
3.1 Description:

3.1.1

The event screen will just have the information about the event: the start and
end time, location, description, name of event. The user will also be able to
hit a button to add this event to the calendar on their phone.

3.2 User Tasks:

3.2.1 View event information
3.2.2 Add event to your phones calendar
Map
1. Main Screen
1.1 Description:
1.1.1 The main screen will show the Google map and have all the functionality that
Google maps provides such as dragging the screen, zooming in or out, etc. It
will also have button that pinpoints the users current location. You can also
find a building using a drop down selector. You can go to class schedule
screen to enter your class schedule.
1.2 User Tasks:
1.2.1 Search for a building by code/name drop down selector to find building
1.2.2 Allow you to move screen, zoom in and out, etc as you can do with any
Google map
1.2.3 Current Location button that pinpoints the users current location on the
map
1.2.4 Go to schedule screen button on the screen
2. Schedule Screen
2.1 Description:
2.1.1 The screen will list the classes you have added. The user will also be able to
add additional classes or select a class to view it or edit it.
2.2 User Tasks:
2.2.1 Add class takes you to the class entry screen
2.2.2 Select class to view information
3. Class Entry Screen
3.1 Description:
3.1.1 This screen will allow the user to add a class. It will be a form that includes
the class days and times, class name/number, building and classroom
number, and professor
3.2 User Tasks:
3.2.1 Enter text for class name/number, professor, classroom number, times, drop
down selector for building location
3.2.2 Add class button to submit the class
4. Class Information Screen
4.1 Description:
4.1.1 Displays all class information specified in the requirements for a class entry.
Also allows you to edit any of the information.
4.2 User Tasks:
4.2.1 Displays class information
4.2.2 Edit information button that takes you to the Class Entry Screen.
Sports
1. Main Screen
1.1 Description:

1.1.1

The sports screen will be split in half. One side will be the mens and one
side will be the womens. The sports will just be listed out in alphabetical
order and the user will be able to select any of these to go to the individual
sports screen.

1.2 User Tasks:

1.2.1 Select a sport all sports will be listed out and be a button that you can select
to take you to that sports screen
2. Individual Sports Screen
2.1 Description:
2.1.1 Will contain a list of the schedule with the following information: date,
opponent, location, TV channel (if on TV), time or result (if the game has
been played). The overall record will also be listed at the top of the page
underneath the name of the sport.
2.2 User Tasks:
2.2.1 View schedule with information as specified by the description and
requirements
Directory
1. Main Screen
1.1 Description:
1.1.1 The main screen will simply have a textbox and a dropdown selector that will
allow you to type a name in and select what kind of member you are
searching for: all, faculty/staff, or student. This will interface directly with
the USC directory online.
1.2 User Tasks:
1.2.1 Search name by text and either all, faculty/staff, or student from drop down
selector this takes you to the search results screen.
2. Search Result Screen
2.1 Description:
2.1.1 This will list the search results. If no relevant people are found, it will have
an error and take you back to the search screen. The user will be able to
select any of the listed people to get their information
2.2 User Tasks:
2.2.1 Select an entry to display that persons information in the display screen
2.2.2 Scroll bar to scroll up and down through the results
3. Display Screen
3.1 Description:
3.1.1 This will display the persons information.
3.2 User Tasks:
3.2.1 User can view the selected individuals information
3.2.2 Can select go to location (if an office location exists) it will link to the map
and pinpoint the location
3.2 Reporting Requirements
1. Project Code
1.1 Versioning
1.1.1 Code will be uploading and checked in at the end of every workday with
documentation.

2. Project Progress
2.1 Progress and Development
2.1.1 Documentation will be kept up to date and posted on the wiki.
2.1.2 Meetings will be held with Dr. Vidal every Tuesday at 3:30 PM
3.3 Security Requirements
1. Security and Privacy
1.1 Personal Data Privacy
1.1.1 All data used is open to the public and free to access.
1.1.2 Anyone who feels violated by out publication of data may have their data
removed from the system at their request.
3.4 User Interface Requirements
1. Appearance
1.1 Visual Appeal
1.1.1 All icons bust be crisp, clean, and distinguishable
1.1.2 Entire interface must be pleasing to the eye.
1.2 Functionality
1.2.1 All buttons and objects must be reactive to touch and work as intended.
3.5 Technology Architecture Requirements
1. Android
1.1 Boundaries
1.1.1 All functions must stay within the platform boundaries.
1.1.2 All data must be easily viewable on different android screen sizes.
3.6 Customer Service Requirements
1. Errors
1.1 Reporting and Handling
1.1.1 Errors must be easy to report for users.
1.1.2 Errors must be handled and fixed immediately.