1
Team Builder Project
Software Requirements Specification
Draft 2
February 2, 2015
2
Table of Contents
Introduction
Purpose………4 Scope of Project……….4 Overview……….5 Business Context………5 Glossary………6Overall Description
Product Perspective………7 Product Functions……….7 Similar Systems………..…………7 User Characteristics……….7 User Objectives………..8 Constraints……….8Specific Requirements
Functional Requirements……….8User Interface Requirements……….…10
3 Non-Functional Requirements……….11
Logical Database Requirements………11
Life Cycle Model
Choosing A Model………12
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.
Constraints affecting this software development project will include the
following:
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
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
sub-headings in the document along with page numbers where the specific sub-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.
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.
HTML (Hypertext Markup Language) - the standard markup language used to create
web pages.
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
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, likeGoogle 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
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
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).
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 partition7 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
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.
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
