Software Requirements

Specification

for

<Project Title>
Version 1.0

Prepared by

Group Name: <place your group name here>

<name>Atif Mahmood <student #>118 <e-mail>
<name>Basit Munir <student #>121 <e-mail>
<name>Hamza Shahid <student #>127 <e-mail>
<name>Salman Arshad <student #> <e-mail>

Supervisor: <your Supervisor name here>

Coordinator: <your Coordinator’s name here>

Date: <place the date of submission here>

Software Requirements Specification for <Project> Page ii

Content

REVISIONS................................................................................................................................................................III
1 INTRODUCTION................................................................................................................................................1
1.1 DOCUMENT PURPOSE.................................................................................................................................1
1.2 PRODUCT SCOPE........................................................................................................................................1
1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW....................................................................................1
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS........................................................................................1
1.5 DOCUMENT CONVENTIONS.........................................................................................................................1
1.6 REFERENCES AND ACKNOWLEDGMENTS...................................................................................................2
2 OVERALL DESCRIPTION...............................................................................................................................3
2.1 PRODUCT PERSPECTIVE.............................................................................................................................3
2.2 PRODUCT FUNCTIONALITY..........................................................................................................................3
2.3 USERS AND CHARACTERISTICS..................................................................................................................3
2.4 OPERATING ENVIRONMENT.........................................................................................................................3
2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS..........................................................................................4
2.6 USER DOCUMENTATION..............................................................................................................................4
2.7 ASSUMPTIONS AND DEPENDENCIES...........................................................................................................4
3 SPECIFIC REQUIREMENTS...........................................................................................................................5
3.1 EXTERNAL INTERFACE REQUIREMENTS.....................................................................................................5
3.2 FUNCTIONAL REQUIREMENTS.....................................................................................................................6
3.3 BEHAVIOUR REQUIREMENTS......................................................................................................................6
4 OTHER NON-FUNCTIONAL REQUIREMENTS..........................................................................................7
4.1 PERFORMANCE REQUIREMENTS................................................................................................................7
4.2 SAFETY AND SECURITY REQUIREMENTS...................................................................................................7
4.3 SOFTWARE QUALITY ATTRIBUTES..............................................................................................................7
5 OTHER REQUIREMENTS................................................................................................................................8
APPENDIX A – DATA DICTIONARY.......................................................................................................................9
APPENDIX B - GROUP LOG..................................................................................................................................10
Software Requirements Specification for <Project> Page iii

Revisions
Version Primary Author(s) Description of Version Date Completed
Draft Type Full Name Information about the revision. This table does 00/00/00
and not need to be filled in whenever a document is
Number touched, only when the version is being upgraded.

<In this template you will find text bounded by the “<>” symbols. This text appears in italics
and is intended to guide you through the template and provide explanations regarding the
different sections in this document. There are two types of comments in this document.
These comments that are in black are intended specifically for that course. These comments
that are in blue are more general and apply to any SRS. Please, make sure to delete all of
the comments before submitting the document.

The explanations provided below, do not cover all of the material, but merely, the general
nature of the information you would usually find in SRS documents. It is based on the IEEE
requirements and was adapted specifically for the needs of Software Engineering
3K04/3M04 courses. Most of the sections in this template are required sections, i.e. you
must include them in your version of the document. Failure to do so will result in marks
deductions. Optional sections will be explicitly marked as optional.
Software Requirements Specification for <Project> Page 1

1 Introduction
<TO DO: Please provide a brief introduction to your project and a brief overview of what the reader
will find in this section.>

1.1 Document Purpose

The purpose of this software requirement specification (SRS) document is to provide the users a
complete picture of the system and detailed information about the system services that are
provided to the user’s. The document covers all of the software’s intended features, and along with
it gives a detailed information about the graphical interfaces (GUI’S) of the system. It will also
provide the information about the system performance and system security.

1.2 Product Scope

The I-trade system is a web based system, that is all about providing the users an ease to sell,
buy, mend or even help in repairing their I-phones. Our system will simply do a verification test to
identify I-phone by uploading pictures and processing them. Image filtration can also be done to
get clearer outlook of pictures. The I-phone can also be rated out of 10, if required, using the
images.

1.3 Intended Audience and Document Overview

This SRS document is for all the stakeholders that are the participants of the system, including the
users, developers, and supervisor. The readers shall consider Chapter 1 (Introduction) and
Chapter 2 (Overall Description), which gives a complete and detailed introduction and overview of
the system.

The readers can read core features and services that are provided by the I-trade system in
Chapter 3 (Specific Requirements) of SRS.

Readers that are interested in knowing about the non-technical aspects of the system must visit
Chapter 4 (Other non functional requirements) which includes all of the information about the
performance, security, safety and other attribute of the system that might be important for the
users.

1.4 Definitions, Acronyms and Abbreviations

These are the following abbreviations that the users might need to know:
 Image processing (IP).
 Object detection (OP).
 Object verification (OV).
 Image filtration (IF).
 Software Requirement Specification (SRS).
Software Requirements Specification for <Project> Page 2

Term Definition
1.5 D
Image Processing It is a method to perform some operations on an image, in o
order to get an enhanced image or to extract some useful c
information from it. u
Object Detection It is a technique that allows us to identify and locate objects m
in an image. e
A technique to know whether the uploaded mobile pictures n
Object Verification
are of I-phone or not.
Image Filtration Filtering an image is a technique for modifying and
t
enhancing an image.
Mobile Rating Based on the condition of mobile that is judged through the
uploaded pictures through image processing the mobile is
rated out of 10.
Software Requirements A document that completely describes all of the functions
Specification of a proposed system and the constraints under which it
must operate. For example, this document.
Stakeholder Any person with an interest in the project.
User Reviewer or Author.
Conventions
These are the following document conventions our document is following.
Formatting Conventions:
We are using the Arial font with a font size of 12 form the font family.
Styling conventions:
The writing style that we are using in this document is Italic. More over the headings and the sub-
headings are in the bold text.
Glossary:

1.6 References and Acknowledgments

<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document.

TO DO: Use the standard IEEE citation guide for this section. An example citation guide is posted
for you on the website.>
Software Requirements Specification for <Project> Page 3

2 Overall Description
2.1 Product Perspective
The product I-Trade is a system that fully focuses on the buying, selling, purchasing and even
repairing or mending of the users I-phone. As compared with other systems such as OLX, E-bay
that focuses on every product belonging to different categories but our system fully focuses on the
trading of I-phone mobile devices only.
The I-trade product database might store the following information.
 User’s details.
 New mobiles information.
 Old mobiles information.
 Repairing Orders details.
 Repairing orders status.

2.2 Product Functionality

The list that is mentioned below offers a complete outline and description of the main features and
functionalities of the I-Trade system. The following list contains all of the system core features that
are necessary for the system to correctly perform its services.

1. User Registration.
 Registration form only appears once on the screen for the new user.
 User register him/her self on the system.
 After registration user becomes an authenticated user.
Software Requirements Specification for <Project> Page 4

2. User Login.
 User can login into the system through entering their email and password.
 User can also login through gmail and facebook.

3. I-phone Repairing.
 User can ask for I-phone maintenance work.
 User will enter all the required information.
 Also mention address.

4. Upload I-phone Pictures.

 User can upload their mobile pictures.
 User can check their mobile market price.

5. Market price calculation.

 User shall submit pictures to calculate the market price.
 User shall know about the mobile market price.

6. Check new mobiles.

 User shall check all the new mobiles available.
 User shall check their prices.

7. Buy new I-phone.

 User shall check new models and their prices.
 User shall buy new I-phones.

8. Upgrade I-phone.
 User shall upgrade their I-phone.
 User shall sell their old I-phone.
 User shall purchase new I-phone by paying the additional amount.

9. Update Profile.
 User shall update their profile.

10. Repairing Orders.

 Admin can check all of the repairing orders.

11. Repairing order status.

 Admin shall check the repairing orders status.
 Admin shall check the orders that are completed and also the pending orders.

2.3 Users and Characteristics

There are 3 kinds of users that will be interacting with the system. On number one there are those
users that are willing to buy a new I-phone. On number second there are those users who want to
upgrade their I-phone by selling the old I-phone and paying the remaining amount to buy the new I-
phone they desire. The last and final users of this system are those who want the repairing
services from us. The first two users are thee most important users of this system on the basis of
finance.

Users that are interested in buying new I-phones will interact with the (Check new mobiles and
prices, Buy new I-phones) functionalities. Those users who are willing to upgrade their I-phones
might interact with (Upload I-phone Pictures, Upgrade I-phone, Market price calculation)
Software Requirements Specification for <Project> Page 5
functionalities. User that interact with the system for repairing services might interact with (I-phone
Repairing) services of this system.

2.4 Operating Environment

The I-trade system is a web based system. This system will operate on those computer devices
that are operating on Microsoft operating systems such as (Windows operating system). The
system will best work on the windows 7 and windows 10. The system will perform its best services
on google chrome browser other browsers may not support some of the system features.

2.5 Design and Implementation Constraints

The tools that are used to develop this project must be PHP, HTML, CSS, Javascript, Bootstrap.
Database used for the storage of data must be mySqli. The I-trade system must be a web based
system. The color schemes must be good for the user to provide a good interface such as not too
much dull colors neither too much light colors. The designing of screens must be easy for the
users to understand and navigate with. The buttons and other elements must be aligned on the
screen and should be of suitable size too.

2.6 User Documentation

The system will be designed in such a way that I will be easy for the user to interact with. How ever
the user might need some supplementary information too about some features of the system. Fro
this purpose there will be two manuals Help and I-Trade tutorial. The help menu is basically a
combination of the system components. The I-Trade tutorial is a short video which is the step by
step demonstration of each of the system feature.

2.7 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated in
the SRS. These could include third-party or commercial components that you plan to use, issues
around the development or operating environment, or constraints. The project could be affected if
these assumptions are incorrect, are not shared, or change. Also identify any dependencies the
project has on external factors, such as software components that you intend to reuse from
another project.
TO DO: Provide a short list of some major assumptions that might significantly affect your design.
For example, you can assume that your client will have 1, 2 or at most 50 Automated Banking
Machines. Every number has a significant effect on the design of your system. >
Software Requirements Specification for <Project> Page 6

3 Specific Requirements
3.1 External Interface Requirements
3.1.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., Cancel) that will
appear on every screen, error message display standards, and so on. Define the software
components for which a user interface is needed.
TO DO: The least you can do for this section is to describe in words the different User Interfaces
and the different screens that will be available to the user. Those who will be able to provide
optional Graphical User Interface screenshots, will be rewarded by extra marks.>

3.1.2 Hardware Interfaces

As I-trade system is a web based system and it does not need any complex hardware other than
laptops, pc’s, mobile phones, tablets and an internet connection.

3.1.3 Software Interfaces

I-trade system is a web based system and is also deployed on the server so we will require a
server side scripting language. For this purpose, we are using PHP. As the system is also using
Image processing techniques so we are also using Python. To store all of the important information
we are using MYSQLI database.

3.1.4 Communications Interfaces

<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication standards
that will be used, such as FTP or HTTP. Specify any communication security or encryption issues,
data transfer rates, and synchronization mechanisms.

TO DO: Do not go into too much detail, but provide 1-2 paragraphs were you will outline the major
communication standards. For example, if you decide to use encryption there is no need to specify
the exact encryption standards, but rather, specify the fact that the data will be encrypted and
name what standards you consider using. >
Software Requirements Specification for <Project> Page 7

3.2 Functional Requirements

Functional Requirement 1: User Registration
Description: All the new users will register themselves on the system by using this feature.
Response and sequence:
1) A registration form shall be displayed to the user.
2) User shall fill all of the required fields.
3) User shall click on the register button.
4) Data is then transferred to the system database.

Functional Requirement 2: User Login

Description: To use the I-trade services user login to their accounts by this feature.
Response and sequence:
1) Login form is shown to the registered users.
2) User shall enter their login credentials.
3) System then verifies the login credentials from database.
4) If login credentials are correct user shall log into their account.
5) If not user shall enter the login credentials again.

Functional Requirement 3: I-phone Repairing

Description: If a user is looking for maintenance work of their I-phone then they will use this
system feature.
Response and sequence:
1) User shall click on repairing services button.
2) User will be displayed by a repairing form.
3) User fill all of the required fields.
4) User then submits the repairing form on clicking the confirm order button.
5) A mobile engineer is then go the given address to perform the maintenance work.

Functional Requirement 4: Upload I-phone Pictures.

Description: If a user wants to upload their mobile pictures for selling or upgrading they will use
this feature.
Response and sequence:
1) User shall click on upload pictures button.
2) User shall select pictures to be uploaded from their respective devices.
3) User shall click on submit pictures button.
4) Pictures are then uploaded to the server.

Functional Requirement 5: Market Price Calculation.

Description: This system feature is responsible to calculate the I-phone market price by
processing images that are uploaded by the user.
Response and sequence:
1) Pictures uploaded by user are then filtered if required,
2) Pictures are then processed further to detect scratches, dents etc in the mobile.
3) Based on the mobile condition it is rated out of 10.
4) Based on it’s rating out of 10 it’s market price is calculated.

Functional Requirement 6: Check New Mobiles.

Description: Users that are looking for new mobiles and their prices shall use this system feature.
Response and sequence:
1) User shall click on new mobile button.
2) A new screen will open consisting of all the new mobiles available and information related
to them.
Software Requirements Specification for <Project> Page 8

Functional Requirement 7: Buy New I-phone.

Description: The users who are willing to buy new I-phones shall use this feature.
Response and sequence:
1) User shall click on buy new I-phone button.
2) User shall select new I-phone.
3) User shall select the payment method.
4) User shall pay the amount.
5) The new I-phone is then delivered to the user on their doorstep.

Functional Requirement 8: Upgrade I-phone.

Description: Users who want to sell their old I-phones and buy new I-phones by paying the
additional amount shall use this feature of the I-trade system.
Response and sequence:
1) User shall click on Upgrade I-phone button.
2) User shall sell their old I-phone.
3) User shall select new I-phone.
4) User shall select the payment method to pay the remaining amount.
5) User shall pay the remaining amount.
6) New I-phone will be delivered to user on their doorstep.

Functional Requirement 9: Update Profile.

Description: By using this system feature user shall update their profile.
Response and sequence:
1) User shall click on update profile button.
2) A new form will open containing user profile details.
3) User shall update any field such as name, password etc.
4) User shall click on submit updated profile button.
5) Old data in system database has been replaced by new data that is submitted by user.

Functional Requirement 10: Repairing Orders.

Description: This system feature is only intended for admin use only. By using this feature admin
can check all of the repairing orders.
Response and sequence:
1) The admin shall access this feature through admin panel.
2) Admin shall check all of the mobile repairing or maintenance orders.

Functional Requirement 11: Repairing Orders Status.

Description: Like the above system feature this feature is also intended for admin use only. By
using this feature admin can check status (such as remaining or done) of the repairing orders.
Response and sequence:
1) Admin shall access this feature from admin portal.
2) Admin shall click on repairing orders status button.
3) Admin shall check orders that are pending or remaining.
4) Admin shall check orders that are completed or done.

3.3 Behaviour Requirements

3.3.1 Use Case View

<A use case defines a goal-oriented set of interactions between external actors and the system
under consideration. Since sometimes we will not be able to specify completely the behaviour of
Software Requirements Specification for <Project> Page 9
the system by just State Diagrams, we use use-cases to complete what we have already started in
section 3.3.1.

TO DO: Provide a use case diagram which will encapsulate the entire system and all possible
actors. Do not include detailed use case descriptions (these will be needed when you will be
working on the Test Plan), but make sure to include a short description of what every use-case is,
who are the actors in your diagram. For more information please refer to your UML guide and the
MiniThermostat SRS example file.>
Software Requirements Specification for <Project> Page 10

4 Other Non-functional Requirements

4.1 Performance Requirements

4.2 Safety and Security Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well as
actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied. Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements.
TODO:
 Provide at least 3 different safety requirements based on your interview with the client or,
on your ABM related research, and again you need to be creative here.
 Describe briefly what level of security is expected from this product by your client and
provide a bulleted (or numbered) list of the major security requirements.>

4.3 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.

TODO: Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Portability, etc…) provide requirements
related to the different software quality attributes. Base the information you include in these
subsections on the material you have learned in the class. Make sure, that you do not just write
“This software shall be maintainable…” Indicate how you plan to achieve it, & etc…Do not forget to
include such attributes as the design for change. Please note that you need to include at least 2
quality attributes, but it is the mere minimum and it will not receive the full marks.>

5 Other Requirements
<This section is Optional. 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.>
Software Requirements Specification for <Project> Page 11

Appendix A – Data Dictionary

<Data dictionary is used to track all the different variables, states and functional requirements that
you described in your document. Make sure to include the complete list of all constants, state
Software Requirements Specification for <Project> Page 12
variables (and their possible states), inputs and outputs in a table. In the table, include the
description of these items as well as all related operations and requirements.>
Software Requirements Specification for <Project> Page 13

Appendix B - Group Log

<Please include here all the minutes from your group meetings, your group activities, and any
other relevant information that will assist the Teaching Assistant to determine the effort put forth to
produce this document>