Requirements Documentx - uscandroidapp

quarterceladonΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 6 μήνες)

60 εμφανίσεις

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
proje
ct. 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. Th
is 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
t
eam. 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, wouldn’t 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 thei
r 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 Sy
stem 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 conce
ived 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 a
nd 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 the
ir 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:



S
hort time for development



Lack of knowledge of the android infrastructure



Staying within the
boundaries of the android’s 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 Requir
ements


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 even
t information

3.2.2

Add event to your phone’s 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 user’s 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 user’s 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
do
wn 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

Disp
lays 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 men’s and one
side will be the women’s. 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.

Indivi
dual 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 pag
e
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 a
ny of the listed people to get their information

2.2

User Tasks:

2.2.1

Select an entry to display that person’s 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 person’s informa
tion.

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 object
s 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.