TSE2101 Assignment Part 2 Group 7

Software Design Specification for ABC System Page 1
Software Design
Specification
for
Visitor management for resident

association
Version <2.0>
Group No.: 7
Muhammad Haziq Iskandar 1171203824
Ahmad Aiman Nazhan Bin Mohd Azhar 1221303604
Ben Naser Mohamed Jamal Ali 1221301985
Kim Jia Bin 1191202517
Date: 14 January 2024
Contents
1 System Overview...................................................................................................................................................
1.1 Description......................................................................................................................................................
1.2 Actors.............................................................................................................................................................
1.3 Assumptions and Dependencies....................................................................................................................
2 Use Cases..............................................................................................................................................................
2.1 Use Case Diagram.........................................................................................................................................
2.2 Visitor..............................................................................................................................................................
2.3 Owner.............................................................................................................................................................
2.5 Tenant............................................................................................................................................................
3 Data Design............................................................................................................................................................
3.1 Design Class Diagram....................................................................................................................................
3.2 Data Dictionary...............................................................................................................................................
3.3 Data Structures..............................................................................................................................................
4 Architecture Design..............................................................................................................................................
4.1 Software Architecture.....................................................................................................................................
5 Interface Design....................................................................................................................................................
5.1 Main Screens.................................................................................................................................................
5.2 Subsystem 1 - Admin.....................................................................................................................................
5.3 Subsystem 2 - Visitor.....................................................................................................................................
5.4 Subsystem 3 - Owner.....................................................................................................................................
6 Component Design...............................................................................................................................................
6.1 Main Components..........................................................................................................................................
7 Deployment Design...............................................................................................................................................
7.1 Deployment Diagram......................................................................................................................................
8 Updated Requirements.........................................................................................................................................
Revisions
Version Primary Author(s) Description of Version Date Completed
Report Kim Jia Bin Part 1 of project and first version of 01/12/2023
Version 1.0 Ben Naser Mohamed Jamal report
Ali
Ahmad Aiman Nazhan Bin
Mohd Azhar
Muhammad Haziq Iskandar
Report Kim Jia Bin Part 2 of project and revised version with 14/01/2024
Version 2.0 Ben Naser Mohamed Jamal more information and detail
Ali
Ahmad Aiman Nazhan Bin
Mohd Azhar
Muhammad Haziq Iskandar
1 System Overview
1.1 Description
A Visitor Management system that allows visitors to register themselves for visitation.
Owners and tenants can also log in to the system to approve of said visitation and also manage
their profile and view announcements posted by the admin
1.2 Actors
Actor Use Cases
Admin User Management, Reports & analytics,System

Configuration, Login
Owner Login, Access Control, Feedback Forms, Visitor History
Tenant Login, Access Control, Feedback Forms, Visitor History
Visitor Visitor Registration, Visitor Check-in, Visitor Check-out
1.3 Assumptions and Dependencies

1. Owner may have multiple units within the building.
2. Visitors may forget or simply not bother to check-out.
3. Whether delivery drivers are required to check in to keep records.
4. If Owner/tenant or visitor devices can support the program.
5. The system should be accessible to residents, owners/agents, and administrators.
6. Users may have varying levels of technical expertise.
2 Use Cases
2.1 Use Case Diagram
2.2 Visitor
2.2.1 Use Case 1
Use Case Name: Register Visitation

Description: Visitor will register for visitation
Primary Actor: Visitor
Precondition Visitor will submit a visitation request after inputting details

like name and date.
Postcondition Visitor will be directed to a screen notifying the visitor that
request has been submitted and awaiting approval of
owner/tenant.
Main Success Scenario: 1. Visitor fills in all required data
2. Visitor submits the request
3. Visitor is directed to the “pending approval” page
Alternative Scenario: 1. Visitor did not fill in required data
a. Will prompt visitor to fill in data and not accept
request otherwise
2.2.2 Use Case 2
Use Case Name: Visitor Check-in
Description: Visitor will check themselves in
Primary Actor: Visitor
Precondition Visitor will submit a ticket stating they have checked into the
premise
Postcondition Visitor will be updated to “checked in” status
Main Success Scenario: 1. Visitor checks in
Alternative Scenario: 1. Visitor Did not check in

2.3 Owner
2.3.1 Use case 1
Use Case Name: Visitation Approve
Description: Owner will approve visitation request
Primary Actor: Owner
Precondition Owner will approve visitation request submitted by visitor
Postcondition Visitation request status will be changed to “Approved”
Main Success Scenario: 1. Owner press “approve”

2. Visitation request changes status to “approved”
Alternative Scenario: 1. Owner forgets to approve
2. Owner did not approve request
3. Visitor put wrong info so request did not show up
2.3.2 Use Case 2
Use Case Name: Submit Feedback Form
Description: Owner submits form regarding any issues or feedbacks
Primary Actor: Owner
Precondition Owner fills in form and describes any problems
Postcondition Form submitted and pop-up window saying “submitted”

appear
Main Success Scenario: 1. Form is submitted with no issues
Alternative Scenario: 1. Form submitted but no issues to report

2. Incorrectly filled in form
2.4 Admin
2.4.1 Use case 1
Use Case Name: Post Announcement
Description: Admin post new announcement from management
Primary Actor: Admin
Precondition Admin uploads new announcement
Postcondition New announcement posted
Main Success Scenario: 1. New announcement is posted and shown on

tenant/owner mainpage
Alternative Scenario: 1. Typo in announcement
2. Wrong information in announcement
2.5 Tenant
2.5.1 Use case 1
Use Case Name: Visitation Approve
Description: Tenant will approve visitation request
Primary Actor: Tenant
Precondition Tenant will approve visitation request submitted by visitor
Postcondition Visitation request status will be changed to “Approved”
Main Success Scenario: 1. Tenant press “approve”

2. Visitation request changes status to “approved”
Alternative Scenario: 1. Tenant forgets to approve
2. Tenant did not approve request
3. Visitor put wrong info so request did not show up
2.5.2 Use Case 2
Use Case Name: Submit Feedback Form
Description: Tenant submits form regarding any issues or feedbacks
Primary Actor: Tenant
Precondition Tenant fills in form and describes any problems
Postcondition Form submitted and pop-up window saying “submitted”

appear
Main Success Scenario: 2. Form is submitted with no issues
Alternative Scenario: 3. Form submitted but no issues to report

4. Incorrectly filled in form
3 Data Design
3.1 Design Class Diagram
3.2 Data Dictionary
FK
Table Name Attribute Name Description Type Required PK/FK Referenced
Table
User username Username of the account user VARCHAR(15) YES PK
email Email of the account user VARCHAR(255) YES
phoneNum Phone Number of the account user INT YES
Login loginEmail Registered user’s email VARCHAR(255) YES PK
loginPassword Registered user’s password VARCHAR(20) YES
Admin adminId Admin account ID INT YES PK
username Username of the account user VARCHAR(15) YES FK User
Owner/Tenant ownerTenantId Owner/Tenant account ID INT YES PK
OT_FirstName First name of the Owner/Tenant VARCHAR(20) NO
OT_LastName Last name of the Owner/Tenant VARCHAR(20) NO
phoneNum Phone Number of the account user INT YES FK User
OT_Age Age of the Owner/Tenant INT YES
OT_Sex Gender of the Owner/Tenant VARCHAR(10) YES
buildingId The Building ID INT YES FK Building
Visitor visitorId Visitor account ID INT YES PK
V_FirstName First name of the Visitor VARCHAR(20) NO
V_LastName Last name of the Visitor VARCHAR(20) NO
phoneNum Phone Number of the account user INT YES FK User
V_Age Age of the Visitor INT YES
V_Sex Gender of the Visitor VARCHAR(10) YES
visitId The visit ID INT YES FK VisitingDetail
Announcement announcementId The announcement ID INT YES PK
announcementDescription Description of the announcement made TEXT YES
announcementDate The announcement date DATE YES
Building buildingId The building ID INT YES PK
buildingDesc Description of the building TEXT NO
VisitingDetail visitId The visit ID INT YES PK
visitDate Date of the visit (DD/MM/YYYY) DATE YES
visitTime Time of the visit (HH:MM) TIME YES
visitStatus Status of the visit (approved/not approved) BOOLEAN YES
buildingId The building ID INT YES FK Building
Feedback feedbackId The feedback ID INT YES PK
feedbackDescription The description of the feedback TEXT YES
Report reportId The report ID INT YES PK
reportDescription The description of the report TEXT YES
3.3 Data Structures
3.3.1 User
Table name :
Field name Data type
username String
email String
phoneNum Integer
3.3.2 Login
Table name :
loginEmail String
loginPassword String
3.3.3 Admin
Table name :
adminId Integer
username String
3.3.4 Owner/Tenant
Table name :
ownerTenantId Integer
username String
OT_FirstName String
OT_LastName String
phoneNum Integer
OT_Age Integer
OT_Sex String
buildingId Integer
3.3.5 Visitor
Table name :
visitorId Integer
username String
V_FirstName String
V_LastName String
phoneNum Integer
V_Age Integer
V_Sex String
visitId Integer
3.3.6 Announcement
Table name :
announcementId Integer
announcementDescription Text
announcementDate Timestamp
3.3.7 Building
Table name :
buildingId Integer
buildingDesc Text
3.3.8 VisitingDetail
Table name :
visitId Integer
visitDate Date
visitTime Time
visitStatus Boolean
buildingId Integer
3.3.9 Feedback
Table name :
feedbackId Integer
feedbackDescription Text
username String
3.3.10 Report
Table name :
reportId Integer
reportDescription Text
username String
4 Architecture Design
4.1 Software Architecture
4.1.1 Subsystem 1 : Admin

4.1.2 Subsystem 2 : Owner
4.1.3 Subsystem 3 : Tenant

4.1.4 Subsystem 4 : Visitor

5 Interface Design
5.1 Main Screens
Login page for any users. Can be used to proceed to the sign up page or admin login page.
Users can sign up here.
Admins can login through this page.

5.2 Subsystem 1 - Admin

Admin can check reports by Owners, check feedback given by Owners and Visitors, generate
analysis reports, tweak system and security settings and delete accounts here.
Admins can view reports made by the Owners.

Admins can view feedback given by Visitors and Owners.
Admins can view current buildings and their descriptions.

5.3 Subsystem 2 - Visitor

Visitors can view and edit their profiles, check announcements, give feedback and check in.
Visitors can give feedback.

Visitors can view their check in data and choose to check out.
Visitors can see new announcements made.

5.4 Subsystem 3 - Owner

Owners can check their own profile, view visitor logs, make reports and give feedback.
Owners can give feedback.
Owners can write down reports.
Owners can edit their profile and view announcements.

Owners can view current announcements.

6 Component Design
6.1 Main Components
<TO DO: Describe the main components (modules, classes, packages, etc.) and the table with the
components and related subsystems here.>
1. User Management Module :

- Description: Manages user-related functionalities including account creation, login, and
profile management.
Component Subsystem
AccountCreationClass User Management
LoginClass User Management
UserProfileClass User Management
2. Visitor Registration and Tracking Module :

- Description: Handles visitor registration and monitors their check-ins and check-outs.
Component Subsystem
VisitorRegistrationClass Visitor Management
VisitorCheckInClass Visitor Management
VisitorCheckOutClass Visitor Management

3. Incident Reporting Module :
- Description: Facilitates reporting of incidents within the community.
Component Subsystem
IncidentReportClass Incident Reporting
ReportManagementClass Incident Reporting
4. Announcement Management Module :

- Description: Manages creation and distribution of community-wide announcements.
Component Subsystem
AnnouncementCreationClass Announcement Management
AnnouncementDistributionClass Announcement Management
5. Reporting and Analytics Module :

Description: Generates reports and analytics based on system usage.
Component Subsystem
DataAnalysisClass Reporting and Analytics
ReportGenerationClass Reporting and Analytics
VisualizationClass Reporting and Analytics
6.1.1 Component 1
<TO DO: Describe the component and place the diagram here. There should be algorithm,
pseudocode, flowchart, activity diagram to support the processing in the component.>
…
7 Deployment Design
7.1 Deployment Diagram
8 Updated Requirements
<This section is Optional. Place other requirements that have been updated from the SRS,
particularly those that would have impact on the software design.>

TSE2101 Assignment Part 2 Group 7

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TSE2101 Assignment Part 2 Group 7

Uploaded by

Copyright:

Available Formats

Software Design Specification for ABC System Page 1

Visitor management for resident

Date: 14 January 2024

Actor Use Cases

Admin User Management, Reports & analytics,System

Owner Login, Access Control, Feedback Forms, Visitor History

Tenant Login, Access Control, Feedback Forms, Visitor History

Visitor Visitor Registration, Visitor Check-in, Visitor Check-out

1.3 Assumptions and Dependencies

2.2.1 Use Case 1

Use Case Name: Register Visitation

Primary Actor: Visitor

Precondition Visitor will submit a visitation request after inputting details

2.2.2 Use Case 2

Use Case Name: Visitor Check-in

Description: Visitor will check themselves in

Primary Actor: Visitor

Main Success Scenario: 1. Visitor checks in

Alternative Scenario: 1. Visitor Did not check in

2.3.1 Use case 1

Use Case Name: Visitation Approve

Description: Owner will approve visitation request

Primary Actor: Owner

Precondition Owner will approve visitation request submitted by visitor

Postcondition Visitation request status will be changed to “Approved”

Main Success Scenario: 1. Owner press “approve”

2.3.2 Use Case 2

Use Case Name: Submit Feedback Form

Description: Owner submits form regarding any issues or feedbacks

Primary Actor: Owner

Precondition Owner fills in form and describes any problems

Postcondition Form submitted and pop-up window saying “submitted”

Alternative Scenario: 1. Form submitted but no issues to report

Use Case Name: Post Announcement

Description: Admin post new announcement from management

Primary Actor: Admin

Precondition Admin uploads new announcement

Postcondition New announcement posted

Main Success Scenario: 1. New announcement is posted and shown on

2.5.1 Use case 1

Use Case Name: Visitation Approve

Description: Tenant will approve visitation request

Primary Actor: Tenant

Precondition Tenant will approve visitation request submitted by visitor

Postcondition Visitation request status will be changed to “Approved”

Main Success Scenario: 1. Tenant press “approve”

2.5.2 Use Case 2

Use Case Name: Submit Feedback Form

Description: Tenant submits form regarding any issues or feedbacks

Primary Actor: Tenant

Precondition Tenant fills in form and describes any problems

Postcondition Form submitted and pop-up window saying “submitted”

Alternative Scenario: 3. Form submitted but no issues to report

3.3 Data Structures

4.1.1 Subsystem 1 : Admin

4.1.2 Subsystem 2 : Owner

4.1.3 Subsystem 3 : Tenant

4.1.4 Subsystem 4 : Visitor

Users can sign up here.

Admins can login through this page.

5.2 Subsystem 1 - Admin

Admins can view reports made by the Owners.

Admins can view feedback given by Visitors and Owners.