COURSE PROJECT REPORT

PRESCHOOL ENROLLMENT SYSTEM

Subject: SWD392

​
​

​ ​

1
– Ho Chi Minh City, July 2025 –

Table of Contents
Record of Changes​ 3
I. Overview​ 4
I.1 Project Information​ 4
I.2 Project Team​ 4
II. Requirement Specification​ 4
II.1 Problem description​ 4
II.2 Major Features​ 4
II.3 Context Diagram​ 4
II.4 Nonfunctional Requirements​ 5
II.5 Functional requirements​ 5
II.5.1 Actors​ 5
II.5.2 Use Cases​ 5
II.5.2 .1 Diagram(s)​ 5
II.5.2.2 Use case descriptions​ 6
II.5.3 Activity diagram​ 8
III. Analysis models.​ 9
III.1 Interaction diagrams​ 9
III.2 State diagram​ 10
IV. Design specification​ 11
IV.1 Integrated Communication Diagrams​ 11
IV.2 System High-Level Design​ 11
IV.3 Component and Package Diagram​ 11
IV.4 Class diagram​ 12
IV.5 Database Design​ 12
V. Implementation​ 13
V.1 Map architecture to the structure of the project​ 13
V.2 Map Class Diagram and Interaction Diagram to Code​ 13
V. Applying Alternative Architecture Patterns​ 13
V.1 Applying the service-oriented architecture​ 13
V.2 Applying Service Discovery Pattern in the service-oriented architecture​ 13

2
Record of Changes
Date A*​ In charge Change Description
M, D
14 May A QuynhPVN Create SRS
2025

14 May A DatHt
2025

14 May A LanDDT Add Actors

2025

*A - Added M - Modified D - Deleted

3
I. Overview
I.1 Project Information
•​ Project name: Preschool Enrollment System
•​ Project code: PES
•​ Group name: SWD392-Group1
•​ Software type: Website
I.2 Project Team

Full Name Role Email Mobile

Vo Thi Thanh Van Lecturer [email protected]

Pham Van Nhu Quynh Leader [email protected] 0703346041

Hoang Tien Dat Member [email protected] 0982443113

Tran Van Hua Tri Member [email protected] 0886122578

Dang Dinh Thien Lan Member [email protected] 0934930041

Nguyen Mai Thanh Nam Member [email protected] 0914744318

4
II. Requirement Specification
II.1 Problem description
[Gives the overall description about the product with some introduction and the context
diagram. The context diagram presents the boundary and connections between the system
you’re developing and everything else in the universe. This identifies external entities (or
terminators – software, hardware, human components, and other systems) outside the system
that interface to it in some way, as well as data, control, and material flows between the
terminators and the system.]
The Preschool Enrollment System is designed to replace the existing manual and
paper-based processes used by preschools for managing student admissions.
II.2 Major Features
[Include a numbered list of the major features of the new product, emphasizing those
features that distinguish it from previous or competing products. Specific user requirements
and functional requirements may be traced back to these features.]
<<Sample:
FE-01:​ Order and pay for meals from the cafeteria menu to be picked up or delivered.
FE-02:​ Order and pay for meals from local restaurants to be delivered.
FE-03:​ Create, view, modify, and cancel meal subscriptions for standing or recurring
meal orders, or for daily special meals.
FE-04:​ Create, view, modify, delete, and archive cafeteria menus.
FE-05:​ View ingredient lists and nutritional information for cafeteria menu items.
>>
II.3 Context Diagram
[Context Diagram is the highest-level system analysis diagram, showing the system as a
"black box" with:
External entities interacting with the system
Data flows into and out of the system]

II.4 Nonfunctional requirements

[Provide the descriptions for the functions which have no UI (or not screens), i.e
batch/cron job, service, API, etc.]

Feature System
# Description
Function

5
<<Feature <<Function
1 <<Function Name1 Description>>
Name>> Name1>>

2 …

II.5 Functional requirements

II.5.1 Actors
[An actor is a person (or sometimes another software system or a hardware device) that
interacts with the system to perform a use case. Following are some questions you might ask
to help user representatives identify actors
●​ Who (or what) is notified when something occurs within the system?
●​ Who (or what) provides information or services to the system?
●​ Who (or what) helps the system respond to and complete a task?
This part gives the description of system actors, you can follow the table form as below]

# Actor Description

A user without an account. They can register for an account to log

1 Guest in and start submitting an admission application for their child at the
preschool.

A registered user. They can:

• Submit an admission application for their child.
• Track the application status.
2 Parent
• Receive the electronic admission letter by email.
• View the class schedule and class details.
• See their child’s evaluation results.

School staff, divided into four roles:

- HR: Manages staff accounts and personnel records (cannot modify
the Principal’s account).

3 Staff - Admission: Reviews and approves admission applications;

confirms enrollment; sends results to parents via email.
- Education: Updates enrollment dates; creates class schedules;
organizes regular and special activities; creates classes; assigns
teachers and students; sends student evaluations to parents.

6
- Teacher: Views their class schedule; sees the list of students in
their class; submits comments and evaluations on students to the
Education department.

System administrator. They can:

• Manage global system settings and permissions.
4 Admin
• Manage all user accounts (Guests, Parents, Staff).
• View activity reports and handle technical issues.

II.5.2 Use Cases

[A use case (UC) describes a sequence of interactions between a system and an external
actor that results in the actor being able to achieve some outcome of value. The names of use
cases are always written in the form of a verb followed by an object. Select strong, descriptive
names to make it evident from the name that the use case will deliver something valuable for
some user]
II.5.2.1 Diagram(s)
[Provide the UC diagram(s) to show the actor-UCs and UC-UC relationships like the sample
below. You can have multiple UC diagrams for the system]

7
II.5.2.2 Use case descriptions
This part describes the use cases, you can follow the table form as below]

ID Use Case Actors Use Case Description

01 Withdraw Funds ATM Customer

02 Query Account ATM Customer

03 …

II.5.3 <<Feature 01>>

II.5.3.1 <<UseCaseCode_UC Name>>

II.5.3.1.1 Functional Description

UC ID and Name:

Created By: Date Created:

Primary Actor: Secondary

Actors:

Trigger:

Description:

Preconditions:

Postconditions:

Normal Flow:

Alternative Flows:

Exceptions:

Priority: High (Medium, Low), Must Have (Should Have, Could Have),..

Frequency of Use:

Business Rules:

Other Information:

8
Assumptions:

Functional Description Contents

Use Case ID and Name
Give each use case a unique integer sequence number identifier. State a concise name for the
use case that indicates the value the use case would provide to some user. Begin with an
action verb, followed by an object.
Author and Date Created
Enter the name of the person who initially wrote this use case and the date it was written.
Primary and Secondary Actors
An actor is a person or other entity external to the software system being specified who
interacts with the system and performs use cases to accomplish tasks. Different actors often
correspond to different user classes, or roles, identified from the customer community that
will use the product. Name the primary actor that will be initiating this use case and any other
secondary actors who will participate in completing execution of the use case.
Trigger
Identify the business event, system event, or user action that initiates the use case. This
trigger alerts the system that it should begin testing the preconditions for the use case so it can
judge whether to proceed with execution.
Description
Provide a brief description of the reason for and outcome of this use case, or a high-level
description of the sequence of actions and the outcome of executing the use case.
Preconditions
List any activities that must take place, or any conditions that must be true, before the use
case can be started. The system must be able to test each precondition. Number each
precondition. Example: PRE-1: User’s identity has been authenticated.
Postconditions
Describe the state of the system at the successful conclusion of the use case execution. Label
each postcondition in the form POST-X, where X is a sequence number. Example: POST-1:
Price of item in the database has been updated with the new value.
Normal Flow
Provide a description of the user actions and corresponding system responses that will take
place during execution of the use case under normal, expected conditions. This dialog
sequence will ultimately lead to accomplishing the goal stated in the use case name and

9
description. Show a numbered list of actions performed by the actor, alternating with
responses provided by the system. The normal flow is numbered “X.0”, where “X” is the Use
Case ID.
Alternative Flows
Document other successful usage scenarios that can take place within this use case. State the
alternative flow, and describe any differences in the sequence of steps that take place. Number
each alternative flow in the form “X.Y”, where “X” is the Use Case ID and Y is a sequence
number for the alternative flow. For example, “5.3” would indicate the third alternative flow
for use case number 5. Indicate where each alternative flow would branch off from the normal
flow, and if pertinent, where it would rejoin the normal flow.
Exceptions
Describe any anticipated error conditions that could occur during execution of the use case
and how the system is to respond to those conditions. Number each alternative flow in the
form “X.Y.EZ”, where “X” is the Use Case ID, Y indicates the normal (0) or alternative (>0)
flow during which this exception could take place, “E” indicates an exception, and “Z” is a
sequence number for the exceptions. For example “5.0.E2” would indicate the second
exception for the normal flow for use case number 5. Indicate where in the normal (or an
alternative) flow each exception could occur.
Priority
Indicate the relative priority of implementing the functionality required to allow this use case
to be executed. Use the same priority scheme as that used for the functional requirements.
Frequency of Use
Estimate the number of times this use case will be performed per some appropriate unit of
time. This gives an early indicator of throughput, concurrent usage loads, and transaction
capacity.
Business Rules
List any business rules that influence this use case. Don’t include the business rule text here,
just its identifier so the reader can find it in another repository when needed.
Other Information
Identify any additional requirements, such as quality attributes, for the use case that may need
to be addressed during design or implementation. Also list any associated functional
requirements that aren’t a direct part of the use case flows but which a developer needs to
know about. Describe what should happen if the use case execution fails for some
unanticipated or systemic reason (e.g., loss of network connectivity, timeout). If the use case
results in a durable state change in a database or the outside world, state whether the change
is rolled back, completed correctly, partially completed with a known state, or left in an
undetermined state as a result of the exception.

10
Assumptions
List any assumptions that were made regarding this use case or how it might execute.

II.5.3.1.2 Business Rules

Provide the business rules those are applied only to the use case

ID Business Rule Business Rule Description

FR1 Password Encoding User’s password must be encoded with MD5 hashing

II.5.3.1.3 Activity diagram

[This part describes the use cases, you can follow the table form as below]
Sample:

………

11
II.6 Entity Relationship Diagram
[Provide the entity relationship diagram and the entity descriptions in the table format as
below]

III. Analysis models.

III.1 Interaction diagrams
[Interaction diagrams are a type of UML diagram that illustrate how objects interact in a
particular scenario of a use case. They focus on the flow of messages between objects or
components over time.
There are two main types:
-​ Sequence Diagram – Emphasizes the time-ordering of messages
-​ Communication Diagram – Emphasizes the structure and relationships between
objects]

III.1.1.Sequence Diagram

[Provide the sequence diagram(s) for the feature, see the sample below]

12
III.1.2. Communication Diagram
[Provide the Communication diagram(s) for the feature, see the sample below]

III.2 State diagram

[Provide the State diagram(s) for the feature, see the sample below]

13
IV. Design specification
IV.1 Integrated Communication Diagrams
Sample

IV.2 System High-Level Design

Sample

14
IV.3 Component and Package Diagram
IV.3.1 Component Diagram
Sample

IV.3.1 . Package Diagram

[Provide the package diagram for each sub-system. The content of this section including the
overall package diagram, the explanation, package and class naming conventions in each
package. Please see the sample & description table format below (please note: package
names don’t follow Java package naming convention yet)]

15
Package descriptions

No Package Description

01 omemberauthorityrm <Description of the package>

02 registration <Description of the package>

03 fedrpc <Description of the package>

04 ofed <Description of the package>

05 mongoDB <Description of the package>

06 fedtools <Description of the package>

07 …

IV.4 Class diagram

[This part presents the class diagram for the relevant feature]

16
IV.5 Database Design
[Provide the tables relationship like example below – following MySQL database naming
convention]

17
V. Implementation
V.1 Map architecture to the structure of the project
[Provide:
1.​ Overview of the Chosen Architecture
Briefly describe the architectural style (e.g., Layered, MVC, Service-Oriented Architecture)
Explain why it was selected for this project (e.g., to meet non-functional requirements like
maintainability, scalability, reusability)
2.​ Mapping to Project Structure
Present the actual project folder/package structure
Map each layer/component in the architecture to concrete project modules]

V.2 Map Class Diagram and Interaction Diagram to Code

[Demo the implementation of several features using design patterns]

18
VI. Applying Alternative Architecture Patterns
VI.1 Applying the ………….. (ex: Service-Oriented Architecture (SOA)) architecture
[Redesign part of the system architecture using Service-Oriented Architecture (SOA) to
improve reusability, scalability, and modularity.
Students must provide:
1.​ Problem Identification
Briefly describe which non-functional requirement(s) are not fully supported by the
current architecture (e.g., NF-05: Reusability)
2.​ SOA-Based Solution
Reorganize system components into independent services
E.g., refactor FSOData into separate service modules
3.​ Supporting Diagrams
Deployment Diagram
Updated Class Diagram
Component Diagram showing separate services]

VI.2 Applying Service Discovery Pattern in the service-oriented architecture

[Support dynamic service registration and discovery in SOA or microservice-based
architecture for horizontal scalability and ease of expansion.
Students must provide:
1.​ Problem & Requirement
Explain the relevant non-functional requirement (e.g., NF-06: Scalability)
Describe the need for service discovery in a growing system (e.g., multiple branches,
independent modules)
2.​ Service Discovery-Based Solution
Integrate a Service Discovery Pattern
Mention possible technologies: Consul, Eureka, Kubernetes DNS
3.​ Supporting Diagrams
Deployment Diagram (with multiple instances and registry)
Updated Class/Component Diagram including a Discovery Service]

19