Bmr Android Srs 1.6

8/4/2019 Bmr Android Srs 1.6

1/34

CS 415

Bama Mobile Registration Android

Software Requirements Specifications

Version

Unclassified BMR Incorporated, 2009 Page 1


2/34

Bama Mobile Registration Version:

Software Requirements Specifications Date: 11/21/2009

Bmr-Android

Revision HistoryDate Version Description Author

10/06/2009 1.0 Created the initial draft Paul Kilgo

10/07/2009 1.1 Created draft of section 3 Xiannuan Liang

10/12/2009 1.2 Revision of Document Joshua K. Sullivan

10/13/2009 1.3 Final Revision Joshua K. Sullivan

10/25/2009 1.4 Revision as per Teachers Instructions Joshua K. Sullivan

11/09/2009 1.5 Additions Joshua K. Sullivan

11/21/2009 1.6 Final Revision for Demo Joshua K. Sullivan



3/34



Bmr-Android

Table of Contents

1. Introduction 5

1.1 Purpose 5

1.2 Scope 5

1.3 Definitions, Acronyms, and Abbreviations 5

1.4 References 5

1.5 Overview 5

2. Overall Description 6

2.1 Product perspective 6

2.1.1 Interfaces 6

2.2 Constraints 7

3. Specific Requirements 7

3.1 Functional Requirements 7

3.1.1 7

3.1.2 7

3.1.3 7

3.1.4 7

3.2 Non-Functional Requirements 7

3.1.2 7

3.1.3 7

3.2.3 7

4. Use Case Diagram 8

5. Use Case Scenarios 9-16

6. Activity Diagrams 17-24

7. Test Cases 18-28

8. Software Architecture 28-31

8.1 Introduction 28

8.1.1 Purpose 28

8.1.2 Scope 28

8.1.3 Definitions, Acronyms, and Abbreviations 28

8.1.4 Overview 28

8. 2 Architectural Representation 27

8.3 Architectural Goals and Constraints 28

8.4 Use-Case View 28

8.4.1 Use-Case Realizations 298.5 Logical View 29

8.5.1 Overview 29

8.5.2 Architecturally Significant Classes 29

8.6 Interface Description 29

8.7 Size and Performance 29

8.8 Quality 30

9. Conceptual Architecture (Activity Flow Chart) 31



4/34



Bmr-Android

10. System Architecture 32

11. Class Architecture 33

12. Sequence Diagram 34



5/34



Bmr-Android

Software Requirements Specifications

1. Introduction

The basic goal of this document is to provide an overview of the software specifics of our project.

1.1 Purpose

The purpose of this document is to outline the software project Bama Mobile Registration for Android.

This document outlines the external behavior of this application, including nonfunctional requirements,

design constraints and other miscellaneous specifications for this software.

1.2 Scope

The scope of the project includes creating a user interface to the MyBama registration system as well as a

backend that will emulate some of its behavior, specifically for testing. We will then make this user

interface and the backend interact. Additionally, this project may extend to add in some nicer features

which are not a part of the bare minimum requirements, just some feature thought would be nice to include.

1.3 Definitions, Acronyms, and Abbreviations

Bama Mobile Registration can be abbreviated BMR.

1.4 References

All public information can be found at the following web address.

http://groups.google.com/group/bmr-android?hl=en

1.5 Overview

The current class registration system for the University of Alabama is MyBama, which has no known APIs

to accomplish our most basic goal. So, instead, we have split the project into two parts: one part to handle

the emulation of MyBama. Essentially, we are creating our own API. The second part is the client itself

which will exist on the user's mobile device.

The end-user to this product is the student who wishes to use a mobile device to manage his or her class

schedule. University of Alabama students are the customer for this project. It is important to note this since

our design will stem only from the software team's experience using the registration system.

The product will have four main screens: the login screen, semester management screen, search screen, and

the class listing screen. Each of the four screens will provide certain functionality.

Using this product a University of Alabama student will be able to successfully

1 Login to the system

2 Manage their semester through adding and dropping classes

3 View the information about a class

4 Search and find classes

http://groups.google.com/group/bmr-android?hl=enhttp://groups.google.com/group/bmr-android?hl=en


6/34



Bmr-Android

2. Overall Description

This section will contain information about the project as a whole including perspectives and constraints.

2.1 Product perspective

2.1.1Interfaces

The product will have four main screens: the login screen which allows a user to log into the system,

semester management screen which allows a user to manage their classes, class listing screen which will

provide a user with all information about a class, and class search screen which allows users to search for

classes. Each of the four screens will provide certain functionality.

2.1.1.1 Login Screen

The login screen will allow the user to choose from list of accounts which have been used in the past.

The user can select an existing account or add a new one. When the user adds a new one, the user name

will appear in the list. If the user chooses an account from the list and the password for the chosen accounts

is unsaved, the user will be prompted for a password and also granted the option to save the password. If

the password is saved, the system will attempt to log in. If the login is unsuccessful, the user will beprompted to update the password.

The accounts should be editable. A long-click, clicking down and holding down your click on the screen,

should be able to invoke an option to delete an account, and if the password is saved, an option to forget the

password.

A successful login will bring up the Semester Management Screen.

2.1.1.2 Semester Management Screen

Upon first viewing this screen (presumably after successful login), the user will be presented with a list of

classes for which they have registered. If the user has not registered for any classes in the current semester,

no classes are presented. Class information should be presented in the list: course title, course code,

instructor, and meeting times.

A menu action should present to option to switch terms or search for classes. Electing to switch terms will

invoke a pop-up screen asking the user which semester they would like to switch to. A search action will

bring up the Class Search Screen.

Clicking a class in the list will bring up the Class Listing Screen.

Long-clicking a class will bring up a menu to drop the class. If the user selects to drop the class, they are

asked to confirm. If confirmed, the program issues commands to the back-end to drop the class.

2.1.1.3 Class Listing Screen

This screen should show all known information about a given class. A menu action shall present the user

with an option to add this class if the user is not already taking the class.

2.1.1.4 Class Search Screen

Upon entering this screen, the user will be prompted by a search box, already highlighted, to provide a

search term. The user should be able to type in any string of characters. The user can search for specific

classes by class code (e.g., CS124), CRN, or just by a generic search term. The backend will sort out what

kind of data the user has entered and try to match this against the database. The results of a search are listed

just below the search box in a similar fashion as on the Semester ManagementScreen.



7/34



Bmr-Android

A user can click a result to view its class listing on the Class Listing Screen.

The user can long-click a result to try and add the class. Adding the class does not return the user to the

Semester Management Screen.

2.2 Constraints

The system has the constraint of working on an android cell-phone. This includes limited power and

resources. The product is also limited by the android platform. The team is also constrained by time.

3.Specific Requirements

3.1 Functional Requirements

3.3.1 Search Class Catalog

The user will have the ability to search the class catalog for various classes and find information on each of

the classes in the catalog. This will be integrated in with the Class Search Screen.

3.3.2 Add/Drop Classes

The user will have the ability to add or drop the classes that they have found. This feature will be useful for

setting up a new schedule or for changing classes after a semester has already started. The Class

Management screen will provide the use with the screen that will show them their current classes. If the

user wants to add or drop they will then go to the Class Listing Screen which will have the add and drop

option.

3.3.3 Confirm Schedule

The user will have the ability to confirm their schedule through the application. This involves either

clicking confirm because the user has adequate funding to pay for the semester or paying for the semester

then clicking confirm.

3.2 Non-Functional Requirements

3.2.1 Security

Security will be an issue because of the possibility of monetary transactions as well as the various student

data being transferred over a wireless connection. Because of these issues the application will have various

security features to enable to user to know that all action performed on the application will be safe.

3.2.2 Visual Aesthetics

The application will be aesthetically appealing to the user in order to make the application more desirable.

We will test whether or not we have successfully created an aesthetically appealing application by using

team members as test subjects.

3.2.3 Connection Permanency

The application will be availability 24/7 so that the users can asses all features of the application no matter

the time.



8/34



Bmr-Android

4.Use Case Diagram



9/34



Bmr-Android

5.Use Case Scenarios

5.1

Name: Add User

Identifier: UC01

Preconditions

1. Application exists on Android device

Basic Course

1. User starts application

2. User decides to add a new username to local database

3. User inserts username and password

4. User selects whether or not to save the password

5. Information is determined to exist in MyBama backend and is saved into local database.

6. The users current term is displayed

Alternate Course A: Username/password determined to be incorrect

Condition: User enters a username/password combination that does not exist within MyBama

A.1 Message is displayed that informs user that the combination entered is incorrect

A.2 List of users is displayed.

Post conditions

1. User list is displayed without new username

2. Users current term is displayed



10/34



Bmr-Android

5.2Name: Login

Identifier: UC02

Preconditions


2. User has a legitimate username/password in the MyBama system

3. Username exists within local database

Basic Course


2. User selects username from list

3. If prompted, the user enters password


Alternate Course A: Stored password is incorrect

Condition: If the users password has been modified since the most recent login

A.1 User is prompted to enter new password

Post conditions




11/34



Bmr-Android

5.3Name: Add Class

Identifier: UC03

Preconditions


2. User has a valid username/password

Basic Course


2. User selects username to login

3. User navigates to class search

4. User searches for class

5. User then selects class that was searched for

6. User adds this class to current term

Alternate Course A: class searched for does not exist

Condition: the class the user searches for does not exist within MyBamaA.1 User is returned to search page to search for a different class

Alternate Course B: class selected has already been added to schedule

Condition: the class the user tries to add already exists in the students schedule

B.1 Message is displayed informing user that the class has already been added

B.2 User is returned to the class search page

Post conditions

1. Current term page is displayed



12/34



Bmr-Android

5.4Name: Drop Class

Identifier UC04

Preconditions



Basic Course



3. User navigates to current term

4. User selects class to drop

5. User drops class

Post conditions

1. Updated current term is displayed



13/34



Bmr-Android

5.5Name: Confirm Schedule

Identifier UC05

Preconditions



Basic Course




4. User selects confirm schedule

5. Message is displayed telling user the schedule is confirmed

Alternate Course A: Schedule is already confirmed

Condition: User tries to confirm schedule that has already been confirmed

A.1 Message is displayed informing user that schedule is already confirmed

Post conditions




14/34



Bmr-Android

5.6Name: Switch Term

Identifier UC06

Preconditions



Basic Course



3. User initiates switch term

4. User selects term to display

5. New term is displayed

Post conditions

1. Updated term is displayed



15/34



Bmr-Android

5.7Name: Search Classes

Identifier UC07

Preconditions



Basic Course




4. User selects Search classes

5. Class search is displayed

Post conditions

1. Class search is displayed



16/34



Bmr-Android

5.8Name: View Classes

Identifier UC08

Preconditions



Basic Course



3. Current term is displayed

Post conditions




17/34



Bmr-Android

6. Activity Diagrams

6.1 Add user



18/34



Bmr-Android

6.2 Login



19/34



Bmr-Android

6.3 Add Class



20/34



Bmr-Android

6.4 Drop Class



21/34



Bmr-Android

6.5 Confirm Schedule



22/34



Bmr-Android

6.6 Switch Term



23/34



Bmr-Android

6.7 Search Classes



24/34



Bmr-Android

6.8 View Classes



25/34



Bmr-Android

7. Test Cases

The test cases are listed below as well as the steps a test must step through as they search for bugs in the system. If

the tester reaches the last step without find a bug then the test case passes.

7.1 User logs in using a valid user name and password and is granted access.--Pass, Josh & Ben, 11/14/2009

a. Start application-Pass, Josh & Ben, 11/14/2009

b. Add new user name to local database.--Pass, Josh & Ben, 11/14/2009

c. Insert Username and Password.--Pass, Josh & Ben, 11/14/2009

d. Select to save password.--Pass, Josh & Ben, 11/14/2009

e. Information is saved in local database.--Pass, Josh & Ben, 11/14/2009

f. Current term is displayed.--Pass, Josh & Ben, 11/14/2009

g. Return to step a and work through till step d except this time do not save password, continue on to

step f . If f passes then 7.1 is complete.--Pass, Josh & Ben, 11/14/2009

7.2 User logs in with invalid credentials and is denied access.--Pass, Josh & Ben, 11/14/2009

a. Start application.--Pass, Josh & Ben, 11/14/2009

b. Select user name from List.--Pass, Josh & Ben, 11/14/2009

c. If prompted, enter an incorrect password.--Pass, Josh & Ben, 11/14/2009

d. Access denied pop up should be viewable.--Pass, Josh & Ben, 11/14/2009

7.3 User adds class which he/she has necessary requirements to register for and the class is added to their schedule.

--Pass, Josh & Ben, 11/14/2009


b. Select user name and login.--Pass, Josh & Ben, 11/14/2009

c. Navigate to class search.--Pass, Josh & Ben, 11/14/2009

d. Search for a class.--Pass, Josh & Ben, 11/14/2009

e. Select the search class.--Pass, Josh & Ben, 11/14/2009

f. Add class to current term.--Pass, Josh & Ben, 11/14/2009



26/34



Bmr-Android

7.4 User adds class which results in a failure imposed by the back-end (no prerequisite, not open for registration, too

many students signed up, current term not manageable).--Pass, Josh & Ben, 11/14/2009

a. Start application.--Pass, Josh & Ben, 11/14/2009b. Select user name and login.--Pass, Josh & Ben, 11/14/2009

c. Navigate to class search.--Pass, Josh & Ben, 11/14/2009

d. Search for a class.--Pass, Josh & Ben, 11/14/2009

e. Select the search class.--Pass, Josh & Ben, 11/14/2009

f. Add class to current term.--Pass, Josh & Ben, 11/14/2009

g. Class should not be added.--Pass, Josh & Ben, 11/14/2009

7.5 User drops class successfully. --Pass, Josh & Ben, 11/13/2009


b. Select user name and login.--Pass, Josh & Ben, 11/13/2009

c. Navigate to current term.--Pass, Josh & Ben, 11/13/2009

d. Select the class to drop.--Pass, Josh & Ben, 11/13/2009

e. Class will drop from list of classes current being taken.--Pass, Josh & Ben, 11/13/2009

7.6 User drops class which ends in failure (co-requisite with an incomplete class, current term not manageable).

--Pass, Josh & Ben, 11/13/2009


b. Select user name and login.--Pass, Josh & Ben, 11/13/2009c. Navigate to current term.--Pass, Josh & Ben, 11/13/2009

d. Select the class to drop.--Pass, Josh & Ben, 11/13/2009

e. Class will not drop.--Pass, Josh & Ben, 11/13/2009

7.7 User searches for class by its class code (CS123), CRN, or with a generic search term.--Pass, Josh & Scott,

11/13/2009

a. Start application.--Pass, Josh & Scott, 11/13/2009

b. Select user name and login.--Pass, Josh & Scott, 11/13/2009

c. Navigate to current term.--Pass, Josh & Scott, 11/13/2009

d. Select the Search class.--Pass, Josh & Scott, 11/13/2009

e. Class search will be viewable.--Pass, Josh & Scott, 11/13/2009



27/34



Bmr-Android

7.8 User performs a search which yields no results.--Pass, Josh & Scott, 11/13/2009

a. Start application.--Pass, Josh & Scott, 11/13/2009

b. Select user name and login.--Pass, Josh & Scott, 11/13/2009

c. Navigate to current term.--Pass, Josh & Scott, 11/13/2009

d. Select the Search class for a class that doesnt exist.--Pass, Josh & Scott, 11/13/2009

e. Class not found will be displayed.--Pass, Josh & Scott, 11/13/2009

7.9 User views the class information for a class listing returned from a search result.--Pass, Josh , 11/14/2009

a. Start application.--Pass, Josh , 11/14/2009

b. Select user name and login.--Pass, Josh , 11/14/2009

c. Navigate to current term.--Pass, Josh , 11/14/2009

d. Select the Search class.--Pass ,Josh , 11/14/2009

e. Class search will be viewable.--Pass, Josh , 11/14/2009

f. Click the class to view all extra information about the class on the class listing. --Pass, Josh ,

11/14/2009

7.10 User views the class information out of the list of classes in the current semester. --Pass, Ben, 11/12/2009

a. Start application.--Pass, Ben, 11/12/2009

b. Select user name and login.--Pass, Ben, 11/12/2009

c. Navigate to current term.--Pass, Ben, 11/12/2009

d. Click the class to view all extra information about the class on the class listing.--Pass, Ben, 11/12/2009

8 Software Architecture

8.1 Introduction

The purpose of this document is to provide an overview of the architecture for the Bama Mobile

Registration project for Android. The project includes writing a client for a currently nonexistent API for

the MyBama course registration system implemented at the University of Alabama. Because the API is

nonexistent, we will include a mostly nonfunctional but approximate backend of what the API should be

able to do.

8.1.1 Purpose

This document will provide the reader with a good overview of how we intend to solve the problem of

registering for class via a mobile phone. The view of the project will be very high-level and will lack

specifics, but should provide some guidance on how the software should be structured.

8.1.2 Scope

This document only defines what is to be done on the mobile platform and the medium through which it



28/34



Bmr-Android

communicates with the backend.

8.1.3 Definitions, Acronyms, and Abbreviations

Bama Mobile Registration is occasionally abbreviated BMR.

ClaXML is the name given to the XML subset the client and server will use to communicate.

8.1.4 Overview

The remainder of this document defines the model we have chosen to use for our client-server

communication and the roles and responsibilities are assigned.

8.2 Architectural Representation

The easiest way to imagine this project is a simple client-server model that communicates in some way

with a server via a cell carrier's data connection or other IP interface. We do not concern ourselves with the

specifics of this communication as this is covered in the scope of the Android SDK.

We are then introducing the model elements of the central server, the mobile device, and thecommunication layers that connect them. In terms of the OSI Model, we place ourselves just over the

application layer as we intend to make the client and server communicate over HTTP or in later

implementations, HTTPS. For this project, we are most interested in making the software for the client.

So this essentially means that the user is somewhere else in the world and communicates with a central

server which should contain all of the class backing, authentication information, et cetera. With this in

mind, it's easy to see that we can't allow the user's phone perform the majority of the decision-making as

this will be performed by the central server since it holds the database. We will essentially be designing a

dumb client which makes requests to the server and displays the result to the user.

Stepping into the intricacies of what goes on inside the client, we can start to see a few of the components

flesh out. For one, we should have four major screens: a login screen, a semester management screen, a

class listing screen, and a class search screen. As well, it makes sense to have a component whose purposeis to maintain the session and communicate with the server. We can refer to this component as Session.

For the platform we are designing for, an easy way is offered for parsing XML: SAX. This introduces a

component which is a SAX handler for ClaXML, called ClaXMLHandler, and as well a data set that it

produces, ClaXMLSet.

The user will navigate through the screens or Activities for Android terminology. These Activities will

make calls to the Session object to connect to and retrieve data from the central server. The Activities will

then display the result to the user.

The Session object sits idly by and will handle making calls to SAX, constructing ClaXMLSets, and

presenting the result in a manner that programmatically makes sense.

8.3 Architectural Goals and ConstraintsWith any network communication, there comes the possibility of security and privacy. This is an especial

concern when dealing with monetary transactions, as confirming a schedule would normally involve. In

final implementations, encryption would be absolutely necessary.

There is a problem of connection loss that we expect to experience when using cell phones with spotty

connections. We will have to design around this as there is not much we can do to remedy the problem.

The phone will end up knowing very little about what classes are available for the user to take. A data



29/34



Bmr-Android

connection would be absolutely necessary to use this application.

With the phone not having any data backing for itself, the application could end up being very slow if it

makes too many requests to the server. We will have to be intelligent about network usage and make clever

use of data caching.

On the plus side, the dumb client will be on the easier side to implement. Since we are relying on the

backend to do most of the class registration logic, all we will have to do is make the client respond to the

server's messages in an appropriate way.

Our dependencies indicate that we need to work from the bottom-up in terms of implementation. We

should start with the ClaXML objects as they are required by Session, then we can work on Session, as it is

required by the Activities. The non-functional portions of the Activities may be worked on in parallel with

the Session and ClaXML objects.

8.4 Use-Case View

The important use cases for this document are Add Class, Drop Class, Confirm Schedule, and

Login as they suggest something about what will be passed over the network to t he server. Also, our

communication medium will need to be able to support these kinds of commands.

Otherwise, it's up to us as the software designers to place these use cases in areas which will make the most

sense to the user. For example, it only makes sense to add a class after we have searched for it first, so it

makes sense we place the Add Class use case somewhere inside the class search screen.

8.4.1 Use-Case Realizations

Almost all of the use cases work in very similar ways, but perhaps the most complicated is the Search use

case. Let us examine it in detail.

First, the user will interact with the user interface inside the Search Activity and perform some input

which causes the system to pass a search string that the user has entered to the Session object. The Session

object will then construct the appropriate URL to handle the search action. The Session object will then

make a call to the SAX libraries and pass it a ClaXMLHandler object and the constructed URL. SAX will

call this URL, take the data returned, and parse it. We can then mine a ClaXMLSet object out of

ClaXMLHandler and examine its contents. We can check for errors and throw an exception if any exist.

Otherwise, we can return the data set back to the Activity. The Activity will then take this data source and

bind it to a user interface component and display the search result to the user.

8.5 Logical View

8.5.1 Overview

On the client side, we are looking at just two main packages. One package which relates specifically to

BMR, and the other which deals primarily with ClaXML.

The BMR package decomposes into a Session object and four Activities which represent the individual

screens.

The ClaXML package decomposes into a handler for SAX and a data set that we can return back to the

classes inside the BMR package.



30/34



Bmr-Android

8.5.2 Architecturally Significant Classes

The Session object will be in charge of all of the communication with the server. It is essentially the only

exit point for the mobile device in our most high-level view of this project.

The Activity classes represent the melding with the user. They will be in charge of responding to inputs

issued by the user.

8.6 Interface Description

All of our Activities are intended to be ListActivities, which means we will have a very list-based user

interface. As most actions involve choosing an item out of a set of items, it seemed most appropriate.

We intend to use Android's standard methods of interaction with the user. For example, we make use of

single-clicks as selections for items in lists, long-clicks for data-altering actions (Edit/Delete), and for any

other actions we intend to put inside the Menu.

8.7 Size and Performance

One thing to consider when designing this software is of course that we are developing for a mobile

platform. That means for one screenful of user interface, we can only accomplish so much. This is why

we ended up with four screens with very discrete functions.

We should be careful to minimize the amount of network communication our application poses as data

connections could end up being very slow or very costly to the user if they have no data plan. Our XML

subset should be very minimal and light.

8.8 Quality

Since we have very discrete actions for each Activity, it becomes rather easy to add on a new element of

functionality. All that's needed is to add an Activity to support this functionality and a bridging to it from

another Activity. If network functionality is needed, the new Activity can just make a call to Session.

Our application calls for very basic usage of the user interface, the hardware of the target device probably

won't be a big issue to us. We are designing with a touch screen in mind, but Android provides alternative

ways of navigation and we can always add support for other input methods in our user interface with

relative ease. It will probably be backwards-compatible across Android versions.

Our application has a very good chance of becoming multilingual as all of the software we are creating has

good support for multiple languages. For the client-server messages, if the server sends a message in some

language, the device would only display character-by-character what the server told it. So, if the server has

been translated, a lot of the client's user interactions have been as well. As well, Android has good support

for different device locales.



31/34



Bmr-Android

9. Conceptual Architecture (Activity Flow Chart)



32/34



Bmr-Android

10.System Architecture



33/34



Bmr-Android

11. Class Architecture



34/34



Bmr-Android

12.Sequence Diagram

Date post:	07-Apr-2018
Category:	Documents
Upload:	haseeb-sheriff
View:	221 times
Download:	0 times

Bmr Android Srs 1.6

Documents