Software Requirements Specification Outline

Software Requirements Specification

Android Scorekeeper

Gregory Kindle
MVNU
2011-2012

1. Introduction

  • 1.1 Product Overview

I will be designing an Android mobile application that can be used to keep score and statistics at basketball and volleyball games. This will be geared towards someone who is running a small league at a church or school. They will use it to keep track of stats and the score during the game. This could also be used by parents to keep track of their kid’s statistics.

  • 1.2 Human Resources
I will be talking with other people who would potentially use this app. Such as the intramural staff on campus so that I can get feedback from them as to how to improve the application.

  • 1.3 Business Context
    This is my senior project at Mount Vernon Nazarene University. I am doing it to gain experience in developing a product on my own from scratch.

2. User Requirements (written for customers)

  • 2.1 User Objectives

    The main function of this application is that the user will be able to assign different statistics to certain players. There will be the option to start a volleyball or a basketball game. The user will have the option to give all players stats such as free throw attempted, free throw made, two-pointer attempted, two-pointer made, three-pointer attempted, three-pointer made, rebound, and foul. The team score will also update whenever a made basket is assigned to a player.

    Before each game the user will enter the names in manually for each team which will be remebered for future games as well. There will also be an option to export the stats after each game to a computer in CSV format for easy sorting in Excel.

  • 2.2 Similar System Information
    After a game is complete the statistics can be exported in a CSV format and then used in another program but the application will be able to function on its own.

  • 2.3 User Characteristics
    Users will not have to have experience with anything before using the application. Everything in the application will be easy to use and easy to learn. In order to use the exporting function the user may need some experience with Excel to take full advantage of what the application can offer.

  • 2.4 User Problem Statement
    N/A

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. Keep track of team score and basic individual statistics for a basketball game

  • Description
    A list of indiviuals on a team with the ability to assign points, rebounds, and fouls to each member of the teams.

  • Inputs
    Touch screen of an Android device with buttons to press for each statistic.

  • Outputs
    The team total score will update whenever points are assigned to the individuals.

  • Criticality
    This is really important since this is the basic function of the application.

  • Technical issues
    Getting all the desired features to fit in the screen in a user friendly way.

  • Risks
    Since this is the most basic feature of the application, if it cannot be achieved then the whole project will fail. In order to assure it won't fail I will have to learn basic Android programming techniques.

  • Dependencies with other requirements
    N/A

2. Export Statistics to Excel after a game is over
  • Description
    • Be able to email a CSV file to a chosen email address after a game is over
  • Inputs
    • Select game to export and select email to send the stats to or select to send entire stats for all games.
  • Outputs
    • An email will be generated with a CSV attached.

  • Criticality
    • This would be really nice but is not totally necessary.
  • Technical issues
    • Creating a CSV file using the proper SQL to get the stats from a game.
  • Risks
    • Creating a CSV file could be tricky.
  • Dependencies with other requirements
    • Has to have functionality to keep track of the statistics.
3. Have ability to select which 5 players are on the floor at a time and be able to perform substitutions
  • Description
    • Be able to choose active players and change them during the game.
  • Inputs
    • Have a button to sub player out that will bring up list of players who are currently on the bench
  • Outputs
    • List of players on the screen will change based on who is on the floor.
  • Criticality
    • Would be better than having all players listed a one time and having to scroll up and down but not requried.
  • Technical issues
    • Need to be able to substitute quickly and the page with the players listed will need to be rebuilt everytime there is a substitution.
  • Risks
    • Could cause speed problems due to searching list of players on team to find who is on the bench everytime the sub button is hit.
  • Dependencies with other requirements
    • Need number one done first since the game page has to already exist to add substitution function.

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
    Describes how this product interfaces with the user.

    • 4.1.1 GUI
      Main Menu with access to enter new team, enter new player, start volleyball game, start basketball game, or send stats. After starting basketball game the two teams must be choosen.

    • 4.1.2 CLI
      N/A

    • 4.1.3 API
      Describes the
      application programming interface , if present. For each public interface function, provide the name, arguments, return values, examples of invocation, and interactions with other functions.

    • 4.1.4 Diagnostics
      Describes whether any debugging information or log data should be produced for diagnostic purposes.

  • 4.2 Hardware Interfaces
    Need to have an Android device to run the application.

  • 4.3 Communications Interfaces
    Able to access Android email program to send CSV file to selected email address after a game is complete

  • 4.4 Software Interfaces
    Will have a mySQLLite database bulit in to store teams and players and their statistics. See diagram at the bottom of this page.

5. Non-Functional Requirements

  • 5.1 Hardware Constraints
    Built to run on Android devices

  • 5.2 Performance Requirements
    Needs to be able to update names of players on teams quickly before the game starts. Also, need to be able to input statistics in real time as they are happening without any significant delay.

  • 5.3 System Environment Constraints
    Describes any standards for which compliance is required, or standard data or application formats that must be supported.

  • 5.4 Security Requirements

  • 5.5 Reliability

  • 5.6 Maintainability

  • 5.7 Portability
    Describes a range of systems that should be supported by this software.

  • 5.8 Extensibility
    N/A

  • 5.9 Development Process Constraints
    Used Eclipse to develop project. Project contains XML files for the layout and Java files with classes and activities.

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) - See below

7. Operational Scenarios

This section may include a set of scenarios that illustrate, from the user's perspective, what will be experienced when utilizing the system under various situations. In the article Inquiry-Based Requirements Analysis (IEEE Software, March 1994), scenarios are defined as follows:

A scenario is simply a proposed specific use of the system. More specifically, a scenario is a description of one or more end-to-end transactions involving the required system and its environment. Scenarios can be documented in different ways, depending up on the level of detail needed. The simplest form is a use-case diagram, which consists of a labeled interaction between actors. More detailed forms are called scripts. These are usually represented as tables or sequence diagrams and involve identifying a sequence of actions and the agent (doer) of each action.

Although scenarios are useful in acquiring and validating requirements, they are not themselves requirements, because they describe the system's behavior only in specific situations; a specification, on the other hand, describes what the system should do in general.

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.

  • Tables in Database:
    Capture.PNG
Topic attachments
I Attachment Action Size Date Who Comment
PNGPNG Capture.PNG manage 24.5 K 2011-12-06 - 21:24 GregoryKindle Tables in Database
Topic revision: r7 - 2012-04-18 - GregoryKindle
 
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