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

Project Title

Josh Tennefoss
Affiliation Mount Vernon Nazarene University
9/20/2011

1. Introduction

  • 1.1 Product Overview

The objective of the system I plan to develop will be to record outcomes and participants of a competition and give statistics about winning and losing records.

1.2 Human Resources
Dr. Skon, friends and family who may be in the potential user base.

  • 1.3 Business Context
    Not Applicable.

2. User Requirements (written for customers)

  • 2.1 User Objectives

    • The program will retrieve a list of contacts from the devices contacts, if applicable, or simply create its own custom profile for a specific player to keep track of them over time.

    • The program will accept input about the players involved in a competition and the outcome of the competition and store it on the device.

      The program will retrieve stored data and give statistics based on the specified parameters (by game type, by person, ect.).

      The program will have an option to sync with another devices data, trading information about players and games in common. (diffucult and not absolutley necessary)

    • The program will have a timer and a score pad option for use with games/competitions that would apply (possibly card games, dice games, anything that would normally require paper and pen to keep score). - Secondary

  • 2.2 Similar System Information
    Stand alone app.

  • 2.3 User Characteristics
    Users will be owners of android devices and interested in recording and getting statistics about competitions. They will not by nature have any special skills, however no special skill should be required.

  • 2.4 User Problem Statement
    Describes any problems currently confronted by the user community.

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. The program should store information about competitions.

  • Description
    A The user will input the data about a specific competition and the device will store the data internally. This will allow the result and ciercumstances of the competition to be retrieved and reproduced at any time.

    The database will store: the date and time of the competition, the name of the competition, 1:n categories associated with the competition, the number of players, a description of the competition, and the id number and rank of each player (if provided). - implemented

  • Inputs
    Any inputs that apply to the android device the user is currently using.

  • Outputs
    The data stored in the database is produced, but the user will not see this.

  • Criticality
    Core importance.

  • Technical issues
    A database layout must be created and implemented that meets the needs and is as efficient as possible.

  • Risks
    Normal to low risk. If the database refused to work ( as in I could not get it to be funcitonal) the entire project would be comprimised. In order reduce this risk I will read up on sqlite on android and work on implementing it.

  • Dependencies with other requirements
    No dependencies.


  1. The program will create and store player profile information

    • Description
      The program will need to consitently indentify players over time, so a profile will be created for each player as needed. The profile can be based from the contacts list or can be custom created from scratch.

      The player 'profile' is simply the id number associated with the player in the phone's contact list. This is how all players are identified and stored. - implemented
      When a contact is removed from the contact list, the database will update the removed player's references in a reasonable way. - not implemented, priority low

    • Inputs
      Any android device inputs.

    • Outputs
      The player profile information will be output and stored internally, the user will not see it, unless a conformation page is displayed.

    • Criticality
      Core importance. The user must be able to keep track of players over time, however the option to create a profile based on ( and possible updated from) the contacts list is of lower importance.

    • Technical issues
      Reading from the contacts list and recieving updates when contacts are updated may be difficult.

    • Risks
      Normal to low risks. The custom profile should be very basic, the contacts profile will be more difficult but is not a neccessity.

    • Dependencies with other requirements
      Requires access and interaction with the devices contact list.

The program will display statistics about results
  • Description
    The program will generate and display statistics about winning or losing records and percentages, or number or games played, ect. The statistics will be based on data previously stored on the device.

    The statistics returned can represent all data available, or a user selected subgroup of players, games, categories, or dates. - 85% implemented, priority medium
    A 'list' mode will be available. This mode will rank players based on probability, and games and categories based on popularity - implemented
    A 'single player' mode will be available. This mode will focus on a single player and give general statistics and compare the focus player to all other players directly - 80% inplemented, priority high
    A 'head to head' mode will be available. This mode will directly compare two or more players, only considering competitions they all participated in. - not implemented, priority low

  • Inputs
    Parameters for the statistics from the user, and information from the database.

  • Outputs
    The statistics will be displayed in an organized fashion on the device.

  • Criticality
    Core importance. The program will be useless unless it can generate and display statistics based on user requests.

  • Technical issues
    Reading from the database.

  • Risks
    Normal to low risks. Generating statistics is basic math but requries some program organization.

  • Dependencies with other requirements
    Requires the player profile information and the competition results to be stored in the database.

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
      Describes the
      graphical user interface, if present. This section should include a set of preliminary screen dumps or mockups to illustrate user interface features. If the system is menu-driven, a description of all menus and their components should be provided.

    • 4.1.2 CLI
      Describes the
      command-line interface, if present. For each command, provide a description of all arguments and example values and invocations.

    • 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
    Describes interfaces to specific hardware devices.

  • 4.3 Communications Interfaces
    Describes network interfaces.

  • 4.4 Software Interfaces
    Describes any remaining software interfaces, such as a database interface, not included above.

5. Non-Functional Requirements

  • 5.1 Hardware Constraints
    Specifies the type(s) of hardware on which the system is expected to run.

  • 5.2 Performance Requirements
    Specifies time and memory constraints that must be satisfied for the system be effective.

  • 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
    Describes any constraints on forward or backward compatibility with other systems.

  • 5.9 Development Process Constraints
    Describes the software development environment to be used, including programming languages, development tools, and software libraries, indicating any reasons that these are required or preferred.

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

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.

Topic revision: r4 - 2012-04-19 - JoshTennefoss
 
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