Software Requirement Specification (SRS) Document: Writing Guide

When developing software, you will have to explain your business aims to the contractors. To put your vision of a future product into a form that will be clear to the development team, a software requirement specification document is a must.

A software requirements specification (SRS) document is used to reach an understanding between stakeholders and developers. It contains vital instructions of the software structure,  as well as the functionality and describes the required quality of user experience.

In this article, we will discuss the importance of SRS documentation, its contents and general writing tips.

What is the purpose of SRS?

To put it simply, the SRS document is a translated version of your application vision into a language that the outsourced developers will understand. SRS includes requirements for the product’s functionality, performance and user experience. A well-written document will prevent misinterpretations and deliver your expectations for the product to the contractor.

Another reason why the SRS is vital for a project is its versatility. The SRS provides detailed instructions for the whole team of developers in a single piece of documentation. Insights could be drawn from an SRS document by:

• Programmers — to decide on a tech stack required to complete the project;
• Analysts — to collect the client’s view on the product and translate it into the developer’s language of tasks, cases and stories;
• Project manager — to lead the team and ensure that the goals are reached under the given constraints;
• Designers — to create an interface matching your view and use cases;
• Testing engineers — to develop test cases and evaluate the system’s work;
• Investors — to get a picture of the future product and decide whether they wish to support it.

What Should Be Included in SRS?

The SRS documentation is created during the software requirement analysis. Every requirement included in the SRS impacts the development time and cost. Given the length of the requirements list, you might want to sort the requirements into three categories:

• Mandatory — the core requirements. A project that is missing these features and characteristics is a failed one.
• Desirable — the requirements that you want to have in the software, but can sacrifice if the implementation will take too much resources and/or time.
• Optional — these requirements are satisfied if possible.

The SRS documentation has to provide instructions sufficient for the developers to build the product that matches the client’s business goals. Typical building blocks for an SRS document are:

• The aim, priorities, auditory, application field and effect of the final product on the system;
• General description of the software;
• Functional requirements: the software’s planned functionality, design and user interfaces, design;

Non-functional requirements: performance, scalability, maintainability, etc.

Functional vs. Non-Functional Requirements: What’s the Difference?

Software requirements are the basic elements that the future product must implement to satisfy both user and business goals. Requirements that were clearly stated save time and resources and enhance the overall quality of the software.

The software requirements fall into three categories: 

• Business requirements — business goals that the software must reach;
• User requirements — users goals and expectations from the software;
• System requirements — system functionality, restrictions and performance. This category includes functional and non-functional requirements.

Functional and non-functional requirements describe the “flesh and bones” of the software. System analysts evaluate and write these requirements to build a bridge between business goals and the development team’s capabilities. But how exactly do functional and non-functional requirements differ from each other? Why are both of these types of requirements important? Let’s dig deeper into the subject.

What are Functional Requirements?

Functional requirements are the “whats” of a product. As suggested by the term, they describe software functionality: key features and responses to the user’s input. Without functional requirements it would be unclear what the goals of the software are and the system wouldn’t work as expected, if at all.

Some examples of functional requirements:

• Administrative functions;
• Authentication and authorisation levels;
• External interfaces (hardware-software connections);
• Reporting requirements;
• Certification requirements.

More practical functional requirements are:

• The user shall be able to search for the product;
• The system shall provide a catalogue of products in response;
• The user shall be able to put the product in the cart and pay for it.

What are Non-Functional Requirements?

Non-functional requirements are the “hows” of a product. They may mistakenly be given a lower priority than functional requirements, due to their seemingly lower impact on the system’s structure. However, non-functional requirements cater to one of the most important things — user experience. They are the quality attributes and properties of a system: how fast it responds to the input, how the interface looks, how many platforms the product is ported to.There are a lot of non-functional requirements, but the most general ones are:

• Performance — the criteria of the system’s working speed;
• Usability — a quality metric of how effectively users can complete their goals within the software;
• Reliability — an attribute of the software’s ability to consistently perform well;
• Scalability — a measure of the system’s reaction to changes in workloads;
• Maintainability — the ability of a software to be returned to a desired condition after maintenance;
• Portability — the software’s ability to run on different platforms and operating systems;
• Security — the software’s policy towards private data storage and administrative accesses.

For more practical non-functional requirements:

• The time between the user’s input and results showing on the screen should be no more than 2 seconds;
• The catalogue must show 20 products on the screen;
• The product shall appear in the user’s shopping cart within 2 seconds.

How to Write Software Use Cases?

Use Cases are written documentation of steps that a user of the software will take to complete their goal. Use cases are commonly used to describe functional requirements. They introduce the system from the user’s point of view and describe how a system will respond to a certain input. The use case is usually a sequence of actions that start from the user goal and end with the goal’s completion.

Use cases provide insights into the system’s expected behaviour and the amount of goals that can be completed. They can also determine the complexity of the system. Using such cases, the analysts decide on which features become software requirements.

A use case can include various elements, depending on software complexity:

• Actor — a user or a process that performs a certain action;
• Preconditions — the system state before and after the use case completion;
• Triggers — an action that initiates the use case;
• Main scenario — the perfectly performed use case;
• Alternative paths — the use case that went wrong or used an alternative path to perform the action.

Now that we’ve covered the basics, let’s discuss how to write use cases.

Discover your users

Understanding your users will help you imagine what they will want to do with your software. When the target audience’s goals are clear, you can think of ways to cater to their needs. Answering the following questions will help:

• Who are the users of this software?
• What task do they want to complete?
• What are their goals?
• What platforms do they use?

Define the user’s actions

At this stage, you know what your users want to accomplish with the software. Outline the sequence of steps the user would take to complete their goal by answering the following questions:

• What should a user do to reach the goal?
• What are user interactions with the software?
• What is the exact course they should take?

Chart the courses

Each user case should have a main line, where the user follows the intended path and has successfully finished their work and alternative paths, where the user makes mistakes. From these mistakes, you can develop ways to avoid them or detailed instructions for users. Narrow down the search by answering:

• What is the normal course of events?
• What are the possible deviations?
• How would the user avoid deviations?

Rinse and repeat

Once you’ve finished with a single user goal, it’s time to pick another. Think of every possible end-user and follow the previous steps until you’ve covered every possible action and route. This will get you close to a well-thought-out software.

Writing a Software Requirement Specification

The SRS documentation has a general outline to it. We will address this outline and explain how and what to write in an SRS document. This instruction is general, but it suits SRS for mobile apps. There is no universal SRS document template, as the contents of the document depend on the project, team, goals and stakeholders’ views. The following are basic points that we use in our documentation.

Introduction

Purpose

Here is where you should clearly state the reasons why this software needs to exist and what goals it will help to accomplish. To define a product’s purpose, answer the following questions:

• What problems does the software aim to solve?
• Who is going to use the product?
• Why is this product important?

A defined and clear purpose will make it easier to pick vital functionality for the product.

Intended audience

Conduct market research to establish who your users will be, what their preferences are and the range of their incomes. The results go in this section.

Project scope

The intended scope of the software. How many platforms you’re planning to use as well as the amount of goals that can be completed with the software. A defined scope will guide developers through the project, providing an understanding of how the project should look and function.

References

The examples of similar software, features and designs. Something for the development team to find guidance in and take inspiration from.

Overall description

Product perspective

Product perspective includes stakeholders’ demands and expectations from the product and communicates the external view of a product to the development team 

 

 

In this section, it will be useful to describe:

• System interfaces
• User interfaces
• Hardware interfaces
• Software interfaces
• Communication Interfaces
• Memory constraints

Product functions

This part of the documentation briefly describes the intended functionality of the product as well as criteria that the functionality should meet to answer the stakeholders’ views. Detailed descriptions will be given later in the document in the form of functional requirements.

Design and implementation constraints

Design constraints are limitations that are applied to the product. Examples of constraints are:

• Physical requirements;
• Regulatory statements;
• Hardware limitations;
• Interfaces to other applications;
• Software development standards;
• Software quality assurance standards.

User characteristics

This section describes the general characteristics of the product’s audience that may affect usage of the product, such as their experience, expertise and disability. If audience research defines who your clients are, user characteristics describe how and what they are.

Functional requirements

This section describes the whats of a future product in greater detail. The previous part includes a brief mention of product features, but this is where functional requirements take shape.

Functional partitioning

This field is used to divide a system’s functional specifications into sub-specifications. These sub-specifications lay out the functionality of the system’s components (for example, software processor or custom software/hardware.)

Functional description

Functional descriptions provide the requirements for sub-functions and controls description: what elements are supposed to appear on the screen/system, their behaviour, restrictions, rules, etc.

External interface requirements 

This section is where all inputs and outputs of a system are defined. Each interface description should provide the following technical requirements:

• Item name;
• Purpose description;
• Source/destination of input/output;
• Input/output range/accuracy/tolerance;
• Window format/organisation;
• Data formats;
• Command formats;
• End messages.

Non-functional requirements

These requirements are the hows of a system. They describe system qualities and shape user experience. 

Performance requirements

Performance is a set of criteria that describe how a process should work, what standards it should meet and how the system must perform under certain conditions. When assessing the performance of a future product, concider stating expected:

• Response time;
• Workload;
• Scalability;
• System reaction on different platforms.

Software system attributes

Software system attributes are the intended quality measurements for a future product. The software attributes that should be included into SRS are:

• Reliability;
• Availability;
• Maintainability;
• Portability.

Safety requirements

Safety requirements describe safety functions that should be implemented in a system. They serve to forward the design towards creating a safety system, concerning possible losses and damages that may happen during product usage. This is where regulations of safety issues and external policies that affect product design should be spelled out.

Security requirements

Security requirements consider authentication, user accounts, logging, admin accesses, the safety of code (open source or encrypted), strategies of retrieving lost passwords, etc. It is important to include these requirements into SRS documentation, otherwise security may be overlooked in product design.

Most Common Mistakes When Writing SRS

The biggest mistake is to not have an SRS document at all or have a brief one, lacking details. To write a proper SRS document is not an easy task. The most common mistakes are to make SRS documents:

• Vague. Imprecise and unclear requirements results in the development team making assumptions, bringing unnecessary functionality or missing out on important features.
• Immeasurable. Most non-functional requirements have calculations applicable to them. These calculations should be precise and measurable to complete the product.
• Incomplete. An unfinished document leads to an unfinished product. It’s advised to finish the document and check it for blank and unclear spots before sending it to the contractor.
• Impractical. The requirement should be rational, applicable and the development team should be able to successfully implement the listed features. They should be bound by a budget and the available technology.
• Rigid. While requirements should be certain and understandable, they should also be flexible, allowing the development team to update the specifications with a better solution.
• Unverifiable. Every member of the development team should have access to the document, allowing them to provide references. Every detail should be in place.
• Inconsistent. Make sure every part of your document is consistent and in line with the other ones, the requirements should not conflict with each other.
• Inaccurate. When writing an SRS document, avoid adding: loopholes, ambiguous statements, superlatives and comparative statements.

Conclusion

Software requirement specification documents play a major role in software development. They require a high level of precision and attention to detail, but the outcome is a good product that meets expectations.