Software Engineering Software Requirements Specification (srs) Document



Download 70.79 Kb.
Date30.06.2017
Size70.79 Kb.
#22315





Software Engineering

Software Requirements Specification

(SRS) Document
Nick Antzoulatos

Roger Kid

Chad Guevremont

Scott Wenkstern

Andrew Polhamus


Dot Com Millionaires
https://www.radford.edu/~softeng17/index.html


11/2/11





Revisions



Version

Primary Author(s)

Description of Version

Date Completed

1

Andrew Polhamus

Nick Antzoulatos

Roger Kid

Chad Guevremont



Scott Wenkstern


Final Draft


11/2/11



Review & Approval

Requirements 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










Contents



1. Introduction

1.1 Purpose of this document
The 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 document
The 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 Overview
Our 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 Context
Radford 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 Objectives
Client’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 Scale

Desired if time permits

1

Desired

2

Somewhat Necessary

3

Super Necessary

4

Required

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 Necessary

    3. 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



  1. 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 Necessary

    3. Technical Issues: what information should be positioned in this section and where to place this button link in the app itself

    4. Risk: the failure of the app to successfully load and the info fails to generate

    5. Dependencies with other requirements: none



  1. 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 Necessary

    3. 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.



  1. 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 - Required

    3. 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.



  1. 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 - Required

    3. 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 Interfaces

Describes how this product interfaces with the user.

  • 4.1.1 GUI
    Our 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 Interfaces

Users 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 Interfaces
The application will only access files from its own memory. It will not interface with a database or external files from the internet.

5. Performance Requirements


The 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 Security


Access 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 Compatibility


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

6.3 Reliability


The 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 Maintainability


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

6.5 Portability


The 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 Extensibility


The 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 Reusability


The 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/Compatibility


The application shall be functional without internet access to anyone with an Android smartphone operating system version 2.2 or higher.

6.9 Resource Utilization


The 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 Serviceability


Our 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 Trip

Assumption: 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 Map

Assumption: 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 Tables

Assumption: 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 Diagrams


Trip 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 University

GUI- 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 References
Provides 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/



Download 70.79 Kb.

Share with your friends:




The database is protected by copyright ©ininet.org 2024
send message

    Main page