How to Create Software Requirements Specifications

After completing your functional and business requirements, you now need to specify the software and platform requirements. This is not quite as easy as writing functional specifications as you need to have somewhat of a technical background and in-depth knowledge of your technical infrastructure and environment to complete this step of project management known as Software Requirements Specifications (SRS). Read on to learn how to create Software Requirements Specifications.

Instructions

1. Contemplate whether this is a build or buy product. More than likely, this has already been determined. Still, it is good to do due diligence of consideration in this document. This is your proposed solution and includes the scope of this deliverable.

2. Complete an "overview" section detailing the application and system. This is a high level summary only of the application and system environment, users and any known constraints, assumptions or dependencies.

3. Summarize the operational requirements. Will more disk space or server be needed to handle the application? When is the application available or unavailable? Identify the network communications, workstation configuration and disaster recovery plans.

4. Identify points of integration with internal and external interfaces. What is the user interface (GUI) like? Are any reports dependent upon this new application? List all the hardware, software and communication interfaces.

5. List all of the known data and features (functional) requirements.

6. List any non-functional or performance requirements (response time, number of concurrent users), security requirements (MLA, LDAP) or any outstanding quality attributes.

7. Reiterate the business rules from the Business Requirements documentation. The developers may not see the business rules, but they will have access to this SRS.

8. List any additional documentation (user manual) or training requirements.

Tips & Warnings

• Be consistent in the jargon you use. Do not switch up names of processes or systems throughout the document.

• Do not underestimate what you need to make the cost look better on paper. Rework is much more costly in the long run.

Resources

• Excellent Site on How to Write Great SRS
• Actual IEEE Specifications for Writing an SRS