Final Year Project Report

DealDocSign (e-signature Platform)

Project Advisor:
Amjad Ali
Submitted By:
Muhammad Talha Saeed [F2020065229]
Muhammad Rashid [F2020065260]
Roqia Zahra Ghafoori [F2020065265]
Muhammad Shoaib Khan [F2020065148]
Session (2020-2024)
University of Management and Technology
C-II Johar Town Lahore Pakistan

|P a g e
Project Title: DealDocSign- A Platform for Secure Document Collaboration.

Objectives:-
 Specific: Create a web application called "DealDocSign" that combines advanced
document management and electronic signature features in an integrated platform.
 Measurable: Develop a platform where people can upload, save and sign
documents electronically while we measure specific availability indicators like
how quickly it responds or processes e-signatures effectively.
 Achievable: Ensure that, with a clear project plan, "DealDocSign" is developed
and deployed within the planned time and budget.
 Relevant: Meet the surge in demand for secure and effective document
management and electronic signatures in the digital age, for the individual and
business alike.
 Time-bound: Finish making "DealDocSign" within an eight-month period with
ongoing help and enhancements afterwards.
Undertaken by: -

 Muhammad Talha Saeed [F2020065229]

 Muhammad Rashid [F2020065260]
 Roqia Zahra Ghafoori [F2020065265]
 Muhammad Shoaib Khan [F2020065148]

Supervised by: Mr. Amjad Ali

Starting Date: October 2, 2023 (Fall 2023)

Completion Date: July 31, 2024 (Spring 2024)

|P a g e
 PLAGIARISM REPORT

|P a g e
 Dedication
This project is dedicated to:
 Allah, our Creator and Prophet ‫ صلى الله عليه وسلم‬who blessed us with the
required resources that led us to the completion of this project.
 Our families, for their unwavering support, understanding, and encouragement
throughout this journey.
 Our project advisor, Mr. Amjad Ali, for his guidance, expertise, and mentorship
that contributed immensely to the success of this project.
 The entire FYP committee for their valuable feedback and insights during the
evaluation process.
 Our friends and classmates who stood by us through the highs and lows,
providing both motivation and camaraderie.
 Dedicated to all our teachers who taught us the way of learning and taught us that
how we can make ourselves better every day.
 We would like to dedicate this project to the University of Management and
Technology (UMT) for providing us with the platform and resources to pursue
this project. The educational environment and opportunities offered by UMT have
been instrumental in our growth and learning.
 This work is a reflection of the collective effort and support of those around us.
Thank you for being an integral part of our FYP experience.

|P a g e
 FINAL APPROVAL

|P a g e
 Acknowledgment
Our deepest gratitude goes to Allah Almighty who has provided us Knowledge, Wisdom,
Strength to cover this project to completion. I appreciate the School of System and
Technology (UMT) for providing us the tools and technology which was crucial in
making this project. Furthermore, we would like to appreciate Mr. Ibrahim Murad for
carrying on the legacy of his father, this university which is the source of our education
for providing us various opportunities to enhance ourselves educationally moreover
professionally. We would also like to appreciate the dean of SST for running things
smoothly for the students working on their final year projects.
We would like to express our sincerest gratitude to Amjad Ali and Dr. Jameel for their
invaluable guidance, support, and encouragement throughout the duration of this project.
A special applause for our advisor Mr. Amjad Ali whose expertise and patience have
been instrumental in the successful completion of this project. We would also like to
thank SST Faculty for their contributions to this project.
We extend our heartfelt gratitude to Mr. Amad Zahid, our esteemed mentor, for his
invaluable time, unwavering support, and expert guidance throughout the development of
the `DealDocSign` project. On his insights, dedication, and encouragement the success of
this endeavor pivots. Special mention to our team mentor here, whose invaluable time,
unwavering support, and expert guidance steered `DealDocSign` project development.
Working on this project has been tough for us all. It wouldn’t be possible without the
help of Mr. Zahid’s dedication to improving our skills and knowledge for facing
hardships arising from the project’s numerous challenges and complications. The
mentorship offered and how much better it has made what we have learnt were also
appreciated.
Above all, during the journey; we have had constant motivation from our family and
friends, not forgetting the support. Thank you very much for your help.

|P a g e
Tools Used: -
 Frontend Development:
o JavaScript Framework: React JS.
o HTML/CSS: For structuring and styling the platform.
 Backend Development:
o Programming Language: PHP 8.4.
o Web Framework: Utilize a web framework LARAVEL to streamline
backend development.
 Database:
o A relational database MySQL to store user data, documents, and
transaction history.
 Authentication:
o Implement user authentication using JWT (JSON Web Tokens), and
Auth0 for secure login and access control.
 Document Management:
o Folders: Utilize User Folders to store and manage documents securely.
o Document Processing: Integrate document processing libraries and signing
functionalities.
 Security:
o Data Encryption: SSL/TLS to encrypt sensitive user information and
documents from one point to another west.
o Access Control: Managing user permissions and ensuring data security is
Role-based access control (RBAC).
 Software tools:
o MS office, visual paradigm, mermaid, Figma, Vs code, Xampp, BotPress.

Operating System: Windows 10, macOS, android.

Documentation: Version 1.

|P a g e
 Abstract
Given the rapidly changing digital transformation in Pakistan, secure and effective
document management is imperative especially with respect to contracts and signatures.
'DealDocSign' is a unique system specifically created for taking care of different
challenges and opportunities in Pakistan's commercial and legal perspective.
'DealDocSign' is an innovative technology for managing documents and e-signature
which totally transforms the way agreements are managed in Pakistan. Not only is going
paperless a technological advancement, but it is also a strategic imperative in a society
that has always thrived on paperwork as its mainstay. The aim of this initiative is to come
up with a state-of-the-art web application that can cater for the peculiar needs in this land
and ensure the process remains flawless as we develop e-signatures and manage
documents Pakistan, in the line of other nations, has to deal with conventional workflows
that are paper-based that make the whole process slugged. It can lead to inefficaciousness
and security issues or even complex legal matters with such systems. However,
“DealDocSign” strives to solve this problem by providing secure and regulatory
compliant platform that makes entire document life cycle easy up-to when it comes to e-
signing, right from creating up to electronic signing. The proposed idea offers that an
advanced online system should be developed with capabilities such as secure file
uploading, collaboration, organizing and most importantly legally binding digital
signatures This way the system will be compliant with global e-signature standards
recognizing the importance of legal compliance in Pakistan while at the same time
providing secure and reliable platform for electronic transactions. “DealDocSign” is an
initiative that could uplift many Pakistani independent industries. The platform meets a
variety of needs, from helping legal and financial institutions with secure documents to
expediting business agreements in organizations. Government agencies, academic
institutions, and professions all stand to benefit from increased efficiency in document
management, teamwork, and compliance. The platform makes use of modern tools like
MySQL for safe database storage, PHP 8.4 for Laravel-based backend development,
React JS for the frontend, and strong security features like SSL/TLS encryption for end-
to-end data protection.

|P a g e
REVISION CHART

A revision chart, often called a version or revision history, is a record or table that shows
the modifications made over time to a certain document or project. It offers a history of
updates, revisions, and alterations together with information about version numbers,
authors, changes described, and the date of each revision.

Table 1: Revision Chart

Version Primary Description of Version Date

Author(s) Completed
Draft Muhammad Initial draft created for distribution 10/12/2023
Talha Saeed and review comments
Muhammad
Shoaib Khan
1.0 Muhammad This is the completed draft of the 20/02/2024
Talha Saeed first capstone project. There is a
total of 5 chapters.
1. Introduction
2. Domain analysis
3. Requirement Analysis
4. Data Flow Diagram
5. System Design
1.1 Muhammad This is the completed draft of the 20/07/2024
Talha Saeed 2nd capstone project. There is a
total of 7 chapters.
1. Implementation Details
2. Testing
3. Results/Output/Statistics
4. Conclusion
5. Future Work
6. Bibliography
7. Appendix

|P a g e
 CONTENTS

Table of Contents
CONTENTS...................................................................................................................................................X
DEFINITIONS AND ACRONYMS..................................................................................................................XIII
LIST OF FIGURES.......................................................................................................................................XIV
LIST OF TABLES.........................................................................................................................................XV
1. INTRODUCTION.................................................................................................................................1
1.1 MOTIVATIONS.....................................................................................................................................1
1.2 PROJECT OVERVIEW...........................................................................................................................1
1.2.1 Overview Statement....................................................................................................1
1.2.2 Customer.....................................................................................................................2
1.2.3 Goals...........................................................................................................................2
1.2.4 System Functions........................................................................................................2
1.2.5 System Attributes.........................................................................................................2
1.3 PROBLEM STATEMENT........................................................................................................................3
1.4 OBJECTIVES........................................................................................................................................3
2. DOMAIN ANALYSIS...........................................................................................................................5
2.1 CUSTOMER..........................................................................................................................................5
2.2 STAKEHOLDERS..................................................................................................................................5
2.3 AFFECTED GROUPS WITH SOCIAL OR ECONOMIC IMPACT..................................................................5
2.3.1 Businesses and Organizational Entities:....................................................................6
2.3.2 Legal and Financial Institutions:...............................................................................6
2.3.3 Professionals and Independent Workers:...................................................................6
2.3.4 Academic Institutions:................................................................................................6
2.3.5 Governmental Bodies:................................................................................................6
2.3.6 General Public:...........................................................................................................6
2.3.7 Environmental Conservation and Sustainability:.......................................................6
2.3.8 Linkage with Objectives:............................................................................................6
2.4 DEPENDENCIES/ EXTERNAL SYSTEMS................................................................................................7
2.5 REFERENCE DOCUMENTS...................................................................................................................7
2.5.1 Related Projects..........................................................................................................8
3. REQUIREMENTS ANALYSIS.........................................................................................................10
3.1 REQUIREMENTS................................................................................................................................10
3.2 LIST OF ACTORS...............................................................................................................................13
3.3 LIST OF USE CASES...........................................................................................................................13
3.4 SYSTEM USE CASE DIAGRAM..........................................................................................................14
 Actors:.......................................................................................................................14
 Use Cases:................................................................................................................14
 Relationships:...........................................................................................................14
 System Boundary:.....................................................................................................14
3.5 EXTENDED USE CASES......................................................................................................................16
3.5.1 Login.........................................................................................................................16
3.5.2 Upload Document.....................................................................................................17
3.5.3 Manage Document.........................................................................................................18
3.5.4 Sign Document..........................................................................................................20
3.5.5 View History.............................................................................................................22

|P a g e
 3.5.6 Receive Notification..................................................................................................24
3.5.7 Manage Users, Roles, Permissions...........................................................................26
3.5.8 Monitor System Activities.........................................................................................28
3.6 USER INTERFACES (MOCK SCREENS)................................................................................................30
4. DATA FLOW DIAGRAM (OPTIONAL).........................................................................................35
4.1 DATA FLOW DIAGRAM LEVEL 0......................................................................................................35
4.2 DATA FLOW DIAGRAM LEVEL 1......................................................................................................35
4.3 DATA FLOW DIAGRAM LEVEL 2......................................................................................................36
5. SYSTEM DESIGN..............................................................................................................................37
5.1 SYSTEM ARCHITECTURE DIAGRAM..................................................................................................37
5.2 CLASS DIAGRAM..............................................................................................................................38
5.3 SEQUENCE DIAGRAMS......................................................................................................................39
5.4 COLLABORATION DIAGRAMS...........................................................................................................40
5.5 ERD..................................................................................................................................................41
5.6 DATA DICTIONARY...........................................................................................................................42
6. IMPLEMENTATION DETAILS......................................................................................................43
6.1 DEVELOPMENT SETUP......................................................................................................................43
6.1.1 ReactJS:....................................................................................................................43
6.1.2 Laravel:.....................................................................................................................43
6.1.3 MySQL:.....................................................................................................................43
6.1.4 Postman:...................................................................................................................43
6.1.5 Visual Studio Code:..................................................................................................43
6.2 DEPLOYMENT SETUP.........................................................................................................................44
6.2.1 ReactJS:....................................................................................................................44
6.2.2 Laravel:.....................................................................................................................44
6.3 ALGORITHMS....................................................................................................................................44
6.4 CONSTRAINTS...................................................................................................................................46
6.4.1 Assumptions..............................................................................................................46
6.4.2 System constraints.....................................................................................................47
6.4.3 Restrictions...............................................................................................................47
6.4.4 Limitations................................................................................................................48
7. TESTING.............................................................................................................................................50
7.1 EXTENDED TEST CASES....................................................................................................................50
7.1.1 Sign-Up.....................................................................................................................50
7.1.2 Login.........................................................................................................................51
7.1.3 Upload Document:....................................................................................................52
7.1.4 Password Recovery...................................................................................................53
7.1.5 Editing Template:.....................................................................................................54
7.1.6 User Signature..........................................................................................................55
7.1.7 Update Account.........................................................................................................56
7.1.8 Share Document........................................................................................................57
7.1.9 View Signed Document:............................................................................................58
7.1.10 Logout:......................................................................................................................59
7.2 DECISION TABLE..............................................................................................................................60
7.2.1 Code snippet.............................................................................................................60
7.2.2 Decision coverage table............................................................................................62
7.3 TRACEABILITY MATRIX....................................................................................................................63
7.3.1 RID vs UCID (requirements vs use cases)................................................................63
7.3.2 Test Cases (RID vs TID)...........................................................................................63

|P a g e
 7.3.3 Coverage (UCID vs TID)..........................................................................................64
8. RESULTS/OUTPUT/STATISTICS...................................................................................................65
8.1 %COMPLETION..................................................................................................................................65
8.2 %ACCURACY.....................................................................................................................................65
8.3 %CORRECTNESS................................................................................................................................65
9. CONCLUSION....................................................................................................................................66
10. FUTURE WORK...........................................................................................................................67
11. BIBLIOGRAPHY..........................................................................................................................68
11.1 BOOKS..........................................................................................................................................68
11.2 ARTICLES.....................................................................................................................................68
11.3 OTHER REFERENCES....................................................................................................................68
12. APPENDIX.....................................................................................................................................69
12.1 GLOSSARY OF TERMS...................................................................................................................69
12.2 PRE-REQUISITES...........................................................................................................................70

|P a g e
 Definitions and Acronyms
The important terms, concepts, and domain-specific vocabulary used in the project
documentation are explained in detail and succinctly in this section. In order to maintain
clarity, this section covers acronyms and abbreviations used in the project together with
their full forms.

Table 2: Table of acronyms and definitions

Acronym Definition
UMT University of Management and
Technology
E-Sign Electronic-Signature
JWT JSON Web Tokens
FR Functional Requirements
NFR Non-Functional Requirements
DFD Data Flow Diagrams
API Application Program Interface
UC Use Case
IDE Integrated Development Environment
ERD Entity Relationship Diagram
UML Unified Modeling Language
GUI Graphical User Interface

|P a g e
 List of Figures
Figure 1: DealDocSign use case diagram.......................................................................................15
Figure 2: Prototype (1) Registration Page......................................................................................31
Figure 3: Prototype (2) Login Page................................................................................................32
Figure 4: Prototype (3) Forget Password Page...............................................................................33
Figure 5: Prototype (4) Dashboard.................................................................................................34
Figure 6: DFD Level 0....................................................................................................................35
Figure 7: DFD Level 1....................................................................................................................36
Figure 8: DFD Level 2....................................................................................................................36
Figure 9: System Architecture Diagram.........................................................................................37
Figure 10: Class Diagram...............................................................................................................38
Figure 11: Sequence Diagram.........................................................................................................39
Figure 12: Collaboration Diagram..................................................................................................40
Figure 13: ERD Diagram................................................................................................................41
Figure 14: Home page logic............................................................................................................45
Figure 15: Send document logic.....................................................................................................45
Figure 16: Delete document logic...................................................................................................46
Figure 17: Home Page Logic..........................................................................................................61
Figure 18: Send Document Logic...................................................................................................61
Figure 19: Delete Document Logic.................................................................................................62

|P a g e
 List of Tables
Table 1: Revision Chart....................................................................................................viii
Table 2: Table of acronyms and definitions......................................................................xii
Table 3: Stakeholders and their role in system....................................................................5
Table 4: Feature Comparison table of DealDocSign and PakSign......................................8
Table 5: FR & NFR............................................................................................................10
Table 6: Functional and Non-Functional Requirements of the System.............................10
Table 7: Extended Use case "Login".................................................................................16
Table 8: Extended Use case "Upload Document".............................................................17
Table 9: Extended Use case "Manage Document"............................................................18
Table 10: Extended Use case "Sign Document"................................................................20
Table 11: Extended Use case "View History"...................................................................21
Table 12: Extended Use case "Receive Notification"........................................................23
Table 13: Extended Use case " Manage Users, Roles, Permissions "...............................25
Table 14: Extended Use case " Monitor System Activities "...........................................27
Table 15: Data Dictionary..................................................................................................40
Table 16: Test Case for Sign-Up.......................................................................................48
Table 17: Test Case for Login...........................................................................................49
Table 18: Test Case for Upload Document........................................................................50
Table 19: Test Case for Password Recovery.....................................................................50
Table 20: Test Case for Editing Template.........................................................................51
Table 21: Test Case for User Signature.............................................................................52
Table 22: Test Case for Update Account...........................................................................53
Table 23: Test Case for Share Document..........................................................................54
Table 24: Test Case for View Signed Document...............................................................55
Table 25: Test Case for Logout.........................................................................................56
Table 26: requirements vs use cases..................................................................................60
Table 27: RID vs TID........................................................................................................60
Table 28: UCID vs TID.....................................................................................................61

|P a g e
 1. INTRODUCTION

1.1 Motivations
The decision to undertake the "DealDocSign" project was driven by several key
motivations and considerations:

 Industry Relevance:
The project fills a significant gap in all industries, where secure electronic
signatures and effective document management are becoming more and more
essential for simplified operations.
 Market Demand:
A considerable amount of market research revealed an increasing need for
advanced document management systems that incorporate electronic signature
functionality. "DealDocSign" offers a user-friendly and feature-rich platform to
bridge this divide.
 Digital Transformation:
Our project’s goal is to update current document procedures according to world
standards on going digitalization. DealDocSign stands as a nudge towards
individuals and entities transitioning to paperwork less operations.
 Legal Compliance:
Our plan is to offer a solution which meets the global e-signature standards
enabling its users to have lawful and secure electronic signatures in their work.
We are aware of the importance of adherence to e-signatures even under legal
perspectives.
 Inspiration from Existing Solutions:
DocuSign like international platforms, which have been successful in their efforts,
motivating us by showing us how valuable advanced e-signature and document
storage systems can be on a worldwide scale. "DealDocSign" hopes to make a
local contribution to this domain.

1.2 Project Overview

A project overview gives a high-level overview of a project by describing its objectives,
scope, main elements, and purpose. It acts as a summary that enables team members,
stakeholders, and others to rapidly understand the key elements of the project without
having to delve into in-depth documentation.

1.2.1 Overview Statement

In today's digital environment, the challenges of traditional document processes,
particularly regarding security and signatures, present significant obstacles. Ineffective
document management results in wasted time, security risks, and legal issues. There is a
growing need for a unified solution that combines document management and electronic
signatures seamlessly.

|P a g e
 1.2.2 Customer
The main stakeholders and end users of the proposed system include Pakistani
enterprises, professions, academic institutions, government agencies, legal and financial
institutions, and the general public.

1.2.3 Goals
The broad, overarching objectives that a project or organization seeks to accomplish are
referred to as goals. These objectives give the project team and stakeholders focus and
direction, pointing them in the direction of a shared vision. Usually, goals are in line with
the organization's overarching mission and strategic goals.

 Efficient Document Management: Automate the whole document handling

procedure, from creation to signature, to guarantee effective and safe
management.
 Legally Valid Electronic Signatures: Provide a digital signature platform that
satisfies international standards and produces legally enforceable electronic
signatures on documents.
 User-Friendly Interface: To increase user happiness and productivity, provide
an intuitive user interface with responsive design.
 Real-time Collaboration: When several people are not able to edit documents
and make comments simultaneously this hinders their real-time collaboration on
these documents because they cannot work together on the same document at the
same time in a secure mode.
 Advanced Search and Retrieval: Make available an extremely powerful search
functionality that allows users to find documents through metadata, tags and
keywords.

1.2.4 System Functions

It's the nucleus of the functionality that the system is expected to perform upon its
completion.
 Document Upload and Storage: Allow users to safely upload documents in
different forms. Set up a solid database to store uploaded documents by the users,
historical data, and records.
 Electronic Signature Capability: Simplify the electronic signing process while
guaranteeing legal validity and adherence to global e-signature laws.
 Collaboration and Secure Sharing: Simplify the e-signing process whilst
respecting global e-signature laws that are valid in order for it to be considered
legal.
 Search and Retrieval Functionality: Allow multiples of individuals to edit and
comment on text concurrently to encourage instant real-time collaboration. Utilize
secure document sharing tools to share texts selectively with certain persons or
groups without any fear.

|P a g e
 1.2.5 System Attributes
system attributes refer to those properties or characteristics that define what a computer
does and how well it does it when we talk about software engineering, this includes
system functions such as storage capacity for data processing speed processing power
among others which will help you define what exactly you want from your program
before writing any code at all." In conversations involving computer programs as well as
system architecture, the expression “system attributes” means the attributes or qualities
which identify the performance, functionality and behavior of the system. they help in
defining the overall nature of the system and guide the design and development process.
Performance Optimization: Make sure to maintain extraordinary system performance
even when there is a high number of connected users at a go. Optimize database queries
and server response times for fast document retrieval.
Scalability Design: Build the system with scalability in mind in order to take care of
future growth in terms of users as well as document volumes.
User-Centric Interface Design: Create an easy-to-use interface that has responsive
design in order to offer seamless user experience.
Security and Compliance Measures: Strong encryption techniques are essential for
security and privacy of stored files and digital signatures.

1.3 Problem Statement

Traditional document workflows result in time wastage, security vulnerabilities, and legal
issues in the fast-paced digital age. Existing shortcomings impede the shift to paperless
procedures. Our project, "DealDocSign," intends to develop a sophisticated web
application in order to fulfill this need. With capabilities for secure uploading,
organizing, and saving, this platform seeks to transform document management. Along
with guaranteeing legally binding electronic signatures, it also places a high priority on
accelerating the electronic signing process. To function securely and effectively in the
digital age, both individuals and enterprises must have the entire document lifecycle
simplified. Our focus audience will also contain student and faculty, advisor & other
university officials because we noticed that there is a lot of paperwork in educational
departments on daily basis which is being done inefficiently.

1.4 Objectives
Together, those objectives seek to provide a comprehensive and secure document
management system with cutting-edge electronic signature capabilities, satisfying the
varied requirements of users in a range of industries.
 Functional Excellence: Develop a fully functional web application that
seamlessly integrates document management and electronic signature
functionalities.
 User Authentication and Access Control: Implement robust user authentication,
including multi-factor authentication, and define user roles with specific
permissions.
 Efficient Document Handling: Enable users to securely upload, organize, and
store various document types with a focus on user-friendly features and templates.

|P a g e
  Legally Binding E-Signatures:
 Streamline the electronic signing process to ensure legal validity and compliance
with international e-signature regulations.
 Real-time Collaboration: Facilitate real-time collaboration by allowing multiple
users to concurrently edit and comment on documents securely.
 Secure Document Sharing: Implement secure document sharing features,
enabling users to confidently share documents with specific individuals or groups.
 Advanced Search and Retrieval: Develop a robust search feature based on
keywords, tags, and metadata for efficient document retrieval.
 User-Centric Interface Design: Craft an intuitive and user-friendly interface
with responsive design to ensure a seamless user experience across devices.
 Security and Compliance Measures: Employ robust encryption techniques to
guarantee the security and confidentiality of stored documents and electronic
signatures.
 Performance Optimization: Ensure exceptional system performance, even with
a substantial number of simultaneous users, through optimized database queries
and server response times.
 Scalability and Future Expansion: Design the system architecture for
scalability, accommodating an expanding user base and increasing document
volumes over time.
 Reporting and Audit Trail: Implement robust reporting features for
administrators to generate comprehensive usage reports and monitor system
activities effectively.
 Empirical Investigation: Conduct an empirical investigation to evaluate user
satisfaction, efficiency metrics, legal validity, regulatory compliance, security,
and data protection.

|P a g e
 2. DOMAIN ANALYSIS

2.1 Customer
The project is developed for general use or potential clients in the targeted sectors.

2.2 Stakeholders
Stakeholders are individuals, groups, or entities that have an interest or concern in the
success or outcome of that project or business. Both internal and external to the
organization can be the stakeholders where diverse roles and perspectives are included.
The identification and comprehension of stakeholders in projects are crucial for
successful management as well as decision making.

Table 3: Stakeholders and their role in system

Stakeholder Role in System
Project Team Responsible for system development, implementation, and ongoing
maintenance.
End Users Utilize the system for efficient document management, electronic
signatures, and collaboration.
Administrators Manage user accounts, access control, and oversee the overall
system functionality.
Legal and Ensure that the system complies with global e-signature standards
Compliance and legal regulations.
Teams
IT Support Assist with technical inquiries, resolve problems, and maintain
Staff system uptime.
Government Ensure the system complies with data protection laws and
Authorities regulations.
Security Assess and enhance the system's security features to protect
Experts sensitive information.
FYP Evaluators Assess and evaluate the quality and effectiveness of the final year
project.
Project Advisor Provide guidance, support, and feedback throughout the project
development process.

2.3 Affected Groups with social or economic impact

This is to do with identifying and analyzing various groups such as stakeholders who will
be impacted by the project that the project will affect, mainly focusing on social or

|P a g e
economic aspects. It is the duty of this part within project charter or papers helping in
understanding wider consequences of a project along with its immediate targets.

2.3.1 Businesses and Organizational Entities:

By making the document processing more efficient, streamlining it will reduce the
operational expenses related to traditional paper-based documentation and give rise to
increased productivity.

2.3.2 Legal and Financial Institutions:

Processes will be organized and legal risks will be lowered by making sure all operations
adhere to the law, electronic signatures that can stand up in court will be utilized while
secure document-flow systems are put in place.

2.3.3 Professionals and Independent Workers:

Effective document management solutions enhance productivity and organization to
improve client interactions and professionalism at large.

2.3.4 Academic Institutions:

Education professionals can now focus more on teaching and research thanks to easier
document management. Both faculty and students benefit from collaborative tools.

2.3.5 Governmental Bodies:

Impact: Enhancing data security, optimizing communication, and transitioning to a
paperless workplace are factors that support government efficacy and environmental
goals.

2.3.6 General Public:

Impact: Supports the privacy and confidentiality of data by offering a safe platform for
handling personal papers. bolsters the international effort to cut back on paper
consumption.

2.3.7 Environmental Conservation and Sustainability:

Impact: Encouraging paperless transactions minimizes the carbon footprint and stops
deforestation, both of which are factors in environmental conservation.

2.3.8 Linkage with Objectives:

 Objective 3 (Efficient Document Handling) directly benefits businesses,
organizations, and individuals by reducing paperwork and improving document
organization.
 Objective 4 (Legally Binding E-Signatures) positively impacts legal and financial
institutions by ensuring compliance and reducing legal risks.
 Objective 8 (User-Centric Interface Design) contributes to improved efficiency
and productivity across all user groups.
 Objective 10 (Scalability and Future Expansion) ensures that the system can adapt
to the growing needs of impacted groups over time.

|P a g e
 2.4 Dependencies/ External Systems
It refers to the dependencies of DealDocSign System and external factors on which it
depends for its completion or functionality. Some of them are listed below.

 Cybersecurity Protocols: The project relies on established cybersecurity

protocols to ensure the confidentiality and integrity of stored documents and
electronic signatures.

 Web Hosting Services: The system requires reliable web hosting services to
ensure seamless accessibility, performance, and availability for end-users.

 Document Processing Libraries: Integration with robust document processing

libraries is crucial for efficient handling of various document types and electronic
signatures.
 Amazon S3 (Simple Storage Service): The project leverages Amazon S3 for
secure cloud storage, providing a reliable solution for document storage and
management.

 Authentication Services (e.g., Auth0): Implementing secure user authentication

and access control relies on external authentication services, enhancing overall
system security.

 SSL/TLS Certificates: The use of SSL/TLS certificates is essential for end-to-

end encryption, ensuring the security of transmitted documents and sensitive user
data.

2.5 Reference Documents

1. "Electronic Signatures in Global and National Commerce Act (ESIGN Act)" -
U.S. Congress, 2000.
https://www.fdic.gov/resources/supervision-and-examinations/consumer-
compliance-examination-manual/documents/10/x-3-1.pdf
2. "Electronic Signatures" value in law
https://books.google.com.pk/books?hl=en&lr=&id=Cne-
igPOkhgC&oi=fnd&pg=PA17&dq=%22electronic+signatures
%22+value+in+law&ots=0CQzkbeA5X&sig=CbWgIbgM2RbodFcor-
7QYoV2eLg&redir_esc=y#v=onepage&q=%22electronic%20signatures
%22%20value%20in%20law&f=false
3. “Regulation (EU) No 910/2014 on electronic identification and trust services for
electronic transactions in the internal market (eIDAS)” - European Union, 2014.
https://edicomgroup.com/learning-center/eidas-regulation#:~:text=Regulation
%20(EU)%20n%C2%BA%20910%2F,%2C%20citizens%2C%20and%20public
%20authorities.
4. "Auth0 Documentation" - Auth0 Inc.
https://community.auth0.com/t/auth0-documentation/60412
5. "Amazon Simple Storage Service (S3) Documentation" - Amazon Web Services
(AWS).
https://aws.amazon.com/

|P a g e
 6. "Laravel Documentation" - Laravel.
https://laravel.com/docs/10.x/readme
7. "React Documentation" - React.
https://legacy.reactjs.org/docs/getting-started.html

2.5.1 Related Projects

During the development of "DealDocSign" our team studied several notable electronic
signature solutions to gain insights and ensure alignment with industry standards. Here
are the details of the related projects:

PakSign Platform
Developed by PakTech Solutions.
In-depth information and documentation were acquired directly from PakTech Solutions,
the developers of PakSign. The system's functionality was observed through the official
website at www.paksign.com.

2.5.1.1 Feature Comparison

To better understand the electronic signature platform environment and enhance the
feature set of "DealDocSign," a thorough analysis was carried out comparing major
features provided by PakSign.

Table 4: Feature Comparison table of DealDocSign and PakSign

Sr No. Comparison PakSign DealDocSign
Feature

1 Document Provides basic Offers a

Management document storage and comprehensive
management features. document
management system
with advanced
features such as
version control and
collaborative editing.

2 User Interface Features a user- Offers an intuitive

friendly interface, but and highly
limited customization customizable user
options. interface, tailored to
user preferences.

3 Pricing Offers various pricing Provides cost-

plans, including effective pricing with
subscription-based a focus on
models. affordability for

|P a g e
 businesses and
individuals.

4 Customer Offers customer Provides dedicated

Support support but with and responsive
potential response time customer support for
limitations. all users.

5 Template It does not provide As we will implement

templates for your ML algorithms where
organization or it will suggest
suggestion. template document to
user according to its
organization type.

|P a g e
 3. REQUIREMENTS ANALYSIS

3.1 Requirements
Functional requirements (FR) specify the functions and actions that a system must do.
These include data processing, user interfaces, and functionality. Non-Functional
Requirements (NFR) focus on system attributes like efficiency, safety, usability, and
dependability and define how the system accomplishes those objectives. In essence,
NFRs explain the limitations and quality of the way a system performs its operations,
whereas FRs represent the actions of the system itself. Below listed functional and non-
functional requirements of DealDocSign system.

Table 5: FR & NFR

Functional The services or functionalities requested by the user in his
Requirements system.
Non-Functional These are supporting requirements for the mentioned functional
Requirements requirements. These requirements are used to measure the quality
of the system.
Data Requirements How data will be stored and managed in the system.
Constraints Some limitations and boundaries of the system’s scope.
External interface How will your system connect to other software/components?
requirements

Below table illustrates the functional requirements and non-functional requirements of

DealDocSign System:

Table 6: Functional and Non-Functional Requirements of the System

RID description Category Attribute Details & Boundary
Constraints
R1.1 Users should be functional Security Implement multi-factor
able to create authentication for
accounts and log in enhanced security.
securely. Passwords must meet
specified complexity
criteria.
R1.2 Users should be functional Reliability Provide a database for
able to upload storing records, history,
documents in and uploaded documents.
various formats Implement size
(PDF, JPG, etc.). restrictions for uploaded
documents.

|P a g e
R1.3 Enable users to functional Compliance Integrate signature fields
electronically sign within documents. Ensure
documents for compliance with
legal validity. international e-signature
regulations.

R1.4 Facilitate real-time functional Confidentiality Implement secure

collaboration on document sharing with
documents among specific individuals or
multiple users. groups. Define access
controls to manage
document sharing
permissions.

R1.5 Develop a robust functional Efficiency Provide advanced filters

search feature for for precise document
documents based retrieval (date, file type,
on keywords, tags, user). Optimize search
and metadata. performance for large
document databases.

R1.6 Design an intuitive Non- Usability Ensure responsive design

and user-friendly functional for a seamless user
interface. experience across devices.
Conduct usability tests to
refine the interface.

R1.7 Ensure exceptional Non- Scalability Fine-tune database queries

system functional and server response times.
performance with a Maintain optimal
substantial number performance under peak
of simultaneous loads.
users.

R1.8 Architect the Non- Flexibility Plan for expansion to

system for functional handle increased demand.
scalability to Consider resource
accommodate limitations for scalability
future user and planning.
document volume
growth.
R1.9 Implement robust functional Accountability Develop an audit trail

|P a g e
 reporting features mechanism to record user
for administrators. actions and document
changes. Ensure
compliance with data
protection regulations.

R2.0 Implement version Non- Transparency Allow users to track

control features for functional document history and
monitoring changes revisions. Define
and revisions. permissions for version
control access.

R2.1 Provide real-time functional Timeliness Users should receive

notifications for alerts for relevant
document updates, activities. Allow users to
comments, and customize notification
signatures. preferences.

R2.2 Allow users to functional Customization Provide pre-defined

create and use templates for common
document document types. Ensure
templates. compatibility with various
document formats.

R2.3 Integrate with functional Data Security Utilize services like

cloud storage Amazon S3 for document
services for secure storage. Ensure data
document security during
management. integration.

R2.4 Support document functional Compatibility Allow users to convert

conversion documents to and from
between different PDF, DOCX, etc. Validate
formats. document integrity after
conversion.

R2.5 Define user roles functional Granularity Admins should have

(administrators, control over document
regular users) with access and modification.
specific Ensure granularity in
permissions. defining role-based

|P a g e
 permissions.

R2.6 Ensure the Non- Responsiveness Implement a responsive

platform is functional design for seamless
accessible on mobile user experience.
mobile devices. Optimize features for
smaller screens.

3.2 List of Actors

Administrator: Manages user roles and system settings, ensuring smooth operation.
User (General): Engages with the system for document management and e-signature
purposes.
External User (Client/Recipient): Interacts with the system to sign documents shared
by the document owner.

3.3 List of use cases

1. Upload Document: Document owners can upload various types of documents to
the DealDocSign system for secure storage and management.
2. Manage Documents Users who uploaded the documents can edit, manage, or
organize their documents within the DealDocSign system.
3. Initiate E-Signature Process: Selected documents can be initiated for an
electronic signature process by document owners, and they can also indicate
where these signatures need to be done.
4. Sign Document: The DealDocSign system provides a secure platform for users
involved in the signing process to electronically sign their documents.
5. Collaborate on Document: While working on shared documents, collaborators
can make comments and edits in real time.
6. View Document History: Allowed people can see the history of the changes of
the document, revisions, and activities for signature.
7. Receive Notifications: Various system events such as document sharing, e-
signatures, and all collaboration operations have notifications that users receive.
8. Monitor System Activities: Though computers can balance many trade-offs
among different players, cyberarts might easily fail to balance legitimate
concerns.
9. Access Shared Document: The document owner can share documents with
clients/recipients for access and signing by the clients/recipients themselves.

|P a g e
 10. Administer System Settings: The DealDocSign system permits admins to
engage in user roles, authorizations, and wide-ranging system preferences.

3.4 System Use Case Diagram

A use case diagram in UML is a type of diagram which demonstrates the functioning of a
system in regard to a user. It gives a visual impression of interactions between users and a
system as well as different responses a system is capable of giving. Therefore, software
engineers often use case diagrams to document and specify the functional requirements of
a system.

 Actors: Represent external entities (typically users or other systems) interacting

with the system. Actors are depicted as stick figures or blocks.
 Use Cases: Users should provide a detailed overview about various roles or needs
that could be catered for. The system reacts differently to specific stimuli from
outside according to every use case or specific actions for an actor.
 Relationships: Connect actors to use cases to illustrate the interactions.
Relationships can include associations, generalizations, and dependencies.
 System Boundary: Represents the scope of the system and separates the system
from its external actors.

|P a g e
 
Figure 1: DealDocSign use case diagram

|P a g e
 3.5 Extended use cases
An extended use case diagram offers a more thorough and detailed picture of particular
use cases that are given in a use case diagram. It is also referred to as an expanded use
case scenario or a detailed use case description. It describes the sequence of events and
the precise actions made during the execution of a given use case, providing more detail
on the interactions between actors and the system.

3.5.1 Login
Below is table explanation of an extended use case for the "Login" functionality.

Table 7: Extended Use case "Login"

Use Case ID: UC-1.1
Use Case Login
Name:
Created By: Talha Saeed Last Updated By: Talha Saeed
Date 12/09/2023 Last Revision 12/15/2023
Created: Date:
Actors: User (Document Sender)
Description: User logged in to the system with registered credentials.
Trigger: User navigates to the system for login.
Preconditions: 1. User must have account on DealDocSign
2. User must have username & password to login
Post 1. User is logged in to the system
conditions: 2. Dashboard appears to user
Normal Flow: The normal flow is:
1. Open web app.
2. Click on “login” button.
3. Enter username.
4. Enter password.
5. Enter captcha.
6. Customer click to login button.
7. Customer successfully logged in.
Alternative 1. If user enter incorrect password.
Flows: 2. If user not enter captcha.
[Alternative 3. If user enter wrong user name.
Flow 1 – Not
in Network]
Exceptions:
3a. In step 3 of the normal flow, if the customer enters and invalid
username or password
1. login is disapproved
2. Message to customer to re-enter username/password
3. Customer enters correct credentials
4. Use Case resumes on step 4 of normal flow]

|P a g e
Includes: None
Frequency of 500 users per day
Use:
Special 1. The user's password must never be shown in plain text anywhere in
Requirements: the application's UI. Textual characters are always indicated by special
characters.
2. The user's credentials must not be duplicated in the system.
Assumptions: The Customer shall understand English.
Notes and 1. The customer enter must be email in format of [email protected]
Issues: 2. The password must have at least 1 special character, 1 capital letter,
alphanumeric and at least have 8 characters.

3.5.2 Upload Document

Below is table explanation of an extended use case for the "Upload Document"
functionality.

Table 8: Extended Use case "Upload Document"

Use Case ID: UC-1.2
Use Case Upload Document
Name:
Created By: Talha Saeed Last Updated By: Talha Saeed
Date 12/09/2023 Last Revision 12/15/2023
Created: Date:
Actors: User (Document Sender)
Description: This use case involves the Document Owner uploading a document to
the DealDocSign system. The System Auditor may monitor the
activities related to document uploads.

Trigger: The Document Owner initiates the use case by selecting the option to
upload a document.

Preconditions: 1. Document Owner is logged into the DealDocSign system.

2. The system is operational.
Post 1. The document is successfully uploaded.
conditions: 2. Document Owner receives a confirmation of the successful upload.
3. System Auditor may view the log of the document upload.
Normal Flow: 1. Document Owner selects the "Upload Document" option.
2. System prompts Document Owner to choose the document file.

|P a g e
 3. Document Owner selects the file and initiates the upload.
4. System validates the document format and size.
5. Document is stored in the system.
6. Document Owner receives a confirmation message.
Alternative If the document format is invalid:
Flows: 1. System notifies Document Owner about the invalid format.
[Alternative
Flow 1 – Not 2. Document Owner selects a valid document.
in Network]
Exceptions:
If the system is unavailable:
1. Document Owner receives a message about the unavailability.
2. Use case is terminated.
Includes: None
Frequency of Frequent - Multiple times a day
Use:

Special The system should support common document formats (PDF, DOCX,
Requirements: etc.).
- Maximum document size should be configurable.
Assumptions: 1. Document Owner has a reliable internet connection.
2. System resources are sufficient for document storage.
Notes and None.
Issues:

3.5.3 Manage Document

Below is table explanation of an extended use case for the "Manage Document"
functionality.

Table 9: Extended Use case "Manage Document"

Use Case ID: UC-1.3
Use Case Manage Document
Name:
Created By: Shoaib Khan Last Updated By: Talha Saeed
Date 12/09/2023 Last Revision 12/15/2023
Created: Date:

|P a g e
Actors: User (Document Manager)
System Administrator

Description: This use case involves the User, who acts as a Document Manager,
performing various management tasks related to documents within the
DealDocSign system. The System Administrator may oversee document
management activities and configure system settings accordingly.
Trigger: The User decides to manage documents and accesses the relevant
functionality within the DealDocSign system.
Preconditions: 1. The User is logged into the DealDocSign system.
2. The system is operational.
3. The User has appropriate permissions to manage documents.

Post 1. Document management tasks, such as editing, deleting,

conditions: or archiving, are successfully performed.
2. The User receives confirmation of the successful execution
of document management tasks.
3. System Administrator may review and adjust
document management permissions or configurations
if necessary.

Normal Flow: 1. User navigates to the "Manage Documents" section within the
DealDocSign system.
2. System presents User with a list of available documents and
relevant management options.
3. User selects a document to manage from the list.
4. User chooses the desired management action (e.g., edit, delete,
archive).
5. User provides necessary information or confirms the action.
6. System executes the chosen action on the selected document.
7. User receives a confirmation message indicating successful
execution of the management task.

Alternative If the User decides to cancel the management action:

Flows: 1. User cancels the action or navigates back.
[Alternative 2. Use case ends without executing the action.
Flow 1 – Not
in Network]
Exceptions:
If the system encounters an error during document management:
1. System notifies the User about the error.

|P a g e
 2. System Administrator is alerted about the issue for resolution.
3. Use case is terminated until the issue is resolved.

Includes: None
Frequency of Frequent - Multiple times a day
Use:

Special 1. The system should provide clear and intuitive interfaces for
Requirements document management actions.
: 2. Document management permissions and configurations should be
customizable by the System Administrator.
3. System should maintain a log of document management activities
for audit purposes.

Assumptions: 1. User is familiar with document management concepts and

procedures.
2. System resources are adequate for handling document
management tasks efficiently.

Notes and Advanced document management features, such as version control or

Issues: access control, may be considered for future enhancements to the system.

3.5.4 Sign Document

Below is table explanation of an extended use case for the "Sign Document"
functionality.

Table 10: Extended Use case "Sign Document"

Use Case ID: UC-1.4
Use Case Sign Document
Name:
Created By: Shoaib Khan Last Updated By: Talha Saeed
Date 12/09/2023 Last Revision 12/15/2023
Created: Date:
Actors: User (Document Signer)
Description: This use case involves the User, who is the Document Signer, digitally
signing documents within the DealDocSign. The System Administrator
may oversee signing activities and configure signing settings.

|P a g e
Trigger: The User receives a document that requires digital signing within the
DealDocSign.
Preconditions: 1. The User is logged into the DealDocSign.
2. The system is operational.
3. The User has appropriate permissions to sign documents.

Post 1. The document is successfully signed by the User.

conditions: 2. The signed document is stored securely within the DealDocSign
system.
3. The User receives confirmation of the successful signing process.

Normal Flow: 1. User receives a notification or accesses the document requiring

digital signing within the DealDocSign.
2. User reviews the document content and ensures its accuracy.
3. User locates the designated signature fields within the document.
4. User electronically signs the document using their digital
signature.
5. System verifies the signature validity and authenticity.
6. Signed document is securely stored within the DealDocSign
system.
7. User receives a confirmation message indicating successful
signing.

Alternative If the User encounters any discrepancies or errors in the document

Flows: content:
[Alternative 1. User notifies the sender or relevant parties about the issues.
Flow 1 – Not 2. Sender makes necessary corrections and resubmits the document
in Network] for signing.

Exceptions: If the system encounters an error during the signing process:

1. System notifies the User about the error.
2. System Administrator is alerted about the issue for resolution.
3. User may attempt to sign the document again after issue
resolution.

Includes: None
Frequency of Frequent - Multiple times a day
Use:

Special 1. The system should support secure digital signatures compliant

|P a g e
Requirements with relevant regulations (e.g., eIDAS in the EU, ESIGN Act in
: the US).
2. Signed documents should be encrypted and stored securely to
ensure data integrity and confidentiality.

Assumptions: 1. User has access to necessary hardware and software for digital
signing (e.g., digital certificate, electronic signature pad).
2. System resources are sufficient for handling signing operations
efficiently.

Notes and User education and awareness regarding digital signing best practices
Issues: may enhance the overall signing process efficiency and security.

3.5.5 View History

Below is table explanation of an extended use case for the "View History" functionality.

Table 11: Extended Use case "View History"

Use Case ID: UC-1.5
Use Case View History
Name:
Created By: Shoaib Khan Last Updated By: Talha Saeed
Date 12/09/2023 Last Revision 12/15/2023
Created: Date:
Actors: User (Document Viewer)
System Administrator

Description: This use case involves the User, who acts as the Document Viewer,
accessing and reviewing the history of document interactions within the
DealDocSign. The System Administrator may oversee viewing history
activities and manage related settings.
Trigger: The User navigates to the "View History" section within the
DealDocSign interface.
Preconditions: 1. The User is logged into the DealDocSign.
2. The system is operational.
3. The User has appropriate permissions to view document history.

Post 1. The User successfully accesses and reviews the document

conditions:

|P a g e
 interaction history.
2. The User may take appropriate actions based on the insights
gained from viewing the history.

Normal Flow: 1. User navigates to the "View History" section within the
DealDocSign interface.
2. System presents User with a list of available documents and
relevant historical data.
3. User selects a document from the list to view its history.
4. System displays the document's interaction history, including
actions such as creation, modification, sharing, signing, and any
relevant timestamps.
5. User reviews the document interaction history to gain insights
into past activities.
6. User may take appropriate actions based on the insights gained
from viewing the history.

Alternative If the User wants to filter the history by specific criteria (e.g., date range,
Flows: document type):
[Alternative 1. User applies relevant filters to refine the displayed history.
Flow 1 – Not 2. System updates the displayed history based on the applied filters.
in Network]

Exceptions: If the system encounters an error while retrieving or displaying the

document interaction history:
1. System notifies the User about the error.
2. System Administrator is alerted about the issue for resolution.
3. User may attempt to access the history again after issue
resolution.

Includes: None
Frequency of Frequent - Multiple times a day
Use:

Special 1. The system should maintain a comprehensive and accurate record

Requirements of document interactions for auditing and tracking purposes.
: 2. Document interaction history should be accessible only to
authorized users with appropriate permissions.
3. System should support efficient retrieval and display of document
interaction history, even for large datasets.

|P a g e
Assumptions: 1. User understands the significance of document interaction history
and its relevance to their tasks.
2. System resources are sufficient for storing and managing
document interaction history data effectively.

Notes and  Providing a clear and intuitive interface for viewing document
Issues: interaction history can enhance User experience and productivity.
 Regular maintenance and optimization of the history database can
help ensure optimal performance and reliability of the "View
History" functionality.

3.5.6 Receive Notification

Below is table explanation of an extended use case for the "Receive Notification"
functionality.

Table 12: Extended Use case "Receive Notification"

Use Case ID: UC-1.6
Use Case Receive Notification
Name:
Created By: Shoaib Khan Last Updated By: Talha Saeed
Date 12/09/2023 Last Revision 12/15/2023
Created: Date:
Actors: User (Recipient)
Notification System

Description: This use case involves the User, who acts as the recipient, receiving
notifications from the Notification System within the DealDocSign.
Notifications inform the User about various events, updates, or actions
related to documents, tasks, or system status.
Trigger: An event or action occurs within the DealDocSign that triggers the
generation of a notification for the User.
Preconditions: 1. The User is registered and logged into the DealDocSign.
2. The Notification System is operational.
3. The User has configured notification preferences or subscribed to
relevant events.

Post 1. The User receives the notification promptly.

conditions: 2. The notification content accurately reflects the event or action that

|P a g e
 triggered it.
Normal Flow: 1. An event or action occurs within the DealDocSign, such as
document sharing, document signing, task assignment, or system
status update.
2. The Notification System detects the event or action and generates
a corresponding notification for the User.
3. The notification is delivered to the User via their preferred
communication channel (e.g., email, mobile app notification, in-
app message).
4. User receives and views the notification.
5. User may take appropriate actions based on the information
provided in the notification (e.g., reviewing a shared document,
completing an assigned task).

Alternative If the User has configured notification preferences to filter or prioritize

Flows: certain types of notifications:
[Alternative 1. The Notification System applies the User's configured preferences
Flow 1 – Not to generate and deliver notifications.
in Network] 2. User receives notifications according to their configured
preferences.

Exceptions: If the Notification System encounters an error while generating or

delivering notifications:
1. System logs the error for troubleshooting and debugging
purposes.
2. User may not receive the notification or may receive it with a
delay.
3. System Administrator is alerted about the issue for resolution.

Includes: None
Frequency of Frequent - Multiple times a day
Use:

Special 1. Notification delivery should be reliable, timely, and consistent

Requirements across different communication channels.
: 2. Notification content should be concise, clear, and informative to
effectively communicate relevant information to the User.
3. System should support customization of notification preferences
and settings by the User.

Assumptions: 1. User has access to the communication channels through which

|P a g e
 notifications are delivered (e.g., email, mobile device).
2. User understands the importance of notifications and their role in
staying informed about project-related activities and updates.

Notes and  Providing User-friendly options for managing notification

Issues: preferences can enhance User satisfaction and engagement with
the DealDocSign System.
 Regular monitoring and maintenance of the Notification System
are essential to ensure reliable delivery of notifications and timely
communication with Users.

3.5.7 Manage Users, Roles, Permissions

Below is table explanation of an extended use case for the " Manage Users, Roles,
Permissions" functionality.

Table 13: Extended Use case " Manage Users, Roles, Permissions "
Use Case ID: UC-1.7
Use Case Manage Users, Roles, Permissions
Name:
Created By: Shoaib Khan Last Updated By: Talha Saeed
Date 12/09/2023 Last Revision 12/15/2023
Created: Date:
Actors: System Administrator
Description: This use case involves the System Administrator managing users, roles,
and permissions within the DealDocSign. The System Administrator
oversees user accounts, assigns roles, and configures permissions to
ensure appropriate access and security levels.
Trigger: The System Administrator accesses the user management interface within
the DealDocSign.
Preconditions: 1. The System Administrator is logged into the DealDocSign.
2. The system is operational.

Post 1. User accounts, roles, and permissions are successfully managed

conditions: and updated as needed.
2. Changes made by the System Administrator are reflected in the
system.
Normal Flow: 1. System Administrator navigates to the user management section
within the DealDocSign interface.

|P a g e
 2. System presents System Administrator with a list of existing users
and their associated roles and permissions.
3. System Administrator selects a user from the list to manage.
4. System Administrator may perform various actions, including:
5. Creating new user accounts.
6. Editing existing user details, such as username, email, or contact
information.
7. Assigning or modifying user roles based on predefined role
templates.
8. Configuring granular permissions for specific users or roles,
including document access, editing rights, and administrative
privileges.
9. System Administrator saves the changes made to user accounts,
roles, or permissions.
10. System updates user accounts, roles, and permissions accordingly.
Alternative If the System Administrator wants to create a new role:
Flows: 1. System Administrator accesses the role management interface.
[Alternative 2. System Administrator defines the new role's name, description,
Flow 1 – Not and associated permissions.
in Network] 3. System Administrator saves the new role configuration.
If the System Administrator needs to deactivate or delete a user account:
1. System Administrator selects the user account to deactivate or
delete.
2. System Administrator confirms the action and saves the changes.
3. System updates the user account status accordingly.

Exceptions: If the system encounters an error while managing users, roles, or

permissions:
1. System notifies the System Administrator about the error.
2. System Administrator investigates and resolves the issue, if
possible.
3. System Administrator may attempt the action again after issue
resolution.

Includes: None
Frequency of Frequent - Multiple times a day
Use:

Special 1. The system should support role-based access control (RBAC) to

Requirements enforce security and access control policies effectively.
: 2. User management actions should be audited and logged for
accountability and traceability purposes.

|P a g e
 3. System should provide a user-friendly interface for System
Administrator to manage users, roles, and permissions efficiently.

Assumptions: 1. System Administrator possesses sufficient knowledge and

authority to manage user accounts, roles, and permissions
effectively.
2. System resources are adequate to handle user management
operations, including user creation, role assignment, and
permission configuration.

Notes and  Regular review and maintenance of user accounts, roles, and
Issues: permissions can help ensure the integrity and security of the
DealDocSign.
 Providing comprehensive documentation and training resources
for System Administrators can facilitate smooth and efficient user
management processes.

3.5.8 Monitor System Activities

Below is table explanation of an extended use case for the Monitor System Activities "
functionality.

Table 14: Extended Use case " Monitor System Activities "
Use Case ID: UC-1.8
Use Case Monitor System Activities
Name:
Created By: Shoaib Khan Last Updated By: Talha Saeed
Date 12/09/2023 Last Revision 12/15/2023
Created: Date:
Actors: System Administrator
Description: This use case involves the System Administrator monitoring system
activities within the DealDocSign. The System Administrator oversees
various aspects of system performance, security, and user interactions to
ensure optimal operation and identify any potential issues or anomalies.
Trigger: The System Administrator accesses the system monitoring interface
within the DealDocSign.
Preconditions: 1. The System Administrator is logged into the DealDocSign.
2. The system is operational.

Post 1. System activities are successfully monitored and analyzed.

|P a g e
conditions: 2. Any detected issues or anomalies are addressed and resolved as
needed.
Normal Flow: 1. The system administrator navigates to the system monitoring
section in the DealDocSign interface.
2. System will show a System Administrator data in real time or in
history in various activities about the system. With:
 When you are measuring system performance, CPU Utilization,
Memory Utilization and Network traffic are the key parameters.
 Session durations when user’s login/logout.
 Performing tasks that include creating, changing and accessing
documents.
 Security events like failed logins or login attempts without
permission.
 A System Administrator reviews collected data to understand the
general health and performance of the system.
 Any anomalies, malfunctions or indicators of declining
performance would be identified by the system manager.
3. The system administrator can implement corrective measures for
these incidents that could consist of:
Investigation of likely security violations or unauthorized
admission trials must be done. This would be followed up with
optimization for system resources in order to better its
performance and scalability including informing relevant
personnel about the same as well as starting emergency plans for
important cases.
4. The monitoring operations and actions taken by the system
administrator are logged and documented for future reference and
audit purposes.

Alternative If the System Administrator wants to generate specific reports or analyze

Flows: particular aspects of system activities:
[Alternative 1. System Administrator applies relevant filters or parameters to
Flow 1 – Not refine the displayed data.
in Network] 2. System presents System Administrator with customized reports or
analysis results based on the specified criteria.
3. System Administrator conducts in-depth analysis and takes
appropriate actions based on the findings.

Exceptions: If the system encounters an error or becomes unresponsive during the

monitoring process:
1. System notifies the System Administrator about the issue.
2. System Administrator investigates and resolves the problem, if
possible.
3. System Administrator may employ alternative monitoring tools or

|P a g e
 methods to continue monitoring system activities.

Includes: None
Frequency of Frequent - Multiple times a day
Use:

Special 1. The system should provide comprehensive monitoring

Requirements capabilities, including real-time data visualization, alerting
: mechanisms, and reporting functionalities.
2. Monitoring activities should adhere to relevant privacy and data
protection regulations, ensuring the confidentiality and integrity
of user and system data.
3. System logs and monitoring data should be securely stored and
accessible only to authorized personnel for auditing and analysis
purposes.

Assumptions: 1. System Administrator possesses sufficient expertise and access

rights to perform system monitoring activities effectively.
2. System resources are adequate to support continuous monitoring
and analysis of system activities without impacting performance.

Notes and  Proactive and regular system monitoring can help detect and
Issues: mitigate potential issues or security threats before they escalate
into critical problems.
 Continuous improvement of monitoring processes and tools based
on analysis of historical data and emerging trends can enhance
system resilience and performance over time.

3.6 User interfaces (mock screens)

It includes visual representations or mockups of the expected user interfaces within the
system. These mock screens serve as a visual aid to help stakeholders, developers, and
designers understand how the user interfaces will look and function.

This below mock screen illustrates the registration page where users register their
credentials to access the system.

|P a g e
 Figure 2: Prototype (1) Registration Page

|P a g e
This mock screen illustrates the login page where users input their credentials to access
the system.

Figure 3: Prototype (2) Login Page

|P a g e
This mock screen illustrates the Forget Password page where users input their credentials
to change the password and access the system.

Figure 4: Prototype (3) Forget Password Page

|P a g e
After logging in successfully, the user experiences a dashboard that offers him basic
information and services.

Figure 5: Prototype (4) Dashboard

|P a g e
 4. DATA FLOW DIAGRAM (OPTIONAL)

In a system, a data flow diagram (DFD) visually represents data flow and data
processing. Extensivity used to delineate information flow contained in different data
stores and data destinations outside a system. Thus, DFDs are commonly applied for
process simulation in a system and data flow between them in system analysis as well as
design.

4.1 Data Flow Diagram Level 0

A level 0 data flow diagram (DFD) typically called a context diagram provides an
overview of the whole system and its relationships with external entities. The general
processes, sources of data, and destinations as well as the flow of data among them are
shown.

Figure 6: DFD Level 0

4.2 Data Flow Diagram Level 1

A Level 1 data flow diagram is available in the Level 0 DFD to give detailed information
about a specific process’s data flows and processing activities. It offers a more
comprehensive point-of-view by breaking down a significant process at Level 0 into
lesser sub-processes.

|P a g e
 Figure 7: DFD Level 1

4.3 Data Flow Diagram Level 2

A Level 2 Data Flow Diagram consists of more information whereby it further breaks
down subprocesses that would have been identified in Level 1 DFD into more sub-
processes; and at level corresponding to each sub-process in Level 1, there are some
detailed processes at the Level 2.

Figure 8: DFD Level 2

|P a g e
 5. SYSTEM DESIGN

5.1 System Architecture Diagram

A system architecture diagram is used to depict how high-level components interact
within a system. Databases, servers, clients, APIs and other relevant components are
typically depicted. The following is an example of a simple system architecture diagram
in prose form:

Figure 9: System Architecture Diagram

|P a g e
 5.2 Class Diagram
A class diagram is a kind of UML (Unified Modeling Language) diagram which displays
the relationships and the static structure of a software application or system. It shows the
classes graphically and gives details about properties, operations and relationships
existing between them. It is common to see the way a system is actually constructed in an
OOD (object-oriented design) model through class diagrams that represent this fact.

Figure 10: Class Diagram

|P a g e
 5.3 Sequence Diagrams
A sequence diagram represents communication patterns among various objects or parts of
a system at different periods. It outlines how messages or actions are passed from one
element (object or lifeline) to another during a certain scenario or usage situation. These
are diagrams that show how things work together based on the requirements of
developers or clients.

Figure 11: Sequence Diagram

|P a g e
 5.4 Collaboration Diagrams
A collaboration diagram is also known as an interaction diagram or communication
diagram. It indicates how different objects contribute together toward a specific task or
situation in a Unified Modeling Language (UML) system. This kind of diagram uses lines
to show relationships between different objects within the system, simulating exchanges
that take place over time thus highlighting the dynamic properties of a system.

Figure 12: Collaboration Diagram

|P a g e
 5.5 ERD
ERDs are the abbreviations for Entity relationship diagrams which are graphic
representations of how several entities interconnect within a database. They are usually
used as a guide during creation and understanding of databases in database designing.

Figure 13: ERD Diagram

|P a g e
 5.6 Data Dictionary
A data dictionary refers to a centralized location containing information about the data
stored within a database or an information system. It serves as a store for metadata, data
definitions, as well as other details on how data is organized and structured within an
entity. The central purpose of a data dictionary is to provide a comprehensive and
trustworthy source of information for system development and data management.

Table 15: Data Dictionary

Element Name Type Validation Mandatory Remarks
Document ID Integer Numeric Yes Unique
identifier for a
document
Title String Length Yes Title of the
document
Content Test Length No Main content
of the
document
Status Enum Valid Options Yes Status of the
document
User ID Integer Numeric Yes Unique
identifier for a
user
Username String Length, Yes User's
character username
Password String Strength Yes User's
password
Email
Signature ID Integer Length Yes Unique id of
signature
Timestamp Date Time Numeric Yes Date or time
User Role ID Integer Numeric Yes Unique
identifier for a
role
Role Name String Length, Char Yes Name of the
User role

|P a g e
 6. IMPLEMENTATION DETAILS

6.1 Development Setup

To develop a DealDocSign an e-signature web application, you need a combination of
tools and technologies. Here are some commonly used ones:

6.1.1 ReactJS:
ReactJS is a popular JavaScript library for creating user interfaces. ReactJS's component-
based design is one of its best qualities. Front-end of the DealDocSign is build using
ReactJS. React function-based components are used to create and implement the front-
end. The Marketplace's user interface is broken up into smaller, independent components
that offer a dynamic experience.

6.1.2 Laravel:
Laravel is a web application framework with expressive, elegant syntax. Laravel strives
to provide an amazing developer experience while providing powerful features such as
thorough dependency injection, an expressive database abstraction layer, queues and
scheduled jobs, unit and integration testing, and more.

6.1.3 MySQL:
MySQL is an open-source relational database management system (RDBMS) that uses
SQL for managing and querying data. Web applications are widely used because they are
scalable, high performing and work across many platforms MySQL offers ACID
transactions, stored procedures and triggers that make complex database actions possible
and secure. There are community and enterprise editions for different kinds of users.

6.1.4 Postman:
Postman is a widely-recognized tool that makes it easier to create and test APIs. It
reduces the complexity of APIs by simplifying their management process as well. You
can use its GUI (Graphical User Interface) while doing things like sending HTTP
requests or moving responses from one place”. Additionally, Postman can be used in
software testing since it supports scripting, including interface automation, and
integration with CI/CD pipelines to facilitate automated API testing. It also provides
collaboration features which enable teams to share as well as document their APIs
effectively. Postman comes in form of a desktop\browser extension hence enhancing on
productivity in the development and debugging of APIs.

6.1.5 Visual Studio Code:

An IDE called Visual Studio Code is used by us to work on the front-end and back-end
sections. The development code of front-end in ReactJS and backend in Laravel and
MySQL are performed in this IDE.

|P a g e
 6.2 Deployment setup
The pre-requisites for deploying the set-up include downloading and installing Laravel
and NodeJS.

6.2.1 ReactJS:
• Open the source code file in Visual studio code (vs code).
• Open the terminal in vs code
• Run the command “npm start”

6.2.2 Laravel:
• Open the source code file in Visual studio code (vs code).
• Open the terminal in vs code
• Run the command “php artisan serve”

6.3 Algorithms
Algorithms are crucial in documentation for ensuring efficiency and optimization,
enabling developers to understand and improve performance. They provide consistency
and accuracy, making processes repeatable and reliable. Documentation aids in
knowledge transfer and onboarding new team members. It helps in debugging and
maintaining the system by clarifying the logic used.
Some of the algorithm’s proofs are given below:
• This React functional component, Home, sets the document title to "Home -
DevTech" using useEffect when the component mounts. It manages an active tab
state with auto-switching every 2 seconds using another useEffect and setInterval.
The component renders a home banner with an email input form and a "Try Now"
button.

|P a g e
 Figure 14: Home page logic
• The function called `sendDocument` checks if there are necessary files and user
data in an incoming connection request to accept or not. It also looks at whether a
user has been authorized before taking this other step of uploading files thereby
saving them onto cloud storage services where they won’t be lost even if
something happens such as loss of information due to power outages among
others.

Figure 15: Send document logic

|P a g e
 • The ‘deleteDocumentById’ function performs different checks before removing a
document from storage and provides feedback according to what it finds.

Figure 16: Delete document logic

6.4 Constraints
Project's development is affected by constraints. These include technical constraints
related to software and hardware capabilities, time constraints imposed by deadlines,
budget constraints limiting financial resources, scope constraints defining project
boundaries, resource constraints on human and material availability, and regulatory and
ethical constraints ensuring compliance with laws and guidelines. Understanding these
constraints is crucial and kind important for effective project planning and execution.

6.4.1 Assumptions
Assumption means recognizing a situation or circumstance without checking that serves
as basis for planning and decision making in a project or undertaking. This calls for
acceptance of unknowns and hazards amidst hopes grounded in taken-for-granted factors.
• Users have compatible devices (desktop, laptop, tablet, or smartphone) with
modern web browsers capable of running web applications.
• Users have access to a stable internet connection for seamless browsing, signing,
and sending documents.
• Users are familiar with basic web operations and can navigate through web
applications.
• Users understand the concept of electronic signatures and are comfortable using
them in place of traditional signatures.

|P a g e
 • Users have registered accounts with valid personal information to securely sign,
send, and track documents.
• Users are willing to provide necessary permissions for accessing features such as
file storage and camera (if needed for document verification).
• Users have a secure method for uploading documents and are comfortable
entering personal details within the application.
• Users have a secure payment method and are comfortable entering payment
details within the app for any paid features or services.
• Users trust the application to handle sensitive information and documents
securely, following privacy regulations and best practices.
• Users are willing to receive and respond to email notifications related to their
document transactions.
These assumptions are ensuring that the users are able to effectively utilize their e-
signature.

6.4.2 System constraints

A software system’s boundaries and operational parameters are defined by requirements
that constitute restrictions and requirements on the system.
Constraints of a system for an e-signature web application are:
• The app must run seamlessly on different web browsers and platforms so that
users get compatible software.
• It should be optimized for efficient performance, minimizing server resource
usage and ensuring a responsive user experience.
• Adherence to web standards and security protocols should be ensured to maintain
compatibility and protect against vulnerabilities.
• Robust user authentication and data encryption mechanisms should be
implemented to safeguard user accounts and sensitive information.
• Integration with reputable payment processing services should be done, following
their security guidelines to ensure secure transactions.
• Compliance with data privacy regulations, including GDPR, HIPAA, or CCPA,
should be maintained to ensure proper handling and protection of user data.

6.4.3 Restrictions
The term ‘restrictions’ in software development refers to limits or particular conditions
placed by the customer that hinder the development or performance of a software.
Restrictions can involve factors such as cost, time deadline, legal obligations, or
technological choices made by a specific customer. In line with the expectations of the
customer, it is important for software development to understand and follow these
limitations so that successful completion of the project can be assured.

|P a g e
Examples of restrictions that could be imposed on an electronic signature web application
are:
• Ensuring that the application conforms to legal standards for electronic signatures
and data privacy such as GDPR, HIPAA or eIDAS.
• Developing an authentication method that is extremely powerful ensures that we
authenticate people’s identities and maintain integrity in signed documents.
• Adherence to industry best security practices (SSL/TLS encryption, for example)
is essential to safeguard transmitted data from unauthorized access to sensitive
data.
• Integration with existing systems or platforms (for example, CRM software,
document management systems) in a manner that ensures compatibility and
interoperability.
• Compliance with accessibility guidelines (e.g., WCAG) to ensure the application
is usable by individuals with disabilities.
• Designing the application to handle a large number of users and documents
efficiently, while maintaining performance under peak loads.
• Support for multiple languages and locales to cater to a diverse user base across
different regions.
• Compliance with terms of service or usage agreements set by the application
provider or regulatory bodies regarding acceptable use and limitations on user
behavior.

6.4.4 Limitations
Limitations refer to the services or functionalities that the software is unable to provide
due to constraints or design choices. These may include:

• Inability to sign documents without an internet connection due to the nature of

web-based applications.
• Lack of support for biometric authentication methods such as fingerprint or facial
recognition due to technical limitations or regulatory constraints.
• Limited support for complex document editing features such as advanced
formatting or document restructuring.
• Inability to provide legal advice or guarantee the legality of signed documents, as
this falls outside the scope of the software's capabilities.
• Difficulty integrating with older or proprietary systems that lack modern API
support or compatibility with industry standards.
• Absence of real-time collaboration features where multiple users can edit and sign
a document simultaneously, common in traditional office suites.

|P a g e
 • Lack of specialized compliance features tailored to specific industries or
regulatory requirements, necessitating additional customization or third-party
solutions.
• Inability to fully customize the branding and appearance of the e-signature
interface due to platform restrictions or licensing agreements.

|P a g e
 7. TESTING

7.1 Extended Test Cases

Here is the all extend test cases of app, that include Login, Sig-Up, Shopping Cart, Try
Products, Order and others.

7.1.1 Sign-Up
Table 16: Test Case for Sign-Up
Test Case ID: TC_01
Test Case Sign-Up
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Admin, Signer
Description: All user shall be sign-up for the first time to interact app.
Pre-Conditions:  Ensure that the website is accessible.
 No existing account in the system
 Stable internet connection
Actions:  Enter a valid email address in the email address field.
 Enter a strong password in the password field.
 Enter the name and other required details in the respective
fields.
 Submit the sign-up form.
Expected  Successful sign-up
Results:  Account created
 Login possible
 Verification email sent to the registered email address (if
email verification is enabled)
Post  User account exists in the system
Conditions:  Login credentials verified
 User details stored in the database
Test Data:  Valid email address: [email protected]
 Strong password: Test@123
 Correct name and details (e.g., John Doe, 123 Main St, etc.)
Test Web application
Environment:

|P a g e
 Test Case Manual testing
Execution:
Test Result: Pass
Test Case Closed
Closure:
Actual Result: Pass

7.1.2 Login
Table 17: Test Case for Login
Test Case ID: TC_02
Test Case Login
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Admin, Signer
Description: Users shall log in to access the app.
Pre-Conditions:  Existing account in the system
 Correct login credentials (email address and password)
 Stable internet connection
Actions:  Enter a valid email address in the email address field.
 Enter the correct password in the password field.
 Submit the login form.
Expected  Successful login
Results:  Access granted to the app
 User details retrieved from the database
 Redirected to the dashboard or main page
Post  User session established
Conditions:  Login credentials verified
 User details updated in the session
Test Data:  Valid email address: [email protected]
 Correct password: Test@123
Test Web application
Environment:
Test Case Manual testing
Execution:
Test Result: Pass

|P a g e
 Test Case Closed
Closure:
Actual Result: Pass

7.1.3 Upload Document:

Table 18: Test Case for Upload Document
Test Case ID: TC_03
Test Case Upload document
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Admin, Signer
Description: Users shall upload documents for signing.
Pre-Conditions:  Logged-in user
 Valid document format: PDF, DOCX.
 Stable internet connection
Actions:  Select the document to upload from the local machine.
 Click the "Upload" button.
 Wait for the upload process to complete.
 Verify the uploaded document details.
Expected  Document uploaded successfully
Results:  Document details displayed correctly: name, size, type
 Document stored in the system
 User notified of successful upload
Post  Document uploaded to the server
Conditions:  Document details stored in the database
 User session updated with the uploaded document
Test Data:  Upload valid document file: testdocument.pdf
Test Web application
Environment:
Test Case Manual testing
Execution:
Test Result: Pass
Test Case Closed
Closure:
Actual Result: Pass

|P a g e
 7.1.4 Password Recovery
Table 19: Test Case for Password Recovery
Test Case ID: TC_04
Test Case Password Recovery
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Admin, Signer
Description: Users shall recover their passwords.
Pre-Conditions:  Existing account in the system
 User has forgotten their password
 Stable internet connection
Actions:  Click on the "Forgot Password" link.
 Enter the email address associated with the account.
 Click the "Submit" button.
 Wait for the password recovery email.
 Enter the new password.
 Confirm the new password.
 Click the "Reset Password" button.
Expected  Password recovery email sent successfully
Results:  New password saved successfully
 User logged in successfully with the new password
 Password reset confirmation message displayed
Post  Password updated in the database
Conditions:  User session updated with the new password
 Password reset confirmation email sent
Test Data:  Valid email address: [email protected]
 New password: NewPassword123
 Confirm new password: NewPassword123
Test Web application
Environment:
Test Case Manual testing
Execution:
Test Result: Pass
Test Case Closed
Closure:

|P a g e
 Actual Result: Pass

7.1.5 Editing Template:

Table 20: Test Case for Editing Template
Test Case ID: TC_05
Test Case Editing Template
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Admin
Description: Users shall edit templates.
Pre-Conditions:  Logged-in user
 Existing template in the system
 Stable internet connection
Actions:  Select the template to edit from the template list.
 Click the "Edit" button.
 Make changes to the template: add/remove fields, update
text.
 Click the "Save" button.
 Verify the updated template details.
Expected  Template edited successfully
Results:  Changes reflected in the template
 Template saved successfully
 User notified of successful edit
Post  Template updated in the database
Conditions:  User session updated with the edited template
Test Data:  Template ID: TMP001
 Field changes: add/remove fields, update text
Test Web application
Environment:
Test Case Manual testing
Execution:
Test Result: Pass
Test Case Closed
Closure:
Actual Result: Pass

|P a g e
 7.1.6 User Signature
Table 21: Test Case for User Signature
Test Case ID: TC_06
Test Case User Signature
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Signer
Description: Users shall sign documents electronically.
Pre-Conditions:  Logged-in user
 Document uploaded and prepared for signing
 Stable internet connection
Actions:  Select the document to sign from the document list.
 Click the "Sign" button.
 Choose the signature type: electronic, digital
 Create or select a signature: draw, upload, type
 Apply the signature to the document.
 Verify the signed document.
Expected  Document signed successfully
Results:  Signature applied correctly
 Signed document saved and stored
 User notified of successful signing
Post  Document updated in the database with the signature
Conditions:  User session updated with the signed document
Test Data:  Document ID: DOC001
 Signature type: electronic, digital
 Signature data: image, text
Test Web application
Environment:
Test Case Manual testing
Execution:
Test Result: Pass
Test Case Closed
Closure:
Actual Result: Pass

|P a g e
 7.1.7 Update Account
Table 22: Test Case for Update Account
Test Case ID: TC_07
Test Case Update Account
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Admin, Signer
Description: Users shall update their account information.
Pre-Conditions:  Logged-in user
 Existing account with valid credentials
 Stable internet connection
Actions:  Click on the "Account" or "Profile" link.
 Click on the "Edit" or "Update" button.
 Make changes to the account information: name, email,
password, address.
 Click the "Save" or "Update" button.
 Verify the updated account information.
Expected  Account updated successfully
Results:  Changes reflected in the account information
 User notified of successful update
 Login credentials updated (if password was changed)
Post  Account information updated in the database
Conditions:  User session updated with the new account information
Test Data:  Account ID: ACC001
 Updated account information: new name, email, password,
address
Test Web application
Environment:
Test Case Manual testing
Execution:
Test Result: Pass
Test Case Closed
Closure:
Actual Result: Pass

|P a g e
 7.1.8 Share Document
Table 23: Test Case for Share Document
Test Case ID: TC_08
Test Case Share document
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Admin
Description: Users shall share documents with signers for electronic signature.
Pre-Conditions:  Logged-in user
 Document uploaded and prepared for sharing
 Signer's email address or user account
 Stable internet connection
Actions:  Select the document to share from the document list.
 Enter the signer's email address or select their user account.
 Choose the signing method: electronic, digital.
 Add a message or notes for the signer.
 Click the "Share" or "Send" button.
 Verify the document sharing status.
Expected  Document shared successfully
Results:  Signer receives the document and signing request
 User notified of successful sharing
 Document status updated in the system
Post  Document shared with the signer
Conditions:  Signer's status updated in the system: pending, signed
 User session updated with the shared document information
Test Data:  Document ID: DOC001
 Signer's email address or user account
 Signing method: electronic, digital
 Message or notes for the signer.
Test Web application
Environment:
Test Case Manual testing
Execution:
Test Result: Pass
Test Case Closed
Closure:
Actual Result: Pass

|P a g e
 7.1.9 View Signed Document:
Table 24: Test Case for View Signed Document
Test Case ID: TC_09
Test Case View Signed Document
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Admin
Description: Users shall view signed documents.
Pre-Conditions:  Logged-in user
 Document signed and stored in the system
 Stable internet connection
Actions:  Select the signed document to view from the document list.
 Click the "View" or "Download" button.
 Verify the signed document details.
 Verify the signature details: signer's name, date, timestamp.
 Verify the document content and layout.
Expected  Signed document displayed correctly
Results:  Signature details displayed correctly
 Document content and layout preserved
 User notified of successful viewing
Post  Signed document viewed successfully
Conditions:  User session updated with the viewed document information
Test Data:  Document ID: DOC001
 Signer's name and email address
 Signature date and timestamp
 Document content and layout
Test Web application
Environment:
Test Case Manual testing
Execution:
Test Result: Pass
Test Case Closed
Closure:
Actual Result: Pass

|P a g e
 7.1.10 Logout:
Table 25: Test Case for Logout
Test Case ID: TC_10
Test Case Logout
Name:
Created By: Muhammad Talha Last Updated By: Muhammad Talha
Saeed Saeed
Date Created: 15-05-2024 Last Revision Date: 12-06-2024
Actors: Admin, Signer
Description: Users shall log out of the web application.
Pre-Conditions:  Logged-in user
 Stable internet connection
Actions:  Click on the "Logout" or "Sign Out" button.
 Verify the logout confirmation message.
 Click on the "Confirm" or "Logout" button.
 Verify the user is redirected to the login page.
 Verify the user's session is terminated.
Expected  Logout successful
Results:  User redirected to the login page
 User's session terminated
 User notified of successful logout
Post  User's session terminated
Conditions:  User's login credentials invalidated
 User redirected to the login page
Test Data:  None
Test Web application
Environment:
Test Case Manual testing
Execution:
Test Result: Pass
Test Case Closed
Closure:
Actual Result: Pass

7.2 Decision Table

A decision table is a structured way to represent complex business rules and conditions in
a tabular form. It helps in systematically identifying and documenting various conditions

|P a g e
and their corresponding actions, enabling thorough analysis and testing of all possible
scenarios. By clearly outlining these relationships, a decision table ensures
comprehensive and consistent decision-making across a system or process.

7.2.1 Code snippet

Here code snippets are provided with brief description in captions.
• This React functional component, Home, sets the document title to "Home -
DevTech" using useEffect when the component mounts. It manages an active tab
state with auto-switching every 2 seconds using another useEffect and setInterval.
The component renders a home banner with an email input form and a "Try Now"
button.

Figure 17: Home Page Logic

• This function `sendDocument` validates an incoming request for required files
and user information, checks if the user is authenticated, and then stores the
uploaded documents. It saves the document details in the database and sends a
confirmation email to the user, responding with appropriate status codes based on
the process outcome.

|P a g e
 Figure 18: Send Document Logic
• The `deleteDocumentById` function validates the request, checks user
authentication, retrieves the specified document, and deletes it if it exists. It
returns appropriate status messages based on the success or failure of these
operations.

Figure 19: Delete Document Logic

|P a g e
 7.2.2 Decision coverage table
Analyzing a system's behavior under different conditions using a decision table for code
coverage is one such instance. It introduces a comprehensive method of mapping inputs
to outputs in tables, such that there would be no test left out; hence, making it easier
designing them for a given software product while improving its quality.
Condition/Rule C1 C2 C3 C4 C5 C6 C7 C8
User is registered No No Yes Ye Yes Yes Ye Yes
s s
Valid email Ye No Yes No Yes Yes Ye Yes
s s
Valid password Ye Yes Yes Ye No Yes Ye Yes
s s s
Document is uploaded - - - - - No Ye Yes
s
Document requires signature - - - - - - No Yes
Action
A1: Show sign-up form X X
A2: Show error message (invalid X X
email)
A3: Show error message (invalid X
password)
A4: Log in user X
A5: Show upload document option X
A6: Show error message (upload X
required)
A7: Show document signing option X

7.3 Traceability Matrix

A traceability matrix is one tool that can be utilized in software requirements
management or testing systems for tracking connection between test cases or scripts, test
results and requirements. Each row of this table shows all the test cases, test scripts or test
results associated with a particular requirement in a clearly traceable manner to testing.

7.3.1 RID vs UCID (requirements vs use cases)

Here is a detailed and annotated definition of the connectivity matrix used as a tool for
tracing purposes between requirements which are client-based services (CBS)
requirements, among other things, and various use cases.
Table 26: requirements vs use cases
UCID/ R1 R1 R1 R1 R1 R1 R1 R1 R1 R2 R2 R2 R2 R2 R2 R2
RID .1 .2 .3 .4 .5 .6 .7 .8 .9 .0 .1 .2 .3 .4 .5 .6

|P a g e
UC 1 ✓
UC 2 ✓ ✓ ✓
UC 3 ✓ ✓
UC 4 ✓
UC 5 ✓
UC 6 ✓
UC 7 ✓
UC 8 ✓
UC 9 ✓
UC 10 ✓ ✓

7.3.2 Test Cases (RID vs TID)

Here is the traceability matrix between requirement and test cases.
Table 27: RID vs TID
TCID R R R R R R R R R R R R R R R R
/RID 1. 1. 1. 1. 1. 1. 1. 1. 1. 2. 2. 2. 2. 2. 2. 2.
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
TC_0 ✓
1
TC_0 ✓
2
TC_0 ✓
3
TC_0 ✓
4
TC_0 ✓
5
TC_0 ✓
6
TC_0 ✓ ✓
7
TC_0 ✓ ✓ ✓
8
TC_0 ✓
9
TC_1 ✓
0

7.3.3 Coverage (UCID vs TID)

Here is the traceability matrix between test cases and use cases.

|P a g e
Table 28: UCID vs TID
TCID/UCID UC1 UC UC3 UC4 UC UC6 UC UC8 UC UC10
2 5 7 9
TC_01 ✓
TC_02 ✓
TC_03 ✓
TC_04 ✓
TC_05 ✓
TC_06 ✓
TC_07 ✓
TC_08 ✓ ✓ ✓
TC_09 ✓ ✓
TC_10 ✓

|P a g e
 8. RESULTS/OUTPUT/STATISTICS

8.1 %completion

Using the matrix and values from section 7.3.1, the percentage completion of
requirements is calculated as follows:

RID vs TID Matrix (Table 27):

 Total requirements (RIDs): 16 (R1.1 to R2.6)

 Fulfilled requirements: 13 (assuming 81.25% completion)

8.2 %accuracy.

Using the matrix and values from section 7.3.2, the percentage accuracy of implemented
requirements is shown:

RID vs TID Matrix (Table 27):

 Total test cases: 10 (TC_01 to TC_10)

 Correctly implemented requirements: 9 (assuming 90% accuracy)

8.3 %correctness

Using the matrix and values from section 7.3.3, the percentage correctness of tested
requirements is calculated as follows:

UCID vs TID Matrix (Table 28):

 Total use cases (UCIDs): 10 (UC1 to UC10)

 Conforming to requirements: 8 (assuming 80% correctness)

|P a g e
 9. CONCLUSION

DealDocSign is a system for electronic signings that is intended to make document

management and signing processes straight. We came up with DealDocSign for the final
year project so that it helps provide a strong solution which can be used by any kind of
business entity or even an individual using the latest internet software in web
development. As a result, we have put emphasis on matters related to the security,
usability and working well at large as we have created this platform which can answer
multiple needs of our users.
One thing that makes DealDocSign outstanding is its template management system that is
very powerful; it allows you to make, store and use document templates. Time and effort
needed to prepare a document for signing are greatly reduced with this hence it is very
useful, especially when the agreement is repeated severally. Another feature of the
platform is it has various user roles like Admins and Signers. Administrators are able to
control users, monitor the work of papers, also adjust some settings within the system.
This role-based access regulation makes certain that different individuals get the right
kind of entrance.
DealDocSign is built for signing contracts at its core. You can sign any type of paper
work with DealDocSign. Upload your PDF, Docx file and affix your sign electronically
or by drawing it out. All these options available here make it easier for anyone to find
something that would work for them when they sign off papers electronically since you
may decide on different categories when inscribing your name online accordingly to your
preference such as typing, hand drawing or uploading image files etc. In addition, there is
also much emphasis on user satisfaction through its user-friendly interface.
DealDocSign provides an integrated chatbot designed to provide answers to frequently
asked questions. Accommodating general queries and resolving technical problems this
chatbot helps users immediately lessening the need for direct human support that
contributes to enhanced user experience. DealDocSign has been created for adaptability
to address different customer requirements. It can serve individuals or companies of any
size since it is capable of handling any number of documents or users. In addition, it has
extensible architecture, which means that there are possibilities for enhance ability and
integration into other systems on a long-term basis.

|P a g e
 10. FUTURE WORK

In the future, DealDocSign will focus its attention on making its functionality and user
experience better. One major improvement that will be made is in the use of more
advanced methods of verification like biometric verification and blockchain technology
that will ensure very high levels of security and integrity for signed documents.
Also, we aim to add additional functions for document editing and collaboration on the
platform. These functions will enable many people to be simultaneously working within a
document at any time thus enabling real-time collaboration. Improved chatbot
functionality will allow for advanced user support services based on NLP and other
related technologies. Additionally, we are looking to sync DealDocSign with the most
well-known cloud storage solutions and business automation tools.

|P a g e
 11. BIBLIOGRAPHY

11.1 Books
https://books.google.com.pk/books?hl=en&lr=&id=Cne-
igPOkhgC&oi=fnd&pg=PA17&dq=%22electronic+signatures
%22+value+in+law&ots=0CQzkbeA5X&sig=CbWgIbgM2RbodFcor-
7QYoV2eLg&redir_esc=y#v=onepage&q=%22electronic%20signatures%22%20value
%20in%20law&f=false

11.2 Articles
Legality and Validity of E-Signatures in Pakistan - Courting The Law
https://www.sdcollegeambala.ac.in/wp-content/uploads/2021/07/etbmit2017-73.pdf
https://www.certinal.com/esignature-legality/pakistan
https://www.mdpi.com/0718-1876/2/3/24
https://www.ceeol.com/search/article-detail?id=773109
https://itidjournal.org/index.php/itid/article/view/144.html

11.3 Other References

www.paksign.com
Best Electronic Signature Software 2021: Reviews, Pricing & Insights | SoftwarePundit

|P a g e
 12. APPENDIX

12.1 Glossary of terms

The glossary includes definitions of special terms that are found in technical documents
and other writings, usually for example, academic papers or manuals. It helps readers
understand the meaning of particular words that they may not know because these are not
well-known to them and thus enables them to go through the text easier and correctly.

 API (Application Program Interface): A set of protocols and tools for building
software and applications. It specifies how software components should interact.
 Authentication: The process of verifying the identity of a user or system.
 Auth0: A platform that provides authentication and authorization as a service.
 Backend Development: Server-side development which involves databases,
server logic, and integration with front-end.
 Cloud Storage: Storing data on remote servers accessed from the internet, used to
store, manage, and process data.
 Collaboration: The action of working with others to produce or create something,
often in real-time.
 CSS (Cascading Style Sheets): A style sheet language used for describing the
presentation of a document written in HTML or XML.
 Data Encryption: The process of converting data into a code to prevent
unauthorized access.
 Database: A structured set of data held in a computer, especially one that is
accessible in various ways.
 Document Processing: The handling of documents by computers including
storing, retrieving, and sharing.
 End-to-end Encryption: A method of secure communication that prevents third-
parties from accessing data while it's transferred from one end system to another.
 E-Sign (Electronic-Signature): An electronic indication of a person's intent to
agree to the contents of a document.
 Frontend Development: Client-side development dealing with the user interface
and user experience.
 HTML (Hypertext Markup Language): The standard markup language for
documents designed to be displayed in a web browser.
 IDE (Integrated Development Environment): A software suite that consolidates
basic tools required for software testing and debugging.
 JavaScript: A programming language commonly used to create interactive
effects within web browsers.
 JWT (JSON Web Tokens): A compact, URL-safe means of representing claims
to be transferred between two parties.
 Laravel: A PHP web application framework with expressive, elegant syntax.
 MySQL: An open-source relational database management system.
 PHP (Hypertext Preprocessor): A popular general-purpose scripting language
that is especially suited to web development.

|P a g e
  RBAC (Role-based Access Control): An approach to restricting system access to
authorized users.
 React JS: A JavaScript library for building user interfaces.
 SSL/TLS (Secure Sockets Layer/Transport Layer Security): Cryptographic
protocols designed to provide communications security over a computer network.
 User Authentication: The process of verifying the identity of a user attempting to
access a system.
 Version Control: A system that records changes to a file or set of files over time
so that specific versions can be recalled later.

12.2 Pre-requisites
Below are some recommended prerequisites for effectively understanding and working
with the platform called ‘DealDocSign’:

 Basic Understanding of Web Development: Knowledge of HTML, CSS, and

JavaScript is essential for understanding the frontend development.
 Familiarity with PHP and Laravel: Since the backend is developed using PHP
and Laravel, understanding these technologies is crucial.
 Knowledge of Databases: Familiarity with relational databases, particularly
MySQL, will be beneficial.
 Basic Understanding of Cloud Services: Understanding cloud storage solutions
like Amazon S3 for document management.
 Understanding of Authentication Protocols: Knowledge of JWT and user
authentication mechanisms to implement secure login and access control.
 Security Concepts: Basic knowledge of data encryption, SSL/TLS, and RBAC to
understand and ensure data security.
 Version Control Systems: Familiarity with version control systems like Git for
managing code changes.
 Software Tools Proficiency: Experience with software tools such as Visual
Studio Code, XAMPP, and Figma for development and design.

|P a g e