How to Create SRS for Edtech App: Don’t Reinvent the Wheel, Take What’s Already Written

Don’t waste your time on thinking what to write in your SRS document. We’ve done it already and want to share. Whether you’re creating SRS for an edtech app or not – our template will be a blast for you. Just read, adjust it to your case, and voilà – your SRS is done!

 

But first, SRS…what’s the heck?

 

Software Requirements Specification Definition

Software Requirements Specification, also known as SRS is a report or a complex document that describes in detail the product which is going to be developed. In other words, this is a reference point for everybody associated with the project, from an application engineer, developer, a creator to an analyzer and a UX designer.

 

In a nutshell, SRS is an official document which outlines:

1. Product you want to get at the end;
2. How it could be build/developed/achieved (project’s roadmap);
3. Things/factors to pay attention to (in order not to miss something very important);

How does SRS for edtech app look like? Pfff…, pretty much like any other SRS. We know, it’s hard to visualise the SRS document, but funny enough, it helps to visualize the end product. To be more practical and less abstract, we offer you to learn how to create SRS by looking at the project we’ve developed for the edtech startup, Kör.

 

Overview of the SRS Document

As everything in this world, you want to start building up from the core, work on it’s structure so that it can hold itself together and then keep building all the way up, covering all the little details on the way.  This is how its structure may be:

 

I. Introduction

• Purpose
• Document conventions
• Target audience
• References

II. General description

• Project scope
• Types of users
• Product perspective: Hardware interfaces, Software interfaces, User interfaces, Communication interface, Site adaptation requirements
• External interface
• Operating requirements
• Restraints
• Assumptions and dependencies

III. Requirements

• Functional
• Safety & security
• Usability
• Code quality
• Performance requirements

IV. Verification

Stage by Stage – How to Create SRS Document

I. Introduction

In this section, we give a general overview of the product to be developed. It wouldn’t be bad to mention the product’s specifications, including its special characteristics, benefits, general budget estimates and the project’s timeline.

 

1.1 Purpose

 

Predictably, in ‘Purpose’ section we describe… purpose of the project. For example, how we would describe it for Kör:

1.2 Document conventions

 

Any SRS includes conventions that should be obviously mentioned in the document. Thus, most of formal documents use set font style and size with bold headings and color highlights. The goal is simple – to make the document more readable and comprehensible. Another tip from our team – is to use simple and understandable language as well.

 

1.3 Target audience

 

In the introduction, we also mention who this document is prepared for. As a rule, SRSs are mainly used by business analysts, software engineers, designers, QA/QC engineers, project managers, investors and the customer.

 

1.4 References

 

Nah, it’s probably not the most important part of the document, but still necessary one. In this section, you can attach some links with your references, sources, useful materials etc.

 

II. General description

 

Here we get to more detailed characteristics of your product. Try to be both clear and precise for other parties (whether these are developers, business owners or users) to understand.

 

2.1 Project scope

 

In this part, we usually describe the product’s basic functionality at a high level. Each aspect of the functionality should be mentioned in the project scope. It’s time to spill some beans (joking, not beans, but exact features would be good). You can add a DFD (Data Flow Diagram) here that will show the general system flow. That’s, for example, DRD for Kör’s ‘book a mandatory course’ feature:

Besides, you can include some tables with the features planned to be developed during certain sprints. Here’s how it may look (on the picture – Kör functionality for the first two sprints):

2.2 Types of users

 

In general, any app/platform/website you’re planning to develop will have different user segments. Hope, it’s not a big surprise for you. In this section, we advise to outline & define what your user types are. Let’s again take Kör, an educational platform for driving schools in Norway. For the app, we outlined 4 main stakeholders and described them in our SRS document:

Each of these user types requires specific features, functionality, and follows different goals. Thus, ‘book a lesson’ and ‘pay for a lesson’ features may be relevant for user#1 (student), while user#2 (instructor) doesn’t need them at all.

 

2.3 Product perspective

 

This section describes how the product interacts with other softwares (if any). For instance, if the product is a part of a larger suite, this is where the connections between different elements should be described (e.g. with a block diagram).

 

2.3.1 Hardware interfaces

 

In this part, we identify hardware interfaces: for example, a browser which could support CGI, HTML & Javascript. It’s more about defining configuration characteristics: which devices developers are going to cover and how they will do it. Supported device types can be:

• Hard disks
• USB
• External hard drives (USB – eSATA enclosures etc.)
• IDE, SATA, RAID controllers and attached devices.

 

2.3.2 Software interfaces

 

After we outlined hardware interfaces, it’s time to move to software ones. Software interface is an interface that allows two independent software components to exchange information.

 

Important: any software item you describe should have its unique specific number with the relevant version mentioned.

 

To summarize, for each software interface, it’s good to write: its purpose (what’s for), message content, format and version number. In case if you have an extensive documentation on the software interface, just add link to it for the reference.

 

2.3.3 User interfaces

 

Two basic things you need to describe here:

1. Logic between users and software. Go deep into details: from screen images to app layouts, from menu’s content to reports etc.
2. Ways to optimize the interface.Just enumerate what the crucial recommendations and restraints are for optimizing user interface.

Useful tip – don’t forget to add project’s design guidelines in this section (if there are any, of course).

 

2.3.4 Communication interface

 

Then, we describe any communication interfaces to other systems or devices such as local area networks, remote serial devices etc. The described project has to support all web browser’s types.

 

2.3.5 Site adaptive requirements

 

Duh, we’re still not over. Another point is to mention the data, initialization sequences or features specific for a certain website or a mission. Here you can specify grid values, safety limits for the website/operational mode you’re dealing with. You can also describe the functionality which requires changes for the particular software installation (if any).

 

2.4 External interface

 

This is simply the external system the product is integrated with and the data it sends/receives to and from them. How to describe external interface? Well, here’s our structure for it:

• Name of the software;
• Its purpose & functions (within your product);
• Input/output data;
• Connectability with other inputs/outputs;
• Formats of data, command, screen, and window;
• Tolerance, accuracy, valid inputs;
• Items of measure;
• End messages.

 

2.5 Operating requirements

 

Thety include:

• Actions started by a user (e.g. booking a course);
• Interactive and unattended operations;
• Functions assisting to process data;
• Some backup and recovery processes.

 

2.6 Restraints

 

Paragraph’s name talks for itself. In SRS, we also shouldn’t forget about restraints and limitations. In general, restraints can be implementation and design ones.

 

Implementation restraints

 

In this part, we outline limitations resulted from development standards. Among them are:

• programming language, database;
• coding standards;
• communication standards;
• restrictions imposed by operational environment;
• constraints that can be imposed by the business logic of the project.

 

Design restraints

 

It’s always not an easy task to visualize a product just by using requirements specifications. Yet, to remove such restraints and make your cooperation with a client/development partner smoothier, we usually try to add app’s wireframes, mockups, and prototypes to SRS.

 

If you don’t know what the difference between these three words is, here’s a brief ‘Fulcrum wikipedia’ intro:

• A wireframe is a low-detail representation of a design.

This is mainly black and white site page plan. It outlines the arrangement of basic elements: buttons, images, texts. It does not perform any real functions of the site. The results of interactions, clicks, animations should be described additionally in the comments.

Why do you need it? To determine where and which content will be located. The wireframe and comments to it can be used to compose the technical specification.

 

• A mockup is a detailed static representation of a design. It includes colors, images, typography. Mockup is more like a beautiful picture of an application or a website.

 

For what? In order to create the style and mood of the project, present and coordinate visual details with the customer.

 

• A prototype is an imitation of user interaction with the product’s interface. It’s an interactive version of the wireframe.

Why do you need it? In order to illustrate location of blocks and buttons and to conduct usability testing.

Read more: How to Create a Prototype for Your Design Project?

 

2.7 Assumptions and dependancies

 

This section should incorporate the elements that aren’t plan imperatives in essence. Still, they rather can influence the improvement cycle whenever changed. It can be third-party integrations which are not foreseen during the main development, but described as options in future improvement cycles.

 

III. Requirements

3.1 Functional

 

FR (functional requirements) are item highlights or capacities that developers will later need to consider while building your app. Thus, it’s critical to make them clear both for the technical group and the partners. In general, FR describe system behavior under specific conditions.

 

Let’s get clear which functional requirements you may outline:

• construction– includes desired device compatibility;
• durability – gives information about staying power of the system;
• adaptability & environmental conditions– describe external factors influencing the app.

 

3.2 Safety & security

 

Safety is over all. Sure, you know it without us. That’s why, you need to include a special part in your SRS where you describe product’s safety & security requirements which need to be followed.

 

As an example, you can mention that information transmission should be securely transmitted to the server without any changes. Or if you’re changing information on your website through HTML editor, then don’t forget to write: ‘through the HTML editor it should not be possible to put a shell on the server, etc’.

 

3.3 Usability

 

Make clear and measurable requirements for product’s usability. Next, for each requirement you describe, outline its purpose and effect on the product’s usability: ‘to shorten waiting time for users, the login process shouldn’t take longer that 10 seconds’.

 

3.4 Code quality

 

Again, might be obvious but in this part, you describe the requirements for the quality of the code. What tests should be used? What metrics to use to determine code quality? How much code should the tests cover? All these questions would be great to answer here.

 

3.5 Performance requirements

 

Performance  imposes certain restrictions. Let’s say the project database must withstand 1000 requests per second. These requirements may lead to tremendous work to optimize the project. If you don’t want to have any unpleasant incidents during your app’s functioning, mention all necessary performance requirements here.

 

IV. Verification

Wow, we’ve got to the last part of SRS. This one is where you describe methods/metrics/key points to help you verify that the final product meets all SRS requirements. In general, it means that you need to outline product’s basic requirements along with methods/techniques to verify them (you could make it in a table format).

 

5 Steps To Take While Writing SRS for EdTech App

Woo-hoo, we’ve done with the SRS structure and its main sections. Now, let’s make a brief summary of how to create SRS for your edtech app effectively. There are 5 steps that will be crucial while you’re writing software requirement specifications:

 

Step 1. Outline

Use the already existing templates to write SRS correctly. If you haven’t done it earlier, look for the available templates in the Internet. Don’t waste your time on reinventing the wheel, it’s already been reinvented for you.

 

Step 2. Details

Be detailed, don’t miss any important information. SRS is crucial for further development of the whole project, since your project’s success depends on the precision and clarity of the technical task.

 

Step 3. Visualization

Charts, infographics, images, graphics and different visuals will help to understand any idea quicker. So, if there is a chance to visualize some information, use it.

 

Step 4. Approval

When the SRS is finished, we pass it to stakeholders. They should read it cautiously and leave remarks or comments. You can’t start any development or further works without approval of your SRS.

 

Step 5. Availability and updates

Get ready for the fact that the SRS you’ve made is probably going to be edited later on. At Fulcrum, we regularly refresh the data to keep it up to date.

 

How Does the Process Usually Go?

1. Reaching out to our company.
2. Showcasing your app development idea.
3. Discussing it with our team members.
4. Reaching an agreement.
5. Signing the NDA.
6. Refine the inquiry, provide additional details, describe your goal.
7. Assignation of tasks to the team members.
8. Constant spread of the new information to the colleagues.
9. Continuous optimization of the project and questionnaires.
10. SRS is complete.
11. You get the final project quote.
12. You choose to develop the app with us or not.
13. If yes, meet the entire team.

 

Edtech projects realized by Fulcrum Rocks:

1. Kör is an online platform in Norway which allows booking driving programs & lessons online.
2. Bloss is an education and lifestyle platform that helps parents and parents-to-be with starting a family and raising their little ones.
3. VUC^it is a digital coach that strengthens your social, emotional and creative skills to master remote work.
4. DoIt is an adaptive platform for learning. It features various assignments for corporate employees who want to improve.

 

Read more: Kick Off Your Education App Development: How to Create an E-Learning App

How to Create SRS using Mindmapping

As a bonus, we want to share the technique we use at Fulcrum to create a successful SRS: mind mapping. How does it work for us?

 

Usually, we schedule a meeting where we generate new ideas for SRS document. Together we outline the product’s key features. Then, we transform the outcomes into a significant mind map.

 

Here’s a super brief instruction from Fulcrum on effective mind mapping for your SRS:

1. Interview, survey or organize a core group inside your team to identify the users of your app, their characteristics and needs.
2. Create a huge visualization in the format of mind map to answer the questions Who, Why, and When: Who will win from your solution? Why do they really need it? When could they use the product?
3. Make a user stories mind map. Based on it, develop different scenarios and define features that fit users’ needs best. Put the mind map data to the SRS doc.
4. Constantly refresh and expand the map.

Fulcrum Expertise

Voilà! We’ve gone through the basic things you need to know to write your SRS. Even more – we’ve outlined some structure templates and description which you can adjust and use for your edtech app. Don’t neglect it!

 

From our experience, people underestimate the time and effort that you can take off the developer’s shoulders whilst achieving the desired goal along with the reduction of the development costs.

 

Writing documentation may seem unnecessary and not so important. However, having done dozens of the projects, we know that correctly written project’s documentation is a key factor for your product’s success.

 

Find the right person to do it for you, as it is typically written either by a technical writer, a systems architect, or a software programmer trying to get one of those in your team is key. Most companies provide incomplete assessments and jump-start the project, demonstrating a lack of professional experience as you must estimate and assign tasks efficiently.

 

Whether you need help with defining your project’s scope, functionality or developing the product you’ve dream about, we’re always here to assist. We have had many projects successfully completed, always with a proper discussion of all details and safe estimations to base yourself on. Just, let’s talk business!

 

FAQ: Software requirements specification