Month: July 2022

Web or mobile application development is a complex process, where any tiny issue or task has endless solutions. There are so many technologies, third-party services, frameworks, and libraries to choose from, that it’s simple to lose focus. The business solutions to certain problems are even more vast: there are endless ways to build your app’s user experience and business logic, and this may cause confusion.

Approaching development without some sort of a documentation and a plan is a way to fail the whole project. Some business owners prefer to jump right into development, but from my experience it always ends in broken deadlines, failed expectations and going over budget

Leyla Orudjeva, business analyst at Mobindustry

Often, when clients discuss what they’d like to see in the application or on their website, developers interpret it their way based on their previous experience. Because humans haven’t learned to read each other’s minds, vague tasks and preferences often lead to misunderstandings and frustration. 

This is why good software development vendors never work without clear requirements that are properly documented. The software requirement specification is one of the most important documents in software development, and in this article, you’ll learn how it helps to manage expectations and organize the development process.

What is a Software requirement specification?

A software requirement specification is a comprehensive document that describes your future project in detail: from its functionality and features to technologies and exact ways they should be implemented. 

Writing an SRS is one of the first stages of mobile app development or web development.

A software requirement specification describes the goals of your project and the ways your software will achieve these goals. Basically, this document guarantees that you get exactly what you expect, and what’s best for your business. 

System requirements specification vs Software requirements specification vs Functional requirements specification

Before we start talking about the software requirements specification, its importance, and best practices of its creation, let’s clarify the difference between other types of specifications. 

Many specialists use the terms System and Software requirement specification interchangeably, but there’s a slight difference between these two types of documents. 

A system requirement specification is more focused on technical details and describes the system requirements such as hardware, network connection, and a tech stack. A software requirement specification also covers these details but also includes business logic, use cases, and many other details. 

So, a software requirement specification is more comprehensive than a system requirement specification. 

The functional specification is focused on functions and features of the future software, it describes the business logic and contains concrete metrics that will allow the team to find out if their solution corresponds to the business goals and requirements. 

Why is SRS important? 

I want to dedicate a separate paragraph to the importance of SRS in software development, just because some business owners choose to skip this part of the development process, and then pay way more money for fixing the technical and organizational issues on the project. 

SRS allows you to avoid any guessing games or improvisation on your project, and you can be sure you get exactly what you want after investing in development

The importance of SRS is immense: it not only describes how your future project should look and perform, but it also serves as a communication tool for you and your team. Software requirement specification allows all team members to be on the same page and resolve any misunderstandings quickly by simply looking at the documentation. 

SRS allows you to avoid any guessing games or improvisation on your project, and you can be sure you get exactly what you want after investing in development. An SRS document is the best reference for all your team members, something you can rely on.

What is the structure of an SRS?

An SRS is a complex document that contains everything you and your team need to know about the project. The deliverables within the SRS document include:

• Purpose of the software
• Description of future software
• Features and functionality
• Functional requirements
• Non-functional requirements
• Third-party integrations
• Target devices
• Use cases
• Implementation constraints
• Project roadmap
• Key stakeholders, their roles and responsibilities

Out of all these project details, functional and non-functional requirements are the most important: you’ll probably spend the bulk of your time formulating them. Let’s talk about these types of requirements in detail.

Functional and technical requirements of SRS — what is the difference?

Functional and non-functional requirements are the most important part of your SRS documentation. They describe the functionality of your future product, its business logic, and its performance. 

So, what’s the difference between functional and non-functional requirements? Let’s find out. 

Functional requirements

This type of requirements describes the functionality and features of your future software. They include all features that make up the user journey and allow your users to achieve their goals and complete tasks. 

For example, if you’re building a parcel delivery application, your users will require various features to track and pick up their parcels. Your functional requirements will include features like personal profiles, login, onboarding, parcel tracking, location tracking, ability to edit personal information, QR-code scanner for picking up the parcel, and so on. The feature list will depend on your business operations and services.

So, the functional requirements show how your software will work, and how it will respond to different inputs and interactions with users.

Non-functional requirements

Non-functional or technical requirements show how your software will perform, and what qualities it will have. Here are some examples of non-functional requirements:

• Performance requirements
• User experience and user interface requirements
• Language 
• Security
• Operating system
• Device coverage
• Usability
• Availability

Non-functional requirements define all the aspects of the user interaction with your software. For example, if the status of the parcel delivery changes, how should your user be notified about it? How fast?

How to create a Software requirement specification

How do you write an SRS document? If you’ve never created such documentation, this guide is for you. The simplest way to create a software requirement specification is to use a template and modify it according to your needs. However, without any technical knowledge, it may be challenging to create an SRS that won’t need any clarifications in the future. 

I’d recommend you involve a team of technical specialists in this task. Usually, an SRS document is created by a business analyst and a lead software engineer. At Mobindustry our business analyst conducts a series of interviews with a client, learns about their business goals and requirements, and then creates a comprehensive SRS. 

Let’s look at how the process of building an SRS goes.

SRS document template

Creating an outline

First, you need to define all the aspects of the SRS you’ll need to cover. For this, you can either create an outline yourself or use a template. I’ll demonstrate what an SRS outline may look like. 

1. Introduction

1.1 Purpose and goals

1.2 Target audience

1.3 Intended use

1.4 Scope

1.5. Definitions

2. Project description

2.1. User needs

2.2 Assumptions and dependencies

2.3 Risks

3. Features, functionality, and requirements

3.1 Functional requirements

3.2 Non-functional requirements

3.3 External interface requirements

3.4 Use cases

This is an overall outline of your future documentation. It can look different depending on your specific needs, so feel free to make changes to it.

Now that you have the structure of your document, it’s time to fill it in. 

Defining the purpose

This is the first step of actually writing specifications for software. Approach the introduction with all the stakeholders in mind: think about how each team member will use your documentation, and who exactly will have access to it. 

Your SRS should be clear to each specialist, from developers and testers to project managers and designers. Sales and marketing teams will likely use your software requirements specification as well. 

In this section, you need to also describe the goals and objectives of the project. Mention your expectations and future business benefits you plan to gain from this product. 

Giving an overview

Now that you have your goals and expectations defined, it’s time to describe how of exactly you’re planning to achieve them. What product will you make? Is it a standalone application? Or a module that you plan to integrate into an already existing system? 

 Describe your target audience and how exactly they’ll use your product. Find your what external factors your product may be dependent upon: for example, your technical environment such as operating systems, frameworks, etc, can influence your project at any time. 

Define the risks you may encounter during and after the development. 

Describing functional and technical requirements

Writing functional and non-functional requirements is one of the most important parts of creating an SRS document. In describing your requirements there’s no such thing as being too detailed. Each requirement should be thoroughly described, and here’s where the software engineering experience comes in handy. 

For a person that hasn’t encountered many various development projects, it can be easy to overlook many important details. Usually, they aren’t obvious, but inevitably appear during the development, and can cause misunderstandings. Of course, your specification might still need some clarifications along the way, but it’s best to provide as much detail as possible. 

Many details in functional and non-functional requirements aren’t obvious, but they inevitably appear during the development, and can cause misunderstandings. 

To make this task easier, divide your requirements into categories. Describe the functional requirement first, and then move to technical or non-functional requirements. If you’re creating your SRS with a business analyst, they’ll ask the right questions to effectively extract all business requirements you haven’t even thought about. 

Each functional requirement should serve a purpose, so you need to focus on your users, their experiences, and goals. Don’t forget about the external factors as well: this is especially important if your software should work with other systems and modules.

Get feedback

Now that your requirements specification is ready, it’s time to get the approval of all the stakeholders. For this, they’ll need to review the document and provide their feedback. 

After all the necessary changes are made, your SRS document is finally ready and can be used as the main guide in your software development process.

Software use cases in an SRS document

Software use cases are the most important part of the SRS document along with functional and technical requirements. Software use cases describe how exactly your users will interact with your application at every stage of their user journey. 

For example, if you’re developing a food delivery application, the user journey will look something like this: 

1. Download and open an application
2. Go through the onboarding process
3. Register and login
4. Verify the phone number
5. Look through offers on the main screen
6. Choose specific food or restaurant
7. Review the restaurant
8. Pick a dish
9. Place an order
10. Track the delivery
11. Receive an order
12. Share feedback

Each of these steps requires multiple features, certain algorithms, and business logic, and all these separate tasks your user needs to achieve, make up the use cases of your app.

Let’s look at one of the use cases I mentioned above as an example — user registration and login. This use case, just like any other, needs to have the following information:

• User story — a short description of a situation and goals a user needs to achieve

As a user, I want to register in the application so that I can order food and explore

restaurants.

• Preconditions —  everything that needs to be done to get to the given use case.

1. Application is downloaded to the device.
2. The user’s phone is connected to the Internet.
3. The user opens the Food Delivery app.
4. The Splash screen is displayed while the Food Delivery app is loading.

• Flow — an algorithm of user interaction that describes everything that appears on the screen after each user action, like tapping a button.

1. Login/ Registration screen opens with:

● Full name text input field.

● Phone Number field.

● Email text input field. Not mandatory.

● Terms and Conditions link

● Agree to Terms and Conditions checkbox

● Login with the existing account link.

● Sign Up button (disabled until the ‘Agree to Terms and Conditions’ checkbox

is checked, the Full Name and Phone fields are not empty).

2. The user fills the Full name field (required, max 50).

3. The user fills the Phone Number field (input mask +44| 0000 0000). Show an error

message about an invalid phone number if the number does not fit into the chosen

country number requirements. Text: ‘<Please enter valid number>’

Note: the example above is just a part of the flow, so that you can see the level of detailing that goes into describing each step of the user story. 

• Exceptions — situations that go beyond an ideal scenario. For example, an invalid phone number or network errors. For each of these scenarios, you need to create a response from your application. 

This is a structure of use cases we write at Mobindustry. If you’d like to see a full software specification example, please contact us, and we’ll send you a sample. 

How to check if your software requirement specification is good

You’ve created a detailed SRS. How do you know that it’s good enough to serve as a development plan for your software development team? A good SRS has special characteristics that indicate its quality. Let’s look at them in detail. 

Correctness

The SRS document is deemed to be correct if the requirements stated in it are expected from the system itself.

Clarity

An SRS documentation should be easy to understand for all members of the development process, from stakeholders to developers and other specialists.

Viability

An SRS document should be created will all the current conditions and limitations in mind. They include budget, technical capabilities, team size, and deadline.

Completion

Your SRS should be complete with details and cover most user scenarios so that your development team can use this document as their guide and avoid any confusion during the development.

Flexibility

A rare product stays unchanged throughout the whole development process, so your documentation should be flexible enough to accept changes. Try to keep all the information well-structured, so that you can make changes quickly in one section of the document.

Consistency

The requirements in your SRS document shouldn’t contradict each other, and you should use the same terminology across the documentation. The structure of your document should be clear and predictable.

Accuracy

The document should have clear requirements and instructions so that any team member can use it without having to ask any additional questions. Avoid ambiguity, loopholes, subjective suggestions, and so on.

A software requirement specification example

At Mobindustry we create SRS documents for each of our projects because approaching development without it will lead to chaos, broken deadlines, and exceeded budget. 

If you’re interested in examples of software requirement specifications, just leave your email, and we’ll send you a real software requirement specification we created for one of our internal custom Android app projects.

Conclusion

The software requirement specification is the most important document in software development, that ensures software quality and helps facilitate the development process. To create a good specification, you need to have experience in software development, so that you include enough details for your team to use this document as a guide. 

In this article, I showed you how to write specifications for software projects, and what they should look like. 
If you’d like to get a high-quality SRS document, make sure to contact us. Our business analyst will translate your business needs and goals into clear and detailed technical requirements and specifications for any type of software, from websites to custom Flutter apps from scratch.