Introduction

Software Requirement Specification (SRS) document usually contains a software vendor’s understanding of a customer’s software requirements. This document ensures that the software vendor and the customer are in agreement as to the features required in the software system being built. SRS is created after the initial requirement elicitation phase in which Software vendor interacts with the customer to understand the software needs. Usually SRS documentation is prepared by a business analyst who has some technical background.

An SRS is written in precise, clear and plain language so that it can be reviewed by a business analyst or customer representative with minimal technical expertise. However it also contains analytical models (use case diagrams, entity relationship diagrams, data dictionary etc.) which can be used for the detailed design and the development of the software system. SRS is one of the most critical pieces of software development since it acts as the bridge betweens the software developers and business analysts. An incomplete or incorrect SRS can have disastrous effects on a software project.

In this article I explain the major sections of a typical Software Requirement Specification document. I also provide a generic SRS template which can be customized for your project needs.

What is the need for an SRS document?

Software Requirements Specification is usually the first deliverable for any software project. As they say, first impression is the best impression!, and you should ensure that even the first draft of an SRS is of high quality.

The benefits of a good SRS are,

• A contract between the customer and the software vendor – A good SRS document specifies all the features required in the final system including technical requirements and interface requirements. SRS document is used by the customer to determine whether the software vendor has provided all the features in the delivered software system. To the Software vendor it provides a solid foundation to fix the scope of the software system.

• Enables costing and pricing of the project – A well defined SRS enables software developers to accurately estimate the amount of effort required to build the software product. Function point analysis and SMC are some the techniques adopted for estimating effort.

• Input for detailed design – A good SRS enables experienced developers to convert the requirements directly to a technical design. For example, a well defined data dictionary can be easily converted to a database specification.

• Management of customer expectations – Since SRS precisely defines project scope, it ensures that customer expectations don’t change during software development. If they do, SRS can be modified and costing/pricing can be done again on the changes required.

What are the contents of an effective SRS document?

There is no single precise template for writing good Software Requirement Specifications. The contents of an SRS document depends on the software product being developed and also on the expertise of the people doing the requirement elicitation. Different business/technology domains in a company usually have their own customized version of SRS template. Still a good Software Requirement Specification (SRS) usually contains project scope section, functional requirements, requirement analysis models, external interface requirements and non functional requirements. Each of these are explained below.

Scope of the project/ Product vision

One of the most important items in the requirements specification is the precise scope definition of the project. Accuracy of this is important since SRS is also used for estimation and costing. This section should include a brief overview of the project and should also indicate the goals of the project including its benefits. Sometimes it is better to separate the project scope into a separate document.

If the project is for the development of a product, product vision defines the scope and the target user base of the product.

Functional Requirements

Functional requirements specify the business requirements of the project in detail. Usually business requirements are specified in terms of the actions that user performs on the software system. This is known as the use case model. But not all requirements need to be specified as use cases. Functional requirements should contain a combination of use cases and plain textual description of system features. System features are specified at a higher level and use cases attempt to translate into user actions.

Again there is no fixed format for use case description, but it usually contains the following information,

• Use case diagram – For a small systems, a single diagram can be used to depict all the use cases in the system.

• List of actors and their details – This identifies the various types of users interacting with the software system.

• Use case description – Purpose of the use case and how and when it is invoked by the user. This should also include an identifier for easy reference.

• Preconditions – List of system states/conditions that must be true for the successful execution of the use case. This section is optional and could be easily incorporated into the basic steps section.

• Basic steps – These indicates the various fine grained steps required for the execution of the use case.

• Alternate steps – These indicate alternate events of the use case being described.

• Business validations/rules – These indicates various types of input validations or business rules required in the use case being described.

• Post conditions – Indicates the results of the use case. Please note that this section is optional and could be incorporated into the basic steps section.

To ensure that all the business requirements are addressed in the final software product, a traceability matrix document is used. Traceability matrix tracks each requirement through various phases of software development (detailed design, unit test plans, system testing plans, user acceptance test plans and code components). This requires that every requirement in the SRS should be identifiable by a unique number or tag.

For software projects where majority of features are available as user interfaces, it is better to complement this section with screen prototypes. These user interfaces can change during detailed design, but having a draft version of user interface in the requirements document helps a lot in communicating business requirements. However some customers insist on having finalized user interfaces in the requirements specification document.

Requirement Analysis Models

Once the overall use cases in the system are identified in requirements elicitation, requirement analysis models can be developed to drill down to specifics of each requirement. For example, a use case such as “Add customer” may not specify all the customer details that needs to be captured by the system. This is usually specified in the data dictionary model and also in the screen prototype.

Requirement Analysis models act as the bridge between functional requirements and the detailed design of the software system. For example, Use cases lead to user interface design, data dictionary and entity relationship diagrams are used for designing database schema and class diagrams.

Following are some of the widely used requirement analysis models,

Entity Relationship Diagrams

Entity relationship model diagram (ERD) is a conceptual representation of the data in a software system. During detail design this model is mapped in to the physical database model. There are different diagramming conventions available for creating ER diagrams. Following is a sample ERD in Crow’s foot notation (this is taken from the ERD of a course registration Web application requirements),

This diagram indicates that there is one and only one instructor for a course and an instructor can have one or more courses. The relationship is captured as instructor “teaches” course.

Data Dictionary

Data dictionary in a requirements document is an extension of the entity relationship diagrams. Which ER diagrams specify system entities and their relationships, a data dictionary lists all the attributes pertaining to each of those entities.

In a data dictionary, each attribute of the entity data in system is analyzed in detail including type of attribute, whether it is optional and a brief description of the attribute. Please see the sample SRS template section for more details.

In addition to the above models, sometimes it is useful to develop state transition diagrams and data flow diagrams. To describe a complex process flow or a workflow in the application, process flow diagrams or flowcharts can be used.

External Interface Requirements

It is very rare that we have a standalone software system. Usually a software system interacts with a number of external applications for data input and output. For example, an e-business application usually needs to be integrated to an external payment gateway. All the external interface requirements are detailed in this section. The important thing to document here are the entities that are passed across the external interfaces.

Non Functional Requirements

Non functional or technical requirements specify how the software system should operate. In contrast functional requirements specify what a software system should do. Some of the non functional requirements are derived from the functional requirements. Non functional requirements captured include performance requirements, application scalability, application security, maintainability, usability, availability, logging and auditing, data migration requirements, multi lingual support etc. Please note that only a subset of the list are applicable for a specific project.

Importance of a good SRS template

A good SRS template ensures that all important information required in a Software Requirement Specification is captured during requirement elicitation. Following is the table of contents taken from the SRS template linked below.

Contents of Software Requirements Specification (SRS) Template

Download Sample SRS template

Click here to download a generic software requirement specification template. Please note that this SRS template is written in open office RTF format(A PDF version is available here). Not all sections are mandatory and you can easily customize this template for your project requirements.

• Download SRS template in Open Office format
• Download SRS template in PDF format
• Download SRS template in Microsoft Office format

Further Reading / References

• Crow’s foot notation for ER diagrams

Recommended Books

• Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle. – This is an excellent book on requirements gathering. It also covers all the major requirements modeling techniques. Appendix of this book contains a number of good requirements document samples including vision and scope document, use cases and business rules. Highly recommended.
• Writing Effective Use Cases – This is an excellent book that can help you in mastering the art of writing effective use cases. Written by Alistair Cockburn almost a decade ago this is a must have book for a business analyst. It will help you in steering clear of a lot of mistakes during use case preparation.

Final Thought

Always remember that the primary purpose of an SRS document is to ensure proper communication between people involved in the development of a software product. So the SRS template acts just as a guideline and you can add any additional information that helps this communication.