1

UNIVERSITY OF RWANDA

COLLEGE OF SCIENCE AND TECHNOLOGY

MASTERS OF ICT

OPTION: OPERATIONAL COMMUNICATIONS

Module Title: SOFTWARE DEVELOPMENT FOR TELECOM SYSTEMS

Module Code: OC62601

PREPARED BY:

NGABONZIZA Emmanuel Reg no: 221031465

ASSIGNMENT TOPIC: Software system requirements and specifications for telecom.

July 31, 2023

 2

Abstract
Any application starts with an idea, and the development begins with a Software Requirements
Specification (SRS) document. You might have a truly brilliant and unique digital product idea,
but the journey to the implementation phase ultimately defines whether your application will
succeed or fail. The SRS document is a vital part of this journey.
Approaching software development without documentation and a clear plan leads to a chaotic
implementation process, costly reworks, delays, or even a failed project. In fact, inadequate or
incomplete requirements are the most common reason for project failure. However, it possible to
avoid all these issues and lay the groundwork for a successful outcome by creating accurate and
understandable SRS documentation.
In this work, we explore the essentials of this document, why it’s a cornerstone for any software
project, and what makes up an effective SRS. Moreover, we’ll look on how to write a SRS to
make it a practical guide for stakeholders and all participants involved in the project
development.

1.INTRODUCTION
Software requirements specification is a technical document describing your project’s
functionality, features, design, limitations, and goals. Simply put, an SRS outlines how an
application should operate and how the product development team should build it. While you as
a client may use it to define your project expectations and deliverables, your software
development company will use it to assess the amount of work, define the technology stack, and
estimate the project cost.
Just as a statement of work (SOW), this document is crucial, especially when you outsource
software development. An SRS document serves as a project roadmap for you and your
dedicated team, leaving little room for confusion and misunderstandings. As a single source of
truth that everyone can refer to, the requirement document sheds light on product specifications
and deadlines, ensuring a shared understanding and alignment.
Moreover, it’s next to impossible to develop an app exactly what you expect without an SRS.
That’s why writing down clear software requirements guarantees your development team will
build the product matching your needs. an SRS is helpful for:

Stakeholders to understand what is going to happen with a project and which

requirements must be met

Investors, if there are to evaluate the prospects of software to make an informed decision
any
 3

Software engineers to define the programming languages and plan their work

Designers to create mockups based on requirements and use cases

QA specialists to test software against your requirements and business needs

2.What Does an SRS Include?

Software requirements specification is a blueprint for the development team, providing all the
information they need to build the software according to the specified requirements. But it also
should outline your product’s purpose, describing what the application is supposed to do and
how it should perform.
An SRS can vary in format and length depending on how complex the project is and the selected
development methodology. However, there are essential elements every good SRS document
must contain:
2.1 Purpose of the digital product is a clear and concise statement that defines the intent of the
software. This statement should address your needs, outlining what the app will achieve once
completed.
2.2 Description of the product provides a high-level overview of the software, including
intended users, the type of environment it will operate in, and any other relevant information that
could impact the software development process.
2.3 Functionality of the product describes the features, capabilities, and limitations or
constraints that might affect the software’s performance.
2.4 Performance of the product should include requirements related to its performance in a
production environment: speed, efficiency, reliability, and scalability.
2.5 Non-functional requirements address such factors as security, compatibility, and
maintainability.
2.6 External interfaces include information about how the application will interact with other
systems it must connect to. So, here communication protocols and data formats are described.
Also, it outlines details of the screen layout, logic interface of the software, hardware interface,
and design.
Design constraints or environmental limitations that may impact the development
4
 5

Functional Requirements Document and Non-Functional Requirements

To understand the difference, think of it this way: functional requirements are like the meat and
potatoes of a meal, while non-functional requirements are like the seasoning.
Functional requirements document is essential to the system’s core function, describing the
features and fundamental behavior, just as meat and potatoes are the core elements of a meal.
Without them, the system won’t work as intended, just as a meal won’t be satisfying without the
main course. For example, when you register and sign in to a system, it sends you a welcome
email.
On the other hand, non-functional requirements enhance the user experience and make the
system more delightful to use, just as the seasoning makes a meal more enjoyable to eat. They
specify the general characteristics impacting user experience.
Coming back to an example of the registration confirmation, a welcome email sent within five
seconds after signing in would be a non-functional requirement.
So while functional requirements are crucial to the system’s operation, non-functional
requirements are equally important to the user’s needs and expectations. A system that is slow,
unreliable, or difficult to use will significantly impact the user’s decision to use it.

Functional requirements Non-functional requirements

Outline the functions the app will have Outline how the app will perform

Identify the app’s core features Identify the way the app should behave

Explain what the app must do Explain how the app should do it

Ensure the app meets user requirements Ensure the app meets user expectations

3.Write a Software Requirement Specification Document

The creation of an SRS should be one of the first things to do when you plan to develop a new
project. Writing it may seem difficult, but it’s essential to building successful software. The more
elaborate and detailed your SRS is, the fewer chances for the development team to take the
wrong turns.
To make the process of writing an SRS more efficient and manageable, we recommend you
follow a structure that starts with a skeleton and general information on the project. Then it will
be easier for you to flesh out the details to create a comprehensive draft. Here’s a six-step guide
to creating an SRS document:
 6

Step 1. Create an Outline

The first step is to create an outline that will act as a framework for the document and your guide
through the writing process. You can either create your outline or use an SRS document template
as a basis. Anyway, the outline should contain the following important elements:
Introduction
Purpose
Intended use and target audience
Product scope
Definitions
General description
Business requirements
User needs
Product limitations and constraints
Assumptions and dependencies
Software features and requirements
Features
Functional requirements
External interface requirements
Non-functional requirements
Supporting information
Step 2. Define What the Purpose of Your Software
This section is a summary of the SRS document. It allows you to write a clear picture of what
you want your product to do and how you want it to function. So, here you should include a
detailed description of the intended users, how they will interact with the product, and the value
your product will deliver. Answering the following question will help you to write the purpose:
What problems does your product solve?
Who are the intended users?
Why is your product important?
 7

Step 3. Give an Overview

This section is where you clarify your software’s idea and explain why it can be appealing to
users. Describe all features and functions and define how they will fit the user’s needs. Also,
mention whether the product is new or a replacement for the old one, is it a stand-alone app or an
add-on to an existing system? Additionally, you can highlight any assumptions about the
product’s functionality.
Step 4. Describe Functional and Non-functional Requirements
Often, clients don’t have a clear idea about the intended functionality at the start of the project.
In this case, Relevant cooperates closely with you to understand the demands and assigns
business analysts to assist with it.
Whether you write it internally or with the help of external experts, you should detail all the
requirements associated with your app. For your dedicated development team to understand it
properly, describe this information adequately. It would help them if you include use cases here
as well since they can illustrate how a user will interact with the system.
Step 5. Add Supplemental Details
If you have something else to add, any alternative ideas or proposals, references, or any other
additional information that could help developers finish the job, write them down here.
Step 6. Get Approval
At this part stakeholders review the SRS report carefully and leave comments or additions if
there are any. After edits, give them to read the document again, and if everything is correct from
their perspective, they’ll approve it and accept it as a plan of action. After that, you’re ready to
move toward software development.
4.How to Write Software Use Cases in an SRS
Use cases help you ensure that the users have a smooth and robust experience using your
product. To write use cases, you should put yourself in the shoes of your intended audience and
get a better understanding of how they will interact with your software program. By doing so,
you’ll be able to identify potential issues early on and ensure your product meets the users’
expectations and needs.
To begin, describe your product’s targeted users. Who are they, and what tasks will they need to
perform with your software? Then, focus on one of these users and break down their interaction
into use cases. Each use case will represent a specific interaction the user has with your software
solution.
Now depict the sequence of events that will take place for each use case. This will let you map
out the user’s actions and how your software should respond. Then expand each use case with
alternative actions and probable system responses to ensure that you’ve covered all possible
scenarios.
 8

Finally, repeat these steps for each user type. Thus, you’ll create a comprehensive set of software
use cases that accurately represent how your application will be actually used. By following
these steps, you’ll create software that truly delights your users.

5.Characteristics of a Well Prepared SRS

We provide some features of a good quality SRS so you can ensure your technical requirements
document is good enough to serve as a guide for your software development team.
 9

5.1 Explicit
An SRS requires clear and easy-to-read content using agreed terminology so that all members of
the product development process can easily understand it. Very handy are visuals like diagrams,
models, or schemes as they can explain some points straight away.
5,2 Measurable
Unless the software requirements are measurable, it will be hard to know whether you are going
in the right direction and whether the team is completing the milestones. Project managers have
to understand how to assess the project progress and validate and verify the end product against
the specifications. So, make your requirements measurable.
5.3 Complete
The SRS document must contain all the features you want to build with enough detail for your
development team to complete the project: software requirements, assumptions, dependencies,
and prerequisites. The stakeholders should check whether every part of it is described or if any
details are missing.
5.4 Viable
When writing the specifications, you should take into account the budget, timeframe, and tech
realities of the current environment.
5.5 Flexible
Note that an SRS is a living document that may be updated and refined throughout the
development process, so it’s important to keep it flexible and adjustable.
5.6 Verifiable
It’s also vital to make the document available to all development team members so they can refer
to it whenever necessary. The indicator of clear requirements would be no questions for
clarification or demands for more details from the team.
5.7 Consistent
The software requirements in the document shouldn’t contradict each other. Also, the format of
the whole SRS should be consistent, and ensure you use the same terminology throughout the
paper.
5.8 No Implementation Constraints
Although an SRS requires detailed information, we don’t recommend you make it overly
specific, impose technological or architectural solutions, or specify a design methodology, as it
may restrict software development.
 10

5.9 Accurate
SRS documentation should accurately depict the product’s functionality, specifications, and
instructions so that the team members have no additional questions while using it. So, make sure
every requirement has only one possible interpretation by avoiding subjective suggestions,
ambiguity, and loopholes.
By adhering to these characteristics, you can create an SRS document that meets the needs of all
stakeholders and provides a comprehensive and clear plan of action for your development team.
6.A Software Requirement Specification Typical Example
Below, we provide a condensed SRS document example for a mobile shopping app,
“FashionStyle”.
6.1 Introduction
This document outlines the development plan for “FashionStyle”, a mobile app that will allow
users to browse and purchase clothes from different brands. This plan is intended for software
engineers, designers, and investors of the project.
6.2 Overall Description
In the age of e-commerce, users are constantly seeking convenient ways to shop. However, with
so many brands and products available online, it can be overwhelming for customers to find what
they want. “FashionStyle” aims to solve this problem by offering a platform where consumers
can easily find and buy fashion items from a variety of brands.
6.3 Customers
The target customers are primarily fashion-conscious individuals who prefer to shop online.
They are likely to be tech-savvy and comfortable using mobile apps to make purchases.
6.4 Functionality
Users should be able to create an account with email or social media.
Users should be able to browse and search for clothes based on brand, category, color, and price
range.
Users should be able to view product details, such as descriptions, images, and reviews.
Users should be able to add products to a cart and checkout securely.
Users should be able to receive push notifications about new arrivals, sales, and promotions.
6.5 Platform
The app will be built using React Native, a cross-platform framework that will allow for
both IOS and Android app development. The app will connect to a REST API created with
Node.js and MongoDB to store and retrieve information.
 11

6.6 Development Responsibilities

The software development team for “FashionStyle” will be responsible for programming the app,
designing the user interface, and testing the app for quality assurance.
6.7 User Class and Characteristics
There will be two types of users for “FashionStyle”: customers and admins. Customers will be
able to use all the app’s features, while admins will have access to additional features such as
managing product listings and discounts.
System Features and Requirements
Functional Requirements
Users should be able to browse and search for clothes based on brand, category, color, and price
range.
Users should be able to view product details, such as descriptions, images, and review
Users should be able to add products to a cart and checkout securely
Internal Interfaces
User Interfaces
Back-end software: Node.js
Database software: MongoDB
Front-end software: React Native
Hardware Interfaces
IOS and Android mobile devices
Non-functional requirements
Performance Requirements
The app should load and be ready to use within 5 seconds.
The app should react to user interaction within 2 seconds.
The database should be optimized to ensure fast query performance.
Safety Requirements
The app should ensure secure transactions and protect user data through encryption and other
security measures.
Security Requirements
The REST API’s keys should be stored securely.
 12

Software Quality Attributes

Availability: The app should have a goal of 99.9% availability to ensure customers can shop
anytime.
Correctness: The app should accurately display product information and ensure secure
transactions.
Maintainability: The app should be continuously integrated so that features, updates, and bug
fixes can be deployed rapidly without downtime.
Usability: The interface should be intuitive and easy to navigate, allowing users to shop and
make purchases without confusion.
Common Mistakes to Avoid When Writing an SRS Document
Don’t let your SRS become a confusing mess! While there is no right way to write the
requirement document, we will highlight the most common mistakes to avoid to help you ensure
that your requirements are crystal clear.
First, be careful not to be ambiguous in your language. Remember, an SRS aims to prevent
misunderstandings, so ensure your requirements can’t be misinterpreted. Provide a clear
description for every functionality, and avoid using words with multiple meanings.
Second, avoid overcomplicating your document. Standardizing the language of your document
is not that big of a deal. Simply avoid using jargon and define terms before using them. Also, it
would help to use references, such as “as shown in” or “in accordance with”.
Third, don’t over-specify your requirements. The document is not intended to become a
complete description of the system for developers and architects. Stick to the essentials and
avoid providing too many extra details. This can make the document less readable and vaguer.
Finally, if you struggle with structure and formatting, use a software requirements
specification example to achieve clarity. If you’re unsure how to handle parts of the SRS
template, contact Relevant. We’ll help you write a comprehensive specification document for
your project and ensure your requirements are communicated effectively. Don’t let a poorly
written SRS document derail your project – take the time or assistance to get it right the first
time.
CONCLUSION
The success of any software project relies heavily on the availability of a well-written Software
Requirements Specification document. It’s a critical component that serves as a roadmap for
developers and stakeholders, outlining what the software should do, its technical details, and user
needs.
Although creating a comprehensive SRS takes time and effort initially, and it pay off later with a
robust app that meets both yours and your users’ expectations. Moreover, this document gives
tips to follow for creating an effective and detailed SRS.
 13

List of abbreviations:
1.SRS: software requirement and specification
2.SOW: statement of work
3. REST: representational state transfer
4.API: application programming interface

References
1.https://www.techtarget.com/searchsoftwarequality/definition/software-requirements-
specification
2.https://www.Krazytech.com
3. https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-
document
4. https://relevant.software/blog/software-requirements-specification-srs-document/