Difference: SoftwareRequirementsSpecificationMarcus (2 vs. 3)

Revision 32012-04-22 - MarcusHartzler

Line: 1 to 1
 
META TOPICPARENT name="HartzlerMarcusCAP"
Changed:
<
<

Software Requirements Specification Outline

>
>
1. Introduction
  • 1.1 Product Overview
This project is to create a web-based system for inputting data for a sports league over a wide range of sports. Not only should this system be able to store different leagues (per sport), teams in the leagues, and players on the teams, but it should also store scheduling information (per sport), like weeks, days in a week, games in a day, teams playing in the games, game time, game location, etc. Even more detailed, the system should allow for individual stats to be kept track of and scores to be submitted for games and all of that to be kept track of in the database. The web-based system should also present the information in an aesthetically pleasing way for anyone to view. To do this, the system will most likely use but is not limited to using HTML, Javascript, jQuery, PHP, and XML.
 
Changed:
<
<
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.
>
>
  • 1.2 Human Resources
The people that are going to (and currently) use this website are the students and faculty of MVNU. They will all use the viewing capabilities of the website, so they’ll be able to see when games are, who’s playing who, what the standings of the different leagues are, etc. As far as using the website to actually input data, just the MVNU intramural staff will be using that interface.
 
Changed:
<
<

Software Requirements Specification

Project Title

Author(s)
Affiliation
Date
Version History with Revision Dates

1. Introduction

  • 1.1 Product Overview

Provides a brief overview of the product objectives and scope. Start by copying the first section from your project proposal, and revise as necessary to reflect any changes and refinements since your proposal was submitted.

1.2 Human Resources
Describes the potential users, customers, and domain experts that have been consulted or will be consulted in the development of the system.

  • 1.3 Business Context
    Provides an overview of the business organization sponsoring the development of this product. This overview should include the business's mission statement and its organizational objectives or goals.

2. User Requirements (written for customers)

  • 2.1 User Objectives
    This section describes a list of objectives and requirements for the system from the user's perspective. It may include a "wish list" of desirable characteristics, along with comments if a characteristic is not likely to be feasible or consistent with the overall organizational context.

  • 2.2 Similar System Information
    Describes the relationship of this product with any other products. Specifies if this product is intended to be stand-alone, or else used as a component of a larger product. If the latter, this section discusses the relationship of this product to the larger product.

  • 2.3 User Characteristics
    Describes the features of the user community, including their expected expertise with software systems and the application domain.

  • 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. Short imperative sentence stating what the system should do.

  • Description
    A description of the function or object, explaining it as unambiguously as possible.

  • Inputs
    Describe input data and its source (e.g., keyboard, mouse, file, another system)

  • Outputs
    Describe any data produced and its destination

  • Criticality
    Describes how essential this requirement is to the overall system.

  • Technical issues
    Describes any design or implementation issues involved in satisfying this requirement.

  • Risks
    Describes the circumstances under which this requirement might not able to be satisfied, and what actions can be taken to reduce the probability of this occurrence.

  • Dependencies with other requirements
    Refer to other requirements or modules which must be developed for this requirement to function as intended.

  1. Short imperative sentence stating the second ranked requirement

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.

>
>
  • 1.3 Business Context Not applicable.

2. User Requirements

  • 2.1 User Objectives Users would like to be able to use this site to change the data in the database without needing to have any experience with programming or working with code at all, so the interface should be user friendly and should be completely web-based.

  • 2.2 Similar System Information This product is a stand-alone product.

  • 2.3 User Characteristics
The user community will only be able to use basic web site navigation and input straight forward forms in web sites.

  • 2.4 User Problem Statement
The user’s problem is that currently there isn’t really a good way for information regarding intramurals to be made available for everyone to see in a consistent way. There were attempts made to create an area on the MVNU SGA website to show the intramural schedules, standings, and stats, but the amount of work needed to keep up the information was very taxing because the HTML had to be changed and then updated and the stats had to be calculated by hand and stored in files that weren’t used by the site itself.

3. Functional Requirements

I. Data Input

  • Description - The system should allow users to input data and store that data in a database.
  • Inputs - The input data should be simple forms and it a keyboard and mouse would be used to input it.
  • Outputs - The data produced would be the forms that are stored in the database.
  • Criticality - This is very important because if the website doesn’t allow for input, then people with no experience with databases would have to go directly into the database and input the data manually.
  • Technical issues - The code used to put the data in the database will need to be tailor-made for this data, so everything regarding how the data is represented will need to be determined before this system is created.
  • Risks - If this requirement isn’t met, then if the intramural staff doesn’t have someone who can manually input data into a database then the website will be pointless because it won’t have any data in it. If the staff does, it will still require a lot of time and maintenance to input data into the database manually and it would be easy to make mistakes while inputting data.
  • Dependencies with other requirements - This is dependent on a working database and a user-friendly user-interface.

II. Working Database

  • Description - There needs to be a database that stores all of the information for the website.
  • Inputs - The inputs are forms sent from the website to the database.
  • Outputs - The output is data from the database.
  • Criticality - Extremely important. Without a database, no information can be stored so everything would need to be hardcoded into the HTML.
  • Technical issues - Trying to figure out how to normalize all of the data.
  • Risks - Without a database, everything will have to be hardcoded, so the problem of a high maintenance website won’t be fixed.
  • Dependencies with other requirements - This is dependent on a working user-interface for data entry.

III. User Interface for Data Entry

  • Description - There needs to be a user interface designed so that anyone can input data into the database.
  • Inputs - Inputs would just be HTML, JS and CSS to format the environment.
  • Outputs - The output would be what the user sees on the monitor.
  • Criticality - Pretty important, without the user interface it might be difficult to know how to input the data.
  • Risks - A bad user interface wouldn’t really fix the problem of difficulty entering and updating data.
  • Dependencies with other requirements - This is dependent on the database because it needs to show the most current data stored in the database.

IV. User Interface for Data Viewing

  • Description - There needs to be a user interface designed so that anyone can view the data in the database in a way that’s easily understandable.
  • Inputs - Inputs would just be HTML, JS and CSS to format the environment.
  • Outputs - The output would be what the user sees on the monitor.
  • Criticality - Very important, this is the whole point of the system. If no one could see the data, there would be no point in having it in the first place.
  • Risks - A bad user interface would make it hard to require people to rely on the website to find out information regarding intramurals.
  • Dependencies with other requirements - This is dependent on the database because it needs to show the most current data stored in the database.

4. Interface Requirements

  • 4.1 User Interfaces - The user interface is just a webpage.
4.1.1 GUI

4.1.2 CLI - Not applicable.

4.1.3 API - Not applicable.

4.1.4 Diagnostics - Not applicable.

  • 4.2 Hardware Interfaces
◦ A personal computer, mouse and keyboard.

  • 4.3 Communications Interfaces
◦ The computer has to be connected to the internet.

  • 4.4 Software Interfaces
◦ The computer needs to have a current version of one of the following web browsers:

Safari

Firefox

Google Chrome

Internet Explorer

5. Non-Functional Requirements

  • 5.1 Hardware Constraints
◦ Personal computers.

  • 5.2 Performance Requirements
◦ 1 GB of memory and an average bandwidth.

  • 5.3 System Environment Constraints
◦ Not applicable.

  • 5.4 Security Requirements
◦ The database should not only be available to intramural staff.

◦ The editing area of the website should only be accessible by intramural staff members.

◦ The usernames and passwords should only be accessible by intramural staff members.

  • 5.5 Reliability
◦ The website shouldn’t crash.

  • 5.6 Maintainability
◦ The editing area should be able to be used by anyone who is familiar with entering data.

  • 5.7 Portability
◦ Any device that has web browsing capabilities.

  • 5.8 Extensibility
◦ Cannot be used with web browsers that aren’t specified in 4.4.

  • 5.9 Development Process Constraints
◦ Apache server to host the website: allows HTML embedded PHP and SQL databases

◦ PHP: easy-to-use server-side language

◦ HTML: current standard in webpage-formatting

◦ CSS: current standard in HTML styling

◦ JS: easy-to-use client-side language.

◦ JQUERY: easy-to-use JS library that makes the XHTML structure easy to manipulate

◦ AJAX: easy way to call PHP files and an easy way to request XML documents

◦ XML: easy way to store data

SQL: simple database

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:

Intramural Database (XML)

year: PK id, title

weekday (child of year entity): PK title

month (child of year entity): PK title

season (child of year): PK id, title

sport (child of season): PK id, title, scoring_unit

stat (child of sport): PK id, title, calculation

court (child of sport): PK title

league (child of sport): PK id, title

week (child of sport): PK id, title

team (child of league): PK id, title, wins, losses, points_for, points_against

player (child of team): PK id, first_name, last_name, athlete, gender, paid

day (child of week): PK id, FK title, FK month, day

game (child of day): PK id, FK team1_id, FK team2_id, team1_score, team2_score, FK court, time, ref

7. Operational Scenarios

Someone views the intramural site:

  1. The client requests the webpage.
  2. The server runs the PHP code on the webpage and then sends the resulting HTML, JS and CSS to the client.
  3. Client uses the CSS to format the HTML in the web browser.
  4. Webpage uses the JS to run client-side operations.
  5. Client makes an AJAX call to get the XML file that stores the database and parses it.
  6. All pages that require the database can be created using the database that has been parsed on the client side.

Someone edits the data stored on the database from the website.

  1. The user clicks the “Submit” button (or equivalent).
  2. The data needed to update the database is sent to the server using an AJAX call to a specific PHP file.
  3. The PHP file is ran and the database is updated and saved.
  4. The response text from the PHP file is sent back to the client.
  5. The client makes and AJAX call to receive the XML database and reparses it so that the database on the client is up to date.
  6. The information in the HTML is refreshed to reflect the change in the database.

8. Appendices

  • 10.1 Definitions, Acronyms, Abbreviations – Not applicable.
  • 10.2 References - Not applicable.
 
META FILEATTACHMENT attachment="Software_Requirements_Specification.docx" attr="" comment="Software Requirements Specification" date="1323447972" name="Software_Requirements_Specification.docx" path="Software_Requirements_Specification.docx" size="128761" user="MarcusHartzler" version="1"
 
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