June 23, 2018

As an experienced software development company, we know that writing good system requirements specification is pivotal to the success of any software project. Working with dozens of different requests from various industries we have accumulated knowledge and created a vision of how ideal SRS documentation should look like. In this article, we share our best practices for creating outstanding SRS documentation which will be both very comprehensive for the developers and protect your project from some of the challenges you and your business may face without having well-outlined system functionality and requirements to the final software.

List of the Contents


Every software has specific goals and serves particular purposes. Each goal and purpose translates a process or several processes that the software aims to solve or to automate. To deliver the right product, we should define it well from the beginning. System requirements specification or SRS frameworks development, it documents every operation and dictates how software should behave, it can be as detailed as what a button should do and should be as complete and correct as possible. The purpose of a system requirements document is to describe the behavior as well as the different functionalities of an application or software in a specific environment.

In this blog post, we are going to discuss System requirements specification or SRS and its needs. We will give some advice to help you while writing software requirements specifications, and we will enumerate some common bad practices and writing good requirements examples that you can you use as a guide. Then we will take software system requirements examples to better understand the concept. First of all, let’s address the reason why it is essential to write a system requirements specification during the development process as documentation is its inevitable part.


First of all, customers or product owners work on writing system requirements specification to define the objectives of the software as well as the scope of intervention of the team that develops it. A thorough description helps the development team to implement and build software. We then use the system requirements specification to validate and check the product to ensure that it has the required features. Development should start from a specification. If somehow the delivered software doesn’t meet the requirements, the specification serves as a reference, and the development team works to meet all the described needs.

Writing technical specifications for software is then an important starting point for any development project. It involves not only the development team but also the owners and/or users. It helps the development team during the design and implementation of the product. Making sure that the specifications are complete and clear which means that they do not lead to ambiguity prevents from spending lots of time correcting, redefining, and reimplementing the software. Moreover, early detection of problems in specification leads to effective time management since it is a lot easier to update specifications prior to any development than to update the specification then the corresponding functionalities.

Generally, writing technical specifications for software comes after a first discussion between the development team and the product owner. Specifications serve as a reference for cost and time estimation. Since writing system requirements document aims to describe faithfully the software to develop, it makes the estimation process a lot easier and much more accurate.

Additionally, the development of an application is an evolving process; it will not always involve the same persons. Writing software requirements specifications aims to document the behavior of the software making it easier to hand over the development from a team to another. This is why it is essential to know how to write a requirement specification.

Knowing how much time your project will require to complete will be a good start. Read our previous article “How to calculate man-hours for the software development” to learn how we set a timeline for our customer’s projects. Also, you can contact us in the website chat or via the form to get an expertly crafted estimation of the development duration and cost for your specific case.


A good specification makes the product easier to update. Any change in the software requires updating the project requirement specification inviting every party involved in the process to rethink the changes to be made.

Moreover, SRS can be used like Functional Specification Document (FSD) or Product Requirement Document (PRD). SRS includes requirements that help write Functional Specification Document and can even include FSD, SRS describes all functionalities and explains how the functionality will inside a given system as a part of a larger system or as an independent system. FSD is the software-only part of an SRS document. Indeed, an SRS may contain hardware requirements, system interaction requirements as well.

It is crucial to writing a good software system requirements specification. Later in this blog post, we are going to analyze system requirements specification document example to understand the difference between well written and poorly written specifications. In the following section, we are going to see how to write a system requirements document.


In this section, we are going to learn how to write SRS document. A good system requirements document should answer the following questions:

  • What should the application or software do? Answering this question helps identify the main functionalities and the primary purpose of the software.
  • How should the software behave? It helps to understand how the app interacts with the environment where it is deployed; it also defines the hardware specification and defines the IHM: how the software interacts with the end users. The software to be described may be a whole system, but sometimes it is part of a more extensive system. It is then essential to define how this part interacts with a bigger system, how the two systems communicate with each other. CRM system requirements specification is a good example of system requirements where it is essential to understand how the software should behave.
  • What are the requirements in terms of performance? It will, for instance, give information about the acceptable response time, how fast it should respond, and how fast it should handle problems when they occur.
  • Are there requirements or constraints that should be taken into account or respected? It aims to determine the constraints to be taken into account during the design, development, and deployment of the system.

Now that we have defined what an SRS should contain and what questions it should answer as well as how to write SRS document, let’s see how to write software requirements the different steps needed to write an SRS.

The outlines may differ from a project requirement specification to another. However, we can consider the following outline:

  • An introduction: The first step for how to write a requirement specification is to agree on what should the software do, whether we are writing CRM system requirement specification or another system requirements specification. At this point, it is important that the development team and the product owners define and write this part together. The product owner doesn’t necessarily have the skills to write a good SRS, but the development team doesn’t know what the end users need. This is why It is important for the two parties to work closely together at this stage. In this section, it is important to put the software to build in its context. Here, we address the reason why the product needs to be built, who is going to use it, what it should or should not do (sometimes it is helpful and necessary to mention what we should not expect from the software). Sometimes, some terms are specific to the business, and their mention in the systems requirements document is important to understand the specification and to build the software. It is essential to define these technical terms so that the content can be understood. At the end of the introduction part, we can include a brief overview of the document to give the readers an idea of what they can expect from the system requirements document. It is also important to mention in the SRS all the documents that can be read to have a further understanding of the system, and all references should be documented as well.
  • A general description: in the description section, it is important to explain the different functionalities of the application. In this part, the hardware interfaces and user interfaces are defined. In what device the end users expect to access the application for instance or what are the functionalities, how can users expect to see them in the application, what is displayed on the menus, what are the other parts like Reports, exports, etc.?
  • Specific requirements: In this section, all the necessary details are described so that it is made easier to design the product and validate it according to requirements. Here, it is important to describe all inputs the software handle and all the outputs to better define interaction with other systems and facilitate integration. The functionalities enumerated in the previous section will be detailed here. The performance criteria need to be defined here as well. It may be tempting to leave for later some parts of the documentation that may change during the development process or at a later stage. However, it is important to thoroughly document the SRS and update the content if needed and when needed.
  • References: it may sound obvious now that we mention it but it is important to include information about the content so that it is easier to find the information when needed.


An SRS is a technical document, and there are few practices to avoid to write a good system requirements specification. We will see these bad practices through the software system requirements specification example.

  • Incomplete dictionary: An SRS may include jargon that only people familiar with the business can understand. A requirement specification aims to give everyone involved in the development a better understanding of what the software does etc. it is important that everyone understands all the terms that are used in the system requirement document. Before using them, it is important to define them, even better have them at one place so that readers can find them quickly when needed
  • Mixing concepts: it may be tempting to throw all information we have at the same place, but that leads to poor documentation.
  • Include development instruction: it is important to separate software requirements from technical implementation. The product owners know better their needs and the development team knows better how to develop the product that meets these needs.
  • Passive action: it is important to know what to expect from the software, but it is as important to understand who is going to interact with it to have the expected result. For instance: reports are generated by clicking on a given button. It is important to know that we expect the report generation from the software, but it is also important to know who is going to click on the button to generate the report.
  • Ambiguous and incomplete documentation: sometimes some requirement lines may lead to several interpretations. However, it is important that they are clear and don’t lead to misunderstanding or interpretation for both documentation writers and the persons to whom the SRS is intended. Also, for each functionality or situation described in the SRS, it is important that the SRS does not present aspects that are not determined yet.


Now that we have defined what’s an SRS and seen how to write software requirements, and what is generally included in one requirement specification among the most common bad practices, let’s consider a simple yet useful system requirement specification document examples.

Let’s consider a system requirements example for a system managing ATM cash withdrawal. First, check out a system specification example of a poorly written specification and then see how to write good requirements.


When a customer selects from the menu that he wants to withdraw money, he will be asked to choose how much money does he want to withdraw. The system is checking his account to see if his balance allows that transaction. If his balance allows the transaction, the transaction is validated. The system releases the customer’s card and delivers the cash with a receipt of the transaction. All the operations must be fast.

This system specification example seems clear. However, when we do some analysis, it presents some examples of bad practices. This specification lacks clarity, and it does not tell:

  • For the choice of the amount:
    • how the customer chooses or indicates the amount, he wants to withdraw.
    • Is there a list of choices
    • can he manually input money he wants to withdraw
    • how much is the limit he can withdraw during a single transaction
    • is there any rule for an acceptable amount a customer can withdraw
  • For the validation of the transaction: what are the rules for the validation?
  • For the money delivery: does the customer receive a receipt all the time?


The previous specification can be improved as following after taking into correcting the bad practices we have identified earlier. Earlier, we have seen how to write a software specification, in this section, we are going to apply the good practices we have mentioned.

When a customer selects the menu: “Withdraw money”, he has the possibility to choose between six different amount on the screen: $10, $20, $30, $50, $100, $200, $300 or choose from the screen to input manually the amount he wants to withdraw. The amount must be multiple of one of the tickets issued by the ATM while respecting the maximum number of tickets for a transaction. Once the customer has chosen the amount, he can select the validate button to continue with the transaction or select the сancel button to cancel the transaction and get back his card. If the customer validates the amount he selected, the system validates if his balance allows him to withdraw the amount he requested and if the customer has not yet reached the maximum daily amount. The system also validated if the ATM can issue the amount: the system checks if the ATM has enough money to satisfy the customer’s need and if the amount is a multiple of delivered tickets. If the validation is OK, the system asks the customer if he wants a receipt for his transaction. If the customer wants a receipt for the transaction, the system prepares the receipt, releases the customer’s card, delivers the money and the receipt. If the validation is OK, but the customer does not want a receipt, the system releases the customer’s card, delivers the money. If the transaction is not validated, the ATM releases the customer’s card and displays the reason why his transaction has been denied. Every transaction should take at most three seconds.


A system requirements specification is a must when it comes to developing software. Some good practices lead to good documentation. Since SRS is useful for both customers and software development team, it is essential to develop a complete and clear system requirements document, in this blog post we have seen how to write a software specification. SRS helps the customers to define their needs with accuracy, while it helps the development team understand what the customers need in terms of development. Investing time in writing the SRS document will lead to the successful development of the software the customers need.

Having difficulties creating the specification requirements or define user workflow and experience for your custom software project? Existek is an innovative offshore software development company experienced in the creation of custom solutions for small, medium, and large-scale enterprises. Fill in the form or contact us directly at the live chat at our website and we will provide you with a free consultation, help you to set goals for your project, pick up best technologies and engagement model, outline specification requirements and give an estimation of the budget and time needed to complete your project.