Team Builder Project

Transcription

1 Team Builder Project Software Requirements Specification Draft 2 February 2, 2015 Team:.dat ASCII 1

2 Table of Contents Introduction Purpose 4 Scope of Project.4 Overview.5 Business Context 5 Glossary 6 Overall Description Product Perspective 7 Product Functions.7 Similar Systems.. 7 User Characteristics.7 User Objectives..8 Constraints.8 Specific Requirements Functional Requirements.8 User Interface Requirements. 10 System Requirements. 11 2

3 Non-Functional Requirements.11 Logical Database Requirements 11 Life Cycle Model Choosing A Model 12 Introduction 3

4 Purpose The purpose of this document is to define the requirements of the software system Team Builder and give an overview of the project. The intended audience of this document is Professor Blase Cindric and Professor John Kirchmeyer of the University of Mount Union. Scope of Project The products to be produced from this project are a website containing an online application that allows users working on group projects to find other group members on Mount Union s campus. Users of this system shall include all professors of the University of Mount Union and eventually members of the public as well. Other prospective users shall include Mount Union students. following: Constraints affecting this software development project will include the Scheduling group meetings and programming time effectively by the group Finishing the final project in its entirety by no later than April 20 th, 2015 Completing all the research for implementing both the website as well as the application that will be imbedded in the website 4

5 Overview The contents of this Software Requirements Specification document include both general and specific details outlining the various inner workings of the Team Builder software system. The following section gives a more detailed and in depth look at the project and provides an overall description of the person-finding system for Team Builder. A quick way to find something in this document would be to utilize the table of contents provided at the beginning of this document. It will list all headings and subheadings in the document along with page numbers where the specific headings can be found. Business Context There is no outside organization sponsoring the development or providing the specifications for this project. The specifications and requirements for this software development project are being completely provided by Zach Nelson, Jacob Oravecz, Christina Price, and Austin Kaylor, the software development members of the project Team Builder. The goals that the members of the software development team for Team Builder have for the project are that Team Builder provides an easy way for students, faculty, and staff to find other students, faculty, and staff on Mount Union s campus for group projects, meetings, and other events. 5

6 Glossary Algorithm - a procedure or formula for solving a problem. API (Application-Programming Interface) - A set of routines, protocols, and tools for building software applications. It expresses a software component in terms of its operations, inputs, outputs, and underlying types. Back End (of a website) - "under the hood" part of the website that typically consists of a server, an application, and a database. CSS (Cascading Style Sheets) - a style sheet language used for describing the look and formatting of a document written in a markup language. Front End (of a website) - the part of the website the user can see and interact with. GPS - Global Positioning System based on satellite triangulation. web pages. HTML (Hypertext Markup Language) - the standard markup language used to create IDE (Integrated Development Environment) - a software application that provides comprehensive facilities to computer programmers for software development. Partition - A way of taking a set and dividing it into smaller subsets. Prototype - A preliminary model of an application from which other forms are developed or copied. 6

7 Overall Description Product Perspective This software will be a web application usable by anyone. Product Functions The software s purpose will be to generate teams of individuals by using a shortest path algorithm to determine which individuals are closest to one another using GPS coordinates. The teams will only be comprised of individuals using locations in, or close to, the University of Mount Union s campus. This will be accomplished by choosing a location on a GPS map, like Google Maps, choosing from a list of locations whose GPS locations have been found, or by typing in specific GPS coordinates. These locations are then used by the algorithm to compute and return a set of teams having the shortest total distance between team members. Similar Systems There are multiple, simpler versions of this software all over the web but this version we are developing will focus primarily on the University of Mount Union. Most of the software similar to this is focused on games or mathematics-related problem solving. User Characteristics The users that this software is primarily being developed for are professors at the University. This software will be able to help form student teams. By selecting or inputting student locations and names, the data will be used to generate teams consisting of those who live closest to one another. Little experience will be needed to use this software; the most complicated part would be to determine the GPS coordinates of a place if it is not already listed. 7

8 User Objectives The user of this software should expect a simple functionality. The software will be straightforward and will return accurate results in a timely fashion. Accessibility will also be a focus of the developers so that the system is simple enough for anyone to understand and use to its potential. Constraints There are few constraints for this software but the only issue that may arise during development is finding and implementing a GPS or navigation map. There are some APIs that can be used with Java but finding one that provides what we are looking for will be a challenge. We want to provide functionality, but we do not want to compromise the user friendly interface by incorporating complex components. Specific Requirements Functional Requirements Criticality Scale: <-- Low (1) Moderate (2) Imperative (3) --> Low: Items that can be saved for later prototypes should time issues be encountered. Moderate: Items that will be in the final product, but may not be required for next prototype. Imperative: Items that our system cannot function without and should be in early prototypes. 8

9 1. Description: A blank pixel map which the user can pick arbitrary points on in order to create a collection of points. Criticality: 1 Technical Issues: This feature is not the main focus of the project, but it will use the same problem solving methods as other program functions. Therefore, we will add the mission critical features first, and then reuse the code for this functionality. 2. Description: An option to have the map based on the University of Mount Union campus, where pre-loaded points can be chosen from a drop down menu in order to create a collection of points. Criticality: 3 Technical Issues: Without this requirement being met there would be no way for the user to interact with the program. 3. Description: An implementation of Google Maps where the user can enter street addresses in order to be added to the collection of points. Criticality: 2 Technical Issues: We want this feature to accommodate groups with commuter students, but trying to get Google maps to work with our components will be challenging if we don t have a fully functional prototype using only Mount Union s stored locations. 4. Description: Once a collection of locations has been created, the user will have the option to choose a group size (each point in the collection will represent the location of one group member). 9

10 Criticality: 3 Technical Issues: This is a mission critical function of our program because all other components will have a dependency on this function. 5. Description: Once the group size is chosen, the user can press a button to partition 7 the collection into groups of the indicated size. Each group will be made so that the groups will have the shortest distances between all group members. For example: if there were four people that needed to be split up into two groups, each person would get paired up with person closest to them. Criticality: 3 Technical Issues: For this function we will be implementing a shortest path algorithm in order find the closest group members. If our program fails to achieve this, the groups will not be partitioned correctly. 6. Description: If using the University of Mount Union campus map, the system will be able to find a best central meeting location after the groups have been formed. Criticality: 2 Technical Issues: This feature will be the hardest to implement because it depends on a fully functional prototype. This makes it difficult if there isn t enough time before the project deadline. However, this feature is needed for our program to appeal to Mount Union Students. User Interface Requirements Since the application is web based, the user interface will be both simple and easy to use. The interface will have three modes: each mode having a different interface. The first mode will have the blank pixel map and give the user options 4 and 5 from above after points are 10

11 chosen. The second mode will show a map of Mount Union s campus instead of a blank pixel map. The third will have a global map generated and zoomed by Google to the area of the address the user inputs. There will be tabs conveniently located where the user can switch modes. System Requirements Our program will be written in Java and developed using NetBeans IDE. When completed, our program will run on a Java Applet Interface. This Applet will be embedded in a public webpage. We will use HTML and CSS styling for the front end components of our website. Therefore, our program requires an up-to-date web browser with Java to operate. Non-Functional Requirements Maintainability for Mount Union s campus map will be done by keeping a text file of GPS coordinates of each building on campus. So if a new building is made or an existing building is destroyed, there only needs to be an entry added or deleted to the file. This makes our program easily maintainable. Logical Database Requirements The only information that we will need to store will be the GPS locations of all the buildings on Mount Union s campus. Since this will be such a small dataset we will not need the storage capacity of a database. Instead, we will have a text document that we will store the values at. This text document will then be read by the main program on startup. 11

12 Life Cycle Model Choosing a Model Our group decided to use the Evolutionary Prototyping (Incremental Prototyping) life cycle model; this style of model allows for repeated adjustments to our design. Since our project is web based, we will easily be able to make changes to our design to fit our needs. The Evolutionary Prototyping model allows for important prioritizing of requirements, which we can focus on first, and if adjustments are needed, we can make incremental changes. The Evolutionary Prototyping model also has the customer involved in a lot of the final decisions, which our team will use Professor Blase Cindric and Professor John Kirchmeyer as substitutes since our product doesn't have any customers. We will be consulting with Professor Blase Cindric and Professor John Kirchmeyer to ensure our project fulfills the requirements for our CSC 492 Project Guidelines to a satisfactory level. Once both accept the design and workability of the software, we will parallel that to a satisfied customer. 12