Software Requirements Specification


Quick Summary
Format for a Software Requirements Specification (SRS) document for a particular module or subsystem of software.


The template requires a free Member account
Please log in to download the file. Don't have a log in? Register now, it's fast and free!
Log in to download this file

Username:  
Password:  

What this is

One format for a Software Requirements Specification document for a particular module or subsystem of software. Based on an IEEE standard for SRSs, it contains not only sections for software functionality, but also sections for important software attributes and interface definitions. It also contains an overview section that summarizes important items about the software in a way that is especially effective for non-Development project stakeholders.


Why it's useful

Create the SRS after there is a product or system-level requirements document that identifies requirements more from the customer point of view. The SRS contents can then be written systematically against the system-level requirements, to ensure that all necessary elements are covered.

In development of larger more complex systems with multiple software modules making up the system, it is common to create an architecture-level document before creating the SRS. The product/system-level requirements are mapped to elements of the system architecture. I.e., each element of the system architecture is responsible for implementing aspects of the various user-level requirements. Then each software block of the architecture gets its own SRS document, and every requirement mapped to that module in the architecture document must get covered in the SRS. In this way the team methodically ensures that all user-level requirements will be addressed in the various software modules.


How to use it

Use this outline format to document requirements for your software module(s).

  • Create a first draft of the SRS for your software module.
  • Ensure you've addressed each requirement assigned to this module.
  • Review your draft with other technical team members, including developers creating modules that interface with yours. Do this even at the rough draft stage to flush out possible misunderstandings and highlight open interface issues.
  • Be sure to include appropriate non-development reviewers for items such as usability, installation issues, hardware infrastructure implications etc.
  • Update the document based on the reviews and continue to develop the software requirements detail and any accompanying interface protocol definitions.
  • Hold additional reviews as the requirements are fleshed out.
  • The SRS will then become the guiding document for the design of the software module.

The template requires a free Member account
Please log in to download the file. Don't have a log in? Register now, it's fast and free!
Log in to download this file

Username:  
Password:  





Related Templates
Requirements Interview Checklist
A requirements interview is a focused interview with a key stakeholder or subject matter expert designed to elicit a specific set of requirements. This checklist is organized into sets of questions you should consider for each interview; important preparation that will increase your credibility and help you make the most of your time with these key resources.

Requirements Measurement Plan
This template is designed to help you think through how you will ensure that the documented requirements meet the expectations of your stakeholders, both in content and in quality.

Technique Brief - Context Diagrams
Context diagrams are a time-tested method for using simple symbols to illustrate a system's boundaries, benefits, interactions, and data flows. Simple sketches can aid discussions of project features and scope, and detailed graphical interface specifications can improve communication and understanding with non-technical stakeholders.

BURNING QUESTIONHow can I stay on track if they won't let us do requirements work? 
When the conversation with Management is "we don't need to do requirements," we have to start by looking at how Management seems to be thinking of requirements.



©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
888-722-5235
Learn more about ProjectConnections, our contributors, and our membership levels and product options.