Software Product Requirements Document – Table of Contents

July 10, 2007 in Information Systems, Software Development

Most requirements are written in isolation from the data from the market. But that is not always a good practice. Here is the Table of Contents of a typical software product requirements document where the market data is not neglected. Accompanying is an explanation of each head.

1 Table of Contents

This contains the table of contents

2 Purpose

This section enumerates the purpose of the application. It also points out, with as much clarity as possible, the people who will benefit from this application and how they will benefit from the same. This section is a short description of the environment, the intended users etc. In this section the service provided by the application under question will be enumerated. Whether the application will face competition in the market from similar services or from any other service will also be noted here. In this context, how the competition may be over come can be briefly described.

3 Part I

This deals only with the non-technical details of the project on which the technical details will be built.

3.1 Application Overview

Describes elementary details of the application under question. For example, weather, it is a web application or a static website or a windows application etc. If required, the problem (i.e. the business opportunity) in current context should be explained. This will help the development team keep their focus, decide which features are important and which are not. Secondly, it also help as the common ground between the development team, the marketers and the customers. This section will direct all parties involved throughout the lifetime of the project. This section also contains who the users are going to be and what are the deliverables.

3.2 Business Process

This section describes how the business process works in absence of this application. It is recommended this is written in collaboration with a user who is going to use the application in future. Detail in this section will help the developers capture the requirements completely. Consider the product under question is a mail application. Gmail for example. The business process under question is about “How written communication happens?” People buy paper, buy pens, buy stamps, buy envelopes, they have a table and a chair to sit and write. And they start writing. After they are done, they get gum. They enclose the letter, stick the stamps to the envelop, walk to the post box and drop it. This is the description of the business process called Written Communication. However, a mail application may also face competition from other mode of communication as well. Telephones for example! This could be noted as well.

3.3 Software Process

This section describes how the same business process will work in presence of the application. It will describe briefly how the application integrates in the business environment enumerating the advantages it will bring about in each step. For example most mail applications perform at least these two functions: 1. serve as a mail box and 2. a contact details list. The mail box brings about fast and inexpensive written communication and the contact details facilitates a mobile and weightless address book. So decreased costs, faster communication and data mobility are the advantages of a mail application. Such advantages need to be noted here. If the system interacts with other systems that will also be noted here. It is recommended this section is further broken down into smaller parts, each part describing a small part of the application under question.

3.4 System Requirements

This section will write down the minimum things the user needs to have in order to own this application. Gmail for example needs, a computer, a live internet connection and a Google account.

4 Part II

This part contains the technical details about how the application will be divided into separate parts and how it will be implemented. It is recommended that a few mock screen shots and a few system design concepts be described in some detail. However, it is important to to note that the development team may (and perhaps will) change the design expressed in this part. The intention behind these technical description is just to aid the understanding the developers. A mail application for example, can show a few screen shots of the mail box, or the address book, or the database tables it is going to use in the same. It may also want to enumerate a few encryption technologies if it feels that they are important.

5 Appendix

If there is anything you want to refer, put here.