A19 CS5002 NP 19031004 Netra Bahadur Rana CW1

Informatics College Pokhara
Software Engineering
CS5002NP
Coursework 1
Submitted By: Submitted To:

Netra Bahadur Rana - 19031004 Mr. Sandeep Gurung
Ravi Poon - 19031089 Module Leader
Arogya Prasad Baral - 19031595 Software Engineering
Bipin Gurung - 19030839
Prashant Bastola - 19031066
Group: C4
Date: 31th December, 2020
Contents
1. Introduction ......................................................................................................... 1
2. Environmental Model Specification ..................................................................... 2
2.1 Context Level Diagram (Level 0) ................................................................... 3
2.2 Level 1 Data Flow Diagram ........................................................................... 4
2.3 Level 2 Data Flow Diagram ........................................................................... 6
2.3.1 Level 2 DFD of Registration of Customer: .............................................. 6
2.3.2 Level 2 DFD of Booking .......................................................................... 7
2.3.3 Level 2 DFD of Payment......................................................................... 8
2.3.4 Level 2 DFD of de-registration ................................................................ 9
2.3.5 Level 2 DFD of repot generation ........................................................... 10
2.3.6 Level 2 DFD of notification.................................................................... 11
3. Internal model specification for the system ....................................................... 12
3.1 Entity-Relationship Diagram ........................................................................ 12
3.2 Data Dictionary............................................................................................ 14
3.3 Process Specification .................................................................................. 19
3.3.1 Staff registration ................................................................................... 20
3.3.2 Customer registration ........................................................................... 20
3.3.3 Booking................................................................................................. 21
3.3.4 Membership .......................................................................................... 22
3.3.5 Payment ............................................................................................... 22
3.3.6 Notification ............................................................................................ 23
3.3.7 de-register customer ............................................................................. 24
3.3.8 De-register staff .................................................................................... 25
3.3.9 Report generation ................................................................................. 25
4. Design Specification.......................................................................................... 26
4.1 Structure Diagram ....................................................................................... 27

5. Assignment Diary .............................................................................................. 29
6. Individual Task 1 ............................................................................................... 33
6.1 Introduction to register a customer .............................................................. 33
6.2 Environmental Model Specification ............................................................. 33
6.2.1 Context Level Diagram or level 0 Data flow Diagram (DFD) ................. 34
6.3 Internal Model Specification ........................................................................ 34
6.3.1 ADFD Fragments .................................................................................. 34
6.3.2 Level 2 DFD of Customer Registration ................................................. 35
6.4 Design Specification .................................................................................... 37
6.4.1 Structured chart .................................................................................... 37
6.4.2 Module Specification ............................................................................ 38
6.5 Conclusion .................................................................................................. 39
7. Individual Task 2 ............................................................................................... 39
7.1 Introduction of Book practice room .............................................................. 39
7.2 Environmental model specification .............................................................. 40
7.2.1 Context Level Diagram or Level 0 Data Flow Diagram (DFD) .............. 40
7.3 Internal model specification ......................................................................... 41
7.3.1 Level 1 DFD Fragment ......................................................................... 41
7.3.2 Level 2 DFD.......................................................................................... 42
7.4 Design specification .................................................................................... 43
7.4.1 Structure Chart ..................................................................................... 43
7.4.2 Model specification (MSpecs) ............................................................... 44
7.5 Conclusion .................................................................................................. 45
8. Individual Task 3 ............................................................................................... 45
8.1 Introduction to payment of a Customer: ...................................................... 45
8.2 Environmental Model Specification ............................................................. 46
8.2.1 Context Level Diagram: ........................................................................ 46

8.3 Internal Model Specification:- ...................................................................... 47
8.3.1 Level 1 DFD.......................................................................................... 47
8.3.2 Level 2 DFD.......................................................................................... 48
8.4 Design Specification:- ................................................................................. 49
8.4.1 Structure chart ...................................................................................... 49
8.4.2 Module Specification:- .......................................................................... 50
8.5 Conclusion .................................................................................................. 51
9. Individual Task 4 ............................................................................................... 51
9.1 Introduction ................................................................................................. 51
9.2 Environmental Model Specifications ........................................................... 52
9.2.1 Context Level........................................................................................ 52
9.3 Internal Model Specification for Generate Report ....................................... 53
9.3.1 Level 1 Data Flow Diagram .................................................................. 53
9.3.2 Level 2 Data Flow Diagram .................................................................. 54
9.4.1 Structure Chart ..................................................................................... 55
9.4.2 Module Specification for generate report .............................................. 56
9.5 Conclusion .................................................................................................. 57
10. Individual Task 5 ............................................................................................ 57
10.1 Introduction to De-register of customer ....................................................... 57
10.2 Environmental model specification .............................................................. 58
10.2.1 Context Level Diagram ...................................................................... 58
10.3 Internal Model Specification ........................................................................ 59
10.3.1 Level 1 DFD Fragment ...................................................................... 59
10.3.2 Level 2 DFD ...................................................................................... 60
10.4.1 Structure Chart .................................................................................. 61

10.4.2 Module Specification ......................................................................... 62
10.5 Conclusion: ................................................................................................. 63
11. Summary of the report: ................................................................................... 64
12. Bibliography.................................................................................................... 65
List of Figures
Figure 1: Context level DFD ....................................................................................... 3

Figure 2: Level 1 DFD ................................................................................................ 4
Figure 3: Level 2 DFD of registration of customer ...................................................... 6
Figure 4: Level 2 DFD of Booking .............................................................................. 7
Figure 5: Level 2 DFD of payment ............................................................................. 8
Figure 6: Level 2 DFD of de-registration of customer ................................................. 9
Figure 7: Level 3 DFD of report generation .............................................................. 10
Figure 8: Level 2 DFD of notification ........................................................................ 11
Figure 9: Entity relation Diagram of Sound Strong Database System ...................... 13
Figure 10: Structure chart (Upper level) of Sound Strong System ........................... 28
Figure 11 :Data Flow Diagram of Register a customer............................................. 34
Figure 12: Level 1 Data Flow Diagram Fragment ..................................................... 34
Figure 13: Level 2 DFD Fragments .......................................................................... 36
Figure 14: Structured Diagram for Register Customer. ............................................ 37
Figure 15: Context level of booking .......................................................................... 40
Figure 16: Level DFD of booking .............................................................................. 41
Figure 17: Level 2 DFD of booking ........................................................................... 42
Figure 18: Structure chart of booking ....................................................................... 43
Figure 19: Payment of a customer 0 level DFD diagram .......................................... 46
Figure 20: Customer of a payment 1 level DFD diagram ......................................... 47
Figure 21:Payment of a customer 2 level DFD diagram ........................................... 48
Figure 22: Structure chart of payment of a customer ............................................... 49
Figure 23: Context Level diagram of Report generation ........................................... 52
Figure 24: level 1 DFD of Generate Report .............................................................. 53
Figure 25: Level 2 DFD of Generate Report............................................................. 54
Figure 26: Structure chart of generate report ........................................................... 55
Figure 27: Context level of De-register customer ..................................................... 58
Figure 28: Level 1 DFD of de-register customer ...................................................... 59
Figure 29: Level 2 DFD of de-register customer ...................................................... 60
Figure 30: Structure chart of de-register customer ................................................... 61
List of tables
Table 1: Elements used in DFD ................................................................................. 2

Table 2: Data Dictionary of Admin ............................................................................ 14
Table 3:Data Dictionary of staff ................................................................................ 15
Table 4:Data Dictionary of customer ........................................................................ 16
Table 5:Data Dictionary of Payment ......................................................................... 17
Table 6:Data Dictionary of Booking .......................................................................... 17
Table 7:Data Dictionary of Membership ................................................................... 18
Table 8:Data Dictionary of room_booking ................................................................ 18
Table 9:Data Dictionary of instrument_booking ........................................................ 19
Table 10: Pspecs of staff registration ....................................................................... 20
Table 11: Pspecs of customer registration ............................................................... 20
Table 12: Pspecs of Booking .................................................................................... 21
Table 13: Pspecs of Membership ............................................................................. 22
Table 14: Pspecs of Payment .................................................................................. 22
Table 15: Pspecs of Notification ............................................................................... 23
Table 16: Pspecs of customer deregistration ........................................................... 24
Table 17: Pspecs of staff deregistration ................................................................... 25
Table 18: Pspecs of report generation ..................................................................... 25
Table 19: Elements of a Structure Diagram ............................................................. 27
Table 20: Assignment diary ...................................................................................... 29
Table 21: Division of group task ............................................................................... 30
Table 22: Selection of individual task ....................................................................... 30
Table 23: Meeting log ............................................................................................... 31
CS5002 NP Software Engineering
1. Introduction
This coursework was assigned to us by our software engineering module leader

Sandeep Gurung sir. This coursework was not individual but a group task so that
students can work together in group and have practical knowledge of software
engineering. Task is to make an online system design for practice
rooms/instrument rental service of Sound Strong institute. This institute has been
providing practice room rental service for musicians from long time and has been
using phone-called based booking system but due to recent high demand and
difficulties due to it we have to make online-system design for booking and hiring
of rooms and instruments. We need to have investigate the requirements for the
system.
For booking of the rooms/instrument customer has to pay certain advance if they
aren’t member of the institute. And for the booking one must be registered in the
system which is to be done by customer him/herself and then institute verifies the
registration. In order to deregister from membership customer can request the
institute and it will conform it. Those who have been registered as member are
provided discount and special package by Sound Strong institute. Before
membership duration expires about a week previously customers are notified and
then he/she can choose to be member or not. Also customers can hire instruments
if they want for the practice time they have booked rooms for. Availability of both
rooms and instrument can be checked by customer and chose the time they want
to hire. Staffs can update booking time and alter it if needed and verifies with
respective customers.
This project need analysis before the starting and then all members of group
needed to divide the task to do. Context level, DFD, ERD with data dictionary and
Process Specifications and structured chart were done accordingly and with the
help of module leader as well as internet sources. All process for the designing of
the online system of Sound Strong institute is done accordingly with proper
explanations of the process.
1
2. Environmental Model Specification
Specification is an activity to encircle the different stages of software

development process. The abstract model of a software or an application heavily
depends on the quality of Software Requirements Document (SRD). The design
and implementation require specification at detailed level. Specification is
necessary to break the complexity barriers during the development (Alagar &
Periyasamy, 2011). Data Flow Diagram (DFD) is a of the specification which
graphically represents the flow of data and the process involved in an information
system. The DFD gets more distributed as it goes from highest to lowest level. In
this system, Yourdon Data flow diagram is used. The name, symbol and functions
of the elements used in Yourdon DFD are as follows:
Table 1: Elements used in DFD
Name Symbol Function

Process It shows what the system does.
Each process has one or more
data inputs and produces one
or more data outputs.
Data Flow It shows the movement of data
in the system.
Data Store name Data store is the repository of
the system. Processes can
enter and retrieve data from it.
Terminator (External They work outside the system
name
Entity) but provides input and use the
system output.
There are mainly 3 levels of DFD. They are Level 0 diagram (also known
as context diagram), Level 1 diagram and level 2 diagram.
2
2.1 Context Level Diagram (Level 0)
The context diagram contains only 1 process and that process

must have the system name. In this case, Sound Strong is the system
name so it is placed in the oval shape. It is the highest level of DFD. It
defines the upcoming diagrams. Any involved process must be included
in this level because we cannot add directly in the lower DFD’s.
The purpose of Sound Strong music institute is to provide better

services to its customers by introducing an online system. The
application must keep the record of Admin, Customer and Staff.
Figure 1: Context level DFD
3
In the above figure, the customer provides their information like

booking, payment and membership to the system and the information is verified and
registered by the staff. The staff keeps record of the customers activity and generates
report. The admin manages both customer and staff. The system, automatically, sends
a notification message to the customer after certain time to notify them about their
membership status and room reservation.
2.2 Level 1 Data Flow Diagram
Figure 2: Level 1 DFD
The above figure presents the level 1 DFD of the Sound

Strong music institute 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 which are connected by the flow of data and the data
4
resides in their respective data store. The terminator (External entity) of

the database is represented by the rectangles.
The processes, data flow, data stores are all connected together
which makes it harder to understand the system. Here are the processes
put together consecutively:
1. Staffs are selected through registration form managed by Admin.

2. Customer wanting to join Sound Strong system must register
themselves in the system first.
3. Admin has the privilege to register and de-register both staff and
customer.
4. Customer can book the rooms with their timing and the instruments.
5. A staff can cancel the booking if the customer demands.
6. Customer have an option of membership.
7. If the customer accepts membership, they will get discount and some
special package. If they don’t, they will have to pay in advance up to 8 th
booking.
8. Total payment depends on the membership status.
9. The booking, payment, membership status are maintained by the staff.
10. The system automatically informs the customer about the remaining time
of their reservation as well as their membership.
11. A customer can de-register themselves if they wish to quit the system.
12. Admin can de-register the staff that are no longer working in the system.
13. The staff collects all the data of the customer and finally generates
report.
5
2.3 Level 2 Data Flow Diagram
The level 2 DFD is the lowest level of DFD in this system. In this
level, all the major processes are broken down and shown in more detail
how or why that process occurred.
2.3.1 Level 2 DFD of Registration of Customer:
Figure 3: Level 2 DFD of registration of customer
In the above figure, we can tell easily that the customer in

passing their information in a new account and it gets stored in
customer records. The data from the store is then used to request
staff for registration. After the staff has verified the details, it then
checks if the initial payment is done or not. If its ok then the
registration records also get stored in customer records.
6
2.3.2 Level 2 DFD of Booking
Figure 4: Level 2 DFD of Booking
In this figure, a customer is trying to reserve a room or

instrument. The Sound Strong System is made in such a way that
people can see the availability of the room. Then the customer
sends the details to staff. The staff then verifies the customer and
finally makes the booking which is then stored in booking records.
7
2.3.3 Level 2 DFD of Payment
Figure 5: Level 2 DFD of payment
In this diagram, the membership record is extracted at first.

If the customer is a member in the system, they will get discount in
their total pay amount which is then paid by the customer. The
payment details are stored in payment records.
8
2.3.4 Level 2 DFD of de-registration
Figure 6: Level 2 DFD of de-registration of customer
In this figure, a customer is being deregistered. There are

two ways for this. A customer can deregister himself or the staff
deregisters him/her. We can see that for both process, payment
check is necessary. If the customer has any uncleared payment,
they will not be able to deregister.
9
2.3.5 Level 2 DFD of repot generation
Figure 7: Level 3 DFD of report generation
In this figure, we can easily tell that the records from

customer, payment and booking are all passing through the report
generation process. After the process, they are stored as Report.
The report is then sent to the admin to view it.
10
2.3.6 Level 2 DFD of notification
Figure 8: Level 2 DFD of notification
The above figure illustrates the notification process. As we

can see, there are two data store that sends notification to the
customers. One being membership record and the other being
booking record. The membership record notifies the customer
about the deadline of their membership while the booking records
notifies about the time left of their reservation.
11
3. Internal model specification for the system
3.1 Entity-Relationship Diagram
Diagrams that are created using ER-modelling method which enable

us to view a conceptual data model of the information system are Entity-
Relationship Diagram. They are also known as ER Diagram or ERD. ERD
are used even for the illustration of the local structure of database as well
as for designation of the system. Initial introduction of ER modelling was
done by Peter Chen making it a great technique used in the field of
computers nowadays. The construction steps of ERD help database analyst
to easily understand where the data is stored in the database. Logical
structure of database can be understood easily from the view of the user
whoever is using the database. There are 3 elements used in ERD for the
graphical representation of the data model and they are as follows:
• Entity
Entity are real world objects which are merely identifiable. Entities are
more likely to not have replica in the system. All entities have attributes
which explain their properties. Example are teacher, customer, class,
etc. rectangle shape represent entity.
• Attributes
Attributes represent entities properties and all attributes have values.
Attributes are of 4 kinds: Key attribute, composite attribute, single-valued
attribute, multi-valued attribute and derived attribute. Oval shape
represent entity.
• Relationships
Entities are connected to each other and that connection is due to the
association named as relationship. It represents what connection is
there. Diamond shape represent relationship. The number of entities in
one entity set is defined by the cardinality and its type are: one to one,
one to many, many to one and many to many.
12
Figure 9: Entity relation Diagram of Sound Strong Database System
13
3.2 Data Dictionary
Data which are stored in the database are known as metadata. Meta
data are in the data dictionary therefore data dictionary is indeed very essential.
In data dictionary all the data which are in database, it’s location, who has its
access and much more information are stored. But normally, the users of
database need not to deal with the data dictionary and is only managed by
database administrators (Meador, 2018). There are two kinds of data
dictionary: Active data dictionary and Passive data dictionary. Active data
dictionary are those which updates automatically by database management
system whenever changes happen, but passive data dictionary has to be
annually updated.
Table 1: Admin
Table 2: Data Dictionary of Admin
Field Name Data Type Field size Constrain

Admin_id Int - Primary Key
Admin_name Varchar 30 Not null
address Varchar 40 Not null
contactNo varchar 10 Not null, unique
The table ‘Admin’ has four columns which are:
▪ Admin_id: Defines unique id number of admin which is primary key. It

has integer data type.
▪ Admin_name: Defines name of admin. It has varchar data type. Data
length is of 30.
▪ address: Defines address of admin. It has varchar data type. Data length
is of 40.
▪ contactNo: Defines contact number of admin and has varchar data type.
It is unique. Data length is of 10.
14
Table 2: staff
Table 3:Data Dictionary of staff

staff_id Int - Primary key
staff_name Varchar 30 Not null
enroll_date Date - Not null
contactNo Varchar 10 Unique, Not null
position Varchar 20 Not null
email Varchar 40 Unique, Not null
Admin_id int - Foreign key
Table ‘staff’ has 8 columns which are:
▪ staff_id: Defines unique id of staff which is primary key. It has interger

data type.
▪ staff_name: Defines name of the staff. It has varchar data type. Data
length is 30.
▪ address: Defines address of the staff. It has varchar data type. Data
length is 40.
▪ enroll_date: Defines enrol date of the staff. It has date data type.
▪ contactNo: Defines contact detail of staff. It has varchar data type. It has
to be unique. Data length is 10.
▪ position: Defines position of the staff. It has varchar data type. Data
length is 20.
▪ email: Defines email address of the staff. It has varchar data type. It must
be unique. Data length is 40.
▪ Admin_id: It defines id of the admin of Admin table. It is foreign key.
15
Table 3: Customer
Table 4:Data Dictionary of customer

customer_id int - Primary key
customer_name Varchar 30 Not null
email Varchar 40 Unique, Not null
membership_date Date - Not null
contactNo Varchar 10 Unique, Not null
Admin_id Int - Foreign key
The table ‘Customer’ has 7 columns which are:
▪ customer_id: It defines unique id of customer which is primary key. It has

int data type.
▪ customer_name: It defines name of the customer with data length 30. It
has varchar data type.
▪ email: it defines email address of the customer with data length 40. It
has varchar data type and must be unique.
▪ membership_date: It defines date of membership of the customer. It has
date data type.
▪ contactNo: It defines contact detail of the customer. It has varchar data
type with data length 10. It is unique.
▪ address: It defines address detail of the customer with data length 40. It
has varchar data type.
▪ Admin_id: It is foreign key which defines admin id from admin table.
16
Table 4: Payment
Table 5:Data Dictionary of Payment

payment_id Int - Primary key
payment_date Date - Not Null
payment_method Varchar 20 Not Null
customer_id Int - Foreign key
The table ‘payment’ has 4 columns which are:
▪ payment_id: It defines unique id of payment which is primary key. It has

int data type.
▪ payment_date: It defines the date of the payment. It has date data type.
▪ payment_method: It defines method of the payment with data length 20.
It has varchar data type.
▪ customer_id: It is a foreign key. It defines id number of customers from
customer table who has done payment.
Table 5: Booking
Table 6:Data Dictionary of Booking

booking_id Int - Primary key
booking_time Time - Not null
customer_id int - Foreign key
‘Booking’ table has 3 columns which are:
▪ booking_id: It defines unique id of the booking which is primary key. It

has int data type.
▪ booking_time: It defines time of how long the booking is for. It has time
data type.
▪ customer_id: It defines id of the customer who has done booking. It is
foreign key.
17
Table 6: Membership
Table 7:Data Dictionary of Membership

member_id Int - Primary key
customer_id Int - Foreign key
member_duration varchar 10 Not null
The table ‘membership’ has 3 columns which are:
▪ member_id: It defines unique member id which is primary key. It has int

data type.
▪ customer_id: It defines customer id from customer table who has taken
membership and has int data type.
▪ member_duration: It defines duration of the membership. It has varchar
data type with data length 10.
Table 7: Room_booking
Table 8:Data Dictionary of room_booking

room_id Int - Primary key
room_name Varchar 30 Not null
booking_id int - Foreign key
The table ‘room_booking’ has 3 columns which are:
▪ room_id: It defines id of the room that is for rent and is primary key. It
has int data type.
▪ room_name: It defines name of the room with data length of 30. It has
varchar data type.
▪ booking_id: Defines id of booking from booking table. It is foreign key.
18
Table 8: instrument_booking
Table 9:Data Dictionary of instrument_booking

instrument_id Int - Primary key
instrument_name varchar 30 Not null
booking_id Int - Foreign key
The table ‘instrument_booking’ has 3 columns which are:
▪ instrument_id: It defines id of the instrument that is for rent and is primary

key. It has int data type.
▪ instrument_name: It defines name of the instrument with data length of
30. It has varchar data type.
▪ booking_id: Defines id of booking from booking table. It is foreign key.
3.3 Process Specification
The process specification also known as pspecs is a technique

used to report, examine and clarify the decision-making process and
algorithms used to generate output data from input data. The atm of the
process specification is used to describe the engineering requirements
and procedures for developers. Explanation of decision-making and tasks
performed throughout the system that enables the developer to have a
proper description of the valid design of the system. The objective is to
reduce ambiguity, making it easy for analysts to understand how the
process works. Process specification shall ensure all input data flow
necessary for the generation of output data (University of Calgary, 1997).
19
3.3.1 Staff registration
Table 10: Pspecs of staff registration
Process Name Register Staff

Process Number 1
Input Staff name, age, sex, date of birth, contact,
address, e-mail, date of registration, registered by
Output Staff ID
Details Staff fille the registration form to be registered in
the system. Admin approves the registration.
PSEUDOCODE:
START
IF the staff wants to register in the system
Fill the registration form
Input necessary details
VERIFY Staff details
RETURN Staff ID
STOP
3.3.2 Customer registration
Table 11: Pspecs of customer registration
Process Name Register Customer

Process Number 2
Input Customer name, age, sex, date of birth, address,
contact, e-mail, date of registration, registered by
Output Customer ID
Details Customer fill the registration form where they
provide all the necessary information. The staff
approves the registration.
20
PSEUDOCODE:
START
IF customer wants to use the system
Fill registration form
Input customer details
VERIFY customer details
RETURN customer ID
STOP
3.3.3 Booking
Table 12: Pspecs of Booking
Process Name Booking

Process Number 3
Input Room, instrument which the customer wants
to book
Output Booking ID
Details If the customer wants to book a room or
instrument, staff keeps those records and
gives booking ID. If the room is not available,
staff can either change the time or provide
another room.
PSEUDOCODE:
START
INPUT room/instrument details
IF room/instrument available
Register room/instrument
ELSE
Provide other options.
RETURN Booking ID
STOP
21
3.3.4 Membership
Table 13: Pspecs of Membership
Process Name Membership

Process Number 4
Input Customer ID
Output Membership ID
Details Customer provides Customer ID to the staff and asks for
membership. Staff registers the Customer ID in membership
record.
PSEUDOCODE:
START
IF the customer wants to take membership
INPUT Customer ID
RETURN Membership ID
SET Customer status in Membership record TRUE
STOP
3.3.5 Payment
Table 14: Pspecs of Payment

Process Name Payment
Process Number 5
Input Customer ID, Booking ID, Membership ID, pay method,
date
Output Receipt
Details The payment depends upon the no of rooms or
instruments booked as well as in membership. Only after
calculating these details, total payment is received.
22
PSEUDOCODE:
START
INPUT booking details
Check membership ID
IF customer has Membership ID
GET discount and special pacakges
ELSE
PAY in advance up to 8th booking
RETURN final amount
INPUT Customer ID
IF Cuctomer pays
SET payment TRUE
ELSE
SET payment FALSE
STOP
3.3.6 Notification
Table 15: Pspecs of Notification
Process Name Notification

Process Number 6
Input Booking time details, membership time
details
Output Notification message
Details When the time is about to expire, the
system automatically sends message to the
customer.
23
PSEUDOCODE:
START
Input (booking time, membership time)
IF remaining booking time = 30 mins
SEND notification
IF remaining membership time = 7 days
SEND notification
STOP
3.3.7 de-register customer
Table 16: Pspecs of customer deregistration
Process Name Customer deregistration

Process Number 7
Input Customer ID
Output Deregistration details
Details Customer ID is terminated by staff.
PSEUDOCODE:
START
INPUT Customer ID
VERIFY Customer ID
IF customer wants to de-register
TERMINATE Customer ID
DELETE details from system
STOP
24
3.3.8 De-register staff
Table 17: Pspecs of staff deregistration
Process Name Staff De-registration

Process Number 8
Input Staff ID
Output Deregistration details
Details Admin terminates Staff ID
PSEUDOCODE:
START
INPUT Staff ID
VERIFY Staff ID
IF staff wants to de-register
TERMINATE Staff ID
DELETE details from system
STOP
3.3.9 Report generation
Table 18: Pspecs of report generation
Process Name Report generation

Process Number 9
Input Customer details, registered date, registered by, payment
details, Booking details, membership status
Output Report on customers activities
Details Staff generates the report and admin views it.
25
PSEUDOCODE:
START
CREATE Report
GET (customer details, payment details, booking details,
membership details)
PRINT (customer details+ payment details + booking
details + membership details)
CALL Report
View report details
STOP
4. Design Specification
The design specification provides explicit information on the requirements

for the product and how the product is to be assembled. Design Specifications
describe how the system meets the requirements outlined in the Functional
Requirements. Depending on the system, this may include instructions for
testing specific requirements, configuration settings, or revision of functions or
code. In design specification, the systems are specially made to meet the
expected goals (Ofni systems, n.d.).
26
4.1 Structure Diagram
The structure diagram is a tree shaped illustration of the system.

This diagram helps us to achieve the lowest manageable form of the
system. Structure diagram uses its own set of elements to describe the
processes, data flow, decisions and other information. With the help of this
diagram, we can easily track the movement of data. Here are some
information on the elements used in this diagram:
Table 19: Elements of a Structure Diagram
Name Symbol Description

Process It defines an instruction that are
carried by the system.
Call line It indicates the path.

Decision It represents SELECTION and splits
the sequence.
Parameter It indicates flow of data.
Control Parameter It indicates the completion of a criteria
allowing the system to proceed.
Repetition It highlights a process that can occur
many times.
27
The figure below is the structure diagram of The Sound Strong

music institute system. From this diagram, we can get a clear view of
how all the processes take place.
Figure 10: Structure chart (Upper level) of Sound Strong System
28
5. Assignment Diary
Table 20: Assignment diary
Meeting Activity Date
1. Divided group and individual task 12/02/2020
2. Research discussion 12/05/2020
3 0 level and 1 level DFD 12/07/2020
4. Level 2 DFD 12/08/2020
5. ERD And Data Dictionary 12/10/2020
6. Process Specification 12/14/2020
7. Design Specification 12/18/2020
8. Documentation 12/25/2020
9. Date of submission 12/31/2020
29
Group task
Table 21: Division of group task
Name Responsibility
Netra Bahadur rana He was responsible for the creation of the
DFD diagrams and the report merge.
Ravi Pun He was assigned to create the ERD and data
dictionary for the internal model specification.
Arogya Prasad Baral He chose to create the structured chart.
Bipin Gurung He had his task to complete the assignment
diary keeping record of every meeting we
had.
Prashanta Bastola He was the one involved in most research
works.
Individual task
Table 22: Selection of individual task
Name Task
Arogya Prasad Baral Register a customer
Ravi Pun Booking
Prashant Bastola Payment of customer
Netra Bahadur Rana Generate Report
Bipin Gurung De-register a customer
30
Group Meeting
Table 23: Meeting log
Meeting No. Date Description

1 12/02/2020 This was the first virtual
meeting of all the group
members. In this meeting,
the group task was
divided into multiple
fraction and each
individual was held
responsible for
completion of a certain
part. And the individual
works were also chosen.
2 12/05/2020 In this second meeting,
we discussed on how we
can solve the problem of
having little knowledge
about the topic. The
responsibility for most
part of research was
given to Prashant. His
task was to search and
inform so that we can
have the same view.
3 12/07/2020 The 3rd meeting and we
finally are in the main
content. Netra submitted
the DFD diagrams and we
all discussed whether it
was correct or not. There
31
were some changes done

in the diagrams after the
meeting.
4 12/08/2020 In the 4th meeting, Netra
submitted the 2nd level
DFD diagram and we
discussed on where to
continue.
5 12/10/2020 In the 5th meeting, ERD
diagram which was
designed at the start of
the project was
discussed. ERD played a
huge role in the DFD
modelling. So, we
decided to give the task of
data dictionary to Ravi.
6 12/14/2020 In the 6th meeting, we
talked about the process
modifications. Since it
was based on the DFD,
Netra was assigned to
complete it.
7 12/18/2020 After the process
specification was
complete, Arogya
proposed to do the
structure diagram. The
description part were
partially completed by
Bipin and Prashant.
8 12/25/2020 After the group work and
individual work were
32
complete, we decided to
complete the
documentation part. Netra
could use Ms Word very
easily than others so it
was assigned to him. The
definitions and citations
were done by Prashant.
9 12/31/2020 The final version of the
documentation was
submitted on 31st
December,2020.
6. Individual Task 1
Module: Register a customer
Name: Arogya Prasad Baral
Student ID: 19031595
6.1 Introduction to register a customer
This is the music institute providing musical instruments training

named “Sound Strong”. For every new customer, all the details is collected
along with the payment information. Once the information is collected, the
customer is registered by the admin into the customer record.
6.2 Environmental Model Specification
33
6.2.1 Context Level Diagram or level 0 Data flow Diagram (DFD)
Data flow diagrams are the basic level diagrams. They are
called level 0 because they show only single process node and
are very simple to understand. Having said that, they also offer
some brief to the flow of information in the system.
Figure 11 :Data Flow Diagram of Register a customer
Here, you see a data flow diagram for registration of a

customer into the Sound Strong application. Here, Admin takes
the major call and registers the customer details into the System.
Every Customer hold, its personal information details, and it’s
payment details. This data flow diagram is mainly responsible for
showing the flow of data into the system and showing the process
involved.
6.3 Internal Model Specification
6.3.1 ADFD Fragments
Data flow fragments are the division of the data flow

diagram explaining the respond of every events involved. For
instance, here we are going to explain about the very first event in
the registration of the customer in the Sound Strong.
Figure 12: Level 1 Data Flow Diagram Fragment
34
In the figure, you see a simple level 1 DFD fragment for

customer information. Here a customer information is registered
to customer record.
6.3.2 Level 2 DFD of Customer Registration
This is next level to the data flow diagram fragments. It has

a little more information than the level 1. The level 2 always
includes all the information of level with deeper understanding of
the process.
35
Figure 13: Level 2 DFD Fragments
In this level 2 diagram. We have more detail of the process.

It includes the registration request and payment details from the
payment record. As shown in the figure, the process are carried
in the same flow. At very first the customer request for registration
is received followed by checking his payment details. After all that
information, the registration is done, and the information is saved
in the customer record.
36
6.4 Design Specification
6.4.1 Structured chart
Figure 14: Structured Diagram for Register Customer.
This is the structured diagram for the registration of the

customer. The structure show above also includes the direction
of the information flow and its events. Every event are process in
the same flow. Initially, a customer registration form is filled with
customer details. That customer details initiates the request
followed by the checking his/her payment method. After payment
is received the specific customer is registered.
37
6.4.2 Module Specification
Module Name: Register of customer
Purpose: The purpose of this module is to register a new

customer by an admin.
Input parameters: cust_details, payment_details
Process: check if payment is paid , Register’s customer
Output parameters: cust_reg_details
Calls: checkPayment()
Called By: customerRegister()
PSEUDOCODE
Enter customer details
Check customer payment details
If payment paid by customer
Register customer
Else
Payment not paid
Initiate payment method
GLOBAL VARIABLES: cust_id
LOCAL VARIABLES: cust_name, contact_No, address
38
6.5 Conclusion
The very first event in this application; Sound Strong is to register a

customer. The admin is only responsible for the registration of any
customer. The customer details initiate the process, followed by checking
the payment. Once the payment is done, the customer is successfully
registered into system. After being register, a customer can enjoy the
musical instruments available in Sound Strong.
Module: Book practice room
Name: Ravi Pun
Student ID: NP04CP4A190099
7.1 Introduction of Book practice room
This module is about the booking of practice room on hourly basis

for customers in ‘Sound Strong institute’. To book room customer has to
provide customer details and staff manages all the booking process. First
of all, customer him/herself checks the availability of room and it’s time
and also can check instrument availability if they want. Then they provide
details of the time and room and duration of the room booking. Non-
member customer has to pay certain advance in order to book room while
member will get discount offers. Booking can be updated and altered by
staff if needed. All the booking records are stored for organizational use.
39
7.2 Environmental model specification
7.2.1 Context Level Diagram or Level 0 Data Flow Diagram (DFD)
Figure 15: Context level of booking
Level 0 DFD of ‘Book practice room’ is illustrated in the

given figure. Customer provides customer details to Sound
Strong where staff observe and confirms booking of practice room
of each customer and the details of booking are stored in table
‘booking record’.
40
7.3 Internal model specification
7.3.1 Level 1 DFD Fragment
Figure 16: Level DFD of booking
Above figure demonstrates level 1 DFD fragment for room

booking process. Customer provides details to ‘booking’ which also get
input of room detail and instrument detail from database. All the inputs
are stored in booking record which is retrieved by staff.
41
7.3.2 Level 2 DFD
Figure 17: Level 2 DFD of booking
Given diagram shows level 2 diagram of ‘book practise

room’. Customer weather member or not can check the avalibility
of the room and instruments and choose acoordingly to the
availability. Staff are eligible to approve all the bookings done by
customers and also can alter time or cancel booking if situations
arises. Staff updates all the booking record in regular interval of
time.
42
7.4 Design specification
7.4.1 Structure Chart
Figure 18: Structure chart of booking
Above figure shows structure chart of the ‘book practice room’. In

the system customer provides customer details to ‘booking’ which will
process that info in order to book room or instrument that customer want.
Then the booking id of customer is forwarded after the availability of the
room or instrument to both ‘room’ and ‘instrument’. The room/instrument
customer booked for will be booked and recorded in database and
marked as booked for the booked interval of time. Then the booked
details will be provided to customer by ‘booking’ which will be further
forwarded to Sound Strong so that staff can acquire that data and alter
or cancel if the needs arises to do so.
43
7.4.2 Model specification (MSpecs)
Module Name: Book practice room

Purpose: the purpose of module ‘Book practice room’ is to book
a room for the customer which are available and desired by
them.
PSEUDOCODE:
INPUT customer details
Check room details
Check instrument details
IF room available
Book room
Else
Provide other room details
IF instrument available
Book instrument
Else
Show not available
RETURN Booking ID
Input Parameters: customer details, booking details

Output Parameters: room details, instrument details
Global Variables: customer_id, booking_id, booking_time
Local Variables: room_id, instrument_id
44
7.5 Conclusion
In this module the booking of the rooms are done for practice by
musicians on hourly basis. If they also want instruments to hire they can
rent it too. Rooms if are available then only they can be rented out.
Customer can check the availability whenever they want to and book. The
records can be accessed by staff and altered too.
Module name: Payment of a customer
Name: Prashanta Banstola
London Met ID: 19031066
8.1 Introduction to payment of a Customer:
In Sound solid music founded application, this module depicts

approximately the installment of the customer. The installment subtle
elements of the client is carried out by the staff of the music institute. For
the installment handle, the installment of the client is recorded within the
framework. To begin with the client is checked in case he/she had been
part some time recently. For the ancient part, on the off chance that he/she
is dormant for more than one month, the client ought to enlist themselves.
The new customer ought to enroll within the music organized and can
make the installment. For checking the payment, the installment detail of
the client is checked and in case in the event that it’s time to pay the fee
than the client is educated about the due date for paying the expense. In
the event that there's any changes within the fee structured the clients are
promptly educated. After the installment the installment subtle elements is
upgraded within the framework by the staffs. The over forms summarize
the installment of a client within the system.
45
8.2 Environmental Model Specification
The DFD could be a graphical representation of the stream of data

inside the framework. The DFD comprises of prepare, entities, data
stream, information store etc. By the assistance of DFD able to find out
the information provided by and conveyed to individuals who employments
the framework prepare and the data required in arrange to total the method
and the data required to be put away and accessed.
8.2.1 Context Level Diagram:
Figure 19: Payment of a customer 0 level DFD diagram
The over graph speaks to the setting level graph or 0 level

DFD for installment of a customer module. The graph comprises
of a prepare named Sound solid Music Organized and two entities
named Client and Staff. The client pays to Sound solid Music
Organized while Sound solid Music Organized gives client
installment subtle elements and the staff overhauls the
installment details.
46
8.3 Internal Model Specification:-
8.3.1 Level 1 DFD
Figure 20: Customer of a payment 1 level DFD diagram
The over chart appears the 1 level DFD chart of the

installment of the customer module. The chart is breakdown of
the Sound solid Music organized appeared within the setting level
diagram and representations prepare i.e. installment of a client.
The chart appears the data flows of the method installment i.e.
installment subtle elements, overhauled installment points of
interest and client details.
47
8.3.2 Level 2 DFD
Figure 21:Payment of a customer 2 level DFD diagram
The over chart speaks to the 2 level DFD for installment

of a customer module. The diagram speaks to the detail data of
the module. The client makes installment and the information are
put away in installment Information. The database installment
data gives installment details to the staff though the installment
subtle elements are overhauled by the staff and once more put
away on it. The receipt is made by the data of installment given
by installment information and the receipt points of interest are
given to customer.
48
8.4 Design Specification:-
8.4.1 Structure chart
The structure chart is gotten from the DFD graph. It breaks

down the complete framework into most reduced utilitarian
modules and portrays the capacities of the modules. The chart
represents the method in detail than DFD.
Figure 22: Structure chart of payment of a customer
The chart over speaks to the structure chart on the off chance that
module installment of a customer. Customer makes a installment though
staff checks the customer’s installment. When a customer makes
installment, they get receipt as an prove of installment. A staff can check
the customer’s installment and they can upgrade the points of interest of
installment on the off chance that needed.
49
8.4.2 Module Specification:-
Module name: Payment of a customer

Purpose: The module is related to installment made by the
client which bargains with the details of installment made by
client and the upgrade made by staff after they checks the
payment.
PSEUDOCODE:-
Start
Get customer’s id
Get customer’s info
Get payment details
IF paymentStatus of customer is unpaid
Make payment
Generate receipt
Else send message as already paid
Define updatePayment()
Get customer’s info
Get payment details
Update pament
END
Input Parameters: customer’s id, payment details
Output parameters: Receipt
Global variables: customerInfo
Local variables: customerId
Calls: paymentInfo(), customerDetails()
Called by: checkPayement()
50
8.5 Conclusion
This coursework was given to plan and investigation an application

named Sound solid Music organized and is a group coursework. For the
individual, I was doled out to plan and investigation a module named
payment of a customer. The module was a parcel of the framework that
accounts for the installment area of the framework. The planning segment
of the module was simpler for me since of the gather module we worked
on. Whereas planning the DFD I was able to know the boundaries of the
framework and able to form DFD and structure chart to supply a nitty gritty
representation of the framework that's reasonable by everyone. For the
bunch assignment, planning a framework by the thoughts and
considerations of every bunch part make it moderately more less
demanding than I anticipated. The most objective of our coursework was
not as it were to plan the framework but moreover work on a gather and
total the assignment on time. The coursework made a difference me and
by bunch part to know each other well and to work as a group.
Module: Generate Report

Name: Netra Bahadur Rana
Student ID: 19031004
9.1 Introduction
This module is about generating the customer details from various

other processes and put together as a report. The report includes every
detail of the customer from the time of registration to de-registration. The
generation of report is tasked to Staff. Only the staff has the privilege to
request the system for customer report. The staff has to keep updating the
report. Also, customers can view their report.
51
9.2 Environmental Model Specifications
9.2.1 Context Level
Figure 23: Context Level diagram of Report generation
The above illustrated context level diagram is for the report

generation. This is the highest level so it doesn’t explain in detail but we
can see the data flow between the process and external entities. We can
see that the customer is sending details and the staff is sending report
details in the database and the system sends it to the admin to view it.
52
9.3 Internal Model Specification for Generate Report
9.3.1 Level 1 Data Flow Diagram
Figure 24: level 1 DFD of Generate Report
This level 1 data flow diagram shows the report generation in a

more detailed way. The customer details are all arriving from different
data stores and a new data store ‘report’ is created which stores the
report details. And the admin also receives the report info.
53
9.3.2 Level 2 Data Flow Diagram
Figure 25: Level 2 DFD of Generate Report
The level 2 data flow diagram of report generation contains

1 more additional process than the level 1DFD. Instead of directly
receiving report details from the report generation process, the
admin now has an extra process ‘view report’ which receives the
report details from the report data store.
54
Figure 26: Structure chart of generate report
This is the structured chart for report generation. This

diagram shows the data flow and the process that occur as a
result. We can see that the details of customer are being
processed in generate report and then the report saves the data.
We can update or delete the report the updated report goes to the
Sound Strong database system.
55
9.4.2 Module Specification for generate report
Module name: Generate Report
Purpose: This module is used by the staff to generate report.

The report must contain the details of customer activities.
PSEUDOCODE:
START
CREATE Report
GET (customer details, payment details, booking

details, membership details)
PRINT (customer details+ payment details +

booking details + membership details)
CALL Report
View report details
STOP
Input parameters: customer details, payment details, booking

details, membership details
Output parameters: report details
Global variables: Customer ID
Local variables: customer, payment, booking, discount
Methods: report(), getCustomer(), getPayment(),

getMembership(), getBooking(), callReport()
56
9.5 Conclusion
The generate report module is carried out by the staff for the
organizations purpose. The system can keep track of the customers activity.
Since the system is online, customers can easily check their report status. The
staff keeps updating the report.
In conclusion, the context level, level 1,2 and the structure diagram has
helped me distinguish many things better than ever before. Especially after
doing the report generation module individually, I have learned a lot of things
in software engineering.
Model : De-registration of customer

Name : Bipin Gurung
Student ID : 19030839
10.1 Introduction to De-register of customer
This module is about de-registration of customer by the customer

of the Sound Strong music institute. In order to de-register, customer need
to follow the rules provided by the institute. At first, they have to submit the
application to the system and after the approval from the admin she/he is
deregistered. The staff verifies the report details and the command is
transferred to the data of the system. Hence, all of his/her data will be
permanently deleted from the system. In any case, if the customer is seen
inactive for a certain time, he/she will be automatically deregistered from
the system. If they still want to continue their register after the inactive
deregistered, they have to get permit from the authorized individual of the
institution. As soon as a customer request for deregistration, his/her details
are sent to the system and their data is removed.
57
10.2 Environmental model specification
10.2.1 Context Level Diagram
Figure 27: Context

level of De-register
customer
The above figure is referred to the Level 0 DFD to de-

register a customer. When the customer request to the system, it
approves the request and deregister the customer from the
system. After de-register of a customer his/her data will be
removed from the system. If the customer is inactive, the admin or
authorized automatically deregisters the customer.
58
10.3 Internal Model Specification
10.3.1 Level 1 DFD Fragment
Figure 28: Level 1 DFD of de-register customer
The above figure is level 1 DFD Fragment of Customer

Deregistration. For Deregistration, customer request to the system by
adding their details.
The admin sends the approval and the staff verifies report
deregistration details, after that it will automatically deregistered and all
the data related is deleted from the system. The customer should also
be active if not he/she will automatically deregistered.
59
10.3.2 Level 2 DFD
Figure 29: Level 2 DFD of de-register customer
In the above figure of level 2 DFD of Deregister customer,

customer appeals the system to deregister by adding their details. After
the admin’s approval, the staff verifies the report details and registration.
Customer is now deregistered and all of the data related to the customer
is removed from the data records.
60
Figure 30: Structure chart of de-register

customer
61
10.4.2 Module Specification
Module Name: De-register customer
Purpose: The main purpose of this module is to deregister a

customer from the system or data storage. When a customer
request to the system the admin approves the request and the
staff verifies the report. The command is send to the system and
all the data related to the customer must be deleted after de-
registration of the customer.
Pseudocode:
INPUT cust_id
Validate cust_id
IF cust_id is valid
READ report details
IF staff verifies the report details
THEN
Deregister customer
Delete customer details from the system
END IF
END IF
END
Input Parameters: cust_details
Output Parameters: cust_deregistration details
Global variable: cust_id
62
Local Variable: report verified details
CALLS: getCustomerdetails()
Called By: DeregisterCustomer()
10.5 Conclusion:
In this module, the creating of ‘Deregister customer’ is carried out.

The system keeps track of records of customer which updates the
institution record and make it balanced.
With the help of DFD (Data flow diagram and Structured Chart, we
can understand in more simpler and straight-forward way. In the end, we
have learned plenty about Software Designing.
All the task given improved not only our skills but also taught us
how to work in a group and being each other shoulder makes the work
more easier and saves more time.
63
11. Summary of the report:
This project consists of both group work and individual work. The group
work involves creating an online system for “Sound Strong Music Institute”
which can provide customer a better experience on online booking systems.
The project wanted us to create a Yourdon Structured design and data flow
diagram. We learned a lot from this group coursework. Specification is one of
the topics I, personally, find quite interesting.
The individual coursework also was able to peak the interest of our group
members. A lot of research and time invested on the group work really helped
in the individual tasks. Even though it was individual work, there was still
discussion going on between us members and that really speed up our
progress. All the individual tasks are combined and formed into a report along
with the group work.
I learned an important life lesson during this project. No matter how hard
the task is, if your companions are ready to invest time into it, it will be finished
in a blink of an eye. It was an amazing experience working as a group member
with these guys.
64
12. Bibliography
Alagar, V. & Periyasamy, K., 2011. Specification of Software Systems. 2nd ed. New
York: Springer.
Meador, D., 2018. What is Data Dictionary. [Online]

Available at: https://www.tutorialspoint.com/What-is-Data-Dictionary
[Accessed 3 12 2020].
Ofni systems, n.d.. Design Specification. [Online]

Available at: http://www.ofnisystems.com/services/validation/design-
specification/#:~:text=Compliance%20Blog-
,Design%20Specification,review%20of%20functions%20or%20code.
[Accessed 7 12 2020].
University of Calgary, 1997. CPSC 333: Process Specifications. [Online]

Available at:
http://pages.cpsc.ucalgary.ca/~eberly/Courses/CPSC333/Lectures/DFD/pspecs.html
[Accessed 10 12 2020].
65

A19 CS5002 NP 19031004 Netra Bahadur Rana CW1

Uploaded by

Copyright:

Available Formats

You might also like

A19 CS5002 NP 19031004 Netra Bahadur Rana CW1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A19 CS5002 NP 19031004 Netra Bahadur Rana CW1

Uploaded by

Copyright:

Available Formats

Informatics College Pokhara

Submitted By: Submitted To:

2. Environmental Model Specification ..................................................................... 2

2.1 Context Level Diagram (Level 0) ................................................................... 3

2.2 Level 1 Data Flow Diagram ........................................................................... 4

2.3 Level 2 Data Flow Diagram ........................................................................... 6

2.3.1 Level 2 DFD of Registration of Customer: .............................................. 6

2.3.2 Level 2 DFD of Booking .......................................................................... 7

2.3.3 Level 2 DFD of Payment......................................................................... 8

2.3.4 Level 2 DFD of de-registration ................................................................ 9

2.3.5 Level 2 DFD of repot generation ........................................................... 10

2.3.6 Level 2 DFD of notification.................................................................... 11

3. Internal model specification for the system ....................................................... 12

3.1 Entity-Relationship Diagram ........................................................................ 12

3.2 Data Dictionary............................................................................................ 14

3.3 Process Specification .................................................................................. 19

3.3.1 Staff registration ................................................................................... 20

3.3.2 Customer registration ........................................................................... 20

3.3.4 Membership .......................................................................................... 22

3.3.5 Payment ............................................................................................... 22

3.3.6 Notification ............................................................................................ 23

3.3.7 de-register customer ............................................................................. 24

3.3.8 De-register staff .................................................................................... 25

3.3.9 Report generation ................................................................................. 25

4.1 Structure Diagram ....................................................................................... 27

6. Individual Task 1 ............................................................................................... 33

6.1 Introduction to register a customer .............................................................. 33

6.2 Environmental Model Specification ............................................................. 33

6.3 Internal Model Specification ........................................................................ 34

6.3.1 ADFD Fragments .................................................................................. 34

6.3.2 Level 2 DFD of Customer Registration ................................................. 35

6.4 Design Specification .................................................................................... 37

6.4.1 Structured chart .................................................................................... 37

6.4.2 Module Specification ............................................................................ 38

6.5 Conclusion .................................................................................................. 39

7. Individual Task 2 ............................................................................................... 39

7.1 Introduction of Book practice room .............................................................. 39

7.2 Environmental model specification .............................................................. 40

7.3 Internal model specification ......................................................................... 41

7.3.1 Level 1 DFD Fragment ......................................................................... 41

7.3.2 Level 2 DFD.......................................................................................... 42

7.4 Design specification .................................................................................... 43

7.4.1 Structure Chart ..................................................................................... 43

7.4.2 Model specification (MSpecs) ............................................................... 44

7.5 Conclusion .................................................................................................. 45

8. Individual Task 3 ............................................................................................... 45

8.1 Introduction to payment of a Customer: ...................................................... 45

8.2 Environmental Model Specification ............................................................. 46

8.2.1 Context Level Diagram: ........................................................................ 46

8.3.1 Level 1 DFD.......................................................................................... 47

8.3.2 Level 2 DFD.......................................................................................... 48

8.4 Design Specification:- ................................................................................. 49

8.4.1 Structure chart ...................................................................................... 49

8.4.2 Module Specification:- .......................................................................... 50

8.5 Conclusion .................................................................................................. 51

9. Individual Task 4 ............................................................................................... 51

9.1 Introduction ................................................................................................. 51

9.2 Environmental Model Specifications ........................................................... 52