SRS Template

Torus SRS Template

22nd September 2010

Contents

Introduction...........................................................................................................................3

Purpose.............................................................................................................................3

Scope................................................................................................................................4In Scope.........................................................................................................4

Out of Scope..................................................................................................4

Points of Contact...............................................................................................................4

Document references........................................................................................................4

Glossary of Terms..............................................................................................................5

Change Control..................................................................................................................5

Sign Off.............................................................................................................................5

Users required to Sign Off.................................................................................................5

Assumptions, Constraints and Dependencies........................................................................6

Assumptions......................................................................................................................6

Constraints........................................................................................................................6

Dependencies....................................................................................................................7

.Context.................................................................................................................................7

Context Diagram...............................................................................................................7

Interface Requirements.........................................................................................................8

User Interfaces..................................................................................................................8

Hardware Interfaces..........................................................................................................8

Software Interfaces...........................................................................................................8

Operational Requirements.....................................................................................................9

Security.............................................................................................................................9

Audit Trail........................................................................................................................10

Data Currency.................................................................................................................10

Reliability........................................................................................................................10

Recoverability..................................................................................................................11

System Availability..........................................................................................................11

Traceability Matrix...............................................................................................................12

Functional Requirement (FRX).............................................................................................13Requirement Statement...............................................................................13

Data Requirements......................................................................................13

Torus SRS Document 1

Validation.....................................................................................................13

Screen Design..............................................................................................14

Reference Data............................................................................................14

Workflow......................................................................................................14

Cube and Reporting.....................................................................................14

Use Case......................................................................................................14

Document Control................................................................................................................16

Version Control................................................................................................................16


Introduction

Purpose

The System Requirements Specification (SRS) is a formal statement of the application functional and operational requirements. It serves as the basis for development. The developers agree to provide the capabilities specified. The User agrees to find the product satisfactory if it provides the capabilities specified in the SRS.

Sections 1 through 9 describe the contents of the SRS in accordance with the software development life cycle (SDLC). Section 10 is provided for informational purposes only and describes the general requirements for generating a Requirements Traceability Matrix (RTM) in tandem with the SRS. It provides general guidelines for writing requirements. Section 11 provides information on optional Attachments and Appendices.

A brief description of SRS functions, characteristics, and requirements structure includes the following:

• The SRS provides the following functions: Designing and developing the application system

Evaluating the product in all subsequent phases of the lifecycle

Determining the success of the project • The SRS has the following characteristics:

Demonstrates that the application provides value to Torus in terms of the business objectives and business processes.

Contains a complete set of requirements for the application.

Is solution independent. The SRS is a statement of what the application is to

do—not of how it works. The SRS does not commit the developers to a design. For that reason, any reference to the use of a specific

technology is inappropriate in an SRS, unless the technology is listed as a system constraint (see Section 2.2).

• The SRS provides the following requirements, where a requirement isdefined as a condition the application must meet for the customer to

findthe application satisfactory. A requirement has the following characteristics: Provides a benefit to the organization. That benefit is directly traceable to the business objectives and business processes of Torus.


Describes the capabilities the application must provide in business terms.

Does not describe how the application provides that capability.

Does not describe such design considerations as computer hardware, operating system, and database design.

Is stated in unambiguous words. Its meaning is clear and unmistakable.

Is stated

Scope

Give a description of the intended scope of the system, how it will

accomplish its purpose.

In Scope

List Items Included

Out of Scope

List items excluded

Points of Contact

List the names, titles, and roles of the major participants in the project.

Document references

List the documents that are sources or references for this SRS. Include meeting summaries, white paper analyses, and SDLC deliverables, as well as any other documents that preceded this SRS and provided information for the development of it. Also reference any documents that provided information on the relevant Torus version or business plan.


Name Department Job Title

Glossary of Terms

Include a list of terms, abbreviations, and acronyms used in this document. If the list is longer than a page, it can be included as an Appendix or Attachment to the SRS.

Term Description

Change Control

Any changes to this functionality whilst development is in progress will be reflected by version control of this document. Subsequent to this work being completed and released to the live environment any further changes to this model will be captured by the change request process and these will become supplements to the original document.

Sign Off

Before any prioritisation of this work or any development can be commenced this document must be signed off by the Crime users as acceptance and agreement that the information capture within this document is a true reflection of the Crime business requirements.

Users required to Sign Off


User Name Department Job Title

Assumptions, Constraints and Dependencies

Assumptions

State the assumptions associated with development of the system, where assumptions are defined as future situations, beyond the control of the project, whose outcomes influence the success of a project. The following are examples of assumptions:

Availability of a hardware/software platform Pending legislation Developments in technology

Constraints

State the constraints associated with the development of the system, where constraints are defined as conditions outside the control of the project that limit the design alternatives.

Constraints can be broadly categorized as technical and non-technical. The following are examples of both types of constraints:

Government regulations Technical standards imposed on the solution (for example, the use of a

specific Database Management System) Strategic decisions

Distinguish constraints from preferences, as follows:

Constraints exist because of real business conditions. For example, a delivery date is a constraint only if there are real business consequences that will happen as a result of not meeting the date. If failing to have the subject application operational by the specified date places Torus in legal default, the date is a constraint.

Preferences are arbitrary. For example, a date chosen arbitrarily is a preference. Preferences, if included in the SRS, should be noted as such.

Dependencies


List all other factors that will have a material effect on the success of this development. If these factors are not in place when required then the success of this work will be compromised


Context

Provide a context diagram of the system, with explanations as applicable. The context of a system being developed refers to the connections and relationships between the system and the outside world. Context Diagrams are often used to illustrate these connections and relationships.

Context Diagram

Add diagram here


Interface Requirements

Interface requirements describe interaction of the system with users, hardware, software, and communications.

User Interfaces

Describes the user interfaces that are to be implemented by the system.

Hardware Interfaces

Define any hardware interfaces that are to be supported by the system, including logical structure, physical addresses, and expected behaviour.

Software Interfaces

Name the applications with which the subject application must interface. State the following for each such application:

Name of application Owner of application (if external to the FNS) Details of interface (only if determined by the other application)


Operational Requirements

Provide the operational requirements in this section. Operational requirements describe how the system will run and communicate with operations personnel.

Do not state how these requirements will be satisfied. For example, in the Reliability section, answer the question, “How reliable must the system be?” Do not state what steps will be taken to provide reliability. The rules for stating requirements, outlined in Section 4.1, also apply to these requirements.

Distinguish preferences from requirements. Requirements are based on business needs. Preferences are not. If, for example, the user expresses a desire for sub-second response but does not have a business-related reason for needing it, that desire is a preference.

Other applicable requirements on system attributes may be added to the list of subsections below.

Security

The Security Section describes the need to control access to the data. This includes controlling who may view and alter application data. Use the following criteria:

State the consequences of the following breaches of security in the subject application:

Erasure or contamination of application data Disclosure of Government secrets Disclosure of privileged information about individuals

State the type(s) of security required. Include the need for the following as appropriate:

State if there is a need to control access to the facility housing the application.

State the need to control access by class of users. For example, “No user may access any part of this application who does not have at least a (Specified) clearance.”

State the need to control access by data attributes. State, for example,If one group of users may view an attribute but may not update it

whileanother type of user may update or view it.


State the need to control access based on system function. State, for example, if there is a need to grant access to certain system

functionsto one type of users, but not to others. For example, "The system

shall make Function N available to the System Administrator only."

State if there is a need for accreditation of the security measures adopted for this application.

Audit Trail

List the activities that will be recorded in the application’s audit trail. For each activity, list the data to be recorded.

Data Currency

Data currency is a measure of how recent data are. This section answers the question, “When the application responds to a request for data, how current must the data be?” Answer that question for each type of data request.

Reliability

Reliability is the probability that the system will be able to process all work correctly and completely without being aborted. Reliability is evaluated as follows:

State the following in this section:

What damage can result from failure of this system? Complete or partial loss of the ability to perform a mission-

critical Function Loss of revenue Loss of employee productivity What is the minimum acceptable level of reliability?


Recoverability

Recoverability is the ability to restore function and data in the event of a failure. Answer the following questions in this section:

In the event the application is unavailable to users (down) because of a system failure, how soon after the failure is detected must function be restored?

In the event the database is corrupted, to what level of currency must it be restored? For example “The database must be capable of being restored to its condition of no more than 1 hour before the corruption occurred.”

If the processing site (hardware, data, and onsite backup) is destroyed, how soon must the application be able to be restored

System Availability

System availability is the time when the application must be available for use. Required system availability is used in determining when maintenance may be performed.


Traceability Matrix

A Requirements Traceability Matrix enables you to represent the relationships between Business Requirements and Functional Requirements

The matrix will show which items are linked by placing an "x" in the appropriate cell in the matrix. Items that are "orphans" - i.e. not linked to any items in the other view will be marked with light-red background to flag them.

Ensure "coverage" between different types of requirements. For example: Ensure that all "Business Requirements" in a release have one or more "Functional Requirements". Any orphan "Business Requirements" will likely mean that the corresponding "Functional Requirements" were somehow missed.

FR = Functional Requirement

BR = Business Requirement


BR1

BR2 BR3 BR4 BR5 BR6 BR7 BR8

FR1 X FR2 XFR3 XFR4 X X XFR5 X X

Functional Requirement (FRX)

The functional requirements describe the core functionality of the application. This section includes the data and functional process requirements

Requirement Statement

The requirements must be phrased with the definitive word “shall” and have a unique number for reference purposes. Each requirement and its identifier must be in a separated i.e., one “shall” per paragraph.

Data Requirements

Describe the data requirements by providing data entities, their decomposition, and their definitions. The data requirements describe the business data needed by the application system. Data requirements do not describe the physical database and they are not at the level of identifying field names. For this purpose, a data dictionary should be provided, showing data entities, their attributes, and description

Data Field Name Description Field Type Field Length

Validation

Details the Specific validations required for each data field.

Data Field Name Validation

Screen Design

Add screen design’s that will be required for this Functional Requirement

Reference Data

Details specific reference data for fields

Data Field Name Value

Workflow

Detail any workflow requirements including a process diagram

Cube and Reporting

Detail any Cube or Reporting Requirements.

Use Case

Use Case Use case identifier and reference number and modification historyEach use case should have a unique name suggesting its purpose. The name should express what happens when the use case is performed. It is recommended that the name be an active phrase, e.g. “Place Order”. It is convenient to include a reference number to indicate how it relates to other use cases. The name field should also contain the creation and modification history of the use case preceded by the keyword history.

Description Goal to be achieved by use case and sources for requirementEach use case should have a description that describes the main business goals of the use case. The description should list the sources for the requirement, preceded by the keyword sources.

Actors List of actors involved in use case Lists the actors involved in the use case. Optionally, an actor may be indicated as primary or secondary.

Assumptions

Conditions that must be true for use case to terminate successfullyLists all the assumptions necessary for the goal of the use case to be achieved successfully. Each assumption should be stated as in a declarative manner, as a statement that evaluates to true or false. If an assumption is false then it is unspecified what the use case will do. The fewer assumptions that a use case has then the more robust it is. Use case extensions can be used to specify behaviour when an assumption is false.


Steps Interactions between actors and system that are necessary to achieve goalThe sequence of interactions necessary to successfully meet the goal. The interactions between the system and actors are structured into one or more steps which are expressed in natural language. A step has the form <sequence number><interaction>Conditional statements can be used to express alternate paths through the use case. Repetition and concurrency can also be expressed

Variations Any variations in the steps of a use caseFurther detail about a step may be given by listing any variations on the manner or mode in which it may happen.<step reference> < list of variations separated by or>


Document Control

Version Control

Any changes to the design of the Specialty model whilst development is in progress will be managed through version control of this document

Version Date Amended By

Description

1.0 15th March 2010 Stuart Wilks Draft.

SRS Template

Documents

Transcript of SRS Template