This revision made November 07, 2009 17:10, by Bruce Schubert

Campbell Prediction System

Software Requirements Specification

Version 0.1

Bruce Schubert

Revision History

Name Date Reason for Changes Version
Bruce Schubert November 7, 2009 Created. 0.1

Introduction

Purpose

This Software Requirements Specification (SRS) describes the functional and non-functional requirements for the Campbell Prediction System (CPS) project. This document is intended for the team members that will implement and verify the correctness of the system.

Scope

This project will manifest a training tool and decision support system based on the Campbell Predition System methods to compute, project and visualize potential fire behavior, trigger points and alignments-of-forces on the fireground. See the CPS Vision Document for an expanded description.

Definitions, Acronyms and Abbreviations

Actor
A user or external system that interacts with the system.
CPS
Campbell Prediction System
FBA
Fire Behavior Analyst
SRS
Software Requirements Specification
Use-Case
A description of system behavior, in terms of a sequence of actions, as observed by the user.

References

  1. Vision Document

Overview

[This subsection should describe what the rest of the Software Requirements Specification contains and explain how the document is organized.]

Overall Description

[This section of the Software Requirements Specification should describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3, and makes them easier to understand. Include such items as product perspective, product functions, user characteristics, constraints, assumptions and dependencies, and requirements subsets.]

Insert Use Case Diagrams here...

Use-Case Model Survey

[If using use-case modeling, this section contains an overview of the use-case model or the subset of the use-case model that is applicable for this subsystem or feature. This includes a list of names and brief descriptions of all use cases and actors, along with applicable diagrams and relationships. Refer to the Use-Case-Model Survey Report, which may be used as an enclosure at this point.]

Assumptions and Dependencies

[This section describes any key technical feasibility, subsystem or component availability, or other project related assumptions on which the viability of the software described by this Software Requirements Specification may be based.]

Specific Requirements

[This section of the Software Requirements Specification should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements and testers to test that the system satisfies those requirements. When using use-case modeling, these requirements are captured in the use cases and the applicable supplementary specifications. If use-case modeling is not used, the outline for supplementary specifications may be inserted directly into this section.]

Use-Case Reports

[In use-case modeling, the use cases often define the majority of the functional requirements of the system, along with some non-functional requirements. For each use case in the above use-case model, or subset thereof, refer to, or enclose, the use-case report in this section. Make sure that each requirement is clearly labeled.]

Supplementary Requirements

[Supplementary Specifications capture requirements that are not included in the use cases. The specific requirements from the Supplementary Specifications, which are applicable to this subsystem or feature, should be included here and refined to the necessary level of detail to describe this subsystem or feature. These may be captured directly in this document or referred to as separate Supplementary Specifications, which may be used as an enclosure at this point. Make sure that each requirement is clearly labeled.]

Supporting Information

[The supporting information makes the Software Requirements Specification easier to use. It includes
• Table of Contents
• Index
• Appendices
These may include use-case storyboards or user-interface prototypes. When appendices are included, the Software Requirements Specification should explicitly state whether or not the appendices are to be considered part of the requirements.]
Difference compared to previous revision
|0.1 |} __TOC__ ==Introduction:''[===Purpose=== The introductionThis of the Software Requirements Specification (SRS) should provide an ove Software Requirements Specification (SRS) descrvribiewes of the entire doc the fument. It should include the purpose, scope, definitions, acronyms,unctional abbreviations, references, and overview of the Software Requirements Specification.]'' :''[Note, The So and non-ftware Requirements Specification captures the complete software requirements for the system, or functional requirements for the Ca mportion of thbe system. Following is a typical Softwaell Pre Requdirements Specification ouiction Systlinteme for (CPS)a project.project using u Thise-case mos documdeling.ent This artifact consists of a package containing us is intendede cases o forf the us the te-caseeam model members th andat applwicableill Suimpplementary Specifications and othplement and ver supporting information.erify For a thtemplatee c of an Software Requirements Specification not using use-case modeling, which captures all requirements in a single document,orrectness of with applicable section the sys inserted from the stem. ===Sucopplementarype=== This S projpecifications (which would no onger be needed), see rup_srs.dot.]'' :''[Mect will many differenanifest a tt arrraiangemenitsg t of a Softwareool Requiremeantsd Spdecifsication are ion supppossible. Refer to [IEEE830-1998] for furort systhertem elaborati based on of these explon the Canations, as wmpbell as othePr opeditions for a Softion Systwarteme Requiremen methodts Specifications to c organization.]'' ===Purompose=== :''[Specify uthte,e purpos proje of cthis Software Requirementst and Specvificsuatlion. Thze Spoftware Requirements Specification should fully describotential fire the external e behavior,behavior of th triggere application or subsystem identified. It also points an describes nonfunctional required alignments, design c-onstraints and other factof-fors necessary to provide a complete and comprehensive description of the requorces on the firements fogr the softwareround.] === Scope=== :''[A brif description of the softwareSee the CPS applVicatsion that the SDoftware Reqcuirements Specificationument for appliesn to; the feature or other subsystem grou exping; what Use-case mopandel(s) it is associated with; and anything else that is affected or influenced by ded descripthis document.]tion. ===Definitions, Acronyms and Abbreviations=== :''[This subseAction should providector'': theAdefinitionus of all terms, acronyms, and abbreviations required ser or exto propternaerly inl systerpretm the Software that Requirements Specific interacation. Thits ws informationith may be provided by reference to the project Glossar the systemy.] ===References :''[This. :''CPS'': suCampbsection shouldbell pProvide a redicomplete list of all documentction System :''FBA'': Fis referencedre B elsewheehaviore ir An alysthe :''SRS'': Software Requirements Specification. Each docum :''Usent -Cashould bse'':e i A dentscrified by ptitle, report number (ition of applicable), dasyste,m and publis behavhing organior, ization. Specify the sourcein terms froms of whichathse rquferences can be obtained. This informence of actions,ation may as obs be providerved by the user. ===Red by reference teferences #[[Visio an appendon|Vix sior to another don Document.ocument]] ===Overview :''[This subsection should describe what the rest of the Software Requirements Specification contains and explain how the document is organized.] ... :''[This subsection should describe what the rest of the Software Requirements Specification contains and explain how the document is organized.] ==Overall Description :''[This section of the Software Requirements Specification should describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3, and makes them easier to understand. Include such items as product perspective, product functions, user characteristics, constraints, assumptions and dependencies, and requirements subsets.] Insert Use Case Diagrams here... ===Use-Case Model Survey :''[If using use-case modeling, this section contains an overview of the use-case model or the subset of the use-case model that is applicable for this subsystem or feature. This includes a list of names and brief descriptions of all use cases and actors, along with applicable diagrams and relationships. Refer to the Use-Case-Model Survey Report, which may be used as an enclosure at this point.]
  • Mysql
  • Glassfish
  • Jruby
  • Rails
  • Nblogo
Terms of Use; Privacy Policy;
© 2013, Oracle Corporation and/or its affiliates
(revision 20140418.2d69abc)
 
 
Close
loading
Please Confirm
Close