How to Write a Software Requirements Specifications (SRS) Document
Professional software developers must go through a software requirements gathering process at the beginning of software development projects of any meaningful size. The end product of that project phase is a document commonly referred to as a Software Requirements Specification, or SRS. It's usually the first project milestone or deliverable. The importance of this document cannot be understated. Its foremost function is to record the client's business needs and requirements in written form and become the foundation for the rest of the software development process. Once these requirements are compiled, the document becomes the record of both the client's and developer's understanding of what the software should accomplish. Usually the client reviews and signs the SRS, thus beginning the full software design and development phase. By taking the high level steps involved, you can write an SRS document.
Things You'll Need
- Word processing application
- Diagramming software such as Microsoft Visio
If your organization does not have a standard Software Requirements Specifications document template, create one now (see Resources for links to templates).
Meet with the subject matter experts/clients to gather the requirements.
Define the functions of the software.
Create use cases for the major sub-processes. For example, if you're designing an order entry system, use cases would consist of creating a new order, modifying an existing order and a customer order search.
Define the user interface.
Define any other interfaces such as hardware interfaces or other software system interfaces.
Define the process flow.
Determine any specific business rules.
Define the performance specification.
Create any diagrams needed to illustrate the process flow or elaborate on key requirements.
Compile the SRS document and have all necessary parties review or sign it.
Tips & Warnings
- Create a standard document template.
- Include a traceability matrix.
- Include a linkage between requirements and the source of those requirements.
- Clearly list defined business operation rules.
- Ensure the rules and processes are defined with precise, unambiguous language.
- The SRS only contains functional requirements. No software design or implementation details should be included.