How to Write an SRS Document (The Non-Tricky Way!)?

When a certain law needs more interpretation, the constitutional book acts as a master document for law veterans. For software development, the (software requirement specifications) SRS document is what the whole team refers to when conflicts or confusion appear.

Not sure how to create an SRS document from scratch? You’ve come to the right place. Let’s take a look at how an SRS document should be created using a common example: an eCommerce clothing store.

Step 1: Identify the Problem Your Product Is Solving

Every featured-pack product is developed in order to address a real-life problem. This is why you start your document defining the problem and how your product will act as a solution to it. Therefore, this section is titled ‘ Business Purpose’. You provide a comparative analysis of the current scenario and how will it look like after your product goes live.

For instance, a clothing store that has specific business hours makes the process time-dependent for the customers. The launch of an eCommerce store brings 24/7 access where customers can place orders and get what they need in 24-48 hours.

Step 2: What Is the Scope of Your Product?

In this section, you will highlight the most important features of your product. Whenever a product is developed, it addresses the user’s problem by allowing them to perform a number of actions. This is what is outlined in this section called ‘ Product Scope’.

Following up on our example, the eCommerce clothing store, you can mention features like: the shop will allow the user to view the product catalog, open different categories (men, women, kids), add product(s) to a virtual cart, and make online payments via VISA or MasterCard.

Step 3: A Real World Overview of the Product

This section is where you tell the audience about the multiple ways in which your product will be a problem solver. In the previous section, you focused on internal factors (product features), so now it’s time to focus on the external ones.

For instance, the online clothing store will eliminate the time constraints one has to face while visiting a store physically. Plus, it can make shopping more affordable since the user doesn’t have to drive to a physical store (with gas prices on the rise, this is a significant point to include).

Step 4: Exactly What Functions Will the Product Perform?

You already mentioned the product features ‘ scope’ section. All you have to do here is re-list them and add a little bit of detail about the workflow.

For example, if you are telling the user about adding product(s) to the virtual cart, you will mention that once the product is added, they can proceed to checkout and add their VISA or MasterCard card number or select the cash on delivery option.

Step 5: Which Operating Environment Would the Product Need?

This section includes a checklist of the hardware and software components required for your product to function smoothly. You’ll have to go into some detail about the minimum benchmark for the system processor, the versions of supported operating systems, the versions of internet browsers, and the OS versions for Android and iOS if there is a corresponding mobile application.

Following up on our example, the eCommerce store will need a 1.5GHz processor, Windows 7 or higher, macOS 9 or higher, Google Chrome, Mozilla Firefox, or Microsoft Edge as a browser. As for the mobile application, it will need Android 9 or above and iOS 10 or above for iPhone.

Step 6: Are there Any Constraints in Development or Implementation?

This section is usually included when you are making enhancements to an existing product. You can include a constraint where a newly added feature is only applicable to the data manipulated after deployment.

For instance, let’s say we add a Featured Products category in the online clothing store. If this new category only fetches the frequently ordered products after the addition, it becomes a constraint as it is not working for the existing data.

Step 7: How Will You Train the End-User?

For each newly-built product or feature each product, a user manual is created to educate the end-user regarding the use of the product.

In this section, you will explain how the end-user would be trained: user manuals, service release notes, and so on.

Step 8: What Would the Product Look Like?

This is one of the most important parts of a software requirement specifications document. Why? Because detailed mockups of the product, along with other wireframes. The end goal of this section is to provide a graphic representation of the final product and make it as accurate as possible.

For an eCommerce store, you will need to include the mockups for the homepage, each category page, the product addition page, the cart view, and the payment page.

Step 9: Which Hardware Components Will Be Required for the Product to Work?

Each component of the hardware infrastructure required to run your product should be listed in this section. You have to define the minimum benchmark for each hardware component like hard disk, RAM, and operating system.

For example, the online clothing store would require a hard disk of at least 40 GB, a RAM of 512 MB, and the Windows operating system.

Step 10: Which Software Components Will Be Required for the Product to Work?

For a product to be built, you need both back-end and front-end software. For instance, a database server like SQL, Oracle, and MongoDB would be used for data storage. The front end would be facilitated by Eclipse if the product has been built in Java. All these components are listed in this section titled ‘ Software Interfaces’.

Your eCommerce store would require the inclusion of a MySQL server and Notepad ++ at a minimum.

Step 11: How Will the Different Modules of the Product Communicate?

When a number of actions are being performed from the front end, a lot is simultaneously happening behind the scenes even though the user is not aware of this. Different modules like homepage, category page, checkout page, and payment page are communicating at the backend.

This is done via HTTP requests and query information to generate corresponding responses to the client requests. The purpose of this section is to list every type of communication between the product modules. You need this comprehensive list to help you quickly identify problems if you find that, for example, your category page does’t communicate with the checkout page. Starting with this list, you will find the problem, and its fix easier and faster.

For an eCommerce website, client requests (user’s actions) are handled via HTTP requests to the application server. From there, the query request is sent to the database server and the required query is executed. That query is what brings the response against the action performed by the user.

Step 12: What Workflow Will the User Need to Follow in Order to Use the Product Features?

This is the section where you’ll walk a mile in your user’s shoes. The complete workflow of each feature from the homepage till the action is performed should be included here. In addition, supporting functionalities also need to be included.

In the case of the eCommerce website, things will look like this: upon landing on the homepage, the user will select the required category from the left-hand menu (Men, Women, Kids).

From the category page, the user will click the + button below the product for that product to be added to the virtual cart.

From the cart, the user will click the Proceed to Checkout button.

From the checkout page, the user will select the payment mode (credit card or cash on delivery).

If the credit card is selected, the user will add the card details. Once added, the total payment will be deducted and a notification will be sent via SMS and email on the registered contact number and email of the user.

Once the payment mode is selected, the user will click Confirm button to confirm the placed order.

Step 13: Which Other Factors Can Impact the Product?

In this section, external factors that may impact the performance and security of the product are included. For instance, a poor internet connection can impact the response time of the website.

That’s a Wrap

A software requirement specifications document does not only provide a concise and clear outline of the product to be developed but also brings a number of stakeholders like the development house and QA engineers on the same page. It can be referred to in case of any conflicts or if there is confusion in understanding the requirements of the customer.