Software Requirements Specification Document …softeng17/Software Requirements... · Web viewView...

Software Engineering Software Requirements Specification

(SRS) DocumentNick Antzoulatos

Roger KidChad GuevremontScott Wenkstern

Andrew Polhamus

Dot Com Millionaires

https://www.radford.edu/~softeng17/index.html

11/2/11

https://www.radford.edu/~softeng17/index.html

Revisions

Version Primary Author(s) Description of Version Date Completed

1 Andrew PolhamusNick AntzoulatosRoger KidChad GuevremontScott Wenkstern

Final Draft 11/2/11

Review & ApprovalRequirements Document Approval History

Approving Party Version Approved

Signature Date

Chad Guevremont 1

Dr. T. L. Lewis

Requirements Document Review History

Reviewer Version Reviewed

Signature Date

Nick Antzoulatos 1

Roger Kid 1

Andrew Polhamus 1

Scott Wenkstern 1

Dot Com Millionaires 1

Contents

1. Introduction.............................................................................................................................31.1 Purpose of this document..................................................................................................31.2 Scope of this document......................................................................................................31.3 Overview...........................................................................................................................31.4 Business Context...............................................................................................................3

2. General Description.................................................................................................................42.1 Product Functions..............................................................................................................42.2 Similar System Information...............................................................................................42.3 User Characteristics...........................................................................................................42.4 User Problem Statement....................................................................................................42.5 User Objectives..................................................................................................................42.6 General Constraints...........................................................................................................5

3. Functional Requirements.........................................................................................................54. Interface Requirements............................................................................................................7

4.1 User Interfaces...................................................................................................................74.2 Hardware Interfaces...........................................................................................................94.3 Communications Interfaces.............................................................................................10

5. Performance Requirements....................................................................................................106. Other non-functional attributes..............................................................................................10

6.1 Security............................................................................................................................106.2 Binary Compatibility.......................................................................................................106.3 Reliability........................................................................................................................106.4 Maintainability.................................................................................................................106.5 Portability........................................................................................................................106.6 Extensibility.....................................................................................................................106.7 Reusability.......................................................................................................................116.8 Application Affinity/Compatibility.................................................................................116.9 Resource Utilization........................................................................................................116.10 Serviceability.................................................................................................................11

7. Operational Scenarios............................................................................................................118. Preliminary Use Case Models and Sequence Diagrams........................................................13

8.1 Use Case Model...............................................................................................................138.2 Sequence Diagrams.........................................................................................................14Trip Planner Sequence Diagram............................................................................................14View Map Sequence Diagram...............................................................................................15View Route Time Tables Sequence Diagram........................................................................16

9. Updated Schedule..................................................................................................................1710. Updated Budget...................................................................................................................1811. Appendices..........................................................................................................................18

11.1 Definitions, Acronyms, Abbreviations..........................................................................1811.2 References.....................................................................................................................18


1. Introduction

1.1 Purpose of this documentThe purpose of our app is to develop a functional and robust application that can provide the user with detailed information about the Radford Transit System. The ideal functionality for the user is to input a time and destination into the application, while it produces what route to take and when. Also we want to give the user the option to look at route maps and time tables so they can figure out the best times for themselves.

The purpose of the Facebook “story teller” app is to develop a functional and robust application that can allow users to create and continue a story among their friends. The ideal functionality for the user is to create a story by opening and putting text into the application, while it produces possible friends to send it to in order to continue the story. Also, user should have the option of what friends to send it to if so if they desire.

1.2 Scope of this documentThe scope of our project will include gathering the correct maps, and information for all 5 bus routes and their respective stops. We will provide bus schedule data, such as hours of operation, times of each stop, and a digital picture of each stop. Our app will be able to calculate the next bus arrival time based on current time and destination. It will also supply information that is not specified online like how much time the bus will wait at destinations like Walmart and Christainsburg so people won’t get left behind until the next bus. There will be limited secruity in our app because there will be no logging in, or user accounts. A limitation would be being able to use the GPS feature to calculate the location of the user and programming the GPS location of each bus stop. The app will be available to all stakeholders, and anyone who would like to download it. Aside from the App itself, there will no downloadable content; the app will contain all the needed information. Our expected audiance is anyone who uses the RU transit, which is not limited to just students, since anyone can ride the bus with either a Radford ID or pay to use the service.

The scope of this application will be creating a story started by one user and interlink the story to their friends list. This will include the gathering of accepting permission to install the application and notifying users when a story has been passed down to them. It will also supply information such as what time the last user has edited the story and how long they have been editing. Security will be in place for users need to login into Facebook to access the application so people not on a person’s friends list can’t interact with a story. A limitation would be being able to use the Facebook notification system to alert users of a new story posting. The intended audience for this application will be all currently registered Facebook users that have access to the internet.

1.3 OverviewOur goal is to create an interactive application for the new Radford University transit system. We plan to include a Map with active icons of all of the pick-up/drop off points, which will allow you to view the hours of operation, times of every stop, and other detailed information about each stop. Ideally, we would like to incorporate real-time GPS into the map that would tell the user where the closest bus stop is relative to their location. We will also provide a link to the main website & interactive buttons to auto contact the transit or emergency


services. Being able to tell the user when the next available bus will be & what bus to take in accordance with their route.

1.4 Business ContextRadford Transit is a public transit system providing safe, reliable and convenient public transit to the citizens of Radford, Radford University students, faculty and staff and those who live in the surrounding areas. Professionally operated by New River Valley Community Services, Radford Transit was established on August 8, 2011 through a joint partnership between Radford University, Radford City, the Virginia Department of Rail and Public Transportation, and the Federal Transit Administration.

New River Valley Community Services (NRVCS), which operates Radford Transit, also operates the Community Transit service – a service for individuals on Medicaid and/or those who require special assistance transportation services to community-based programs. Established in 1986, Community Transit provides passenger service throughout the New River Valley - including the counties of Montgomery, Pulaski, Floyd, Giles, and the City of Radford. Our mission is, “Making a Difference by Enhancing Lives.”

2. General Description

2.1 Product Functions

The Dot Com Millionaires will design and develop an application that gives a simple way for students of Radford University to get an easy understanding of the Radford Transit System. The application will allow users to view maps all bus routes and interact with stops to view more detailed information. They will be able to view time schedules for all routes on all days in a clear and concise way. The app will also have a function to plan a trip by picking a destination start and specify which day.

2.2 Similar System Information

The only other existing product similar to ours is the official RU Transit website. To find it, you would have to go through myRU which can be a hassle. Most students don’t think about getting transit information until then need it. Having the information available anywhere on your Android phone will allow users to find out what they want when they want. The old website is not portable and is very confusing. We can enhance upon the system by adding more features, such as being able to overlay multiple route maps for comparison to see which routes get you closer and sooner to certain destinations. We will also add bus stop icons that are interactive and will give additional information about that stop. Another feature we will be adding is landmarks on the map to make it easier to find where you’re going based on a point of reference.

2.3 User Characteristics

The target community is going to be frequent bus users. They should know their habitual bus routes, but that knowledge isn’t really ingrained in them. They may be deterred from riding routes that are unfamiliar to them. We’re not expecting any complex use for our system. The


interface should look and feel like navigating through a video game menu since almost every college kid plays, or has played, video games.

2.4 User Problem Statement

The current problem with the user community is human error. People tend to forget. Imagine if someone went out at night and completely lost track of time. By the time they realized what time it was, the bus already made its last cycle. With our app it will be easy to inform users when they need to catch a bus home. Having a bus map app would get rid of the need for people to have to remember all the information about every route.

2.5 User ObjectivesClient’s Wish List:

Interactive Bus Stop Signs with QR tags Pictures of all bus stops Most popular destinations section GPS Functionality for buses Filtered Time Tables Landmarks on the maps

Having interactive bus signs is a good idea but it would get costly, and times consuming to add QR tags to all 125 bus stop signs and have them correspond with a picture and additional information inside our app. Pictures of all bus stops would increase the app file size significantly. Most popular destinations is a great idea that we plan to implement as a menu choice for the trip planner. GPS is way too expensive to add for the purpose of the app, but buses may be given GPSs in a few years. Filtering the time tables is a good idea to eliminate buses that have already happened that day. We hope this is easy to do by returning only results where the time is greater than the phones current time. Adding landmarks to the maps is the best and simplest idea on the client’s wish list. It adds a relative location that people who don’t know the area can relate to. Our client observed that most students use landmarks as a point of reference.

2.6 General Constraints

Our main constraint is that our app has to fully functioning by December 2011. We still have the majority of the project to complete to transform our well documented ideas into a fully functional app that can solve the confusion that many students have about the Radford Transit System.


3. Functional Requirements

Criticality ScaleDesired if time permits 1Desired 2Somewhat Necessary 3Super Necessary 4Required 5

1. The user shall be able to select their desired bus route.1. Description: The user shall be able to select the correct bus route corresponding to

their desired destination.2. Criticality: 4 - Super Necessary3. Technical issues: The only issues would be organizing the destinations by points of

interest so that more common stops are easy to find.4. Risk: The app makes the process of finding your route extremely complicated and

frustrating.5. Dependencies with other requirements: 4

2. The user shall be able to view a section with information about the app and the transit system in general.

1. Description: The user will be able to press a button on the home screen labeled ““About” where they can read additional information about the app, and the transit system, in general, to get additional information about the Radford Transit System.

2. Criticality: 3 - Somewhat Necessary3. Technical Issues: what information should be positioned in this section and where to

place this button link in the app itself4. Risk: the failure of the app to successfully load and the info fails to generate5. Dependencies with other requirements: none

3. The app should be able to plan a trip based on the day, destination, and time.1. Description: The app will display a series of drop down menus to display possible

days, destinations, and return a set of results based on the current time.2. Criticality: 3 - Somewhat Necessary3. Technical Issues: The implementation of this feature could prove to be more

complicated than originally anticipated. It will require an extensive amount of coding to return the desired result set that includes all possibilities of destinations and starts.

4. Risks: 1. The user is too confused by the trip planner GUI and refuses to use it.2. If the start and destination are parts of different routes it will be hard to

combine routes using a transfer stop.5. Dependencies with other requirements: 1 and 3; it needs to access time tables and

maps.

4. The user shall be able to view and interact with a route map.


1. Description: The user should be able to zoom in and out drag the image to view different parts, and be able to click on an interactive button shaped as an RU transit sign to see detailed information about the stop.

2. Criticality: 5 - Required3. Technical issues: the image that is generated will have to be size restricted or reset

in order to limit the amount of resize and scrolling that the user will have to do.4. Risks:

1. The app fails to load and the map fails to generate as a result.2. The map that is generated is incorrect in the eyes of the user (wrong route).3. The route function fails to select the proper route and the app generates

incorrect information.5. Dependencies with other requirements: dependant on requirement 1 selection of

route.

5. The user shall be able to view all route table information for all 5 routes and days of the week

1. Description: The user will be able to see a table of routes for all 5 routes on any day of the week. This will be accessible by a button from the home screen that will take the user to a second screen where they will be able to specify which route they want. Also the routes will be named more appropriately while keeping the original 10, 20, 30, 40, and 50 numbering system. For example (10) Campus Loop, Green Hills would be more understandable to a freshman.

2. Criticality: 5 - Required3. Technical issues: We need to provide a simpler to understand version of the time

schedules so that it is easy to figure out when and where a bus will be.4. Risk:

1. The app fails to load the table.2. The wrong table is returned.3. The information displayed is factually incorrect.

5. Dependencies with other requirements: none

4. Interface Requirements

4.1 User InterfacesDescribes how this product interfaces with the user.

4.1.1 GUIOur project’s GUI will be supported primarily by menu-driven operation direct manipulation of images, and form-fill-in. The goal of the interface is going to be an


uncluttered interface that gives a short list of options that will allow the user to get the route information they need and a minimal number of clicks.

The Home Screen and its Connecting pages


App Logo Client Tested, Client Approved


Trip Planner Mockup Design

4.1.2 CLI

There will be no command-line interface for our application. 4.1.3 API

Our application will not be utilizing Application Programming Interfaces. 4.1.4 Diagnostics or ROM

Diagnostic data for the debugging of our program will be provided by Appcelerator’s built-in debugger and feedback from testing.

4.2 Hardware InterfacesUsers of the application should have an Android smartphone with the version 2.2 or higher operating system installed. The user should have at least 5mb of hard drive space to save the application.


4.3 Communications InterfacesThe application will only access files from its own memory. It will not interface with a database or external files from the internet.

5. Performance RequirementsThe most memory demanding feature of our application is the Trip Planner. It will need to access both image files and data from time tables. The main map is a 2732x2120 PNG image (753 KB) and the largest route map is 663 KB. Areas that maps don’t cover are cropped out. With these 2 alone the total file size in images should take up 1.416 MB. There will be a few other icons added onto the map with may include a bus icon, start and final destination icons, and route through map overlay (subject to change). It should add only a fairly small memory requirement (50 KB to 1 MB).

6. Other non-functional attributes

6.1 SecurityAccess to modify the application will be limited to Radford University Transit administrators after the app has been released. There will not be login information required. The app and its information and pictures will be accessible to anyone who downloads it.

6.2 Binary CompatibilityOur application shall be accessible by any smartphone with the Android operating system version 2.2 or higher.

6.3 ReliabilityThe application should load in less than 10 seconds with 99.9% uptime. The map image files shall be compressed to reduce the amount of bytes to under a megabyte each. The map image files shall load from the application itself in under 10 seconds.

6.4 MaintainabilityThe code should be well documented so that other programmers can easily make changes and enable the future evolution of the application.

6.5 PortabilityThe application should work on any Android smartphone with an operating system version of 2.2 or higher. The application should also be able to be run and updated using Appcelerator.

6.6 ExtensibilityThe application should support future QR Tag implementations that shall let users can a QR tag on a particular bus stop sign and receive detailed information about that bus stop and its corresponding routes and times. The application should support future route changes or additions, and be able to update the data tables with additional time schedules of these additional routes, or changes to a current route.


6.7 ReusabilityThe application should be reusable by new students to Radford University (freshman and transfer) to inform them about the Radford Transit system for at least 10 years.

6.8 Application Affinity/CompatibilityThe application shall be functional without internet access to anyone with an Android smartphone operating system version 2.2 or higher.

6.9 Resource UtilizationThe application shall use many of the resources common among Android apps including the ability to zoom, drag, and select a destination by touching the bus stop’s icon.The application shall include compressed image files and format text information in a table to reduce the size of the app to fewer than 5mb.

6.10 ServiceabilityOur team will produce proper documentation throughout the entire process, as well as a user manual and training so future modifications to the system will be implemented with minimal effort.

7. Operational Scenarios

Plan a TripAssumption: The user started the app and selects the trip planner button with a known destination in mind.

Normal: The route is selected using a drop down menu. The day is selected using a drop down menu. The time is selected using a drop down menu. The system opens the corresponding map. The map is found. The map is displayed to the user. The user is prompted to select a destination. The user is prompted to select a starting point. The system processes the information. A list of trips and times is returned to the user based on their selections.

Wrong: The user selects the wrong information from the drop down menus. They have to hit the back button to reload the trip planner home page.

The user accidentally hits the back button. The user must start over and enter the route day time again.

Completion: The destination and start locations are picked and the user can see all the times that they can catch the bus during that day based on the time selected. Then they can choose which time best fits their schedule.


View a MapAssumption: The user started the app and selects the map button. Then picks the map they want to look at.

Normal: The map is selected. The system opens a new page’s link. The link is found. The map is returned to the user. The user closes the map. They return to the previous menu with the maps to select.

Wrong: The user selects the wrong map. They have to hit the back button to return to the maps page.

The user accidentally hits the back button. The user must reload the same map again.

Completion: The map is displayed and the user can interact with the image using zoom and drag using the phone’s image features.

View Route Time TablesAssumption: The user started the app and selects the schedule button. Then picks the bus route they want to look at.

Normal: The route’s table is selected. The system opens a new page’s link. The link is found. The table is returned to the user. The user closes the table’s page. They return to the previous menu with the routes to select.

Wrong: The user selects the wrong route. They have to hit the back button to return to the schedules page.

The user accidentally hits the back button. The user must reload the same route again.

Completion: The route’s schedule is displayed and the user can scroll through the table to see all available times for all stops.


8. Preliminary Use Case Models and Sequence Diagrams

8.1 Use Case Model


8.2 Sequence DiagramsTrip Planner Sequence Diagram


View Map Sequence Diagram


View Route Time Tables Sequence Diagram


9. Updated Schedule


10. Updated Budget

11. Appendices

11.1 Definitions, Acronyms, Abbreviations

RU- Radford UniversityGUI- Graphical User Interface: It is what the user sees or interacts with.QR Tag – Two-dimensional barcode scanned by smartphone.MB- Megabyte, 100000 bytes.CLI- Command line interface.

11.2 ReferencesProvides complete citations to all documents and meetings referenced or used in the preparation of this document.

Meetings:

Meetings 6-9.

Programs:

Microsoft Visio Microsoft Project Microsoft Word WireFrameSketcher Pro Titanium Appcelerator.


Kitchen Sink

Web:

www.w3schools.com

http://www.radfordtransit.com/


http://www.radfordtransit.com/

http://www.w3schools.com/

Software Requirements Specification Document …softeng17/Software Requirements... · Web viewView...

Documents

Transcript of Software Requirements Specification Document …softeng17/Software Requirements... · Web viewView...