Software Engineering Software Requirements Specification (srs) Document
Download 70.79 Kb.
|
- Navigate this page:
- 3. Functional Requirements
- 4. Interface Requirements
- 5. Performance Requirements
- 6. Other non-functional attributes
- 6.2 Binary Compatibility
- 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
- 6.8 Application Affinity/Compatibility
- 7. Operational Scenarios
- 8. Preliminary Use Case Models and Sequence Diagrams
- 9 . Updated Schedule
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
Requirements Document Approval History
Requirements Document Review History
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 Description2.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:
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
4. Interface Requirements4.1 User Interfaces Describes how this product interfaces with the user.
The Home Screen and its Connecting pages 
A   pp Logo Client Tested, Client Approved
T  rip Planner Mockup Design
There will be no command-line interface for our application.
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 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 attributes6.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 ScenariosPlan 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 Diagrams8.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
