American International University-Bangladesh (AIUB) 

Department of Computer Science 
Faculty of Science & Technology (FST) 
E-commerce Management System
A Software Requirement Engineering Project Submitted 
By  
 
Semester: Spring_22_23  Section:  Group Number: 
 
SN  Student Name  Student ID  Contribution Individual 
(CO1+CO2)  Marks 
 1. MD.Sadatur Rahman 16-32606-2    
 2. Barua Shaown 19-40674-1    
3.  Dhar Diponkar Sutra  19-41004-2    
 4.  MD. Sabbirul Arefin Sayed  19-39653-1    
         
 
The project will be Evaluated for the following Course Outcomes 
 
 
Evaluation Criteria  Total Marks (50) 
 
Introduction, Format, Submission, Defense  [10 Marks]   
System Overall Description & Functional Requirements  [10 Marks]   
System Quality Attributes and Project Requirements   [10 Marks]   
UML and E-R Diagram with Data Dictionary  [10 Marks]   
UI/UX Prototyping  [10 Marks]   
 
 
 
 
 
 
 
 
 
 
 
Software Requirements
Specification 
for 
<Project> 
Version 1.0 approved. 
Prepared by <author> 
<organization> 
<date created> 
 
 
 
 
 
Table of Contents 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
 
Revision History 
Name  Date  Reason for Changes  Version 
       
       
 

1. Introduction
1.1. Purpose: The main goal of this Software Requirements Specification is to
define and describe the E-Commerce System's roles and requirements. The purpose
of this document is to explain what kind of software an E-commerce website needs.
Users will be able to look at goods, search for them, and buy them on the website.
This SRS will describe the website's functional and non-functional needs and make it
clear what is expected from the website.
1.2. Document conventions: This SRS document follows the following standards
and typographical conventions:
 Convention for main title:
 Font face: Times New Roman
 Font style: Bold
 Font size: 16
 Convention for sub title:
 Font face: Times New Roman
 Font style: Bold
 Font size: 14
 Convention for body:
 Font face: Times New Roman
 Font style: Bold
 Font size: 12
1.3. Intended Audience and reading Suggestions
This Software Requirements Specification (SRS) document is for people with
different wants and interests in online shopping. Here are the different kinds of
readers and the order in which they should read:
 Developers: The primary audience for this SRS will be the e-commerce
website's developers. To build, implement, and test the system, they will need
a deep understanding of the software requirements. Developers should read
the full paper, paying special attention to sections 2 (Overall Description), 3
(System Requirements), and 4 (Interface Requirements).
 Project Managers: Project managers will monitor e-commerce website
development and ensure it satisfies company needs. For project business goals
 and restrictions, they should study part 2.1 (Product Perspective) and section
2.7 (Assumptions and dependencies).
 Marketing stuff: Marketing personnel will promote the e-commerce website
and its benefits. To understand the software, they need study sections 1.1
(Purpose) and 2.2 (Product Features).
 Users: The end users of the software will be the people who use the e-
commerce website. They should read section 2.3 (User Classes and
Characteristics) to find out what kinds of users the software is made for, and
section 3.4 (Non-Functional/Quality Requirements) to learn about the system's
performance and usage requirements.
To make sure that the website meets the business goals, is reliable, and meets the
expectations of end users, it is important that all stakeholders understand the
requirements in this document.

1.4. Project Scope:

 Customers can sign up and handle their profiles in a safe way.
 Good ways to look for products and services so that they can be found quickly
and easily.
 Making a shopping cart so that customers can buy 'n' number of things and
then check out all at once. Customers can put more things in the cart or take
them out.
 Putting up the "Most Purchased" items in each category of goods in the Shop.
 Shop employees are in charge of things like processing orders, ensuring home
delivery, getting feedback from customers about delivery times, updating the
state of orders, and answering online questions from clients.
 Feedback system, so that people who have bought a product or service can say
what they think about it. Also allow relevant customers to rate specific
products.
 Appropriate payment system and gateway for all popular credit cards, checks,
and other relevant payment methods, as they become available.
1.5. References:
 PHP: -http://www.phptherightway.com/
 HTML5: -http://www.w3schools.com/
 CSS3: -http://www.w3schools.com/
 JAVA Script: -http://www.w3schools.com/
2. Overall description
2.1. Product perspective: The product perspective section of your SRS document
should provide an overview of the system and its interactions with other systems. This
includes the hardware and software platforms on which the system will run, the interfaces
the system must provide, and the data that will be exchanged between the system and
other systems.
For example, your E-commerce Management System may interact with a payment
gateway, a shipping provider, and a customer relationship management system.
Therefore, this section of your document should describe how your system interacts with
these systems and how data is exchanged.

2.2. Product Features:

The product features section of your SRS document should provide a detailed list of the
system's features and functionalities. This should include both core features and any
additional features that are planned for future releases.
For example, some of the core features of an E-commerce Management System may
include user account management, product catalog management, order management,
payment processing, shipping management, and reporting. Additional features may
include inventory management, customer feedback, and marketing tools.

2.3. User Classes and Characteristics:

The user classes and characteristics section of your SRS document should describe the
different.
For example, the user classes for your E-commerce Management System may include
customers, sales representatives, and system administrators. Each user class will have
different requirements and characteristics. Customers may require a user-friendly
interface to browse and purchase products, while sales representatives may need access to
customer information and order data.

This section should also describe any unique requirements or characteristics for each user
class, such as the need for multi-language support or the ability to process large volumes
of data.

2.4. Operating Environment:

The operating environment section of your SRS document should describe the hardware,
software, and network environment in which the E-commerce Management System will
operate. This includes the operating system, database management system, and web
server software that will be used.
For example, your E-commerce Management System may run on a Linux server with a
MySQL database and Apache web server software. This section should also describe any
specific hardware or software requirements, such as minimum processor speed or amount
of RAM needed.
 2.5. Design and implementation Constraints:
The design and implementation constraints section of your SRS document should
describe any limitations or constraints that may impact the design and development of the
E-commerce Management System. This may include legal, regulatory, or technical
constraints.
For example, your system may need to comply with specific data privacy laws, or it may
need to integrate with legacy systems that use outdated technology. This section should
also describe any design or implementation decisions that have already been made, such
as the choice of programming language or database management system.

2.6. User Documentation:

The user documentation section of your SRS document should describe the user manuals,
guides, and other documentation that will be provided to users of the E-commerce
Management System. This includes documentation for both technical and non-technical
users.
For example, your system may require user manuals for customers to explain how to
navigate the website and place orders. It may also require technical documentation for
system administrators to manage the system and troubleshoot issues. This section should
describe the types of documentation that will be provided and how they will be delivered.

2.7. Assumption and Documentation:

The user documentation section of your SRS document should describe the user manuals,
guides, and other documentation that will be provided to users of the E-commerce
Management System. This includes documentation for both technical and non-technical
users.
For example, your system may require user manuals for customers to explain how to
navigate the website and place orders. It may also require technical documentation for
system administrators to manage the system and troubleshoot issues. This section should
describe the types of documentation that will be provided and how they will be delivered.

1. System features and requirements

3.1. Functional requirements:
 The software shall allow users to login with their given username and
password.
 The login credentials (username and password) will be verified with database
records.
 If the login successful, the home page of the user account will be displayed.
 If the username and/or password has been inserted wrong, the random
verification code will be generated and sent to the user’s email address by the
system to retry login.
  If the number of login attempt exceed its limit (3 times), the system shall
block the user account login for one hour [optional function]
Priority Level: High
Precondition: user have valid user id and password
Cross-references: 4.1
 Reporting Requirements
 Administrative functions
 Authorization levels
 Audit Tracking
 External Interfaces
 Historical Data management (2 month)
 Legal and Regulatory Requirements.
3.2. External interface requirements
 Hardware Interfaces
 Operating system: Windows
 Hard disks: 2 GB
 Ram: 512 MB
 Processor: Pentium (R) dual core cpu
 Software Interfaces
 Xampp
 Visual studio
 Mysql server
 User Interfaces
 Admin can view, edit and delete everything on the product.
 User can view the information.
3.3. Non-functional requirements
 Performance Requirements: This system doesn't have any performance
requirements because the server request and answer depend on the internet
connection of the end user.
 Safety Requirements: The database could be wiped out at any time by a virus
or a broken computer system. So, it is important to make a copy of the
information so that it doesn't get lost. In case the power goes out, there should
be a proper UPS or inverter.
 Security Requirements: System will use a store that is safe.  Normal people
can only read information. They can't change or edit anything but their own
information and a few other things. There will be different kinds of users, and
each user's access will be limited in some way.
 Features of software quality:
 There could be more than one manager working on the project, and
each of them will be able to make changes to the system. But members
and other people can't change anything.
 The project should be free for anyone to use.
 The standard of the database is kept up in a way that makes it easy for
all of the people who use it to use.
  The user should be able to download and set up the system quickly.

4. Interface requirements
4.1.Data Dictionary:
Table: Users
Fields:
UserID: unique identifier for each user

- FirstName: first name of the user

- LastName: last name of the user
- Email: email address of the user
- Password: user's password
- Address: user's address
- City: user's city
- State: user's state
- ZipCode: user's zip code
- PhoneNumber: user's phone number
- UserRole: user's role in the system (customer or administrator)

Table: Products
Fields:
- ProductID: unique identifier for each product
- ProductName: name of the product
- ProductDescription: description of the product
- Price: price of the product
- CategoryID: category to which the product belongs
- Quantity: quantity of the product in stock

Table: Categories
Fields:
- CategoryID: unique identifier for each category
- CategoryName: name of the category

Table: Orders
Fields:
- OrderID: unique identifier for each order
- UserID: user who placed the order
- Date: date on which the order was placed
- TotalAmount: total amount of the order
- Status: status of the order (processed, shipped, delivered)

Table: OrderDetails
Fields:
- OrderDetailID: unique identifier for each order detail
- OrderID: order to which the order detail belongs
- ProductID: product that was ordered
- Quantity: quantity of the product that was ordered
- UnitPrice: unit price of the product that was ordered

Table: ShoppingCart
Fields:
- ShoppingCartID: unique identifier for each shopping cart
- UserID: user who owns the shopping cart
- DateCreated: date on which the shopping cart was created
Table: ShoppingCartDetails
Fields:
- ShoppingCartDetailID: unique identifier for each shopping cart detail
- ShoppingCartID: shopping cart to which the shopping cart detail belongs
- ProductID: product that was added to the shopping cart
- Quantity: quantity of the product that was added to the shopping cart
- UnitPrice: unit price of the product that was added to the shopping cart

4.2.Usecase Diagram
5. Other requirements
5.1. Glossary: A glossary is a useful component of any software development project,
including an e-commerce management system. It is a document that defines and explains key
terms and concepts used in the project, making it easier for all stakeholders to understand and
communicate effectively. In the context of a Software Requirements Specification (SRS), the
glossary section would provide a comprehensive list of all technical and business terms that are
relevant to the e-commerce management system. It should be written in clear and concise
language, using terminology that is consistent with industry standards.
Some examples of terms that might be included in the glossary section of an e-commerce
management system SRS could include:

1. Product catalog: A database or list of all products that are available for purchase on the e-
commerce platform.

2. Shopping cart: A feature that allows customers to select and save products they wish to
purchase before completing the checkout process.

3. Payment gateway: A third-party service that facilitates online payments by securely

processing credit card or other payment information.

3. Fulfillment: The process of preparing and shipping orders to customers once they have
been placed and paid for.

4. Inventory management: The process of tracking and managing the levels of stock
available for sale on the e-commerce platform.

5. User roles: Different levels of access and permissions granted to users of the e-commerce
management system, such as customer, administrator, and vendor.
Having a glossary section in the SRS ensures that all stakeholders have a clear understanding of
the terminology used in the project, which can help prevent misunderstandings and facilitate
effective communication throughout the development process.

5.2.Analysis Model:
The analysis model is an important component of the software development process, and it is
often included as part of the Software Requirements Specification (SRS).
The analysis model is a high-level description of the e-commerce system's functionality,
structure, and behavior. It is developed to help stakeholders understand the business
requirements of the system and how it will work in practice.

The analysis model typically includes several key elements, including:

1.Use Cases: A use case is a description of a specific scenario in which a user interacts with
the e-commerce system. Use cases help to identify the functional requirements of the system,
including what tasks users will be able to perform and what inputs and outputs are involved.

2.Activity Diagrams: Activity diagrams provide a visual representation of the flow of

activities or processes within the e-commerce system. They help to identify the various steps
involved in different use cases and how they are related to each other.

3.Class Diagrams: Class diagrams describe the different objects and classes that make up the
e-commerce system. They help to define the structure of the system and how different
components are related to each other.

4.Sequence Diagrams: Sequence diagrams show the interactions between different

components of the e-commerce system, including users, database, and external systems. They
help to identify how different parts of the system interact with each other to perform specific
tasks.

The SRS typically includes the analysis model to provide a comprehensive description of the e-
commerce system's requirements. This ensures that all stakeholders have a clear understanding
of the functionality, structure, and behavior of the system, which is critical for the successful
development and implementation of the project.

5.3.Issues list/ TBD:

the Issues List or "To Be Determined" (TBD) section is an important part of the Software
Requirements Specification (SRS). This section is used to identify any areas of the project where
further information is needed, or where decisions have not yet been made.

The Issues List/TBD section typically includes the following:

1.Open Questions: This section lists any questions or concerns that have been raised during
the project but have not yet been fully resolved. These may relate to specific requirements,
design decisions, or other areas of the project.

2.Pending Decisions: This section lists any decisions that still need to be made in order to
move forward with the project. This may include decisions related to the design of the system,
the selection of technology or vendors, or other important aspects of the project.

3.Assumptions: This section lists any assumptions that have been made during the project,
such as assumptions about user behavior or system performance. These assumptions may need to
be revisited and updated as the project progresses.

4.Dependencies: This section lists any dependencies or constraints that may impact the
project, such as requirements from other systems or external factors like regulatory compliance.
The Issues List/TBD section is important because it helps to identify any areas of the project that
require further clarification or decision-making. By identifying these issues early on in the
project, it is possible to address them proactively and avoid delays or other problems later on.
In addition to the Issues List/TBD section, the SRS may also include a section for Change
Requests, which outlines any changes that have been requested to the requirements or design of
the e-commerce management system. This helps to ensure that all stakeholders are aware of any
changes that may impact the project timeline, budget, or scope.