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

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: ‘The purpose of this educational application is to provide students & their families with an educational platform for driving to enable fast lesson bookings, direct communication with instructors and transparent payments.

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:

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.

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

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

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 websire 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 do while writing SRS

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 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. 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. So, don’t neglect it. 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. Just, let’s talk business!

Originally published at https://fulcrum.rocks.