Module Code & Module Title

CS5002 Software Engineering

Assessment Weightage & Type

20% Group Coursework

Year and Semester

2018-19 Autumn

Group Name:
University
SN Student Name College ID
ID
01 Tsedup Dorjee Lama NP01CP4A170237 17031187
02 Nabraj Khadka NP01CP4A170166 17031260
03 Biplab Dhungana NP01CP4A170243 17031222
04 Shikhar Khadka NP01CP4A170156 17031249
05 Sajag Acharya NP01CP4A170158 17031251

I confirm that I understand my coursework needs to be submitted online via Google Classroom
under the relevant module page before the deadline in order for my assignment to be accepted and marked.
I am fully aware that late submissions will be treated as non-submission and a mark of zero will be awarded.
Table of Contents
1. Introduction ....................................................................................................... 1

2. Group tasks ...................................................................................................... 2

2.1 Environmental model specification .............................................................. 2

2.1.1 Context Level Data Flow Diagram (DFD) ............................................. 2

2.2 Internal Model Specification for the system................................................. 4

2.2.1 Level 1 Data Flow Diagram .................................................................. 4

2.2.3 Entity relationship diagram (ERD) ........................................................ 6

2.2.4 Data Dictionary ..................................................................................... 7

2.2.5 Process Specification ........................................................................... 9

2.3 Design Specification ................................................................................. 13

2.3.4 Structure chart .................................................................................... 13

2.4 Assignment diary ...................................................................................... 16

2.4.1 Meeting Log ........................................................................................ 17

2.4.2 Individual task distribution .................................................................. 18

3. Individual tasks ............................................................................................... 19

3.1 Environmental model specification ............................................................ 19

3.1.1 Context level diagram ......................................................................... 19

3.2 Internal module specification..................................................................... 23

3.2.1 Level 1 Data flow Diagram ................................................................. 23

3.2.2 Level 2 Data flow diagram .................................................................. 27

3.3 Design Specification ................................................................................. 31

3.3.1 Structure chart .................................................................................... 31

3.3.2 Module specification ........................................................................... 36

4. Conclusion ...................................................................................................... 40
List of Figures

Figure 1: Context level diagram - fitness application system ......................................... 2

Figure 2: Level 2 DFD - Fitness application system ....................................................... 4
Figure 3: Entity relationship diagram (ERD) - Fitness application system ...................... 6
Figure 4: Structure chart – Login Page ........................................................................ 13
Figure 5: Structure chart - Admin Dashboard .............................................................. 13
Figure 6: Structure chart - Customer Dashboard ......................................................... 14
Figure 7: Structure chart - Staff Dashboard ................................................................. 14
Figure 8: Context level diagram - Register customer ................................................... 19
Figure 9: Context level – Payment ............................................................................... 20
Figure 10: Context level diagram - Generate report ..................................................... 20
Figure 11: Context level diagram - To-do list ............................................................... 21
Figure 12: Context level diagram - De-register customer ............................................. 22
Figure 13: Level 1 DFD - Register customer ................................................................ 23
Figure 14: Level 1 DFD : payment ............................................................................... 24
Figure 15: Level 1 DFD - Generate report ................................................................... 24
Figure 16: Level 1 DFD - To-do list .............................................................................. 25
Figure 17: Level 1 DFD - De-register customer ........................................................... 26
Figure 18: Level 2 DFD - Register customer ................................................................ 27
Figure 19: Level 2 DFD – Payment .............................................................................. 27
Figure 20: Generate report .......................................................................................... 28
Figure 21: Level 2 DFD - To-do list .............................................................................. 29
Figure 22: Level 2 DFD - De-register customer ........................................................... 30
Figure 23: Structure Chart- Register customer ............................................................ 31
Figure 24: Structure chart - Payment ........................................................................... 32
Figure 25: Structure chart - Generate report ................................................................ 33
Figure 26: Structure chart - To-do list .......................................................................... 34
Figure 27: Structure chart - De-register customer ........................................................ 35
List of tables

Table 1: Data Dictionary - Customer Table .................................................................... 7

Table 2: Data Dictionary - Staff table............................................................................... 7
Table 3: Data Dictionary - Task table .............................................................................. 8
Table 4: Data Dictionary - To-do list ................................................................................ 8
Table 5: Meeting Log..................................................................................................... 17
Table 6: Individual task distribution ............................................................................... 18
 CS5002 Software Engineering

1. Introduction

This group coursework of software engineering module was given out in the
second week of our third semester. It is required to be submitted by the eleventh week.
The main propose of this coursework is to solve the problem of a fitness gym centre which
is currently facing a lot of problems in maintaining its records. We are required to analyse
requirements for the development of the fitness application system.

This fitness application is used to maintain record of all its users. The application
requires us to be able to use it with various user types, namely Administrator, staff and
customer. The customer should be able to create a to-do list having the various tasks
they must complete. The staff should be able to assign tasks to the customer and be able
to view and manage their payment status. Administrator should be able to register
customers and staff and generate reports regarding information stored in the database
about them. The application’s login page should also have an option for the customer to
register themselves.

Page | 1
 CS5002 Software Engineering

2. Group tasks

2.1 Environmental model specification

2.1.1 Context Level Diagram (DFD)

Figure 1: Context level diagram - fitness application system

Admin

➢ Register Staff: It will register staff in the system.

➢ De-Register Staff: It will de-register the staff from system.
➢ Extend Contract Period: admin can extend the contract of part time staff whose
contract has ended within the past 10 days.
➢ Register Customer: It will register the customer in the system.
➢ De-Register Customer: It will de-register the customer in the system.
➢ Reactivate customer account: it will reactivate the customer who has remained
inactive for the month.

Page | 2
 CS5002 Software Engineering

➢ View Report: It will give the report about the customer, staff, task or payment.

Customer

➢ View Report: It will give the report about their detail, task or payment.
➢ Register customer: it will register customer into the system.
➢ De-Register customer: It will de-register the customer from the system.
➢ Create / modify list: It will create, update and delete to-do list.
➢ View List: it will show all the to-do list created by customer.
➢ Create / modify task: It will create task for the customer.
➢ View task: It will show all the task created by customer.
➢ Task complete: It will set the selected task’s status to complete.

Staff

➢ Make payment: It will register the payment made by the customer.

➢ Check payment: it will check the payment status of the customer.
➢ Create/ task modify: it will create, update and delete the task assigned to the
customer.
➢ View task: it will show the task created for the customer.

System
➢ Check payment: It will check the payment detail of the customer and send
notification to customer if they haven’t paid the fee.
➢ De-Register customer: It will de-register the customer if they have remained
inactive for a month.
➢ De-register staff: It will automatically de-register the staff whose contracts have
finished.

Page | 3
 CS5002 Software Engineering

2.2 Internal Model Specification for the system

2.2.1 Level 1 Data Flow Diagram

Figure 2: Level 2 DFD - Fitness application system

➢ Register Customer: This process will register a new customer into the customer
database. Customer and admin can access this process.
➢ Payment: This process will handle all the things related with making payment,
checking payment and sending payment notification. Staff and customer can
access this process
➢ View Report: This process will generate a report from a different data available in
the database. The admin can generate a report on payment, customer, task and
staff details whereas the customer can create their own reports on payment and
task. Customer and admin can access this process.
➢ Manage To-do List: This process will create list, update and delete it from database
called list. That list can be viewed by the customer. Task can be created, updated,
deleted and viewed by customer and staff from database called task. Once task is

Page | 4
 CS5002 Software Engineering

completed, status will be changed to complete. Customer and staff can access this
function.
➢ De-register customer: This process will handle all the de-registering existence
customer from the customer database. Admin and customer can access this
process.
➢ Register staff: This process will register the new staff into the database called staff.
Only admin can access this process.
➢ De-register staff: This process will handle all the de-registering the staff from the
system. Admin and system can only access this process.
➢ Extend Contract: This process will extend the contract period of the staff. Only
admin can access this process.
➢ Reactivate customer: This process will reactive the customer who were de-
registered before from the system. Only admin can access this process.

Page | 5
 CS5002 Software Engineering

2.2.3 Entity relationship diagram (ERD)

Figure 3: Entity relationship diagram (ERD) - Fitness application system

2.2.3.1 Entities
➢ Customer: The customer table contains all details about the customers who have
registered for our fitness application.
➢ Staff: A staff table contains all the details of a staff who works in our fitness centre.
➢ Task: A task table contains all the information of the task created by a staff and a
customer.
➢ To-do list: A to-do list table contains all the information about the list of task created
by a customer.

2.2.3.2 Relationship

➢ Customer – Task: A customer can create and manage multiple tasks.

➢ Staff – Task: A staff can create and manage multiple tasks.
➢ Task – To-do list: A to-do list can have many tasks.
➢ Customer – To-do list: A customer can create and manage many to-do lists.

Page | 6
 CS5002 Software Engineering

2.2.4 Data Dictionary

2.2.4.1 Customer table

Column Name Data Size Constraint Reference Remarks
Type Table
Customer_Id Int 10 Primary key To store customer unique id.
Full_Name Varchar 50 Not Null To store customer name.
DOB Date 20 Not Null To store customer’s Date of birth.
User_Name Varchar 50 Not Null To store customer’s username for
gym application.
Password Varchar 50 Not Null To store customer’s password for
gym application.
Location Varchar 50 Not Null To store customer’s place of living.
Date_of_registra Date 20 Not Null To store the date when customer
tion registered for gym.
Payment_Type Varchar 15 Not Null To store the method of payment
used by customer.
Status Varchar 15 Not Null To store the status of customer.
Table 1: Data Dictionary - Customer Table

2.2.4.2 Staff table

Column Name Data Type Size Constraint Reference Remarks
Table
Staff_Id Int 10 Primary To store staff unique id.
Key
Full_Name Varchar 50 Not Null To store staff’s full name.

Job_Title Varchar 50 Not Null To store staff’s position in the gym.

Job_Type Varchar 50 Not Null To store staff’s job to be performed

in the gym.
Salary Int 15 Not Null To store the salary that the staff
receives.
Hire_Date Date 20 Not Null To store date when the staff was
appointed in the gym.
Contract_End_ Date 20 Not Null To store date when the staff’s
Date contract with the gym finishes.
Table 2: Data Dictionary - Staff table

Page | 7
 CS5002 Software Engineering

2.2.4.3 Task table

Column Data Type Size Constraint Reference Remarks
Name Table
Task_Id Int 10 Primary key To store task unique id.

Customer_Id Int 10 Foreign key Customer To get the information stored

about customer in customer table.
Task_Name Varchar 50 Not Null To store name of the tasks to pe
performed by the customer.
Description Varchar 100 Not Null To store task description that are
given to the customer.
Assign_Date Date 20 Not Null To store the date in which a
particular task is assigned to a
customer.
Due_Date Date 20 Not Null To store the date within which a
customer is supposed to finish the
assigned task
Completion_st Varchar 5 Not Null Staff To store the data about the
atus completion of task given to the
costumer.
Table 3: Data Dictionary - Task table

2.2.4.4 To-do list

Column Name Data Type Size Constraint Reference Remarks
Table
List_Id Int 10 Primary Key To store list unique id.

Task_Id Int 10 Foreign Key Task To get the information stored

about task in task table.
Customer_Id Int 10 Foreign Key Customer To get the information stored
about customer in customer
table.
Table 4: Data Dictionary - To-do list

Page | 8
 CS5002 Software Engineering

2.2.5 Process Specification

2.2.5.1 Register customer

➢ MODULE NAME: Register customer

➢ PURPOSE: To register the customer in to the database.
➢ PSEUDOCODE:
START registerCustomer(customerDetails)
IF (existingCustomer(customerDetails))
DISPLAY "Customer already exists"
ELSE
CALL saveCustomer(customerDetails)
DISPLAY "Customer saved"
END IF
STOP

2.2.5.2 Payment
➢ MODULE NAME: Payment
➢ PURPOSE: To handle the payment details and send the notification.
➢ PSECUDOCODE
START payment(task, custID, [paymentInfo])
IF task = "Check Payment"
IF user called function
DISPLAY checkPayment(custID)
ELSE IF system called function
IF (checkPayment(custID) = "Not paid")
notify(custID)
END IF
END IF
ELSE IF task = "Make Payment"
CALL makePayment(custID, paymentInfo)
notify(custID)

Page | 9
 CS5002 Software Engineering

END IF
STOP

2.2.5.3 Generate Report

➢ MODULE NAME: Generate Report
➢ PURPOSE: To generate and display the report of customer and staff.
➢ PSEUDOCODE:
START generateReport(userID, reportType, [custID])
IF userID is an "Admin"
reportData = createReport(reportType, custID)
ELSE
reportData = createReport(reportType, userID)
END IF
DISPLAY createReport(reportData)
STOP

2.2.5.4 To-do list

➢ MODULE NAME: To-do list
➢ PURPOSE: To manage the task and to-do lists created by customer and staff.
➢ PSEUDOCODE:
START manageTodoList(mode)
IF mode = "List"
CALL manageList()
ELSE IF mode = "Task"
CALL manageTask()
END IF
STOP

START manageList()
fn = INPUT "Select function"
IF fn = "Create List"

Page | 10
 CS5002 Software Engineering

CALL createList()
ELSE IF fn = "Add task to list"
CALL listAddTask()
ELSE IF fn = "Remove task to list"
CALL listRemoveTask()
ELSE IF fn = "Delete List"
CALL deleteList()
END IF
STOP

START manageTask()
fn = INPUT "Select function"
IF fn = "Create Task"
CALL createTask()
ELSE IF fn = "Update Task"
CALL updateTask()
ELSE IF fn = "Remove task to list"
CALL listRemoveTask()
ELSE IF fn = "Delete List"
CALL deleteList()
END IF
STOP
2.2.5.5 De-register customer
➢ MODULE NAME: De-register customer
➢ PURPOSE: To de-register a customer.
➢ PSEUDOCODE:
START deregisterCustomer(custID)
IF called by system
IF checkInactive(custID) > 30
CALL deregister(custID)

Page | 11
 CS5002 Software Engineering

END IF
ELSE
IF customerExists(custID)
CALL deregister(custID)
END IF
END IF
STOP

Page | 12
 CS5002 Software Engineering

2.3 Design Specification

2.3.4 Structure chart

Figure 4: Structure chart – Login Page

Figure 5: Structure chart - Admin Dashboard

Page | 13
CS5002 Software Engineering

Figure 6: Structure chart - Customer Dashboard

Figure 7: Structure chart - Staff Dashboard

Page | 14
 CS5002 Software Engineering

In Figure 4 it can be seen that, this system starts at the login page after which the
user can login or a customer can register a new account. Register Customer Module is
explained in detail in its own section below. When a user logs in, their login details are
verified against the database. If verified, their user type is checked and their
corresponding dashboard opens.

Figure 5 shows the structural chart for the admin dashboard. The admin can
choose to either managed the customer data, manage the staff data or generate reports.
When managing customers, the admin can register a customer, de-register customer or
reactivate a customers account. When managing the staff, the admin can register, de-
register the staff or extend the staff contracts.

Figure 6 shows the structural chart for the customer dashboard. The customer can
either manage their to-do list, view reports or de-register their account. When managing
the to-do lists, the customer can view, create, update and delete tasks. These tasks can
be added to a to-do lists which can be created and deleted by the customer. They can
also mark tasks as completed.

Figure 7 shows the structural chart for the staff dashboard. The staff can either
manage tasks that can be given to the customers or manage payment of the customers.
When managing the tasks, the staff can view the existing task for a customer and create
and assign a new tasks to the customers. When managing a payments, the staff can
check whether the customer has paid or not and they can change the payment status of
a customer after the customer has made the payments.

Page | 15
 CS5002 Software Engineering

2.4 Assignment diary

At first glance, the given coursework seemed to be easy for us but as we dive deep
into the coursework lots of problems and error was faced prior the completion of this
coursework. The content of the coursework was massive and somewhat difficult than
what have we assumed. We started to work on this coursework from very beginning and
was estimating to complete it within 8th week but unfortunately two members of our group
got sick so we couldn’t complete the work within estimated time.

While working on the context level diagram, we found many functions that needed
to be added and many functions which were removed. When we started the project, we
assumed that we needed payment rate in our system but as we advance through multiple
iterations of the DFD, we realised that payment rate was not required and would only
make our system unnecessarily complex.

Page | 16
 CS5002 Software Engineering

2.4.1 Meeting Log

S.N. Date Start Time End Time Meeting Location Meeting Objective

1 7th Oct 1:00 PM to 2:00 PM College Learning General Discussion of coursework

2018 Zone
2 28th Oct 2:00 PM to 3:00 PM Nabin’s House Group work discussion and Work
2018 division among group members.

3 15th Nov 01:00 PM 3:00 PM College Learning Individual Context level diagram were
2018 to Zone created at the same time while
consulting each other.
4 24th Nov 02:00 PM 4:00 PM Tsedup’s house A combine Context diagram was made
2018 to using the individual context level
diagram
5 29th Nov 02:00 PM 03:00 PM Tsedup’s house Individual level 1 DFDs were created at
2018 to the same time while consulting each
other.
6 5th Dec 02:00 PM 04:00 PM Tsedup’s house A combine Level 1 DFD was made
2018 to using the individual DFDs
7 15th Dec 12:00 PM 06:00 PM Sajag’s House A combine Level 2 DFD was made.
2018 to
8 25th Dec 1:00 PM to 03:00 PM Sajag’s House Individual level 2 DFDs were separated
2018 from combine DFD
9 5th Jan 02:00 PM 04:00 PM College Learning Individual structure charts were created
2019 to Zone at the same time while consulting each
other.
10 16th Jan 01:00 PM 03:00 PM Tsedup’s House A combine structure chart was made
2019 to using the individual structure charts
11 19th Jan 08:00 AM 04:00 PM Tsedup’s House Individual parts were added and report
2019 to documentation finalization was done.
coursework were distributed individually.

Table 5: Meeting Log

Page | 17
 CS5002 Software Engineering

2.4.2 Individual task distribution

The work was divided among the members as follows:

Name Assigned Tasks

Sajag Acharya Generate report

Tsedup Dorjee Lama Payment

Nabraj Khadka To-do list

Biplab Dhungana De-register a customer

Shikhar Khadka Register a customer

Table 6: Individual task distribution

Page | 18
 CS5002 Software Engineering

3. Individual tasks

3.1 Environmental model specification

3.1.1 Context level diagram

3.1.1.1 Register Customer

Figure 8: Context level diagram - Register customer

This process will be used to register new customer into the system. Admin will register a
customer and customer can register themselves into the system.

Page | 19
 CS5002 Software Engineering

3.1.1.2 Payment

Figure 9: Context level – Payment

This process will handle all the payment and related notification in the system. Staff will
make a payment into system and can check the notification. Customer can get the
notification of the payment made and check their payment detail.

3.1.1.3 Generate Report

Figure 10: Context level diagram - Generate report

Page | 20
 CS5002 Software Engineering

When a user tries to generate the report of a customer and staff this process will generate
and display the report to the user. Only admin and customer can generate a report.

3.1.1.4 To-do List

Figure 11: Context level diagram - To-do list

This process will create to-do list and task for the customer which can later be updated,
deleted and viewed. Staff can create task for customer, modify it and view it. Customer
can create to-do list and task for themselves, modify it and view it.

Page | 21
 CS5002 Software Engineering

3.1.1.5 De-register customer

Figure 12: Context level diagram - De-register customer

This process will de-register a customer from the system. Admin will de-register a
customer from the system. Customer can de-register themselves from the system.

Page | 22
 CS5002 Software Engineering

3.2 Internal module specification

3.2.1 Level 1 Data flow Diagram

3.2.1.1 Register Customer

Figure 13: Level 1 DFD - Register customer

When a user tries to register a customer in to the system this system will register a
customer into the database. Only customer and admin can register a customer in to the
system.

Page | 23
 CS5002 Software Engineering

3.2.1.2 Payment

Figure 14: Level 1 DFD : payment

When a customer or a staff tries to check and make the payment this process will handle
all the things related to the payment and store them into the database. Also, the system
checks the payment of the customer whether he/she paid or not and send a notification
notifying the customer about the payment.

3.2.1.3 Generate report

Figure 15: Level 1 DFD - Generate report

Page | 24
 CS5002 Software Engineering

This process will generate a report. Admin can generate a report which contains detail
about the payment, customer, task and staff. Customer can generate a report which
contains the detail about the payment and task.

3.2.1.4 To-do list

Figure 16: Level 1 DFD - To-do list

When a user tries to This process will create list, update and delete it from database
called list. That list can be viewed by the customer. Task can be created, updated, deleted
and viewed by customer and staff from database called task. Once task is completed,
status will be changed to complete. Customer and staff can access this function.

Page | 25
 CS5002 Software Engineering

3.2.1.5 De-register customer

Figure 17: Level 1 DFD - De-register customer

This process will deregister a customer and a staff from database. Only customer and
Admin can access this process. System can also deregister a customer from database
checking his/her inactive days.

Page | 26
 CS5002 Software Engineering

3.2.2 Level 2 Data flow diagram

3.2.2.1 Register customer

Figure 18: Level 2 DFD - Register customer

When a user tries to register a customer the registration details are checked by process
1.1 to see if the customer already exists within the database. If they do not exist, then the
data is supplied to process 1.2 which stored the data in database as a new customer.

3.2.2.2 Payment

Figure 19: Level 2 DFD – Payment

Page | 27
 CS5002 Software Engineering

When a user check his/her payment details the payment details are checked by process
2.1 check payment details to see whether the customer has paid or not within the
database. if they do not, the customer has to pay which is done by process 2.2 do
payment, then the paid details are supplied to the database and a notification notifying
about the payment done is sent to the customer by the process 2.3 notify customer.

3.2.3.3 Generate report

Figure 20: Generate report

When user tries to generate a report, the process ‘3.1 get report info’ get the respective
report information from database. The customer can only generate the payment and to
do list report while an administrator can generate all kind of report. Then process ‘3.1
create report’ create and displays the respective report to the user.

Page | 28
 CS5002 Software Engineering

3.2.3.4 To-do list

Figure 21: Level 2 DFD - To-do list

When a user tries to manage a task the process ‘4.2 manage task’ let the customer
and staff to create, update and delete the task from database by getting the customer
and task information from database then the modified data is displayed by the process
‘4.2 view tasks’ to user. The process 4.3 create task, creates the to-do list for the
customer which then stores the task list details in database. If a customer wishes to
add task to a list, the process ‘4.4 task to list’ get task information from database and
then store the list information to the database. The process ‘4.5 remove task from list’
and ‘4.6 delete list’ let customer to remove task from list and delete the entire list
respectively from the database. Moreover, the process ‘4.7 complete task’, get the
completed task information and store the completed task details in the database.

Page | 29
 CS5002 Software Engineering

3.2.3.5 De-register customer

Figure 22: Level 2 DFD - De-register customer

When a customer and an administrator tries to deregister a customer, the customer

details are checked by process ‘5.1 check customer info’ from the database, then the
process ‘5.2 de-register customer’ deregister the customer from system. The system also
deregisters a customer by checking his/her inactive days by process ‘5.3 check inactive
days’ within database and then deregister a customer from system.

Page | 30
 CS5002 Software Engineering

3.3 Design Specification

3.3.1 Structure chart

3.3.1.1 Register customer

Figure 23: Structure Chart- Register customer

In the register customer module, when a user calls it, they must provide customers
details as a parameters. The customers details are checked against the database to
check whether the customer is already registered or not. If the customer is not already
registered, then their details are saved in the database as a new customer. When a new
customer is registered, they are not allowed to use the system until their payment has
been verified by a staff member.

Page | 31
 CS5002 Software Engineering

3.3.1.2 Payment

Figure 24: Structure chart – Payment

In the payment module, we can either check the payment info or make the
payment. When the system checks payment info and the customer hasn’t paid their dues,
the customer gets a notification. When a user check the payment info, the respective
payment information is displayed to that user. When making payments, the user provide
payment details and the customer id, after which payment information is updated in the
database and the customer is notified about the change.

Page | 32
 CS5002 Software Engineering

3.3.1.3 Generate report

Figure 25: Structure chart - Generate report

When creating a report, the report type and relevant information is provided after
which the required data is pulled from the database and the report is generated. The
generated report is then displayed to the user.

Page | 33
 CS5002 Software Engineering

3.3.1.4 To-do list

Figure 26: Structure chart - To-do list

In the to-do list module, customers can manage their list and tasks whereas staff
can only manage task for the customers. When managing the tasks users can create
update or delete the tasks. Customers can also complete the task. When managing lists,
customer can create and delete lists as well as add and remove tasks from the lists.

Page | 34
 CS5002 Software Engineering

3.3.1.5 De-register customer

Figure 27: Structure chart - De-register customer

When deregistering customer, the customer id needs to be provided. The customer id is

checked within against the database, to check whether the customer exists. If they exists,
then the de-register module de-registers the customer from the database. If the system
calls the de-register module, it checks the inactive days of the customers. If the customer
has been inactive for more than 30 days then the customer is de-registered from the
database.

Page | 35
 CS5002 Software Engineering

3.3.2 Module specification

3.3.2.1 Register customer

➢ MODULE NAME: Register customer

➢ PURPOSE: To register the customer in to the database.
➢ PSEUDOCODE:
START registerCustomer(customerDetails)
IF (existingCustomer(customerDetails))
DISPLAY "Customer already exists"
ELSE
CALL saveCustomer(customerDetails)
DISPLAY "Customer saved"
END IF
STOP

3.3.2.2 Payment
➢ MODULE NAME: Payment
➢ PURPOSE: To handle the payment details and send the notification.
➢ PSECUDOCODE
START payment(task, custID, [paymentInfo])
IF task = "Check Payment"
IF user called function
DISPLAY checkPayment(custID)
ELSE IF system called function
IF (checkPayment(custID) = "Not paid")
notify(custID)
END IF
END IF
ELSE IF task = "Make Payment"
CALL makePayment(custID, paymentInfo)
notify(custID)

Page | 36
 CS5002 Software Engineering

3.3.2.3 Generate Report

➢ MODULE NAME: Generate Report
➢ PURPOSE: To generate and display the report of customer and staff.
➢ PSEUDOCODE:
START generateReport(userID, reportType, [custID])
IF userID is an "Admin"
reportData = createReport(reportType, custID)
ELSE
reportData = createReport(reportType, userID)
END IF
DISPLAY createReport(reportData)
STOP

3.3.2.4 To-do list

➢ MODULE NAME: To-do list
➢ PURPOSE: To manage the task and to-do lists created by customer and staff.
➢ PSEUDOCODE:
START manageTodoList(mode)
IF mode = "List"
CALL manageList()
ELSE IF mode = "Task"
CALL manageTask()
END IF
STOP

START manageList()
fn = INPUT "Select function"
IF fn = "Create List"
CALL createList()
ELSE IF fn = "Add task to list"
CALL listAddTask()

Page | 37
 CS5002 Software Engineering

ELSE IF fn = "Remove task to list"

CALL listRemoveTask()
ELSE IF fn = "Delete List"
CALL deleteList()
END IF
STOP

START manageTask()
fn = INPUT "Select function"
IF fn = "Create Task"
CALL createTask()
ELSE IF fn = "Update Task"
CALL updateTask()
ELSE IF fn = "Remove task to list"
CALL listRemoveTask()
ELSE IF fn = "Delete List"
CALL deleteList()
END IF
STOP
3.3.2.5 De-register customer
➢ MODULE NAME: De-register customer
➢ PURPOSE: To de-register a customer.
➢ PSEUDOCODE:
START deregisterCustomer(custID)
IF called by system
IF checkInactive(custID) > 30
CALL deregister(custID)
END IF
ELSE
IF customerExists(custID)

Page | 38
 CS5002 Software Engineering

CALL deregister(custID)
END IF
END IF
STOP

Page | 39
 CS5002 Software Engineering

4. Conclusion
After plenty of research and analysis of the requirements that are required to
develop this system, we decided to explain and design the substantial parts of this system
using structured approach that is Yourdon. This application will make a fitness centre to
run more efficiently in a way that, administrator, staff and user can add diverse data about
the users into the system, and edit, delete user data later when needed. We know that it
is impossible for lone to develop this system, engagement of other group member was
the best option to make most out of this project. So, for the development of this system,
we have spent a lot of time on requirement analysis by having many group meetings. The
tasks assigned in the coursework were not easy at all. We have worked hard for the
successful completion of this coursework, each task was carried out in steps, in every
steps deploying the full effort by every member of the group.

Page | 40