Informatics College Pokhara

Software Engineering
CS5002NP
Coursework 1

Submitted By: Submitted To:

Student Name: Aakash Pahari Mr. Sandeep Gurung
Amar Gurung
Anish Shrestha
Sushant Tamang
London Met ID: 18030711 Module Leader
18030716
18030720
19031970
Group: L2C4 Software Engineering
Date: 8-Jan-2020
Table of Contents
Introduction ....................................................................................................................... 1
1. Environmental model Specification ...................................................................... 2
1.1. Context Diagram ................................................................................................... 2
The Event List ................................................................................................................... 3
2. Internal model Specification ................................................................................... 4
2.1. ER Diagram ............................................................................................................ 4
2.2. Level 1 Data Flow Diagram (DFD) ...................................................................... 6
2.3. Level 2 Data Flow Diagram (DFD) ...................................................................... 8
2.4. Data Dictionary ...................................................................................................... 9
2.5. BNF Notations ..................................................................................................... 12
2.6. Process Specification ........................................................................................ 13
3. Design Specification .............................................................................................. 15
3.1. Structure Chart .................................................................................................... 15
4. Assignment Diary ................................................................................................... 17
5. Detailed Specification ............................................................................................ 24
Individual Report 1 ......................................................................................................... 24
5.1. Internal Module Specification ........................................................................... 25
5.1.1. Context level Data Flow Diagram ................................................................. 25
5.1.2. Level 1 Data Flow Diagram (DFD) ................................................................ 26
5.1.3. Level 2 Data Flow Diagram (DFD) ................................................................ 26
5.2. Design Specification .......................................................................................... 27
5.2.1. Structure Chart: ............................................................................................... 27
5.2.2. Module Specification ...................................................................................... 28
Pseudocode: ................................................................................................................... 28
Conclusion....................................................................................................................... 29
Individual report 2 .......................................................................................................... 30
Module introduction ....................................................................................................... 30
Environmental Specification ........................................................................................ 30
1. Context level Diagram (Level 0) ........................................................................... 30
2. Level 1 DFD fragment ............................................................................................ 31
3. Level 2 DFDs for the particular function ............................................................ 32
4. Design Specification .............................................................................................. 33
1. Structure chart ........................................................................................................ 33
Module Specification ..................................................................................................... 34
Pseudocode: ................................................................................................................... 34
Conclusion....................................................................................................................... 35
Individual report 3 .......................................................................................................... 36
Environmental Model Specification ............................................................................ 36
1. Context Level diagram........................................................................................... 36
Internal Model Specification......................................................................................... 37
a) DFD Fragments ....................................................................................................... 37
b) Level 2 ....................................................................................................................... 38
Design specification ...................................................................................................... 39
a) Structure chart ........................................................................................................ 39
Module Specification (Mspecs) ................................................................................... 39
Pseudocode..................................................................................................................... 39
Conclusion....................................................................................................................... 40
Individual report 4 .......................................................................................................... 41
Environmental Model Specification ............................................................................ 41
1) Context Diagram ..................................................................................................... 41
2) Internal Model Specification ................................................................................. 42
a) DFD Fragment ......................................................................................................... 42
b) Level 2 ....................................................................................................................... 43
3) Design Specification .............................................................................................. 44
a) Structured chart ...................................................................................................... 44
Module Specification ..................................................................................................... 44
Pseudocode..................................................................................................................... 44
Conclusion....................................................................................................................... 45
Summary of our Report................................................................................................. 46
Group Conclusion .......................................................................................................... 48
Table of Figures
Figure 1: Context level Diagram....................................................................... 2
Figure 2: Entity Relational Diagram ................................................................. 4
Figure 3: Level 1 DFD ...................................................................................... 6
Figure 4: Level 2 DFD of Perfect GYM Club .................................................... 8
Figure 5: Structure chart of the GYM System ................................................ 15
Figure 6: DFD 0 of Create Customer "To Do List" ......................................... 25
Figure 7: Level 1 DFD of create customer "To Do List" ................................. 26
Figure 8: Level 2 DFD of create customer "To Do List" ................................. 26
Figure 9: Structure Chart of Create Customer "To Do List"............................ 27
Figure 10: Figure DFD 0 of Register a Customer ........................................... 30
Figure 11: Figure DFD 1 Fragment of Register a Customer .......................... 31
Figure 12: Figure DFD 2 Fragment of Register a Customer .......................... 32
Figure 13: Structure Chart of Register a customer......................................... 33
Figure 14: Context diagram of Payment of customer ..................................... 36
Figure 15: DFD fragment for Payment of customer ....................................... 37
Figure 16: Level 2 for Payment of customer fragment ................................... 38
Figure 17: Structured chart of payment of customer module ......................... 39
Figure 18: Context Diagram of Deregister customer ...................................... 41
Figure 19: DFD Fragment of deregister customer.......................................... 42
Figure 20: Level 2 DFD of deregister customer ............................................. 43
Table of Tables
Table 1: Data Dictionary of Customer Table .................................................... 9
Table 2: Data Dictionary of Staff Table .......................................................... 10
Table 3: Data Dictionary of Task Table .......................................................... 10
Table 4: Data Dictionary of Payment Table ................................................... 11
Table 5: Data Dictionary of To do list Table ................................................... 11
Table 6: Pspecs of Register customer ........................................................... 13
Table 7: Pspecs of Register staff ................................................................... 13
Table 8: Pspecs of Payment of customer ...................................................... 13
Table 9: Table 9: Pspecs of Create todolist ................................................... 14
Table 10: Pspecs of set tasks ........................................................................ 14
Table 11: Pspecs of De-register customer ..................................................... 14
Table 12: Pspecs of de-register staff ............................................................. 14
Table 13: Pspecs of Generate report ............................................................. 14
CS5002NP Software Engineering

Introduction
This coursework is about a GYM club named as perfect GYM club which
is facing problems in maintaining records of the customer varying on their
payment details. So, in order to minimize the given problem a computerized
system is needed to be developed. The main agenda of the system is to
maintain the record of all the customers based on their identification of the
information given by the customer.

In this system, the customer who are willing to join GYM should register
themselves in the GYM. The registration will be only done after they some initial
amount is paid to the GYM. Records of the customer are done based on their
general information such as Name of the customer, Date Of Birth, Username,
Password, Location, Date_of_registration, Payment amount and Payment type.
Every single member willing to use Perfect GYM club application must be
registered in a GYM. Customers are given full privilege of the GYM after their
complete registration.

In case, customer is not active for a month than the customer will be
automatically de-registered which is automatically done by the system itself.
The Perfect GYM Club application admin is permitted to create client reporting.
Moreover, in this GYM club workers keeps the client’s payment information.
There may also be different activities to be delegated to clients which clients
have to do while staying at home.

Employees are also accountable for conducting activities to be

completed at home. In this Perfect GYM Club system, clients can establish their
own "To Do List" to set a checklist of the task to be completed as needed.
Clients can build their own To Do List, modify their list, check the list, and if it is
not necessary, erase the list.

1
Anish Shrestha
CS5002NP Software Engineering

1. Environmental model Specification

1.1. Context Diagram

The statement of purpose:

The purpose of the Perfect GYM Club system is to give customers the better
services by providing the proper facilities with the individual report of their
progress in the GYM. It also helps in the data storing of the customer coming
to the GYM and manage the registration in proper order. The details of the
report are provided by the admin or staff to the customer and is managed by
the staff itself.

Figure 1: Context level Diagram

Above is the DFD level 0 or context diagram of the Perfect GYM Club
system. Here, the customer and staffs can create the set of task to be done by
the customers in the GYM. Admin has the privilege of whole system and has
responsibility to look after the customers. Customers are registered to the
system only after some initial payment is done.

2
Anish Shrestha
CS5002NP Software Engineering

The Event List

 Customers register themselves (Flow Oriented)
 Admin generate monthly reports (Temporal event)
 Admin update customer details. (Flow oriented)
 Staff assign tasks to customers. (Flow oriented)
 Customers view their own daily reports. (Flow oriented)
 Customers create “To Do List”. (Flow oriented)
 Customers de-register themselves. (Control event)
 Staff register themselves. (Control event)
 Staff maintains monthly payment details of customer. (Temporal event)
 Staff de-register themselves. (Control event)

3
Anish Shrestha
CS5002NP Software Engineering

2. Internal model Specification

2.1. ER Diagram
An entity relationship diagram (ERD), also known as an entity
relationship model is an graphical illustration of an information system that
shows the relationships among objects, places, concepts, people pr any events
within the system. An entity relationship diagram is a data modelling way that
can profit business processes and be used as the pillar for a relational
database.

Figure 2: Entity Relational Diagram

The above entity relationship diagram illustrates the relationship of the

whole GYM Club System. The system holds Company Staff, Customer and
Admin who have their own classes and function. The function of the Company
4
Anish Shrestha
CS5002NP Software Engineering

Staff is to maintain the payment details of the Customer. Staff are responsible
for assigning task that are to be carried out in home by the Customers.
Moreover, Admin of the Perfect GYM Club application is allowed to create
report of the Customers. Similarly, Customers can create their own “To Do List”
in the Perfect GYM Club application in order to set a reminder about the task
that are to be carried out according to their requirement. Customers have full
privilege to create their own To Do List, Update their list, Read the list and
Delete the list if required.

5
Anish Shrestha
CS5002NP Software Engineering

2.2. Level 1 Data Flow Diagram (DFD)

Figure 3: Level 1 DFD

The above figure illustrates the DFD level 1 of the Perfect GYM Club
system. It shows the overview of the system design with illustration of the major
processes, data stores and data processes. It holds all together of eight
processes that are represented by the circles in regard to the flow of data which
is represented by the data and the tables of the database is represented by the
partial rectangles.

In the above figure, the customer gives the first input to the system by
customer or admin itself by registering the customer providing the essential to

6
Anish Shrestha
CS5002NP Software Engineering

do list information. Admin, staff and the customers are the external entity of the
system. These are the essential parts of the project and without these aspects,
the GYM System cannot carry out its function and responsibilities. The task of
every data flows and stores are described below:

 Customers willing to join a GYM should register themselves in the GYM

giving their details.
 Customers are registered in the GYM only after they have paid certain
amount (Initial Payment) to the GYM.
 Customers can obtain the details and update their records if necessary
and can view their own reports.
 Customers can deregister themselves in case if they are planning to quit
the GYM.
 If in case customer are inactive for one month than the customer is
automatically deregistered. Admin will have full privilege to de register
the customer.
 All set of tasks that can be carried out in the GYM is defined by the GYM
Company.
 Customer are able to create their own To Do List which holds set of
tasks that they can carry out. Customers also have privilege to set a
reminder which allows them to do certain exercise in the fixed period of
time. Customers are allowed to create their own exercise, update the
task which they want to carry out and delete the exercise routine if
required.
 Staff also have privilege to create the “To Do List” for the customer.
 Payment detail of the customer should be checked and in case the time
to pay fee, the customers are to be informed about the deadline for
paying the fee and provided information of any change in fees if found.
 Staff are added to provide necessary information to the users.
 Buffer time of 10 days is given after the termination of contract in order
to extend the contract or else staff is automatically de registered.
 If in case the staff quits before the termination of contract than staff is to
be de registered and is restricted to use the system.

7
Anish Shrestha
CS5002NP Software Engineering

2.3. Level 2 Data Flow Diagram (DFD)

Figure 4: Level 2 DFD of Perfect GYM Club

The above DFD level 2 figure shows us the working mechanism of the
GYM Club System. In the above phenomenon, the customer is required to visit
the GYM Club. The customer willing to join the GYM should register themselves
in the GYM. Once the customer pays certain initial amount, customers can be
registered to the GYM.

8
Anish Shrestha
CS5002NP Software Engineering

2.4. Data Dictionary

A data dictionary is single or multiple tables that shows the fields of each
table in a data model. A data dictionary contains metadata i.e. data about the
database. It contains the information about the database, who is allowed to
access it, where is the database stored and so on. Its field holds the attributes
and properties of each column. A data dictionary can be used to create
database for the data model using any given Relational Database Management
System.

The following tables shows the attributes and information about the
entities like Customer, Staff, Task, to do list and Payment.

Customer Table:

Attributes Data type Keys Description

C_ID Integer PK Identifies the customer name.

Name Varchar(50) Stores name of the customer.

Age Integer Stores the age of the customer.

Phone Varchar(15) Store phone number of the customer.

Weight Float Store weight of the customer.

Height Float Store height of the customer.

Sex Varchar(8) Gender of the customer.

Status Varchar(10) Register or deregister.

Register_by Integer The staff who registered the

customer.

Table 1: Data Dictionary of Customer Table

9
Anish Shrestha
CS5002NP Software Engineering

Staff Table:

Attributes Data types Keys Description ++

S_ID Integer PK Identified the staff

Name Varchar(50) Staff name

Status Varchar(50) Register or Deregister

Is_admin Varchar(10) If admin yes not else no.

Date_of_reg Date Date of register of the staff.

Register_by Varchar(50) The admin person who selected the staff.

Table 2: Data Dictionary of Staff Table

Task Table:

Attributes Data types Keys Description

T_ID Integer PK It identifies the tasks.

Name Varchar(55) Stores name of the task.

Created_By Integer FK Staff who created the task.

Table 3: Data Dictionary of Task Table

10
Anish Shrestha
CS5002NP Software Engineering

Payment Table:

Attributes Data types Key Description

Payment_ID Integer PK It identified the payments.

C_ID Integer FK Stores customer id.

Amount_Paid Integer Amount he/she paid.

Due_Amount Integer Amount remaining to pay.

Date_of_Payment Date Date when the payment is done.

Payment_Taken_By Integer FK

Table 4: Data Dictionary of Payment Table

To do list table:
Attributes Data types Key Description

T_ID Integer PK Uniquely identifies the row.

Task_ID Integer FK Task of the task table.
C_ID Integer FK The customer who’s to do list
is created.
Created_By Integer FK Staff who created to do list.
Table 5: Data Dictionary of To do list Table

11
Anish Shrestha
CS5002NP Software Engineering

2.5. BNF Notations

For registration

Registration_info = Cust name + cust age + cust sex + cust height + cust
weight + cust phone no. + Payment_info *data flow*

Customer_info = cust name + cust age + cust sex + cust height + cust weight
+ cust phone no.

Customers = {Customer} *data store*

Customer = Customer no. + name + age + sex + height + weight + phone

no. + status + registered_by *entity*

For payment

Payment_info = customer number + amount paid *data flow*

Payments = {Payment} *data store*

Payment = payment id + customer no. + amount paid + due amount + date

of payment + taken by *entity*

For staff registration

Staff_info = staff name + registered by + date of registration *data flow*

Staffs = {Staff} *data store*

Staff = Staff id + name + status + is admin + registered by + date of

registration + *entity*

For creating to do list

Todolist_info = customer number + task id + date + created by *data flow*

Todolists = {Todolist} *data store*

Todolist = todolist id + task id + customer no. + created by *entity*

For defining daily tasks

12
Anish Shrestha
CS5002NP Software Engineering

Task_info = task name + staff id *data flow*

Tasks = {Task} *data store*

Task = task id + name + staff id *entity*

2.6. Process Specification

Name: Register Customer

Process Number: 1
Input: Customer name, age, sex, height, weight, date of
registration, registered by
Output: Customer number
Process Details: Customer or admin add customer information
Table 6: Pspecs of Register customer

Name: Register staff

Process Number: 2
Input: Staff name, registered by, date of registration
Output: Staff number
Process Details: Admin add information of staff
Table 7: Pspecs of Register staff

Name: Payment of customer

Process Number: 3
Input: Customer no., amount paid
Output: Invoice, payment due
Process Details: Customer makes payment and receives
invoice
Table 8: Pspecs of Payment of customer

Name: Create to do list

Process Number: 4
Input: Customer number, task id, created by
Output: To do list info

13
Anish Shrestha
CS5002NP Software Engineering

Process Details: To do list is created by either staff or admin and

it is updated and deleted by customer
Table 9: Table 9: Pspecs of Create todolist

Name: Set tasks

Process Number: 5
Input: Task name, staff id
Output: Task information
Process Details: Creates daily tasks
Table 10: Pspecs of set tasks

Name: De-register customer

Process Number: 6
Input: Customer number
Output: Status message
Process Details: Customer status is changed to de-register.
Table 11: Pspecs of De-register customer

Name: De-register staff

Process Number: 7
Input: Staff number
Output: Status message
Process Details: staff status is changed to de-register.
Table 12: Pspecs of de-register staff

Name: Generate report

Process Number: 8
Input: Customer number
Output: report
Process Details: Customer reports are generated.
Table 13: Pspecs of Generate report

14
Anish Shrestha
CS5002NP Software Engineering

3. Design Specification

3.1. Structure Chart

Figure 5: Structure chart of the GYM System

Structure chart represent hierarchical structure of the module. It splits

the whole system into lowest functional modules, describe functions and sub
functions of each and every module of a system to greater detail. It divides the
system into black boxes which means the functionality of the system is known
to the users but the inner most details of the system are unknown. Input are
given to the system and output is generated. Things are read from top to bottom
and left to right.

15
Anish Shrestha
CS5002NP Software Engineering

The above figure illustrates the structure chart of the entire Perfect GYM
Club system. The system required the details of the customer such as Full
Name of the customer, DOB, Username, Password, Location,
Date_of_registration, Payment_amount, and Payment_type including their “To
Do List”. To obtain the details of the customer and update records in case of
need, customer are allowed to view their report. Customer also have privilege
to de register themselves if they are planning to leave the GYM. The system
will automatically de register the customer if customer are found to be in active
for about a month and admin is given full privilege to de register the customer.
Payment is to be done before registration of any customer. Some initial amount
is to be paid to the GYM in order to be registered in the GYM. Registration is
done through staffs. New registration is done after admin checks and verified
the registration details of new customers.

There are set of pre-defined tasks that can be carried out in the GYM
club. Moreover, customer can create their own To Do List which may consists
the set of tasks which they can carry out in GYM premises. Furthermore, they
can also set a reminder which will allow them do certain exercise in the given
period of time. Customer can create their own exercise, update and delete the
exercise routine in case they no longer want to carry out the particular exercise.
Similarly, Staff can also create the “To Do List” for the customer. Customers
are checked and in case it’s time to pay fee than they are informed about the
deadline for paying the fee.

In case of any change in fees structure, customers are informed about

the change in fees structure. Staff are also registered to provide the essential
information to the users. In case of de registration of the staff, firstly 10 days of
buffer time is given to extend their contracts. If found the contact is not extended
staff are de registered and are free to leave the GYM club. Staffs are de
registered and are not allowed to use the system if they are found to leave the
GYM before their contract termination.

16
Anish Shrestha
CS5002NP Software Engineering

4. Assignment Diary
The foremost objective of this coursework is to demonstrate practical
knowledge of “Structured Software Engineering” (Yourdon) by working within a
group of members in fixed period of time. The given task was huge for a single
member to complete in a narrow time period. So, I along with all other three
members of my group decided to divide our task and handle their respective
parts to the respective group members. Every member in the group was
assigned with their parts with full responsibility of the given task. Our group
consists of four members including me. Aakash Pahari, Amar Gurung, Anish
Shrestha, Sushant Tamang are the respective name of group members in our
team. The work was divided into the following way:

Group Member Name Task Responsibility

Aakash Pahari He was assigned to make the report

including Assignment Diary with
individual task.

Amar Gurung He was assigned to handle the task

involving Assignment Diary and his
individual task.

Anish Shrestha This member was assigned to take the

responsibility of handling Design
specification task with individual task.

17
Anish Shrestha
CS5002NP Software Engineering

He was assigned to handle the task

involving Requirement and analysis
Sushant Tamang
with individual task.

After we assigned all of our member with their part of work, we started
our coursework. We were able to complete our task because our team was
jelled and work was managed very clearly and systematically. All of the
members of our group were very active during the time period of the
coursework. Moreover, with the equal support of all of the members and their
important focus on their individual parts handed to them, our coursework was
completed in given period of time. We should know that without the proper
management and discussion on the given topic, we cannot complete our work
in time. That’s why we gave main focus on discussion about the topic and
visualizing all member ideas in order to gain idea and give suggestions to each
other in any case of misunderstanding during their work. If the group is not
found to be jelled and there is conflict among the group members regarding to
the certain topic, the project can never be completed. In order to create a strong,
clear coursework with proper elements we carried out several meetings that
became the main pillar of our success through which we dealt with the proper
time planning issues. Our meeting date and destination are given below:

18
Anish Shrestha
CS5002NP Software Engineering

Group Meeting Date Activity Description

Meeting No 1 20-12-2019 Today was the first day

when we all group member
met with each other for
discussion of our
coursework. On this day
our group was created
which consisted of four
members. We shared
about our ideas and views
about the given
coursework. After short
discussion we came to the
conclusion that it will be
easy for all of us to
complete our work in time if
the given coursework is
divided into parts for each
members of the group.

19
Anish Shrestha
CS5002NP Software Engineering

Group Meeting Date Activity Description

Meeting No 2 26-12-2019 This was the second day

when we all group member
met with each other for
discussion of our
coursework and our venue
was college library. At this
day all of the members
came with their researched
data. After the collection of
data we all started to look
for the errors and mistakes
and hopefully for the
solution if possible. But we
found more mistakes than
we actually thought we
would. Some members
were confused about the
data being collected and
hence, we decided to
terminate our meeting and
asked those members to
research about their task
again.

20
Anish Shrestha
CS5002NP Software Engineering

Group Meeting Date Activity Description

Meeting No 3 1-1-2019 On this day, we again held

meeting after our class
ended. Our meeting again
took place in college
library. At the very day we
again looked for the errors
and still found some minor
errors at our work. After
asking help from our
module teacher and
through the help of internet
surfing we solved all those
issues. After completing
this phase of the
coursework, all that
remained was our
individual task and some
reporting work. We couldn’t
complete our work without
completing our individual
task. That’s why we all took
each individual task for
ourselves. On the next
meeting we were required
to show our completed
individual task with each
other.

21
Anish Shrestha
CS5002NP Software Engineering

Group Meeting Date Activity Description

Meeting No 4 4-1-2020 This was our second last

meeting. This phase was
the important meeting for
all of us. We were together
after our morning class
ended and decided to stay
at our class for the
discussion of our
coursework. We looked
through our individual task
and searched for errors and
potential solution if
possible. When we thought
that we can start our
documentation now we
came to conclusion about
to start our documentation
and our meeting was
terminated to the next date.

22
Anish Shrestha
CS5002NP Software Engineering

Group Meeting Date Activity Description

Meeting No 5 8-1-2020 Today was the final day of

our meeting. It was the day
before the coursework due
date. Hopefully, our task
was all completed and was
ready to submit after a final
check. Some of our
members were unable to
attend this meeting.
Meeting was held on
college canteen and we all
took our task and combined
it to a word file. After proper
documentation of the
coursework we all had a
copy of the coursework
which we all decided to
submit before the due date.

23
Anish Shrestha
CS5002NP Software Engineering

5. Detailed Specification

Individual Report 1
Name: Aakash Pahari

London Met Id: 18030711

Module Name: Create Customer “To Do List”

Module leader: Sandeep Gurung

Module Introduction

This is the Create Customer “To Do List” of the Perfect GYM club.
According to the GYM system, Customer can create, update and delete to do
list. As per requirement, staff and admin manages the system like update
details of the customer and create to do list. Admin have the privilege to manage
staffs and also to register or de register the staff if required.

Here, the staff and customer can create the “To do list” for the customer
in the GYM. Firstly, information about the tasks required to be done is figured
out and is given to the GYM club. Staff views the list of tasks and the task are
registered in the system. Customers are allowed to view information about their
task and they have privilege to update and delete their list of task when
required.

24
Anish Shrestha
CS5002NP Software Engineering

5.1. Internal Module Specification

Internal Module Specification for Create Customer “To Do List”.

5.1.1. Context level Data Flow Diagram

Figure 6: DFD 0 of Create Customer "To Do List"

This is the context level or DFD level 0 for create “To Do List” module.
As shown in the above diagram, there is only one process with the name of the
system. Add to do list is the only one major process in the figure. As shown,
customer have privilege to create list of task to be done in the GYM club. Added
to do list is stored tin the system. Customer have privilege to add to do list
information, update and delete the information if required.

25
Anish Shrestha
CS5002NP Software Engineering

5.1.2. Level 1 Data Flow Diagram (DFD)

Figure 7: Level 1 DFD of create customer "To Do List"

This is the level 1 DFD for the create customer “To Do List” module,
which gives the major process i.e. Perfect Gym Club. For Gym club, customer
need to create a list of task that they are required to do in Gym premises. Then
the data is added to the system through the help of staff. Here, customer have
full privilege to see their information in the database.

5.1.3. Level 2 Data Flow Diagram (DFD)

Figure 8: Level 2 DFD of create customer "To Do List"

This is the DFD level 2 for create customer “To Do List” module. In the
figure shown above, customer are able to create to do list for themselves. To
update the initial information given by the customer, they have to provide their
26
Anish Shrestha
CS5002NP Software Engineering

updated information to the system which is than stored in the system through
the help of the Company Staff. The updated records are then stored in the table
named ToDoList. The information can be viewed by the customers through the
system. In order to delete the information of the customer, they have to provide
the delete information to the system. The information is then stored in the
system and the data can be viewed by the customer through the system.
Company Staff also provides the list of task information to the system and have
privilege to create the task list to be done by the customer itself.

5.2. Design Specification

5.2.1. Structure Chart:

A design specification is the overall document showing information about
a designed product or process. For example, the design DFD model. The given
figure below is the structure chart for create customer to do list module.

Figure 9: Structure Chart of Create Customer "To Do List"

The figure above shows is the structure chart for “To Do List” module. It
shows the assignment of the data for the task to be done by the customer during
the GYM premises. As seen, customer and staff can create the list of task that

27
Anish Shrestha
CS5002NP Software Engineering

a customer can do during the GYM time. Similarly, customer has full privilege
to update, delete and view the task list.

5.2.2. Module Specification

Purpose: The main purpose of this module is to create customer “To Do List”
which means to create set of tasks that customer are required to do during the
GYM. This module is used by both Company Staff and Customers.

Pseudocode:

START

IF customer wants to create to do list

GET to do list info

ADD to do list to ToDoList store

EXIT

IF customer wants to update to do list

GET update info

UPDATE to do list from the store

EXIT

IF customer wants to delete to do list

GET delete info

DELETE to do list from the store

EXIT

IF customer wants to view to do list

GET to do list from the store

RETURN it to the customer

EXIT

END

28
Anish Shrestha
CS5002NP Software Engineering

Conclusion
I was given the duty to create this requirement analysis specification for
the module create customer “To Do List”. The task was though for me and I
was not able to collect then essential information for doing my selected
assignment. However, from the assistance of the lecture slides and
investigating and examining the potential data I was able to create this module.
I confronted a great deal of issues and challenges for which I had to do extra
investigation and put some extra effort to complete the task.

Eventually, the module was effectively created and through this module
I was able to boost my ideas about designing of the charts and creation of
report. Initially, I adapted more about the Data Flow Diagram (DFDs) and got
thoughts regarding making DFDs i.e. level 0 or context diagram, level 1 DFD
and level 2 DFD for module. I became familiar about the necessities and
procedure for improvement of a framework and how to draw a structure outline.

Finally, on the way to solve this module and the coursework I gained
knowledge to maintain myself in bunch of exercises and acquired knowledge
to work as a team.

29
Anish Shrestha
CS5002NP Software Engineering

Individual report 2

Name: Sushant Tamang

London Met Id: 19031970

Module Name: Register a customer

Module Leader: Sandeep Gurung

Module introduction
This is the perfect GYM club’s “Register a customer” as the title indicates the
process of registering the customer. According to this module’s requirement,
customers willing to join a GYM will register in the GYM at first. Customers are
only enrolled in GYM after paying a certain fee to the GYM.

Environmental Specification

1. Context level Diagram (Level 0)

Figure 10: Figure DFD 0 of Register a Customer

In the above figure as we can see that it contains only one process and process
name is with system name which is “perfect Gym Club”. At context level, only
major data flows are shown. It is also known as the highest level of DFD. Also
there are two entity admin and customer.

30
Anish Shrestha
CS5002NP Software Engineering

2. Level 1 DFD fragment

Figure 11: Figure DFD 1 Fragment of Register a Customer

In the above figure it shows the Level 1 DFD fragment of “Register a customer”.
Here, as we can see that process name register a customer stores the
information about customer and payment and at first the system get information
about the registration and customer after that the process is done.

31
Anish Shrestha
CS5002NP Software Engineering

3. Level 2 DFDs for the particular function

Figure 12: Figure DFD 2 Fragment of Register a Customer

In the above figure it indicates or it explains the Level 2 DFDs for the particular
function. In this DFD level 2 it has three process, seven data flow and two
terminator. The process is done in Yourdon’s approach. Here, at first the
customer fill the registration form which the admin check’s it and after that
amount is verified and the clearance table is created. So at last customer
account is created and table is created with customer account name and the
customer id is pass to the customer.

32
Anish Shrestha
CS5002NP Software Engineering

4. Design Specification

1. Structure chart

Figure 13: Structure Chart of Register a customer

In the above figure as we can see that, it is the structure chart for “register
a customer” module. The above figure shows the process of the customer
enrollment or registration of the perfect GYM club where the customer
details and payment details are required to join the perfect GYM club for
every customers who are willing to work out in the GYM.

33
Anish Shrestha
CS5002NP Software Engineering

Module Specification
Module name: register a customer
Purpose: The main goal of the module is registering a customer in the GYM
after paying the initial amount by the customer.

Pseudocode:
START

GET customer info

ENROLL customer info

CHECK if customer info is valid for registration

STORE customer info into Customers store

RETURN customer id to the customer

END

34
Anish Shrestha
CS5002NP Software Engineering

Conclusion
In this coursework of software engineering I was asked to generate a number
of analysis and design specifications of a particular part of the system which is
the part of individual task. Each group member should do individual task, in my
part I have selected the “registering a customer” from many of the given
function.

From the help of the internet and constant evaluation and analysis, I captured
all other ideas needed to generate in the midst of this module. I had to deal with
a lot of problems and difficulties that I had to do with more inquiries and actions.
Ultimately, the module was developed efficiently and I improved various ideas
about constructing software. In this individual task Data-flow diagram (DFD) is
used to solve the lots of problem that the perfect GYM club is facing to maintain
records of the client’s with their clearance details. Here I have done with
Yourdon’s approach which is different from the ‘classical’ top-down approach
used for example in SSADM and other methods. Here I have learn the context
level diagram or level 0 which is the highest level of DFD and it contain single
process also process must name with system name. Furthermore, I have
learned the level 1 DFD fragment, Level 2 DFDs for the particular function and
structure chart. So, overall I get the knowledge how software can be used to
solve the real life problem in different sectors.

35
Anish Shrestha
CS5002NP Software Engineering

Individual report 3

London Met Id: 18030716

Module Name: Payment of customer

Module Leader: Sandeep Gurung

Module introduction

The module is about recording payment done by customer and re-registering

customer who are de-registered or inactive for a month.

Environmental Model Specification

1. Context Level diagram

Figure 14: Context diagram of Payment of customer

This is the context level or 0 level DFD for payment of customer module. As
shown in the diagram above, there is only one process with the name of the
system. That is Perfect GYM Club which is only one major process. In above
figure, customer makes payment for registration.

36
Anish Shrestha
CS5002NP Software Engineering

Internal Model Specification

a) DFD Fragments

Figure 15: DFD fragment for Payment of customer

This is the DFD fragment for payment of customer module. For payment of
customer, customer give amount and customer information. The customers
who are not registered will be registered and are given their customer number.
Their payment information is stored in payment data store.

37
Anish Shrestha
CS5002NP Software Engineering

b) Level 2

Figure 16: Level 2 for Payment of customer fragment

This is the DFD level 2 for payment of customer module. In this figure,
customer provides amount paid and customer information. The payment done
by customer is recorded. The customer who is not member will be given
customer number and their information will be added to Customers store. The
process also checks whether customer is de-registered or had been inactive
for a month. That customer will be re-registered.

38
Anish Shrestha
CS5002NP Software Engineering

Design specification

a) Structure chart

Figure 17: Structured chart of payment of customer module

Module Specification (Mspecs)

Module Name: Payment of customer
Purpose: This module is used by the customer to make payment.

Pseudocode
START

GET amount paid and customer info

STORE payment information in the payment data store

GET member status of customer

CHECK if customer is already member of club

CHECK if customer is de-registered or inactive for a month

USE customer number to re-register customer

ELSE

ADD customer information in the customers’ data store

RETURN customer number

39
Anish Shrestha
CS5002NP Software Engineering

Conclusion
In this coursework, I did Environmental model specification of group task and
payment of customer of individual task. Creating all the internal tasks were
burdensome as it was my first time. It took about 3 days to finish environment
model specification and extra 2 days to create my individual task.

The task was challenging, giving our own individual effort and combining it with
each other achievement was difficult because merging all the tasks of members
was found to be unproductive at first. It seemed like our group member was not
making any progress. After giving some time on solving the issues, finally our
tasks completed successfully.

40
Anish Shrestha
CS5002NP Software Engineering

Individual report 4

London Met Id: 18030720

Module Name: Anish Shrestha

Module Leader: Sandeep Gurung

Module introduction

This is the perfect GYM club’s “Deregister a customer” as the title indicates the
process of deregistering the customer. According to this module’s requirement,
customers willing to leave a GYM will de-register in the GYM. Customers who
have been inactive for a month will be automatically de-registered by the
system.

Environmental Model Specification

1) Context Diagram

Figure 18: Context Diagram of Deregister customer

This is the level 0 DFD for the deregister customer module, which gives the
major process i.e. Perfect Gym Club. For Gym club, customer who wants to
leave the GYM needs to give customer id to the system by either customer itself
or admin. Then only customer is deregistered.

41
Anish Shrestha
CS5002NP Software Engineering

2) Internal Model Specification

a) DFD Fragment

Figure 19: DFD Fragment of deregister customer

This is the DFD fragment for deregister customer module. As shown in the
above diagram, there is only one process with the name of the module.
Deregister customer is the only one major process in the figure. As shown,
customer or admin has privilege to deregister customer. The customer is
deregistered with the help of customer id. The process makes changes to the
customer status in the customers store.

42
Anish Shrestha
CS5002NP Software Engineering

b) Level 2

Figure 20: Level 2 DFD of deregister customer

This is the DFD level 2 for deregister customer module. In the figure shown
above, customers are allowed to deregister themselves. To deregister
customer, customer or admin gives customer id to the deregister process. The
deregister process makes status of customer to deregister in the customer data
store. The system also checks inactive status of customer. The customer is
known inactive from status retrieved from the to do list data store. If the status
is inactive, that is, customer has not been doing its tasks. Then customer is
deregistered.

43
Anish Shrestha
CS5002NP Software Engineering

3) Design Specification

a) Structured chart

Module Specification
Module Name: Deregister customer
Purpose:

Pseudocode
START

GET customer id

CHANGE status of customer to inactive in the Customers store

GET status of customer from the todolist store

IF status is inactive

GET customer id

CHANGE status of customer to inactive in the Customers store

EXIT

END

44
Anish Shrestha
CS5002NP Software Engineering

Conclusion
Part of deregister was in my portion of individual task. It includes all
deregistration of customer and staff. It is one of the most important process of
the system that we are given to build. As given the question all the processes
are carried out in the system. However, I took support from my teacher and my
group leader for the portion that I was facing problem in my task.

While doing this part of the course work I feel difficult while connecting
data flow. It looks little bit massy. Explaining all the levels and structure chart,
it makes me more than what I was before in the software engineering
specifically data flow. I got to know well tool knowledge of “draw.io”. It is one
of the best online site for drawing the charts.

Overall I got the knowledge of how software works in the real world that
includes, what are the problem that user as well customers can face and how
that can be solved in before the development of the stakeholders, how to
reduce the risk of faults, how the data flow in the system and how that can be
manage in the very systematic way. All the other tasks are done with the
collaboration of my group members.

45
Anish Shrestha
CS5002NP Software Engineering

Summary of our Report

This report holds the group coursework of Software Engineering that
accounts for 20% of our total module grades. This coursework is all about the
design and analysis of the GYM Club known as Perfect Club GYM. The
foremost goal of the coursework is to highlight the knowledge we have gained
on “Structured Software Engineering” approach. We are required to develop a
system that will reduce the problem of a GYM club which is to maintain records
of the customer with their payment details. We are required to analyse
requirements on the system and change the current system with new
computerized system. This coursework is group project so, for the completion
of the coursework a group is needed to be formed which can include 4 to 5
members each. To begin with, we began our research and collected essential
information about what our coursework holds and how to complete the work
properly. When we collected the essential information, our work was ready to
be started. The given coursework is huge for a single person to complete so all
of the members of the group decided to split the task into four parts which
ensured our equal support for the task to be completed in time.

We all began our coursework in November 17, 2019. The very first day
of our meeting with the group members we discussed about the ideas about
the coursework. We took the conceptual idea about the work to be done from
all of our group members and also identified the potential issues that we may
have to deal with while doing our coursework. The main idea of the tasks is to
display Internal Model Specification, Environment Model Specification, Data
Dictionary, Process Specification, Design Specification, Assignment Diary,
Requirement Analysis Specification, four individual tasks and the
documentation of the coursework. In order to complete the tasks in a well-
managed way and create a jelled team to minimize the issues regarding to the
task in the coursework, total five meeting session was held. Those meetings
were all about sharing ideas, managing the time, checking errors and solving
potential issues regarding to the coursework. Our final meeting was held in
January 6, 2020. On the very day we collected all the tasks done by every group
members and our document was merged in a single word file. Through equal
support and sharing of ideas among the group members, we were able to

46
Anish Shrestha
CS5002NP Software Engineering

complete our coursework before the due date. The whole coursework was
completed in about a month. At last, the coursework was submitted to the
module teacher at the given time interval.

47
Anish Shrestha
CS5002NP Software Engineering

Group Conclusion
Now that we have completed our coursework, we can say that our skills,
knowledge and understanding has increased by a little. We are glad that we
have completed our coursework in time. This coursework showed us the
importance of group and team work. Every member of our team contributed
equally in their respective parts to complete the task they were given to. Due to
the dedication and determination of all of four members it was possible to
complete the coursework in given time.

This coursework didn’t only built our skills to work as a team but also
contributed in sector such as time managing, skill development, talking skills,
interaction skills and the skills to share ideas with each other. Similarly, it also
built a strong relation among individuals. To be real, we haven’t been that
familiar with our friends till date but this group coursework gave us opportunity
to know our friends too. Working as a jelled team built our capacity to deal with
issues regarding to the work and also helped to generate idea about how to
cope with such issues.

Finally, our coursework is ready to be submitted and I would like to thank

my module teacher and all of the people related to this coursework for providing
us such an enjoyable and important task as part of our coursework.

48
Anish Shrestha