Sie sind auf Seite 1von 15

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, 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........................................................................................7

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

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

Section 7. User Acceptance Testing.....................................................................9

The project acceptance test plan must be prepared which meets the system requirements....9

Section 8. References.........................................................................................10

Section 9. Glossary.............................................................................................11

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

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

Page i
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

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
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

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
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

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
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

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
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

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
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

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
SOAP, WSIL, WSDL
and Security currently
used)

Page 6
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

Section 5. Risk Analysis

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

Page 7
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

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 8
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

Section 7. User Acceptance Testing.

The project acceptance test plan must be prepared which meets the system requirements.

Page 9
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

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 10
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

Section 9. Glossary
Define of all terms and acronyms required to interpret the SRS properly.

Page 11
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

Section 10.Revision History


Identify changes to the SRS.

Version Date Name Description

Page 12
[College/Sponsor Name] SOFTWARE REQUIREMENTS SPECIFICATION
[Project Name] [Version Number] | [Revision Date]

Section 11.Appendices
Include any relevant appendices.

Page 13

Das könnte Ihnen auch gefallen