Software Requirements Specification Outline

This document contains a template structure for a software requirements specification (SRS) document. To use this outline replace the description of each section with the information about your project. If a section is not applicable to your project, keep the heading in your document, and just state that it is not applicable.

Software Requirements Specification

Android Golf Scorecard

Matthew Kraly
MVNU
5/6/2012

1. Introduction

  • 1.1 Product Overview

The product will be an android application that works like a virtual golf scorecard. Allowing the user to put in his or her score for each hole. The player will then be able to save these scorecards and look at them whenever they please.

1.2 Human Resources
Myself (Matt Kraly), Dr. Skon, any user.

  • 1.3 Business Context
    MVNU is sponsoring the project more or less.

2. User Requirements (written for customers)

  • 2.1 User Objectives
    It should pull information from a small database about the course you are playing which includes the lengths of the hole from all available tee boxes as well as the handicap rating for the hole.

  • Users should be able to enter a score for each hole, save the scorecard and view it whenever they please.
  • 2.2 Similar System Information
    Not related to any other product except for the android operating system and android devices.

  • 2.3 User Characteristics

    Average user would have no technological savvy, would be a golfer.
  • 2.4 User Problem Statement
    None really

3. Functional Requirements

This section lists the functional requirements in ranked order. A functional requirement describes a desired behavior or effect of the software system, in other words, what the system must accomplish, but not how it will do it. Other kinds of requirements (such as interface requirements, performance requirements, or reliability requirements) describe how the system accomplishes its functional requirements. Each functional requirement should be specified in a format similar to the following:

  1. Generate a Scorecard for the selected course

  • Description

    Generates a scoredcard with the length of each hole from each tee and the par for that hole as well as the HCP rating
  • Inputs

    Data input will be the name of the golf course, it will be entered by the user with the touch screen
  • Outputs

    The data output will be the scorecard
  • Criticality
    Very essential it is the basis of the entire project

  • Technical issues
    I'll need to figure out how to create and access a small database as well as program a nice looking user interface for the scorecard

  • Risks
    If i cannot create a database or make the GUI look like a scorecard.

  • Dependencies with other requirements

    Depends on the database.
  1. Golf Course Database

  • Description
    It will be a small database that has golf courses and each golf course has 18 holes and each course has 1 or more tee boxes which vary the distance of the holes, and a HCP rating. Each golf course also has a slope and course rating as well as a name.

  • Inputs

    The input will be the information on each course and will most likely come from a CSV file i create from a website
  • Outputs

  • Criticality
    Very critical to making my application useful and large scale

  • Technical issues
    Creating and accessing the database may prove to be difficult because I do not know how.

  • Risks

    If for some reason I cannot figure out how to create a database in SQLite then I will be in trouble.
  • Dependencies with other requirements
    Depends on my ability to gather the information about the golf courses

  1. Save/View Scorecards Feature

  • Description
    Users will be able to save scorecards and view them whenever they would like, scorecards will be sorted by alphabetical order

  • Inputs

    The input will be the date of the round and the course it was played at
  • Outputs

    The output will be a scorecard showing the scores that were entered earlier
  • Criticality
    Very critical in making the application useful

  • Technical issues
    Formatting the scorecard could prove difficult

  • Risks

    Database risks, layout risks
  • Dependencies with other requirements
    Depends on a database that stores the scores

4. Interface Requirements

This section describes how the software interfaces with other software products or users for input or output. Examples of such interfaces include library routines, token streams, shared memory, graphical I/O, and so forth.

  • 4.1 User Interfaces
    It will have a main page asking if you want to "View Scorecards" or "Start New Round". Clicking on "Start New Round" will then allow the user to select a course from a list, this page also has a search box they can use. After a course if picked they will be asked to choose a tee box, after a tee box is picked they will be presented with the scoring page which will have a drop down menu allowing them to choose a score, a "Save Scorecard" button, and display information about the users current score, the course, and the hole. The user will be able to scroll sideways to change the hole they are on.

  • If the user clicks on "View Scorecards" he will be presented with a screen where he needs to choose a date and course where the course was saved. After he picks one he will be presented with his scorecard which is formatted similar to a real scorecard which has his final score on it.

    • 4.1.1 GUI

      The title screen would allow the user to view his or her saved scorecards as well as allow for a new round. If new round is selected it will allow the user to pick a golf course and start a new round.
    • 4.1.2 CLI
      No CLI.

    • 4.1.3 API
      The program will be created with Eclipse and the Android SDK.

    • 4.1.4 Diagnostics
      None

  • 4.2 Hardware Interfaces
    It will be specific to android systems.

  • 4.3 Communications Interfaces
    None

  • 4.4 Software Interfaces
    It will interface with a small database using SQLite.

5. Non-Functional Requirements

  • 5.1 Hardware Constraints
    Any android device.

  • 5.2 Performance Requirements
    Should effectively run on any android device.

  • 5.3 System Environment Constraints
    Must be Android 2.1 or later.

  • 5.4 Security Requirements

    None
  • 5.5 Reliability

    The system should be reasonably reliable, we can't have it crashing all the time.
  • 5.6 Maintainability

    The database should be easily updateable.
  • 5.7 Portability
    The application will only work on Android operating systems of 2.1 or later.

  • 5.8 Extensibility
    None.

  • 5.9 Development Process Constraints
    I plan to use the Eclipse Java programming environment with the Android ADT plugin.

6. System Models
This section includes diagrams showing relationships between major software components and the system environment. It may include one or more of the following:

  1. State Machine Diagrams

  2. Object Models

  3. Data-Flow Models

  4. Entity-Relationship Diagrams (if the system will include a database)

7. Operational Scenarios

The scorecards main scenario will be used on the golf course. Say you are driving to your local course you arrive, simply pull out your phone, choose the golf course from the list of courses. You are on your way, the scorecard will load up, you can then see the handicap and yardage for each hole from any tee box. During your round you will enter how many strokes you took on each hole. At the end of the round you can save your scorecard and it will calculate your score for the round and you will be able to look at it whenever you want.

8. Appendices

Specifies other useful information for understanding the requirements. All SRS documents should include at least the following two appendices:

  • 10.1 Definitions, Acronyms, Abbreviations
    Provides definitions of specialized terms or acronyms that must be understood in the context of this application.

  • 10.2 References
    Provides complete citations or URLs for all documents and web sites referenced or used in the preparation of this document.

Topic revision: r4 - 2012-05-07 - MattKraly
 
This site is powered by the TWiki collaboration platformCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback