Software Requirements
Specification
<Project Name>
Group Members
______________
______________
______________
Version 1.0 approved
<date created>
<Project Name>
Page ii
Table of Contents
Table of Contents .......................................................................................................................... ii
Revision History ........................................................................................................................... iii
1. Introduction ..............................................................................................................................1
1.1
1.2
1.3
1.4
1.5
1.6
Purpose ........................................................................................................................................ 1
Document Conventions ............................................................................................................... 1
Definitions, Acronyms, and Abbreviations ................................................................................. 1
Intended Audience ....................................................................................................................... 1
Scope ........................................................................................................................................... 1
Overview ..................................................................................................................................... 1
2. Overall Description ..................................................................................................................2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Product Perspective ..................................................................................................................... 2
Product Functions ............................................................ Ошибка! Закладка не определена.
User Classes and Characteristics ..................................... Ошибка! Закладка не определена.
Operating Environment ............................................................................................................... 4
Design and Implementation Constraints.......................... Ошибка! Закладка не определена.
User Documentation ........................................................ Ошибка! Закладка не определена.
Assumptions and Dependencies ...................................... Ошибка! Закладка не определена.
3. External Interface Requirements ...........................................................................................4
3.1
3.2
3.3
3.4
User Interfaces ............................................................................................................................. 4
Hardware Interfaces..................................................................................................................... 4
Software Interfaces ...................................................................................................................... 5
Communications Interfaces ......................................................................................................... 5
4. System Features ............................................................... Ошибка! Закладка не определена.
4.1
4.2
System Feature 1 ......................................................................................................................... 5
System Feature 2 (and so on) ...................................................................................................... 6
5. Other Nonfunctional Requirements .......................................................................................6
5.1
5.2
5.3
5.4
5.5
Performance Requirements.......................................................................................................... 6
Safety Requirements .................................................................................................................... 6
Security Requirements................................................................................................................. 6
Software Quality Attributes ......................................................................................................... 7
Business Rules ............................................................................................................................. 7
6. Other Requirements ................................................................................................................7
Appendix A: Glossary....................................................................................................................7
Appendix B: Analysis Models .......................................................................................................7
Appendix C: To Be Determined List ............................................................................................7
<Project Name>
Page iii
Revision History
Name
Date
Reason For Changes
Version
<Project Name>
Page 1
1. Introduction
1.1 Purpose
This Software Requirements Specification document will be expounding upon all the capabilities
our project includes in order to fulfill the business, stakeholder and user needs. The software
requirements specification lays out functional and non-functional requirements that the software
may provide. This document provides the scope of our work and includes features to customer
requirements.
1.2 Document Conventions
The font being used in this document is:
● Arial for the headings, font size of 18.
● Arial for Sub-headings, font size of 14.
● Arial for the body text, font size of 12.
1.3 Definitions, Acronyms, and Abbreviations
< Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the
SRS.>
1.4 Intended Audience
This Software Requirements document is intended for:
● End users of this application who wish to read and find out about the capabilities of the project.
This will include the users, and service providers.
● Developers who can review project’s capabilities and more easily understand where their efforts
should be targeted to improve or add more features to it (it sets the guidelines for future
development).
1.5 Scope
Automating the Service Providing activities is going to provide the people with service provider
needs and also the service provider with a platform through which they can engage with users,
manage their activities, and work with a broader market. The project revolves around providing a
platform with different interfaces for both users and service providers, ending up with two custom
portals to fulfil different needs.
1.6 Overview
• Section 2 consists of product perspective, product features, user classes, operating environment,
implementation constraints, user documents, assumptions and dependencies.
• Section 3 consists of user interfaces, software interfaces and communications interfaces.
• Section 4 consists of all the functional requirements of the project.
• Section 5 consists of all the non-functional requirements of the project.
<Project Name>
Page 2
2. Overall Description
2.1 Product Perspective
There is a great demand in the labour services sector in our country. In one single street in Karachi
well over 150 daily wage labourers with experience in masonry, carpentry, plumbing, quarry and
well digging and everything in between sit on the sidewalk waiting for prospective employers, there
are dozens of certain streets spread out in the city. With no formal education and low incomes, these
daily wage labourers suffer the plight of living in poverty. Keeping all of this in mind we plan to
ease some of the misery suffered by them by providing a Mobile Application/SMS based platform
to get them work based upon their skill and performance. No one likes a clogged drainage or a short
circuit in the electricity line, but these problems can occur at any time and forces the consumer to go
and find the appropriate labour with known skills to come and fix the issue. This not only can
become a hassle but also wastes a lot of time and money. Not only we plan to ease their urgent
problems in a small amount of time but our platform will help the user get their desired skilled
labour for the renovation and repairing of any certain issue. We are aiming to provide a platform for
consumers who find it hard to get services at a decent price. There are some organizations and
companies who are doing this very comparatively like us but just as. Kaardan and Kaamkaaj offer
similar services and features but our platform offers some unique features which differentiate us.
The platforms which already exist don’t have some key features which are helpful for both users
and service providers. These features include zone based access which will help in getting quick
response as the service provider will be within the particular zone the consumer resides in and SMS
based registration and finding work for service providers who don’t have smartphone and internet
access.
2.2 Product Features*
Customer Panel:
 Registration/Login
 List Of Services Provided
 Feedback (Review)
 Map view of workers
 Service Wanted
 View Top Rated Workers
Worker Panel:
 Registration/Login (App)
 Registration through SMS
 Profile Details
 SMS received upon request
 Performance benefits
<Project Name>
Page 3
Admin Panel:
 Dashboard
 Request Monitoring/Management
 Analytics
 Data Monitoring
2.3 User Classes and Characteristics
The application will allow the customers to login and book a service provider of their choice
according to their needs. They will also be able to contact the service provider. The customers will
have an option to book multiple service providers of one aspect at a time (1 Plumber and 1
Electrician. But not 2 Electricians). The portal also allows customers to view the ratings of the best
service providers in an area. Those ratings will be formed through the rating the users gives to the
service provider as feedback. These ratings directly affect the driver’s profile and help alleviate the
process of a service provider getting better work. The users will be able to view the base location of
the service provider on a map with an icon denoting which service provider it is.
2.4 Operating Environment
The project will deliver an application for Android Operating Systems (Mobile Application) and
also a website. Since the application provides a channel for the users, it needs to be accessible by a
mobile phone for quick retrieval of information. The work on the mobile application will initiate in
the second phase.
2.5 Design and Implementation Constraints*
System constraints:
The constraints implemented for the use of the system are as follows:
Software constraints:
Appropriate operating environment required for the system to run as expected and perform
according to what is expected of the user
Cultural constraints:
The language of use must be English since that is a medium that is globally understood and
implemented by all.
Legal constraints:
The application must not plagiarize information from other applications, or copy their
functionalities to avoid legal causes
Knowledge Constraints:
The users of the system should be familiar with the use of such applications since the design of the
application will be based on common applications.
User Constraints:
The users of the application must be an experienced service provider, and must be authenticated in
order to access service provided by the application. The service providers must also have a CNIC
for identification.
<Project Name>
Page 4
2.6 User Documentation*
<List the user documentation components (such as user manuals, on-line help, and tutorials) that
will be delivered along with the software. Identify any known user documentation delivery formats
or standards.>
2.7 Assumptions and Dependencies
The assumptions for the project are:
● The service providers and users have access to a phone. The user must have a smartphone with
internet access however the service provider can have any phone with SMS capability to use the
platform.
● The service providers and users have knowledge of simple English to use the application more
effectively. The ability to understand and use the smartphone will also be required.
The dependencies for the project are:
● The users must be registered to access the information of the application.
● The service providers must be verified.
● The service providers must have their field verified.
● The users must be verified, to contact service providers and post reviews.
● The user must have their notifications for the application turned on to get the push notifications
3. External Interface Requirements
3.1 User Interfaces
<Describe the logical characteristics of each interface between the software product and the users.
This may include sample screen images, any GUI standards or product family style guides that are
to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will
appear on every screen, keyboard shortcuts, error message display standards, and so on. Define
the software components for which a user interface is needed. Details of the user interface design
should be documented in a separate user interface specification.>
3.2 Hardware Interfaces
OPUS, a digital platform catering to handyman needs, is mobile based as well as web based. The
web app is compatible with all the browsers and can be run on any operating system and processor.
For mobile app an interface is required which supports Android OS. The database connectivity
requires a hardware configuration with a fast database system running on high rpm hard-disk
permitting complete data redundancy and back-up systems to support the primary goal of reliability.
The system must interface with the standard output device, keyboard and mouse to interact with this
software.
<Project Name>
Page 5
3.3 Software Interfaces
Database management systems are required software products for our platform because all data
about the system must be stored in a database for later use and system functionality. This DBMS
requirement is an essential software interface which is required for the collaborative functionalities
which will be taking place between the drivers, as well as the users. The DBMS we will be using is
Firebase, is a free and open-source relational database management system emphasizing
extensibility and technical standards compliance. It is designed to handle a range of workloads,
from single machines to data warehouses or Web services with many concurrent users. Firebase is
apt for our software product as well will have two portals interacting with each other, one allowing
the user to book a service and track package, the other allowing the driver to offer a service. All this
information is maintained on the database and is updated regularly with every function taking place
in the system. The communication between the database and the web portal consists of operation
concerning both reading and modifying the data. Another server that will be used is Google Map
Server to provide geographical service and to track the delivery of the package which is primarily
for the use of the Users, as well as the location of the user which will be displayed to the driver. In
terms of user interface, for android the application the front end will be developed via React native
and backend will be implemented via Nodejs.
3.4 Communications Interfaces
The system must utilize the standard HyperText Transfer Protocol (HTTP) to ensure maximum
inter-browser compatibility. The client accesses the system through a web browser or through an
app.
4. Functional Requirements
<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, mode of operation, user class, object class, functional hierarchy, or combinations of
these, whatever makes the most logical sense for your product.>
4.1 System Feature 1
<Don’t really say “System Feature 1.” State the feature name in just a few words.>
4.1.1
Description and Priority
<Provide a short description of the feature and indicate whether it is of High, Medium, or
Low priority. You could also include specific priority component ratings, such as
benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a
high of 9).>
4.1.2
Stimulus/Response Sequences
<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated with
use cases.>
4.1.3
Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the
services provided by the feature, or to execute the use case. Include how the product
<Project Name>
Page 6
should respond to anticipated error conditions or invalid inputs. Requirements should
be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a
placeholder to indicate when necessary information is not yet available.>
<Each requirement should be uniquely identified with a sequence number or a meaningful
tag of some kind.>
REQ-1:
REQ-2:
4.2 System Feature 2 (and so on)
5. Nonfunctional Requirements
5.1 Performance Requirements
● Responses to view information shall take no longer than 5 seconds to appear on the screen
● For each session, the system shall guarantee the connection time 5 minutes from last input, after
which the connection will be deemed expired. A close operation will be performed when expired.
This design is to satisfy each user’s usability and connection quality.
● The system shall update all service providers and user information after every update made in the
database.
5.2 Safety Requirements
● System uses the system memory and resources in a controlled manner so the software won't have
any safety issues.
● Conduct risk assessments to identify potential risks or hazards so that it can be eliminated.
● Ensure effective training is provided to all service providers so that they can carry out their work
safely.
● If there is extensive damage to a wide portion of the database due to catastrophic failure, such as a
disk crash, the recovery method restores a past copy of the database that was backed up to archival
storage (typically tape) and reconstructs a more current state by reapplying or redoing the
operations of committed transactions from the backed up log, up to the time of failure.
5.3 Security Requirements
● System will use secured database
● Normal users and service providers can just read information but they cannot edit or modify
anything except their personal and some other information.
● All exchanges from client to server involving private data shall occur using the highest available
level of secure connection (e.g., https).
● User authentication for login, email addresses should be verified before the system grants user
access. The entered email address to register shouldn’t contradict with any existing email address
already registered.
<Project Name>
Page 7
5.4 Software Quality Attributes
<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility,
interoperability, maintainability, portability, reliability, reusability, robustness, testability, and
usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify
the relative preferences for various attributes, such as ease of use over ease of learning.>
5.5 Business Rules
<List any operating principles about the product, such as which individuals or roles can perform
which functions under specific circumstances. These are not functional requirements in
themselves, but they may imply certain functional requirements to enforce the rules.>
6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>
Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.>
Appendix B: Analysis Models
<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>
Appendix C: To Be Determined List
<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they
can be tracked to closure.>