Requirements Document Template (upedu)
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Requirements Document Template (upedu) as PDF for free.
More details
- Words: 906
- Pages: 6
Note: This template is largely based on the template provided by the Unified Process for Education (www.yoopeedoo.com) with minor modifications.
Team:
Version <1.0> [Note: The following template is provided for use with the Unified Process for EDUcation. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).] [To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]
Version: <1.0> Date:
<document identifier>
Revision History Date
Confidential
Version <x.x>
Description <details>
, 2008
Author
Page 2
Version: <1.0> Date:
<document identifier>
Table of Contents 1. Document Overview 1.1 Purpose 1.2 Document Conventions 1.3 Team Contact information 1.4 References
4 4 4 4 4
2. Project Mission Statement 2.1 Project Introduction 2.2 Product Vision and Scope 2.3 Stakeholders 2.4 Assumptions and Constraints 2.5 Business Requirements
4 4 4 4 4 4
3. Requirements 3.1 Functionality 3.1.1 3.2 Non-functional Requirements 3.3 Performance Requirements 3.4 Security Requirements 3.5 Software Quality Attributes 3.6 Supplementary Requirements
5 5
4. Classification of Functional Requirements
6
5. Appendixes
6
Appendix A: Project Glossary
6
Confidential
, 2008
5 5 5 5 5 5
Page 3
Version: <1.0> Date:
<document identifier>
1.Document Overview 1.1Purpose [The introduction of the Software Requirements Specification (SRS) provides an overview of the entire SRS. It should describe the purpose of the document, what the document contains, and the organization of your document. ] 1.2Document Conventions [Describe standards or formatting conventions that have particular meaning. For example, bold and italicized words are technical terms whose definition can be found in an included glossary.] 1.3Team Contact information 1.4References [If you used any resources to define technical terms in a glossary or to do any other research related to your project, list them here with a brief description of their use (and a proper citation!)]
2.Project Mission Statement 2.1Project Introduction [Give background information about the target product and the motivation for its development. See the text for details on the content of a Project Mission Statement Introduction.] 2.2Product Vision and Scope [Description of the product’s purpose and form, and the limitations (scope) of the project.] 2.3Stakeholders [Description of the people that are affected by the project or product.] 2.4Assumptions and Constraints [State the assumptions and constraints for this project.
For constraints, list and discuss issues that will limit the options available to the developers. For example, you may be required to use certain hardware, programming languages, database software, or software modeling tools 2.5Business Requirements [Client or organization goals should be stated here.]
Confidential
, 2008
Page 4
Version: <1.0> Date:
<document identifier>
3.Requirements [This section of the SRS contains all software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.] 3.1Functionality [This section describes the functional requirements of the system for those requirements that are expressed in the natural language style. For many applications, this may constitute the bulk of the SRS package and thought should be given to the organization of this section. This section is typically organized by feature, but alternative organization methods may also be appropriate; for example, organization by user. The set of requirements should be complete, and each requirement should meet the characteristics outlined in the Requirements Inspection Checklist on pg. 141 in the text] 3.1.1 [A requirement statement.] 3.2Non-functional Requirements 3.3Performance Requirements [State performance requirements here (if any). For each requirement, you should identify if it is a requirement over the entire system or a particular product feature. If there are no performance requirements, just write “None” in this section.] 3.4Security Requirements [State security requirements here (if any). Indentify authentication and privacy requirements. These may be relevant to the product because it enhances a desired product feature or legal reasons. If there are no security requirements, just write “None” in this section.] 3.5Software Quality Attributes [State software quality attribute requirements here. This includes characteristics such as maintainability, availability, etc.]
3.6Supplementary Requirements [Supplementary Specifications capture requirements that are not included in the functional and nonfunctional requirements. If there are no supplementary requirements, you can either remove this section or write “None” in this section.]
Confidential
, 2008
Page 5
Version: <1.0> Date:
<document identifier>
4.Classification of Functional Requirements [List, usually in a table, all functional requirements and order them by priority (Essential, Desirable, and Optional) or by order of appearance in the document.]
Functional Requirement
Priority
... ...
5.Appendixes [When appendices are included, the SRS should explicitly state whether or not the appendices are to be considered part of the requirements]
Appendix A: Project Glossary
Confidential
, 2008
Page 6
Team
Version <1.0> [Note: The following template is provided for use with the Unified Process for EDUcation. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).] [To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]
Version: <1.0> Date:
<document identifier>
Revision History Date
Confidential
Version <x.x>
Description <details>
Author
Page 2
Version: <1.0> Date:
<document identifier>
Table of Contents 1. Document Overview 1.1 Purpose 1.2 Document Conventions 1.3 Team Contact information 1.4 References
4 4 4 4 4
2. Project Mission Statement 2.1 Project Introduction 2.2 Product Vision and Scope 2.3 Stakeholders 2.4 Assumptions and Constraints 2.5 Business Requirements
4 4 4 4 4 4
3. Requirements 3.1 Functionality 3.1.1
5 5
4. Classification of Functional Requirements
6
5. Appendixes
6
Appendix A: Project Glossary
6
Confidential
5 5 5 5 5 5
Page 3
Version: <1.0> Date:
<document identifier>
1.Document Overview 1.1Purpose [The introduction of the Software Requirements Specification (SRS) provides an overview of the entire SRS. It should describe the purpose of the document, what the document contains, and the organization of your document. ] 1.2Document Conventions [Describe standards or formatting conventions that have particular meaning. For example, bold and italicized words are technical terms whose definition can be found in an included glossary.] 1.3Team Contact information 1.4References [If you used any resources to define technical terms in a glossary or to do any other research related to your project, list them here with a brief description of their use (and a proper citation!)]
2.Project Mission Statement 2.1Project Introduction [Give background information about the target product and the motivation for its development. See the text for details on the content of a Project Mission Statement Introduction.] 2.2Product Vision and Scope [Description of the product’s purpose and form, and the limitations (scope) of the project.] 2.3Stakeholders [Description of the people that are affected by the project or product.] 2.4Assumptions and Constraints [State the assumptions and constraints for this project.
For constraints, list and discuss issues that will limit the options available to the developers. For example, you may be required to use certain hardware, programming languages, database software, or software modeling tools 2.5Business Requirements [Client or organization goals should be stated here.]
Confidential
Page 4
Version: <1.0> Date:
<document identifier>
3.Requirements [This section of the SRS contains all software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.] 3.1Functionality [This section describes the functional requirements of the system for those requirements that are expressed in the natural language style. For many applications, this may constitute the bulk of the SRS package and thought should be given to the organization of this section. This section is typically organized by feature, but alternative organization methods may also be appropriate; for example, organization by user. The set of requirements should be complete, and each requirement should meet the characteristics outlined in the Requirements Inspection Checklist on pg. 141 in the text] 3.1.1
3.6Supplementary Requirements [Supplementary Specifications capture requirements that are not included in the functional and nonfunctional requirements. If there are no supplementary requirements, you can either remove this section or write “None” in this section.]
Confidential
Page 5
Version: <1.0> Date:
<document identifier>
4.Classification of Functional Requirements [List, usually in a table, all functional requirements and order them by priority (Essential, Desirable, and Optional) or by order of appearance in the document.]
Functional Requirement
Priority
... ...
5.Appendixes [When appendices are included, the SRS should explicitly state whether or not the appendices are to be considered part of the requirements]
Appendix A: Project Glossary
Confidential
Page 6
Related Documents
Requirements Document Template (upedu)
October 2019 10
Business Requirements Template
October 2019 13
507294 Business Requirements Template
June 2020 5
Software Requirements Specification Template
November 2019 23
