Docstoc

C-Tech SRS

Document Sample
C-Tech SRS Powered By Docstoc
					<Team Name>

<System Name>

Systems Requirements Specification

Version x.x Month dd, yyyy
Copyright  2006 by <client name>, and <team name>

<client name> <system name>

Systems Requirements Specification Introduction

About This Document
Purpose of this Document The Systems Requirements Specification (SRS) is designed to express the behavioral, performance, and development requirements of this product and serves as the fundamental requirements document for the development of the product. The Systems Requirements Specification includes a description of every input into the system, every output from the system and all functions performed by the system in response to input or in support of an output. The SRS meets IEEE830 standards and is the exclusive requirements document to be used in development; all design and testing choices must be compatible with this document. <Client Name>

Document Prepared for Intended Audience Date of Publication Page Count Document Location

<client, system designers, testers, users, trainers, etc.> <today’s date> April 4, 2009

Last saved: This printing: <nn> pages <path>

Refer to Global Template Instructions for naming and save location standards. Prepared From Associated Procedures Prepared by Copyright Notice SRS_Outline.doc CSE616, Object- Oriented Systems Analysis, QQYY

<team member names and emails> Permission to make digital or hard copies of all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for commercial advantage and that copies bear this notice and the full citation on the first page. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permission to republish from <client name & contact info>.

ii

Proprietary and Confidential

April 4, 2009

Product Requirements Document Revision History

<client name> <system name>

Revision History
Date Revision Description Author

April 4, 2009

Proprietary and Confidential

iii

<client name> <system name>

Systems Requirements Specification Introduction

Table of Contents
1. 1.1. 1.2. 1.3. 1.4. 1.5. 2. 2.1. 2.2. 2.3. 2.4. 3. 3.1. 3.2. 3.3. 3.4. 4. 4.1. 4.2. 4.2.1. 4.2.2. 4.2.3. 5. 5.1. 5.2. INTRODUCTION ................................................................................................................................ 1-1 PURPOSE .......................................................................................................................................... 1-1 SCOPE .............................................................................................................................................. 1-1 REFERENCES .................................................................................................................................... 1-1 STANDARDS ...................................................................................................................................... 1-1 DEFINITIONS ...................................................................................................................................... 1-2 OVERALL DESCRIPTION ................................................................................................................. 2-1 PROJECT ABSTRACT .......................................................................................................................... 2-1 FUNCTIONAL OBJECTIVES .................................................................................................................. 2-2 SYSTEM CONSTRAINTS ...................................................................................................................... 2-2 OTHER CONSTRAINTS ........................................................................................................................ 2-4 SYSTEM EVENTS AND DATA FLOWS ............................................................................................ 3-5 EVENT TABLE .................................................................................................................................... 3-5 CONTEXT DIAGRAM ........................................................................................................................... 3-5 PRODUCT FUNCTIONS - SYSTEM ACTIVITIES ....................................................................................... 3-6 USER CHARACTERISTICS ................................................................................................................... 3-6 SPECIFIC REQUIREMENTS ............................................................................................................. 4-1 USE CASE DIAGRAM - ORGANIZED BY SUBSYSTEM............................................................................... 4-1 USE CASES ....................................................................................................................................... 4-2 Use Case Scenario <#> .............................................................................................................. 4-2 Use Case <#> Prototype ............................................................................................................. 4-3 Use Case <#> Object Interaction Diagram .................................................................................. 4-3

VALIDATED OBJECT MODEL .......................................................................................................... 5-4 CLASS DIAGRAM................................................................................................................................ 5-4 CLASS SPECIFICATIONS ..................................................................................................................... 5-5

iv

Proprietary and Confidential

April 4, 2009

Systems Requirements Specification Introduction

<client name> <system name>

1.

Introduction
1.1. Purpose
The Systems Requirements Specification (SRS) is designed to express the behavioral, performance, and development requirements of this product and serves as the fundamental requirements document for the development of the product. The Systems Requirements Specification includes a description of every input into the system, every output from the system and all functions performed by the system in response to input or in support of an output. The SRS meets IEEE830 standards and is the exclusive requirements document to be used in development; all design and testing choices must be compatible with this document.

1.2.

Scope

The scope of the SRS identifies the magnitude of what the product will cover. The Systems Requirements Specification is intended for review by the client to ensure that all desired functional, performance and development requirements have been stated in a way such that they are: Readable: minimizes misinterpretations by developers and testers by using clear, concise, unambiguous, and complete language. Testable: will be used for strategies in Master Test Plan, Functional Test Plan, and other formal testing documents. Modifiable: changes easily as requirements change, accommodates Requirements Traceability Matrix, see section 4 of this document, and Change Management Policy. Useable for Operations: will be used as a living document after project is completed for operations and maintenance. Maintenance projects use the SRS to obtain a greater understanding of the system when changes need to be made. Traceable: works with the Requirements Traceability Matrix to ensure components, responsibilities, and test cases link to minimize impact for requirements change and localize defects. Buildable: will be used by developers to write code from specifications. Documentable: will be used to write user manual and technical manual to help train new staff.

1.3.

References

This is a complete list of all documents referenced elsewhere in this document. 1. Systems Analysis and Design in a Changing World , Satzinger, Burd, Jackson, 3rd edition. 2. The Object Oriented Approach Concepts, System Development and Modeling with UML, Satzinger, Orvik, 2nd edition.

1.4.

Standards

This is a complete list of all standards used in this document. 1. IEEE 830-1993 – The content and qualities of a good Systems Requirements Specification (SRS) are described and several sample SRS outlines are presented. This recommended practice is aimed at specifying requirements of software to be developed but also can be applied to assist in the selection of in-house and commercial software products.
April 4, 2009 Proprietary and Confidential 1-1

<client name> <system name>

Systems Requirements Specification Introduction

1.5.

Definitions
GUI – Graphical User Interface WSID – Workstation Identification Number DB - Database

This section contains a list of definitions for organizational specific words that are not universal.

1-2

Proprietary and Confidential

April 4, 2009

Systems Requirements Specification Overall Description

<client name> <system name>

2.

Overall Description

This section of the SRS describes 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.

2.1.

Project Abstract
<system name> <users, developers, testers, trainers, etc>

Project Name: Customer Departments: Authors: Date:

<team name>, <team member names> <date>

2.1.1.

Project Scope

[A brief description of the scope of this system; what other Project(s) it is associated with, and anything else that is affected or influenced by this document.]

2.1.2.

Background

[A page or two that summarizes the current system and provide some motivation for a new system at this time. The main audience for this section would be designers and implementers who join the project later and are not familiar with the current system. If this is a new system, describe what business need this system will solve. Compare the proposed new system to other competing systems.]

2.1.3.

System Purpose

[Specify:  Who will use/benefit from the new system  Where the system and its users are  What is the scope of the new system o What the new system will be responsible for o What the new system will not be responsible for (drawn from responsibilities that might be conceivably within the scope of the system  Why there is a need for this system]

2.1.4.

System Mission

[Describe the goal of the system in terms of its business purpose in two to four clear, concise sentences.]

April 4, 2009

Proprietary and Confidential

2-1

<client name> <system name>

Systems Requirements Specification Overall Description

2.1.5.

System Functions / Responsibilities

[This section describes the functional objectives of the system, expressed in a natural language style and organized by priority. Functional objectives are typically expressed as a positive statement of what the system will do. Justify each objective with its business purpose (IR AC IS) and make it measurable (money, time, resources).]

2.2.

Functional Objectives
[<Priority> The system shall <function>, creating <IR AC IS benefit>. Evidence of success will be measured by <x> improvement in <measurable performance> ] <… repeat for all Functional Objectives …>

2.3.

System Constraints

System Constraints restrict options of design, behavior, appearance or operation. They become requirements due to factors outside the normal problem domain. System Constraints describe how the product operates inside various circumstances and limit the options designers have if building the product. This section specifies design constraints imposed by other standards, hardware limitations, communication interface limitations, etc. There are a number of attributes of software that can serve as requirements.

2.3.1.

User Interface Constraints

User Interface Constraints consist of 2 parts: the logical characteristics of each interface between the software product and its users and all the aspects of customizing (preferences) the interface with the person who is using the system. [This section should include all of those requirements that affect usability. Examples:  Specify the required training time for a normal users and power users to become productive at particular operations.  Specify measurable task times for typical tasks, or  Base usability requirements of the new system on other systems that the users know and like.  Specify requirements to conform to common usability standards – e.g., IBM’s CUA standards, or the GUI standards published by Microsoft for Windows 95.] For example,        It will take a user x hours of training to be certified a normal user It will take a user y hours of training to be certified a power user It will take a user z hours of training to be certified an administrator. The system shall require a maximum of x seconds for loading and logging into the system. It will take the system administrator x hours to setup and install the system for the first time. The system’s Graphical User Interface (GUI) should adhere to Industry standards so that the GUI will look the same on a variety of operating systems such as Windows XP and Linux. The system shall have a free flowing interface to keep the usability of it to simple and easy. Complex actions and or fancy artwork shall not be included to keep the system complexity minimized.

2-2

Proprietary and Confidential

April 4, 2009

Systems Requirements Specification Overall Description

<client name> <system name>

2.3.2.

Hardware Constraints

Hardware Constraints include configuration characteristics, what devices are to be supported, how they are to be supported, and communication protocols, any applicable characteristics or limits on primary and secondary memory or memory storage, any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, etc. ]

2.3.3.

Software Constraints

Software Constraints are assumptions that particular pieces of software will be available and are necessary to the functioning of the product. This section describes software interfaces to other components of the software system. These may be purchased components, components reused from another application, or components being developed for subsystems outside of the scope of this SRS, but with which this software application must interact. For example,   System must run on linux. Java must be installed on the operating system.

2.3.4.

Communications Constraints

Below is a list of communication devices or protocols with which the product must interact. For example,   System must be able to communicate with printer. System must communicate through TCP/IP.

2.3.5.

Data Management Constraints

This is a detailed description of constraints for data flow to data management software and equipment outside the scope of the project. For example,  System must export financial data to a financial data management program (gnucash)

2.3.6.
For example,       
April 4, 2009

Operational Constraints

Below is a list of restrictions on how the product will run when in its environment.

The throughput of the system shall be kept to x seconds on average but to a maximum of y seconds if the system is under heavy load. The throughput of the system shall be y transactions per second. The system shall have an average of 10 current projects stored and up to a Maximum 50 projects. The system shall have an average of 50 workers currently logged in and up to a Maximum of 100 users logged in. The system shall use a maximum of x% of memory, y% of disk space and z% of company internet bandwidth. The system shall be available x% of the work day which is between 6am and 6pm. The system will have x hours of Mean Time Between Failures (MTBF).
Proprietary and Confidential 2-3

<client name> <system name>

Systems Requirements Specification Overall Description

    

The system will have y hours of Mean Time To Repair (MTTR). Maximum Bugs or Defect Rate Minor Bugs (displaying incorrect information, other display glitches) these will be kept to a maximum of x bugs/KLOC. Critical Bugs (such as user having too much access, not having enough access) these will be kept to a maximum of y bugs/KLOC. Major Bugs (such as system crash, loss of data, failure to create output) these will be kept to a maximum of z bugs/KLOC.

2.3.7.

Site Adaptation Constraints

This is a detailed description of data or initialization sequences specific to a given site.

2.3.8.

Design Standards Compliance

There are a number of attributes of software that can serve as requirements. The following list specifies factors that must be established for the system to work. Existing standards and regulations impose the following constraints on the system. For example,        The system shall be designed using open sources languages and or freeware software. The system interface shall be developed using the Java Programming Language version 1.5 to be able to run on multiple OS. The system shall be developed using MySQL version 5.0 or higher to store data. The system shall be developed using CLIPS version 6.24 to help build the expert system. The system shall be designed be able to switch interfaces and or back end (databases). Front End software should be designed for easy portability to Aspect J or AJAX software. Back End software should be designed for easy portability to a higher capacity and faster database system.System Operational Parameters

2.4.

Other Constraints

Below is a list of all other interfaces that impose design constraints.

2-4

Proprietary and Confidential

April 4, 2009

Systems Requirements Specification System Events and Data Flows

<client name> <system name>

3.

System Events and Data Flows
3.1.
Event [Occurrences at a specific time and place that trigger system processing]

Event Table
Trigger [data inflow or time that system detects] Source [ultimate creator of trigger. May be a person, department, or system. If event type is temporal, this is left blank.] Activity [system process that results from trigger] Response [data that system produces. If only internal effects are made, then this is ‘n/a’] Destination [ultimate destination of data response.]

3.2.

Context Diagram

Context diagrams use data flow diagramming (DFD) notation to illustrate the scope of a problem and the source, sinks of data and control that flows into and out of a system.

<external: data source or destination>

<inflow: group data item> <system name>

<inflow: group data item>

<external: data source or destination>

<outflow: group data item>

<external: data source or destination>

<outflow: group data item>

April 4, 2009

Proprietary and Confidential

3-5

<client name> <system name>

Systems Requirements Specification System Events and Data Flows

3.3.

Product Functions - System Activities

This subsection of the SRS provides a summary of the major processes that the software will perform, which includes the system tasks and features from the Product Requirements document and Project Charter. 2.2.1 [Activity] [Description] <repeat for all activities>

3.4.

User Characteristics

User Characteristics describe those general characteristics of the intended users of the product including educational level, experience, and technical expertise. <system name> users consist of the following:   Managers who wish to perform system administration functions as well as export company financial information. <repeat for all users and system externals>

3-6

Proprietary and Confidential

April 4, 2009

Systems Requirements Specification Specific Requirements

<client name> <system name>

4.

Specific Requirements

This section of the SRS contains all the system requirements to a level of detail sufficient to enable designers to design a system that satisfies those requirements. Testers can use this section to test that the system satisfies those requirements and technical writers can create the necessary support documentation for operations and maintenance. Note: Use Cases are in priority order.

4.1.

Use Case Diagram - organized by subsystem

<verb obj>

<user>

<system name subsystem name>

April 4, 2009

Proprietary and Confidential

4-1

<client name> <system name>

Systems Requirements Specification Specific Requirements

4.2.

Use Cases

Use Cases are requirements from the Client translated into unambiguous language. A Use Case may have multiple inputs or outputs as part of the same functional flow. A Use Case without any input or output is not valid. The detailed requirements of a Use Case tend to be extensive. For this reason, it is recommended that careful consideration be given to organizing the requirements in a manner optimal for understanding. Subcases are identical to use cases except where noted. This section provides descriptions of all the use cases devised for this system. Each use case description provides the following information:

4.2.1. Use Case Scenario <#> <Use Case Name> Purpose Actor Input Data Output Data Invariants
A brief description of what the user is trying to accomplish. A person or external system outside the scope of the system that triggers step one of the Detailed Description. A list of all external data needed for the use case to be performed. A list of all data produced by the use case execution. A condition which is maintained throughout the use case. This section is used to highlight assumptions made for the sake of the use case. Conditions which must hold for the use case to be applicable. It is assumed that these conditions are true prior to the beginning of the use case, and will not be true when the use case completes. Conditions which are guaranteed to hold after completion of the use case. A single, error-free path, which may contain subflows, calculations, logical structures, etc. All exception and error cases, including where/how they were triggered <<includes>> and <<extends>> cases and where they were referenced The rationale for this case, also explains exceptions and errors Any other relevant information not included in the above sections.

Pre-conditions

Post-conditions Basic Flow: Alternative Flow(s): Extension Points: Business Rules: Notes

4-2

Proprietary and Confidential

April 4, 2009

Systems Requirements Specification Specific Requirements

<client name> <system name>

4.2.2. Use Case <#> Prototype
[Complete set of simple discovery prototypes showing all user interaction for basic and alternate flows.]

4.2.3. Use Case <#> Object Interaction Diagram
[Sequence or Collaboration diagram showing all participating classes and messages that trigger response for basic and alternate flows.] <… repeat for all Use Cases…>

April 4, 2009

Proprietary and Confidential

4-3

<client name> <system name>

Systems Requirements Specification Validated Object Model

5.

Validated Object Model

The Validated Object Model is a visual representation of the idealized problem domain. The consistency between the Sequence Diagrams and the Object model validates the requirements.

5.1.

Class Diagram
The Class diagram shows the structural scope-of control- entities and relationships in the problem domain of the Object Model.

<class name>

<class name>

<attributes>

<attributes>

<methods>

<methods>

<class name>

<attributes>

<methods>

5-4

Proprietary and Confidential

April 4, 2009

Systems Requirements Specification Validated Object Model

<client name> <system name>

5.2.

Class Specifications
Class Specifications are the prose detail necessary to elaborate the definitions of each class attribute and algorithm of each class operation. <repeat for each class> Class Parent Description Attributes <attribute name> <description> <class name> <if any> <in prose>

Methods <method name> <description and any parameters>

April 4, 2009

Proprietary and Confidential

5-5


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:97
posted:4/4/2009
language:English
pages:17