<Project Name>
Requirements Specification Document
<Project Name>
Requirements Specification Document
Applications Management and Innovations Services
CIO, Industry Canada
235 Queen Street
Ottawa, ON
K1A 0H5
June 27, 2001
12/27/18 1 of 12 <Authors Name>
<Project Name>
Requirements Specification Document
Prepared by:
<Type Individual’s Name here>, <Type Individual’s Title>
ESD Delivery Team
Application Management and Innovations Services
Accepted by:
Type Client Authority’s Name,
Title, Organization & Date here
Revision History
Revision no. / Date of Issue / Author(s) / Brief Description of Change0.1 / June 25, 2001 / J. Smith / 1st draft.
Table of Contents
1 Revision History
2 Table of Contents......
3 Introduction
3.1 System Overview
3.2 Customers
3.3 Reference Documents
3.4 Assumptions
4 System Requirements
4.1 Functional Requirements
4.2 Interface Requirements
4.3 Performance Requirements
4.4 Qualification Requirements
5 Requirements Testing Criteria
6 Glossary
3 Introduction
3.1 System Overview
<This section will give a high level description of what the new system will be.>
3.2 Customers
<This section will list the customers targeted for this system>
3.3 Reference Documents
<This section will include a reference to all documents and papers used in the analysis to create this document.>
<Please note that if a Requirement for Proposal was issued prior to the start of this requirements specification, the RFP must be used as a reference as well as provide input to generate this specification.>
3.4 Assumptions
<This section will enumerate things we assume will be true for the system>
4 System Requirements
<This section will contain the list of requirements identified during the analysis. Each requirement will represent one unambiguous, testable and verifiable statement, for example “the system shall calculate interest rates on a daily basis”. Requirements that cannot be measured or tested will be rejected, for example “the system shall respond in acceptable time limits”, this statement is ambiguous and should be rejected.>
Requirements for <insert system name> will be divided into four categories:
•Functional Requirements;
•Interface Requirements;
•Performance Requirements; and
•Qualification Requirements;
After the requirements are categorized, each requirement will then be assigned a testing requirement criterion.
4.1 Functional Requirements
< This section will enumerate functional requirements, those are requirements that will apply to the specific “function” (including security functions) of the system, such as the “entry screen will accept on authorized users”.>
The Functional Requirements table will contain the following:
Req #:Unique identifier of the requirement (i.e. no 2 requirements will be assigned the same number).
Requirement:One unique unambiguous sentence representing the requirement
Description:Description of the requirement
Example of Functional Requirements table:
Req. # / Requirement / Description1 / The system shall calculate interest on a daily basis / For a loan given to a producer, the system will calculate interest daily based on the prime rate of +1.
2 / Log all employee name changes / The system will write an entry to the audit log file after any modification of an employee name.
4.2 Interface Requirements
<This section will enumerate Interface requirements, those are requirements that affect/interact with systems external to this system, for example “For each new employee in the ABC system a new record will be created in the XYZ system”. These requirements may be manual or automated (this must be specified in the Description section of the Interface Requirements table).>
The Interface Requirements table will contain the following:
Req #:Unique identifier of the requirement. If this requirement is also identified in the Functional Requirements table, use the same identifier, same requirement name, however the description may include more details, regarding the interface.
Requirement:One unique unambiguous sentence representing the requirement.
Description:Description of the requirement
External System(s):External system name that the requirement interfaces with.
Example of Interface Requirements table:
Req. # / Requirement / Description / External System20 / The system shall record an acknowledgment when a new employee is created into the XYZ table / The XYZ system uses these records to update the time stamp of an employee record. / XYZ - security system
2 / The system will mail the month-end report message to the “Director” at each month-end. / This e-mail is used to manually load data into the Director system. / Director system
4.3 Performance Requirements
<This section will enumerate the Performance requirements; those are measurable requirements that usually encompass a series of unique requirements. For example, all edits to the ABC table will take no longer than 3 seconds.>
The Performance Requirements table will contain the following:
Req. #:Unique identifier of the performance requirement
Performance
Requirement:One unique unambiguous sentence representing the performance requirement.
Description:Description of the requirement, this should include the logistic shy the specific performance is required
Affected
Requirements:The list of requirements affected by the performance demands
Example of Performance Requirements table:
Req. # / Performance Requirement / Description / Affected Req #31 / The system shall perform simple queries (e.g. no more than 2 tables) in less than 10 seconds / This speed is required to ensure better service to the public requesting information on the XYZ system. / 1 & 12
32 / Month-end runs will take no longer than 24 hours / Weekly backups are performed every Sunday at 6:00 a.m.; if the month-end process takes too long, it will affect the operations of AAFC. / 12
4.4 Qualification Requirements
<This section will enumerate the Qualification requirements; those are subjective requirements that usually encompass a series of unique requirements. For example, the system shall be user friendly. This type of requirement is usually tested by the system owner.>
The Qualification Requirements table will contain the following:
Req. #:Unique identifier of the qualification requirement
Qualification
Requirement:One unique unambiguous sentence representing the qualification requirement.
Description:Description of the interpretation of this requirement.
Affected
Requirements:The list of requirements affected.
Example of Qualification Requirements table:
Req. # / Qualification Requirement / Description / Affected Req #43 / The system shall be user friendly / The system shall be used by non-technical users, thus must be simple and easy to use. / All except for batch processing (REQ #6,7,8) and system maintenance function (REQ #13)
35 / The system requires little training / Help menus shall be available for all on-line query screens. / 12
5 Requirements Testing Criteria
<This section shall describe for each use case requirement, the method used to acceptance test the identified requirements. The following represents the type of testing required to accept the requirement>
Demonstration:Demonstrate the operation of the function to the system owner to show that the requirement has been met.
Inspection:Sometimes used in combination with demonstration, it requires visual examination of the code documentation, table dumps, scans, etc.
Analysis/Special
Qualification:The processing of accumulated data obtained from other methods, or any special tools, techniques, procedures, facilities, and acceptable limits. This type of testing usually affects critical parts of the system and/or interfaces.
Example of Requirements Testing Criteria table:
Functional Requirement / Testing RequirementThe system shall be user friendly / Demonstration
Month-end runs will take no longer than 24 hours / Inspection
Transfer of data shall be at a rate of 9600 baud / Analysis
6 Glossary
<Definition of all relevant terms; explored in subsequent sections>
Term / Definition12/27/18 1 of 12 <Authors Name>