Download this free Requirement Specification Document template and use it for your new project. Scroll down to the bottom of the page for the download link.
1 Introduction
1.1 Purpose
<This section shall identify the overall purpose of this document and its intended audience.>
1.2 Scope
<This section shall identify the scope of this document.>
1.3 Definitions, Acronyms, and Abbreviations
<This section shall describe any acronyms used in this document. >
1.4 References
<This section shall identify the documents related to the products that already exist.>
1.5 Standards
<This section shall identify all internal and external standards that will be adhered to in the development of the system. This will also identify those external standards that have been specified by the customer. In case there are corresponding internal standards, this section shall outline the reasons for not using the internal standards.>
2 Background
2.1 Project Drivers
<This section captures the project information in the following sub-sections.>
2.1.1 Problem Statement
| The problem of | (describe the problem) |
| affects | (The stakeholders affected by the problem). |
| The impact of which is | (What is the impact of the problem). |
| A successful solution would | (List some key benefits of a successful solution). |
Table 1 : Problem Statement
2.1.2 Product Position Statement
| For | (who will use the product/system) |
| Who | (describe the benefits from the product/system) |
| (The system/product’s name) | (Is it software, hardware, system, application product?) |
| That | (Scope and goal of the product) |
| Unlike | (Limitation of the current product) |
| Our product | (Strengths of the product, what can be done) |
Table 2: Product Position Statement
2.1.3 Stakeholders
<Describes each stakeholder (non-user) in the system here by filling in the following table. Stakeholder can be fund provider, product owner and ministry.>
| Representative | Who is the stakeholder representative to the project (optional – if documented elsewhere). What we want here is names and role. |
| Description | Brief description of the stakeholder type |
| Type | Qualify the expertise of the stakeholder i.e. GURU, BUSINESS EXPERT, CASUAL USER etc i.e. technical background and degree of sophistication |
| Responsibilities | List the key responsibilities of the stakeholder with regards to the system being developed (i.e. their interest as a stakeholder). |
| Success Criteria | How does the stakeholder define success? How is the stakeholder rewarded? |
| Involvement | How the stakeholder is involved in the project – (i.e. Requirements Reviewer etc.) |
| Deliverables | Any additional deliverables required by the stakeholder. These could be project deliverables or output from the system under development. |
| Comments / Issues | Problems that interfere with success and any other relevant information |
2.1.4 User Profiles
<Describes each user (who will use the system) by filling in the following table. It can be an end-user.>
| Representative | Who is the user representative to the project (optional – if documented else where). This often refers to the Stakeholder that represents the set of users (i.e. Stakeholder: Stakeholder1). |
| Description | Brief description of the user type |
| Type | Qualify the expertise of the user i.e. GURU, CASUAL USER etc i.e. Technical background and degree of sophistication |
| Responsibilities | List the key responsibilities of the user with respect to the system (i.e. captures customer details, produces reports, co-ordinates work). |
| Success Criteria | How does the user define success? How is the user rewarded? |
| Involvement | How the user is involved in the project – relate where possible to RUP workers (i.e. Requirements Reviewer etc.) |
| Deliverables | Deliverables the user produces, and for whom.. |
| Comments / Issues | Problems that interfere with success and any other relevant information. Trends that make the user’s job easier or harder |
Table 4: User profiles
2.2 Product Information
<This section captures product information in the following sub-sections.>
2.2.1 Product viewpoints
<Describe the following;
- User Point of View
- Function Point of View
- Data Point of View
- Deployment Point of View>
2.2.2 Product modes and states
<This section describes current scope of work and future product roadmap.>
2.2.3 Major product constraints
<This could include cost and implementation constraints like platforms, interfaces, technologies to be used etc, desired by the customer.>
2.2.4 Usage Models
<This information is derived, by talking to the users of the system and understanding their usage patterns of this product.>
< Activity Flow Chart>
3 System Architecture
<This section shall give the system architecture in the form of a block diagram, in the context of the larger system and/or related products. Multiple diagrams can be made use of to provide clarity. In the situation where an enhancement of the product is envisaged, the portion of enhancements should be identified within the overall architecture.>
<The diagram should be accompanied by a brief note on the architecture emphasizing the salient points and explaining the product in the context of the overall system architecture.>
4 System Requirements
<This section gives functional requirements of the system.
Each requirement shall be uniquely named using an identifier. This unique identifier shall become part of the traceability matrix and will be used in all cross-referencing. The following are to be kept in mind while documenting a requirement. >
<Is the requirement stated in an unambiguous way? (If there is more than one interpretation possible, then the statement is ambiguous).>
<Is the requirement testable? Can one come up with a test to show whether the requirement is met or not >
<The prescribed format for specifying a requirement is to identify the inputs to the functional requirement, the processing that is supposed to take place and the outputs from the requirement. In the case of requirements that are not amenable to the above encapsulation, a different methodology can be used. The rationale and usage should be described briefly here. This section shall also identify special considerations. >
4.1 Technology Requirements
<This section shall identify all technology requirements including Standards compliance. >
4.2 Functional Requirements
<This section shall identify all Functional requirements. List of functional features>
4.3 Startup requirements
<This section shall identify all startup requirements including reading from Persistence storage>
4.4 Shutdown requirements
<This section shall identify all shutdown requirements including writing to Persistence storage.>
4.5 Interface Requirements
<This section shall identify interfaces to other components & definition of interface formats>
4.6 Portability Requirements
<This section shall identify whether this product is to be ported to different platforms, now or later. Knowledge of the details of the other platforms may influence the design of the product.>
4.7 Performance Requirements
<This section shall identify all performance requirements including Response-time, Throughput, Recovery-time, Startup-time, Shutdown-time requirements & Space / Size constraints.>
4.8 Reliability Requirements
<This section shall identify all Reliability requirements including Accuracy, Availability & Recoverability requirements.>
4.9 Supportability Requirements
<This section shall identify Adaptability, Compatibility, Installability, Maintainability, Configurability, Scalability, Testability requirements.>
4.10 Implementation Requirement
<This section shall identify Third-party components, Licensing of Third party components, Implementation languages, Platform support, Resource limits, Standards Compliance requirements.>
4.11 Operational Environment related Requirements
<This section shall identify all Operational Environment requirements including Target platform details & Operational Scenarios.>
4.12 Usability Requirements
<This section shall identify all Usability requirements including Accessibility, Aesthetics, & Consistency.>
4.13 Security Requirements
<This section shall identify all Security requirements including Security algorithm to be used & Authentication mechanism.>
4.14 Quality requirements
<This section shall identify the requirements of the customer for a defined ‘Quality Requirement’ for example six sigma.>
4.15 Trace requirements
<This section shall identify all trace related requirements including debug logging, error logging & operator activity logging requirements.>
4.16 Configuration requirements
<This section shall identify all Configuration requirements. >
4.17 Error handling requirements
<This section shall identify all error handling requirements. >
4.18 Localization requirements
<This section shall identify requirements related to supporting different languages (Ex: English, French, Spanish, Chinese…) >
4.19 On-line Help requirements
<This section shall identify all On-line Help requirements. >
4.20 Reporting requirements
<This section shall identify all report generation related requirements. >
4.21 Assumptions
<List all the assumptions made in this section.>
5 Detail Requirements
<Use Case Summary Report, in the brief description of the use case, cover inputs, processing, outputs and special consideration.>
<The following table can be use to describe each features>
| Name | (Name of use case) |
| Brief Description | (brief description on the use case) |
| Relationships with actor | (relationships between actor and use case) |
| Inputs | (Identify all inputs for this use case. The following attributes shall be identified;) Unique identifier for input Description on the input Type of input (input characteristics) Range of input values, enumerated or otherwise Source of input |
| Processing | Detailed descriptions of what processing or any validation is expecting to be done for this use case. |
| Outputs | (Identify all outputs for this use case. The following attributes shall be identified;) Unique identifier for output Description on the output Type of output (output characteristics) Format of output (if applicable) Components of output (if applicable) Range of input values, enumerated or otherwise |
| Special Requirements | (Any consideration for the use case) |
6 Development Environment Requirements
6.1 Hardware requirements
<This section shall identify the hardware platform requirements for the project. The complete configuration details listed below shall be documented:
- Computing Power
- Memory
- Disk Storage
- Peripherals
- Network>
6.2 Software requirements
<This section shall identify the software platform requirements. All details listed below shall be documented:
- Operating system environment
- Networking environment
- Tools (compilers, libraries, debuggers etc.)>
6.3 Deviations
<This section shall identify any anticipated deviations from the development platform requirements.>
7 Target Environment Requirements
<This section shall identify the hardware and software requirements for the target environment. In case the target platform is the same as the development platform, then this section shall just mention so.>
8 Additional Development Considerations
8.1 Customer participation requirements
<This section shall identify all situations where the customer is part of the development process. This is likely in joint development projects. This would include participation in Beta and Acceptance testing and also in periodic reviews, etc.>
8.2 Communication Requirements
<In the case of joint development projects, and may in certain other cases too, extensive communication on a routine basis may be essential for effective development. This section shall identify all the communication requirements including periodic telephonic conference calls, distributed databases, document transfers for reviews, and so on.>
8.3 Infrastructure Requirements
<This section shall identify any other infrastructure requirement that will be necessary for the successful completion of the product. Typical examples include satellite link facility of required speed, electronic mail and so on.>
9 Post Development Requirements
9.1 Training Requirements
<This section shall identify the training requirements of the customer, including details like target audience, site of training, scope of training, training material needs and so on>
9.2 Technology Transfer Requirements
<In case the product needs to be delivered completely to the customer, there may be a need for technology transfer and associated training needs. This section shall identify all such needs.>
9.3 Maintenance Requirements
<This section shall identify all the maintenance requirements for the product released. The mechanism for problem reporting, the contact person details etc. should be presented in this section.>
Click here to download Requirement Specification Document Template.
