How to Write a Software Requirements Specification (SRS) Document

# How to Write a Software Requirements Specification (SRS) Document [TOC] ###### tags: `software-requirements-specification` --- ## Introduction ### Purpose This introduction is very important as it sets expectations that we will hit throughout the SRS. ### Intended Audience Define who in your organization will have access to the SRS. This may include developers, testers, and project managers. It could also include stakeholders in other departments, including leadership teams, sales, and marketing. Defining this now will lead to less work in the future. ### Intended Use Define how those from the previous section should use it. ### Product Scope What are the benefits, objectives, and goals we intend to have for this product? This should relate to overall business goals, especially if teams outside of development will have access to the SRS. ### Definitions and Acronyms It’s important to define the risks in the project. What could go wrong? How do me mitigate these risks? Who is in charge of these risk items? For example, if the failure of a medical device would cause slight injury, that is one level of risk. Taking into account the occurrence level and the severity, we can come up with a strategy to mitigate this risk. ## Overall Description Your next step is to give a description of what you’re going to build. Is it a new product? Is it an add-on to a product you’ve already created? Is this going to integrate with another product? Why is this needed? Who is it for? Understanding these questions on the front end makes creating the product much easier for all involved. ### User Needs Describe who will use the product and how. Understanding the user of the product and their needs is a critical part of the process. Who will be using the product? Are they a primary or secondary user? Do you need to know about the purchaser of the product as well as the end user? In medical devices, you will also need to know the needs of the patient. ### Assumptions and Dependencies What are we assuming will be true? Understating and laying out these assumptions ahead of time will help with headaches later. Are we assuming current technology? Are we basing this on a Windows framework? We need to take stock of these assumptions to better understand when our product would fail or not operate perfectly. Finally, you should note if your project is dependent on any external factors. Are we reusing a bit of software from a previous project? This new project would then depend on that operating correctly and should be included. ## System Features and Requirements In order for your development team to meet the requirements properly, we MUST include as much detail as possible. This can feel overwhelming but becomes easier as you break down your requirements into categories. ### Functional Requirements Functional requirements are essential to your product because, as they state, they provide some sort of functionality. Asking yourself the question “does this add to my tool’s functionality?” Or “What function does this provide?” can help with this process. Within Medical devices especially, these functional requirements may have a subset of risks and requirements. You may also have requirements that outline how your software will interact with other tools, which brings us to external interface requirements. ### External Interface Requirements External interface requirements are specific types of functional requirements. These are especially important when working with embedded systems. They outline how your product will interface with other components. There are several types of interfaces you may have requirements for, including: - User - Hardware - Software - Communications ### System Features System features are types of functional requirements. These are features that are required in order for a system to function. ### Nonfunctional Requirements Nonfunctional requirements can be just as important as functional ones. These include: - Performance - Safety - Security - Quality The importance of this type of requirement may vary depending on your industry. In the medical device industry, there are often regulations that require the tracking and accounting of safety. ## Deliver for Approval After completing the SRS, you’ll need to get it approved by key stakeholders. This will require everyone to review the latest version of the document. ## Reference - [How to Write a Software Requirements Specification (SRS Document)](https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-document) - [830-1984 - IEEE Guide for Software Requirements Specifications](https://ieeexplore.ieee.org/document/278253) - [Software Requirement Specification (SRS) Format](https://www.geeksforgeeks.org/software-requirement-specification-srs-format/)