IDProject: Canadoc

Professor: Mohamed Khan

COMP-246 Group 3

Group Members:

Name ID

1
Part A: Project Scope and Requirements 5
Section 1: Problem Statement 5
1.1.a. Problem & Need 5
1.1.b. List of Capabilities and Benefits 5
1.2 Identify the stakeholders and their roles 6
1.3 Identify the sub-systems of your application (What are its functional components) 7
1.4 Who are the intended users of the SRS documentation? 7
Section 2: General Overview Modelling 8
2.1 Context Flow Diagram (CFD) 8
Section 3: Requirements - functional and non-functional 9
3.1 Non-functional requirements 9
3.2 Functional Requirements 10
3.2.1 Entrance subsystem 10
3.2.1.1 Goal use cases 10
3.2.1.2 Use case diagram 11
3.2.1.3 User stories 11
3.2.2 ID subsystem 12
3.2.2.1 Goal use cases 12
3.2.2.2 Use case diagram 13
3.2.2.3 User stories 13
3.2.3 Healthcare subsystem 14
3.2.3.1 Goal use cases 14
3.2.3.2 Use case diagram 15
3.2.3.3 User stories 15
3.2.4 Message subsystem 16
3.2.4.1 Goal use cases 16
3.2.4.2 Use case diagram 17
3.2.4.3 User stories 18
Section 4: Domain Class diagram 19
4.1 List of classes 19
4.2 Diagram 19
Section 5: ERD 21
Section 6: UML System Sequence Diagrams 22
6.1 Goal Use Case: Viewing the ID 22
6.2 Goal Use Case: Viewing Vaccine Passport 23
Section 7: State Diagrams 24
7.1 Login to the System 24
7.2 Message State diagram 25
Section 8: Technologies. 25
Section 9: Gantt Chart 26

Part B: Software Design Architecture 27

2
Section 1: Requirements Edits to Part A. 27
1.1 Context Flow Diagram (section 2) 27
1.2 Sequence diagram (section 6.1) 27
1.3 ERD (section 5) 27
Section 2: Overview Model 27
2.1 Intended users of the SDD document 27
2.2 Architectural Context Diagram (ACD) and Context Flow Diagram (CFD) 28
2.2.1 Architectural Context Diagram (ACD) 28
2.2.2. Context Flow Diagram (CFD) 29
Section 3: Modularization 30
3.1 Analysis Model Partition 30
3.1.1 - Entrance Subsystem 30
3.1.2 - ID Subsystem 31
3.1.3 - Healthcare Subsystem 32
3.1.4 - Message Subsystem 33
3.2 Class Responsibility Collaboration (CRC) 34
3.2.1 Entrance Subsystem 34
3.2.2 ID Subsystem 35
3.2.3 Healthcare Subsystem 36
3.2.4 Message Subsystem 37
3.3 Design classes diagram 38
3.3.1 Entrance Subsystem 38
3.3.2 ID Subsystem 39
3.3.3 Healthcare Subsystem 40
3.3.4 Message Subsystem 41
Section 4: Framework MVC 42
4.1: MVC Pattern Diagrams 42
4.1.1 Entrance Subsystem 42
4.1.2 ID Subsystem 43
4.1.3 Healthcare Subsystem 44
4.1.4 Message Subsystem 45
4.2: System Sequence Diagrams 46
4.2.1 Goal Use Case: Alert Generation for Expiration ID for Citizen or Permanent Resident
(Message Subsystem) 46
4.2.2 Goal Use Case: Scanning Vaccine Passport for Citizen or Permanent Resident (Health
Subsystem) 47
4.3 State Machine Diagrams 48
4.3.1 Object: Driver’s License 48
4.3.2 Object: Message 49
Section 5: Data Layer 50
5.1 Database Schema 50
5.2 Technology List Update 51

3
 Section 6: Gantt Chart 51

Part C: System Design Documents 52

Section 1.0: Corrections to Design Specifications Part B 52
Section 1: Software Design Patterns. 52
1.1. Singleton pattern. 52
1.2. Facade pattern. 52
1.3. Observer pattern. 52
Section 2: Using common software design patterns. 53
Table1. Pattern-Organization table 53
Section 3: UI/UX design. 57
3.1. Welcome 3.2. Login 3.3. Pin Verification 57
3.4. Home Page 3.5. View Driver’s License 58
Section 4: High level Component/Deployment Diagram. 59
Section 5: Gannt chart. 60

4
Part A: Project Scope and Requirements

Section 1: Problem Statement

1.1.a. Problem & Need

Managing and organizing your government documents or keeping track of the status of your government
applications and appointments can be a very troublesome and time-consuming task. This user-friendly mobile
app helps citizens and residents of Canada by organizing all of their important documents, applications, and
appointments all in one secure and accessible place, essentially eliminating the need to carry physical
documents around. This app also provides the ability to easily renew documents, and track appointments
without the need to visit or call a physical location which often results in long wait times and the need for
making time available in a busy schedule.

1.1.b. List of Capabilities and Benefits

(i) Capabilities:

● Store personal documents for easy access whenever and wherever required (ID’s, passport, health
card, social insurance number, permanent resident card, study permits, temporary resident visa, travel
documents, etc.)
● Vaccine passport feature that is required in order to travel internationally and to be able to attend
events with a large gathering of people such as sports events, concerts, etc.
● Notification reminders for expiration of documents.

(ii) Benefits:

● Provides an accessible and time-efficient method to obtain any personal government documents.
● Manage and organize all personal documents and document renewals with ease.
● It eliminates the need to carry physical documents and IDs around, which can get lost or stolen.
● Removes the risk of being provided with fake documentation as all government documents require
verification.
● It eliminates the need to visit or call a physical location which often results in long wait times and the
need for making time available in a busy schedule.
● Prioritizes security and guarantees that user’s information and documents are secure.

5
 1.2 Identify the stakeholders and their roles

Stakeholder Role

End User: Citizen The primary user of the application. Uses the app to
store personal documentation in one place. As well
as being able to renew the documents.

End User: Government Uses the app to manage everything from the back
end, making sure everything works.

IT Security Provides security to make sure the end user’s data is

protected.

System support Provides support to the end user once the system
doesn’t behave as predicted.

Government support Provides the end user with the issues regarding their
application or answers any questions.

6
 1.3 Identify the sub-systems of your application (What are its functional
components)

● Entrance Subsystem
● ID Subsystem
● Healthcare Subsystem
● Message Subsystem

1.4 Who are the intended users of the SRS documentation?

Role Purpose

Developers To understand the purpose of the product and requirements for its
development.

Testers To understand the purpose of the product and requirements for its
testing.

Designers To understand the purpose of the product and requirements for its
development.

Product owner To understand the purpose of the product and provide a clear product
vision for the team.

Scrum master To get information about the product and its stakeholders to insure
team’s productivity.

7
Section 2: General Overview Modelling

2.1 Context Flow Diagram (CFD)

8
Section 3: Requirements - functional and non-functional

3.1 Non-functional requirements

NFR# Name Description

NFR001 Efficiency Requirements of the software system handles capacity, throughput, and response
time to request.

NFR002 Security Requirements of the software system to be able to protect its data, and profile
information from internal and external sources.

NFR003 Flexibility Ability of the software system to adapt to different configurations, and user
expectations.

NFR004 Accessibility Ability of the software to be usable by people that need it, and by people with the
widest range of capabilities.

NFR005 Scalability Ability of the system to expand its processing capabilities upward and outward.

NFR006 Confidentiality Ability of the system to protect sensitive data from 3rd party applications and
sources.

NFR007 Maintainability Ability of the faults in the software to be easily found and fixed.

3.2 Functional Requirements

3.2.1 Entrance subsystem

3.2.1.1 Goal use cases

FR# Goal Use Case Role Description

FR001 Register in the system All users A user will be able to register in the
application.

FR002 Log in to the system All users A user will be able to use password and other
credentials to login in the system.

9
FR003 Logout of the system All users A user will be able to log out of the system at
any time.

FR004 Change password All users A user will be able to change password while
logged in the system

FR005 Log in through fingerprint All users A user will be able to use a fingerprint to login
in the system

3.2.1.2 Use case diagram

3.2.1.3 User stories

# User story Acceptance criteria

1 As a User, I want to be able to register in the - User should confirm his/her identity by
application, so that I am able to use the entering:
program. - SIN number
- Full name
- telephone number
- email address

10
 - physical address
- password

2 As a User, I want to be able to log in the - The system should accept and verify user’s
application, so that I am able to review my email/phone number and password or
fingerprint;
- User should be notified via email about
his/her data being accessed.

3 As a User, I want to be able to log out the - User should confirm the decision to exit the
system, so that I can safely close the system;
application. - The message should be displayed,
confirming successful log out.

4 As a User, I want to be automatically logged - User should receive a message prior log out
out in 10 minutes, so that my data stays if the application is still active and not
protected. working on the background;
- If the phone was turned off, the User
should be automatically logged out, even
before 10 minutes expire.

5 As a User, I want to be able to set my own - The password should contain:

password, so that I can ensure my safety and - uppercase and lowercase letters
easier remember the password. - special symbol
- min 8 characters
- max 15 characters
- User should be instructed about password
requirements

3.2.2 ID subsystem

3.2.2.1 Goal use cases

FR# Goal Use Case Role Description

FR006 View ID Citizen/PR A citizen will be able to view personal IDs in

the application.

FR007 Generate a code for Citizen/PR A citizen will be able to generate a barcode
scanning ID and QR code of the ID.

FR008 Send ID Citizen/PR A citizen will be able to send his/her ID

through email or social media resources.

11
FR009 Update ID PGR A government representative will be able to
update citizens’ ID by uploading a new file
and replacing the old one.

FR010 Remove/Block driving PGR A government representative will be able to

license remove or block citizens’ driver license ID as
a part of the penalty.

3.2.2.2 Use case diagram

3.2.2.3 User stories

# User story Acceptance criteria

1 As a Citizen, I want to be able to view my ID, - An ID can be viewed online;

so that I can check the information on it or - An ID can be viewed offline.

12
 show it to other people if needed.

2 As a Citizen, I want to be able to generate a - The system is able to generate barcode;

code for scanning my ID so that it is easier to - The system is able to generate a QR code.
share my data - The fingerprint confirmation is required for
the operation

3 As a Citizen, I want to be able to send my - The document can be sent as a attached

document directly from the application, so that document through:
I don’t have to download it prior to that - email
- message in the WhatsApp
- message in Telegram
- The fingerprint confirmation is required for
the operation

4 As a Government rep, I want to be able to - The format of the document must be pdf
upload a new citizen’s ID, so that the citizen
can have easier access to the renewed
document.

5 As a Government rep, I want to be able to - Citizen is not able to view his/her driver
remove or block a citizen’s driver license, so license;
that the citizen won’t be able to use it as a - Citizen is not able to scan his/her driver
result of the penalty. license.

3.2.3 Healthcare subsystem

3.2.3.1 Goal use cases

FR# Goal Use Case Role Description

FR011 View health card Citizen/PR A citizen will be able to view the Health
Card in the application.

FR012 Generate a code for Citizen/PR A citizen will be able to generate a barcode
scanning Health card and QR code of the Health card.

FR013 Send health card Citizen/PR A citizen will be able to send his/her Health
card through email or medical program to
the health care professional.

FR014 View vaccine passport Citizen/PR A citizen will be able to access and view
the vaccine passport in the application.

13
FR015 Generate a code for Citizen/PR A citizen will be able to generate a barcode
scanning vaccine passport and QR code of the vaccine passport for
scanning.

3.2.3.2 Use case diagram

3.2.3.3 User stories

# User story Acceptance criteria

1 As a Citizen, I want to be able to view my - A Health card can be viewed

health card, so that I can check the information online;
on it or show it to medical professionals. - A Health card can be viewed
offline.

14
2 As a Citizen, I want to be able to generate a - The system is able to generate barcode;
code for scanning my Health card so that it is - The system is able to generate a QR code.
easier to transfer it to the medical professionals. - The fingerprint confirmation is required for
the operation

3 As a Citizen, I want to be able to send my - The document can be sent as a attached

health card from the application, so that I don’t document through:
have to download it prior to that. - email
- message in the WhatsApp
- message in Telegram
- The fingerprint confirmation is required for
the operation

4 As a Citizen, I want to be able to view my - A Vacince passport can be viewed online;

vaccine passport, so that I can check the - A Vacince passport can be viewed offline.
information on it or show it to medical
professionals.

5 As a Citizen, I want to be able to generate a - The system is able to generate barcode;

code for scanning my vaccine passport so that it - The system is able to generate a QR code.
is easier to scan it for verification when needed. - The fingerprint confirmation is required for
the operation

3.2.4 Message subsystem

3.2.4.1 Goal use cases

FR# Goal Use Case Role Description

FR016 Receive messages Citizen/PR A citizen will be able to receive any

15
 message from the gov. rep. through the
application.

FR017 Receive alert message about Citizen/PR A citizen will receive alert messages
expiry date of the from the system, reminding about expiry
documents. dates of the documents.

FR018 Archive important messages. Citizen/PR A citizen will be able to save messages
of his/her choosing for the desired
period of time in the application.

FR019 Receive notification about Citizen/PR A citizen will be reminded through the
appointments. notification about scheduled meetings in
the government structures.

FR020 Send messages PGR A government rep. will be to send

messages to the citizen or PR through
the application.

3.2.4.2 Use case diagram

16
 3.2.4.3 User stories

# User story Acceptance criteria

1 As a citizen I want to be able to receive - A message should include sound alert

messages from government representatives so - A citizen should be able to review or
that I can stay on track of any government download attached files
process concerning me.

2 As a citizen I want to be able to receive a A citizen should be notified by default:

notification about the expiry date of my - 1 month before the expiry date
documents, so that I can have enough time to - 2 weeks before the expiry date
take necessary measures in advance.

3 As a citizen I want to be able to save (archive) - A citizen should be able to create

important messages, so that I can review them custom folder for saving messages
any time. - A citizen should be able to label
messages

4 As a citizen I want to be reminded about The copy of the reminder can be sent to:
scheduled meetings in government structures, - Email
so that I won’t forget about them and miss - Phone
them.
The citizen will receive two default notifications

17
 set to :
- 24 hours before the appointment
- 3 hours before the appointment

5 As a government representative I want to be The message can be send to:

able to send citizen or PR a message that will - email
be send through tagged channels - Phone number
simultaneously, so that I have to enter a - application
message only once

Section 4: Domain Class diagram

4.1 List of classes

● MainLogin ● VaccinePassport
● User ● OntarioID
● Citizen ● Message
● Pr ● Alert
● SysAdmin ● Notifications
● GovUser ● DriverLicense
● ID ● HealthCard

18
 4.2 Diagram

Section 5: ERD

19
20
Section 6: UML System Sequence Diagrams

6.1 Goal Use Case: Viewing the ID

21
6.2 Goal Use Case: Viewing Vaccine Passport

22
Section 7: State Diagrams

7.1 Login to the System

23
 7.2 Message State diagram

Section 8: Technologies.

Mobile Application (iOS, Android)

Client Side: React Native (HTML/CSS, JavaScript/Typescript)

Business Logic: Express (EJS), Node (JavaScript)

Data side (Database): MongoDB (JavaScript)

24
Section 9: Gantt Chart

25
Part B: Software Design Architecture

Section 1: Requirements Edits to Part A.

1.1 Context Flow Diagram (section 2)

Added a clarification to the Government representative as being Provincial.

1.2 Sequence diagram (section 6.1)

Removed Government Database from the diagram.

1.3 ERD (section 5)

Removed bridge table and government table that connected to the application table.

Section 2: Overview Model

2.1 Intended users of the SDD document

Role Purpose

Developers To understand the architecture and build logic for the application around
it.

Testers To have an understanding of the application’s architecture and build

tests relying on it.

Designers To maintain the UX concept for the application and build UI around it.

26
Product owner To ensure that the application is built according to business
requirements and to have a vision for accommodating additional
functionality in the future.

2.2.1. Context Flow Diagram – CFD ( What Diagram)

27
2.2.2 Architectural Context Diagram – ACD ( How Diagram)

28
Section 3: Modularization

3.1 Analysis Model Partition

3.1.1 - Entrance Subsystem

● Login Interface
● Application Interface
● Register Interface
● User
● Citizen
● PR
● SysAdmin
● GetUser

29
 3.1.2 - ID Subsystem

● User
● Citizen
● PR
● GovUser
● ID
● DriversLicense
● HealthCard
● OntarioID
● VaccinePassport

30
 3.1.3 - Healthcare Subsystem

● User
● Citizen
● PR
● ID
● HealthCard
● VaccinePassport

31
 3.1.4 - Message Subsystem

● User
● Citizen
● PR
● GovUser
● ID
● Message
● Alert
● Notification

32
3.2 Class Responsibility Collaboration (CRC)

3.2.1 Entrance Subsystem

33
3.2.2 ID Subsystem

34
35
3.2.3 Healthcare Subsystem

36
3.2.4 Message Subsystem

37
3.3 Design classes diagram

3.3.1 Entrance Subsystem

38
3.3.2 ID Subsystem

39
3.3.3 Healthcare Subsystem

40
3.3.4 Message Subsystem

41
Section 4: Framework MVC

4.1: MVC Pattern Diagrams

4.1.1 Entrance Subsystem

42
4.1.2 ID Subsystem

43
4.1.3 Healthcare Subsystem

44
4.1.4 Message Subsystem

45
 4.2: System Sequence Diagrams

4.2.1 Goal Use Case: Alert Generation for Expiration ID for Citizen or Permanent
Resident (Message Subsystem)

46
 4.2.2 Goal Use Case: Scanning Vaccine Passport for Citizen or Permanent Resident
(Health Subsystem)

47
4.3 State Machine Diagrams

4.3.1 Object: Driver’s License

48
4.3.2 Object: Message

49
Section 5: Data Layer

5.1 Database Schema

50
 5.2 Technology List Update

No updates required.

Section 6: Gantt Chart

51
Part C: System Design Documents

Section 1.0: Corrections to Design Specifications Part B

No corrections are required.

Section 1: Software Design Patterns.

1.1. Singleton pattern.

As the Canadoc project is focused on working with government ids and documents, there can be only one
implementation of each document. According to that, the use of the Singleton design pattern will be
especially helpful. We are going to apply this pattern to each implementation of the ID class separately.

1.2. Facade pattern.

The Facade pattern is going to be used to construct two high level interfaces: one is for Citizen and
Permanent Resident, and the second one is for the Provincial Government Representative or System
Administrator. In that way, all communication between objects in the application will be wrapped in one
of the two interfaces depending on the User’s role.

1.3. Observer pattern.

We are intending to use the Observer design pattern to set an automatic notification for the User. In
particular, the Message class is going to be set as an Observer and check the status of the ID class (the
implementations of this class such as Driver License and others). When IDs change their status to
‘expired’ the Message will be triggered and the notification will be sent to the User.

52
 Section 2: Using common software design patterns.

Table1. Pattern-Organization table

Design Subsystem Design Pattern

Entrance Subsystem Observer pattern

53
ID Subsystem Singleton pattern

54
55
Healthcare Facade pattern
Subsystem

56
Message Subsystem Observer pattern

Section 3: UI/UX design.

3.1. Welcome 3.2. Login 3.3. Pin Verification

57
3.4. Home Page 3.5. View Driver’s License

58
59
Section 4: High level Component/Deployment Diagram.

60
Section 5: Gannt chart.

61