Software Requirement Specification 1

SOFTWARE
REQUIREMENTS SPECIFICATION
[Name of Mentor College & Sponsor]

[Name of Project]
REVISION NO. : [1] COMPLETION DATE: [Date]
Approver Name(Guide) Signature Planned Date Completion Date

[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]
Contents
Section 1. Overview............................................................................................ 1
1.1 Purpose.............................................................................................. 1
1.2 Business Context...............................................................................1
1.3 Scope................................................................................................. 1
1.4 User Characteristics...........................................................................1
Section 2. Assumptions, Dependencies, and Constraints...................................2

2.1 Assumptions......................................................................................2
2.2 Dependencies....................................................................................2
2.3 Constraints......................................................................................... 2
Section 3. Requirements.....................................................................................3
3.1 Business Requirements.....................................................................3
3.2 Functional Requirements...................................................................3
3.3 Logical Data Requirements................................................................4
3.4 User Requirements............................................................................4
3.5 Information Management Requirements............................................4
3.6 Systems Requirements......................................................................4
3.7 Interfaces........................................................................................... 5
3.8 Other Requirements...........................................................................5
Section 4. Requirements Traceability Matrix.......................................................6
Section 5. Risk analysis......................................................................................6
Section 6. System Design...................................................................................6
Section 7. User Acceptance Testing...................................................................6
Section 8. References......................................................................................... 7
Section 9. Glossary...........................................................................................11
Section 10. Revision History...............................................................................12
Section 11. Appendices......................................................................................13
Page i
Section 1. Overview
1.1 Purpose
Specify the purpose of this Software Requirements Specification (SRS) and its intended
audience.
1.2 Business Context
Provide an overview of the business organization sponsoring the development of the software
application, including the mission statement and organizational objectives of the business unit.
1.3 Scope
Describe the scope of the software application to be produced.
1.4 User Characteristics
Identify each type of user of the software by function, location, and type of device. Specify the
number of users in each group and the nature of their use of the software.
Page 1
Section 2. Assumptions, Dependencies, Constraints

2.1 Assumptions
Describe the assumptions that can affect the requirements specified in this SRS.
2.2 Dependencies
Describe the dependencies that can affect the requirements specified in this SRS.
2.3 Constraints
Describe the constraints that can affect the requirements specified in this SRS.
Page 2
Section 3. Requirements
“All requirements should be designed in Rational RequisitPro software”
3.1 Business Requirements
Describe all business/project requirements for the software.
3.2 Functional Requirements
Customize this subfunction to contain the subfunctions necessary to comprehensively define the
fundamental actions that must take place within the software to accept and process the inputs
and to process and generate the outputs.
Subfunction templates for each of the means of specifying functional requirements are provided
below.
3.2.xf Function X
When functional decomposition is used as the means of specifying the functional requirements
provide a 3.2.xf subfunction for each function. Each 3.2.xf subfunction should be labeled and
titled appropriately for a specific function, where xf is the appropriate sequential subfunction
number and X is the name of the specific function.
3.2.xf.1 Function X Purpose
Describe the intent of the function.
3.2.xf.2 Function X Inputs
Describe the inputs to the function.
3.2.xf.3 Function X Operations
Describe the operations to be performed within the function.
3.2.xf.4 Function X Outputs
Describe the outputs from the function.
Page 3
3.2.xu Use Case Y
When use cases are used as the means of specifying the functional requirements, provide a
3.2.xu subfunction for each use case. Each 3.2.xu subfunction should be labeled and titled
appropriately for a specific use case, where xu is the appropriate sequential subfunction number
and Y is the name of the specific use case.
Within each use case subfunction, specify the use case information, including the actor, pre-
conditions, post-conditions, scenarios, and alternate scenarios.
3.3 Logical Data Requirements
Describe the logical data requirements for the software/Project.
3.4 User Requirements
Describe the user requirements for the software//Project.
3.5 Information Management Requirements
Describe the information management requirements for the software/Project.
3.6 Systems Requirements
3.6.1 Performance Requirements
Describe the performance conditions and their associated capabilities. Expected outcome you will
be judging on the basis of which factors.
3.6.2 Quality Requirements
Describe requirements for the quality characteristics of the software.
Page 4
3.7 Interfaces
Describe the logical characteristics of each interface between the application and other hardware,
software, and communication protocols.
3.8 Other Requirements
Identify any other requirements that do not fit appropriately into the preceding requirement
sections.
Page 5
Section 4. Requirements Traceability Matrix

Traceability matrix is a document defines mapping between customer requirements and prepared
test cases. By preparing Traceability matrix we can ensure that we have covered all
functionalities in our test cases.
This document you have to prepare while writing the test cases. And show to the respective
guides in the further revisions.
Steps:
1. Create a template. There are many on the web from which to choose. The project Guide,
Sponsor and Decision makers will thank you when they are receiving information in a
consistent and logical format.
2. Transfer data from your Project Requirements Catalog. You will need, at bare minimum, the
exact requirement identified.
3. Identify the requirement with a unique ID. The project requirements document should have
already assigned an identifier that you will use in this matrix. If not, you will create one now
and insert it next to the applicable requirement.
4. Copy the Use Case ID into the traceability matrix. You may or may not have used use cases
to develop your requirements. If you did, you will have an identifier on your use case. You
must transfer the ID to this matrix in order to see out of what data or scenario this
requirement was born.
5. Insert the System Requirements Specification (SRS) ID into the traceability matrix. You might
not be the actual author of the SRS, but there must be a line on the matrix to trace the project
requirement to the corresponding system requirement needed.
6. Insert the testing data into the traceability matrix. There are many different testing methods
and procedures that can be used in any project. The traceability matrix must account for the
types of tests used in this project. This should clearly indicate the specific test type, the date
tested and the outcome of pass/fail.
7. Review your data. Your matrix should now clearly show the specific deliverable requirements
from conception clearly through testing. This will ensure that nothing gets moved into project
haphazardly and when asked, the students now have this information at the ready.
 For Reference:
Req. Req. Statement S/W Test Spec. Test Verification Mod. Field
Spec. module Case #
No.
RS.1 Standards to Third party NA NA Partially WSSecurity

be used software verified may be
include (SOAP replaced
WSDL, and
Page 6
SOAP, WSIL, WSDL

and Security currently
used)
Page 7
Section 5. Risk Analysis
Prepare a document for no of risks that may arise in the project
Page 8
Section 6. System Design

Provide System Architecture and All UML diagrams drawn with the help of Rational Rose
Software.
Expected UML diagrams are,
1. Architectural Diagram.
2. Use Case Diagram.
Page 9
Section 7. User Acceptance Testing.
The project acceptance test plan must be prepared which meets the system requirements.
Page 10
Section 8. References
Provide a list of all documents and other sources of information referenced in the SRS and
utilized in developing the SRS. Include for each the document number, title, date, and author.
Document No. Document Title Date Author
Page 11
Section 9. Glossary
Define of all terms and acronyms required to interpret the SRS properly.
Page 12
Section 10.Revision History

Identify changes to the SRS.
Version Date Name Description
Page 13
Section 11.Appendices
Include any relevant appendices.
Page 14

Software Requirement Specification 1

Uploaded by

Software Requirement Specification 1

Uploaded by

SOFTWARE

[Name of Mentor College & Sponsor]

Approver Name(Guide) Signature Planned Date Completion Date

Section 2. Assumptions, Dependencies, and Constraints...................................2

Section 4. Requirements Traceability Matrix.......................................................6

Section 5. Risk analysis......................................................................................6

Section 6. System Design...................................................................................6

Section 7. User Acceptance Testing...................................................................6

Section 10. Revision History...............................................................................12

Section 11. Appendices......................................................................................13

1.2 Business Context

Describe the scope of the software application to be produced.

1.4 User Characteristics

Section 2. Assumptions, Dependencies, Constraints

3.1 Business Requirements

Describe all business/project requirements for the software.

3.2 Functional Requirements

3.2.xf.1 Function X Purpose

Describe the intent of the function.

3.2.xf.2 Function X Inputs

Describe the inputs to the function.

3.2.xf.3 Function X Operations

Describe the operations to be performed within the function.

3.2.xf.4 Function X Outputs

Describe the outputs from the function.

3.2.xu Use Case Y

3.3 Logical Data Requirements

Describe the logical data requirements for the software/Project.

3.4 User Requirements

Describe the user requirements for the software//Project.

3.5 Information Management Requirements

Describe the information management requirements for the software/Project.

3.6 Systems Requirements

3.6.1 Performance Requirements

3.6.2 Quality Requirements

Describe requirements for the quality characteristics of the software.

3.8 Other Requirements

Section 4. Requirements Traceability Matrix

RS.1 Standards to Third party NA NA Partially WSSecurity

SOAP, WSIL, WSDL

Section 5. Risk Analysis

Prepare a document for no of risks that may arise in the project

Section 6. System Design

Expected UML diagrams are,

2. Use Case Diagram.

Section 7. User Acceptance Testing.

Document No. Document Title Date Author

Section 10.Revision History

Version Date Name Description

You might also like