Module Code & Module Title
CS5002NI Software Engineering
Assessment Weightage & Type
20% Group Coursework
SN
Student Name
College ID
University ID
1
Aastha khatri
NP01CP4A190182
19030680
2
Avash Bhandari
NP01CP4S210284
20049392
3
Sampanna Pokharel
NP01CP4S210270
20049419
4
Sandesh Bhurtyal
NP01CP4S210300
20049019
Umesh Shahu Shrestha NP01CP4S210288
20049086
5
I confirm that I understand my coursework needs to be submitted online via Google Classroom under the
relevant module page before the deadline in order for my assignment to be accepted and marked. I am
fully aware that late submissions will be treated as non-submission and a marks of zero will be awarded.
1
Acknowledgement
We would like to express our gratitude towards Mr. Rubin Thapa, Tutor of Software
Engineering module system for his assessment and valuable feedbacks and suggestions
regarding the project along with his dedication and supervision for the coursework is
completed. We also, would like to thank all our friends, teachers and family who helped
us along with providing us the continuous support and positivity. We would also like to
thank Islington College for providing necessary resources for the continuous progress of
this coursework and providing us proper guidance for the completion of the coursework.
i
Table of Contents
Acknowledgement ............................................................................................................ i
1. Introduction ................................................................................................................. 1
2. Project Charter ............................................................................................................ 2
2.1 Problem Statement ................................................................................................ 2
2.2 Business Case ....................................................................................................... 2
2.3 Goal Statement ...................................................................................................... 3
2.4 Timeline ................................................................................................................. 3
2.5 Scope .................................................................................................................... 3
2.5 Team Members...................................................................................................... 4
3. Software Requirement Specification (SRS) ................................................................. 5
3.1 Functional Requirements ....................................................................................... 5
3.2 Non-Functional Requirements ............................................................................... 9
4. Group Tasks .............................................................................................................. 10
4.1 Environmental Model Specification ...................................................................... 10
4.1.1 Context Diagram ........................................................................................... 10
4.2 Internal Model Specification ................................................................................. 11
4.2.1 Level 1 Data Flow Diagram ........................................................................... 11
4.2.2 Level 2 Data Flow Diagram ........................................................................... 12
4.2.3 Entity Relationship Diagram .......................................................................... 15
4.2.4 Data Dictionary.............................................................................................. 18
4.2.4 Process Specification .................................................................................... 23
4.3 Design Specification ............................................................................................ 28
4.5 Assignment Diary................................................................................................. 29
4.5.1 Assumptions.................................................................................................. 29
4.5.2 Group Member Responsibilities .................................................................... 32
4.5.3 Meeting Minute (Group Meetings) ................................................................. 34
5. Individual Task .......................................................................................................... 40
5.1 Register Membership – Aastha Khatri ................................................................. 40
5.2 Enroll Staff Members – Umesh Shahu Shrestha ................................................. 44
Environmental model Specification ............................................................................ 44
Context level diagram ............................................................................................ 44
Internal Module Specification ..................................................................................... 45
Level 1 Data flow Diagram ..................................................................................... 45
Level 2 Data Flow Diagram .................................................................................... 46
Design Specification .................................................................................................. 47
Structure Diagram .................................................................................................. 47
Module specs ......................................................................................................... 48
5.3 Purchase Football Kits – Avash Bhandari ............................................................ 50
5.4 Report Preparation – Sampanna Pokharel .......................................................... 54
5.4.1 Environmental Model Specification ............................................................... 54
5.4.2 Internal Model Specification .......................................................................... 55
5.4.3 Design Specification ...................................................................................... 57
5.5 Take Mock Exam – Sandesh Bhurtyal ................................................................. 61
Introduction ................................................................................................................ 61
Environmental Model Specification ............................................................................ 62
Context Diagram .................................................................................................... 62
Internal model specification for the system ................................................................ 64
The Level 1 DFD fragments ................................................................................... 64
Level 2 DFDs for the particular function ................................................................. 66
Design Specification .................................................................................................. 68
Structure chart for the Take Mock Exam function. ................................................. 68
Module specifications (MSpecs) for Taking Mock Exam modules.......................... 71
Conclusion ................................................................................................................. 73
6. Summary ................................................................................................................... 74
2. References ................................................................................................................ 76
Table of Figures
Figure 1 : Context Level Diagram .................................................................................. 10
Figure 2 : Level 1 DFD .................................................................................................. 11
Figure 3 : Level 2 DFD for Register Member ................................................................. 12
Figure 4 : Level 2 DFD for Take Exam .......................................................................... 13
Figure 5 : DFD for Create Report .................................................................................. 14
Figure 6 : Entity Relationship Diagram .......................................................................... 17
Figure 7 : Context Diagram for Register membership ................................................... 40
Figure 8 : Level 1 DFD for register member .................................................................. 41
Figure 9 : Level 2 DFD for register member .................................................................. 41
Figure 10 : Structure Chart for register Member ............................................................ 42
Figure 11 : Context level diagram for enroll staff members ........................................... 44
Figure 12 : Level 1 DFD for enroll staff members .......................................................... 45
Figure 13 : Level 2 DFD for enroll staff members .......................................................... 46
Figure 14 : Structure chart for enroll staff members ...................................................... 47
Figure 15 : Context diagram for purchase Football Kits ................................................ 50
Figure 16 : Level 1 DFD for purchase football kits ........................................................ 51
Figure 17 : Level 2 DFD for purchase Football Kits ....................................................... 51
Figure 18 : Structure chart of purchase products .......................................................... 52
Figure 19 : Context Diagram of Report Preparation ...................................................... 54
Figure 20 : Level 1 DFD of Report Preparation ............................................................. 55
Figure 21 : Level 2 DFD of Report Preparation ............................................................. 56
Figure 22 : Structure chart of Report Generation .......................................................... 57
Figure 23: DFD Components ........................................................................................ 62
Figure 24: Context Diagram of Taking Exam ................................................................ 63
Figure 25: Level 1 DFD to Take Mock Exam................................................................. 65
Figure 26: DFD Level 2 of Taking Mock Exam .............................................................. 66
Figure 27: Structure Chart of Taking Mock Exam ......................................................... 69
Table of Table
Table 1 : Functional Requirements - Functions and Sub Functions ................................ 8
CS5002NI
Software Engineering
1. Introduction
This is a group coursework involving five students that assume the role of a project team.
In this coursework, we are to analyze and model the requirements for the business of T14. T-14 is a training academy founded by group of retired national football athletes. The
business offers different levels of trainings for its members and along with it, sells football
accessories and kits at a lower price than the market. The business was previously
operating based on an offline model and were running at a loss. With hopes of making
this business profitable, the company board wanted to switch to an online model. Our
project team which is composed of five members have taken the responsibility of
designing an online system for the business of T-14.
To solve the problems faced by T-14, our team decided that it would be suitable to design
for a web based system for the business. With this, the members (students) would then
be able to register, take exams (written and mock), view results and reports, make
purchases from the store, receive announcements, remotely without having to be
physically present in the academy. Likewise, the authorized staff members would then be
able to enroll, design and create test papers (written and mock), grade test papers, create
reports. Finally, the system administrator would be able to make announcements, publish
results, publish reports, manage staffs, members, and store.
The Objectives of this coursework are as follows:
•
To Demonstrate practical knowledge of Structured Software Engineering using
Yourdon approach.
•
To successfully work on a small group of people with limitations of time.
19030680
20049392
20049419
20049019
20049086
1
Project Charter is expected to be short and
to the point.
CS5002NI
Software Engineering
Some numericals/quantifiable facts though assumed
2. Project Charter can be seen(in problems and goals). A clear business
case defining motive. Could have been better with
scope. So 4 out of a 5 seems reasonable.
A project charter is a short document which explains the project in clear and concise
4
language. It can also be said that a project charter marks the beginning and existence of
a project. Project charters lay out the entire project so that the teams working on it can
grasp the objectives, aims, tasks, timelines, and stakeholders. It is generally divided into
six components, and they are – Problem Statement, Business case, Timeline, Scope,
Team Members (Project-Management, 2021).
The project charter for T-14’s project is as follows:
2.1 Problem Statement
One of the major problems faced by T-14 academy is that it has been lacking behind in
the competitive market of training academies. This has led to a 40% decline in yearly
revenue because of decreasing player enrolments. The business is currently running at
a 3% loss.
2.2 Business Case
The motive behind the project is to attract more players to the training institute of T14.
The increase in enrolment rate will make the business generate more revenue which will
lead to higher profits.
19030680
20049392
20049419
20049019
20049086
2
CS5002NI
Software Engineering
2.3 Goal Statement
The goal for the project is to increase the enrollment rate to 30% and increase the profit
margin by 1%. This goal is to be achieved within the next season.
2.4 Timeline
The project is estimated to last for five months, the first 10 days of which will be allocated
for requirement gathering. In the next twenty days, the team will be working on building a
design for the system. Following that, the development team will work on implementing
the system for the next three months. At last, the testing and development will be
completed in the remaining twenty days.
2.5 Scope
The scope in terms of project perspective is requirement engineering, system design,
system concept development, implementation of the system, and finally testing. Similarly,
in regard to product perspective, the scope of the project is user management module,
staff management module, report preparation module, examination module, payment
module.
19030680
20049392
20049419
20049019
20049086
3
CS5002NI
Software Engineering
2.5 Team Members
London MetID
Team Members
Role
19030680
Aastha Khatri
QA & Tester
20049392
Avash Bhandari
Developer
20049419
Sampanna Pokharel
Project Manager
20049019
Sandesh Bhurtyal
Developer
20049086
Umesh Shahu Shrestha
Designer
19030680
20049392
20049419
20049019
20049086
4
Has enough numbers and relevant functional requirements but non-functional requirements fails to cover the parameters as
suggested in the question though there are few done by students. Not using a template(IEEE or any) should not be a matter of
marks deduction but the components as suggested in question has to be addressed in some ways
CS5002NI
Software Engineering
3. Software Requirement Specification (SRS)
6
Software Requirement Specification, also known as SRS, is a specification document for
a product (software, application, websites) that describes how the system is expected to
function/work. It consists of requirements for the software including but not limited to
functional, non-functional, operational, performance. SRS document serves as a formal
report or a contract of agreement between client and the project team. It is generally
written by a technical writer, system architect/analyst or developer (javatpoint, 2020).
For this project, we created SRS document focusing on three sections and they are as
follows
3.1 Functional Requirements
The functional requirements for the system are as follows
ID
Functions and sub
Description
Functions
1
Register Member
1.1
Verify Member
Information
1.2
Verify Payment
User should be able to register as a member.
System should verify and check if a user has already been
registered with given details.
System needs to verify whether the user has paid
appropriate registration fee before proceeding.
19030680
20049392
20049419
20049019
20049086
5
CS5002NI
1.3
Software Engineering
Generate Member
A report needs to be generated at the end of member
Registration Report
registration with information about payment, member details,
registration date, membership expiry date
2
Staff Enrollment
System Admin should be able to add newly appointed staff
to the system.
2.1
Verify Staff Details
System should verify and check if a staff has already been
registered with given details.
2.2
3
Generate Staff
A report needs to be generated at the end of staff enrollment
Enrollment Report
process with information about staff details, registration date
Purchase and Payment
Members can purchase items from the store and pay for
them through system.
3.1
Add Items To Cart
Members can select multiple items that they want to
purchase and add in a cart.
3.2
Payment Gateway
Members have an option to pay either from eSewa or Khalti
4
Design and Test Paper
Staffs should be able to design and create test papers for
mock tests and written tests in the system.
5
Create Report
Staffs should be able to create reports of members based on
their score on physical test, written test, overall performance.
19030680
20049392
20049419
20049019
20049086
6
CS5002NI
5.1
Software Engineering
Check Eligibility
Based on given inputs of test results system should perform
some calculations and indicate whether a member is eligible
to join intermediate training or not.
5.2
Generate Report
At the end, the system should generate overall report and
display it to the user.
6
Take Exam
Members should be able to choose and take exams online.
6.1
Take Mock Exam
Members should be able to give mock exams for
intermediate training.
6.2
Take Written
Intermediate Exam
6.3
Check Answers
Members should be able to give written exams for
intermediate training.
Exams given by members should be checked and assigned
a grade accordingly.
7
Make Announcements
System admin should be able to post announcements
regarding notices, exam and mock test results, and member
report.
7.1
Publish Notices
7.2
Publish Exam Results
System admin should be able to publish notices
System admin should be able to publish results of mock test
and exams
7.3
Publish Member Reports
System admin should be able to publish reports of members
created by staffs
19030680
20049392
20049419
20049019
20049086
7
CS5002NI
8
Software Engineering
Manage Members
System Admin should be able to add/update/delete record of
members
9
Manage Staffs
System Admin should be able to add/update/delete record of
staffs
10
Manage Products
System Admin should be able to add/update/delete record of
products
11
View Records
System Admin should be able to records of members, staffs,
store, and payments
Table 1 : Functional Requirements - Functions and Sub Functions
19030680
20049392
20049419
20049019
20049086
8
CS5002NI
Software Engineering
3.2 Non-Functional Requirements
Non-functional Requirements (NFRs) define system attributes such as security, reliability,
performance, maintainability, scalability, and usability. They act as limits or limitations on
the system's architecture across the various backlogs. Failure to meet any one of these
can result in systems that don't meet internal business, user, or market needs, or that
don't meet regulatory or standards agency criteria. Noncompliance can result in serious
legal consequences in various circumstances (privacy, security, safety, to name a few).
Types of Non-Functional Requirement
•
Scalability
•
Reliability
•
Availability
•
Security
•
Data Integrity
Some of the major Non-Functional Requirements:
•
Members must change the initially assigned login password immediately after the
first successful login.
•
Staffs are never allowed to manage the store. Such attempt should be reported to
the security administrator.
•
The academy website should be capable enough to handle 1000 users without
affecting its performance.
•
The software should be portable. So moving from one operating system to other
operating system does not create any problem.
•
Privacy of information should be maintained by the training academy.
19030680
20049392
20049419
20049019
20049086
9
CS5002NI
Software Engineering
4. Group Tasks
4.1 Environmental Model Specification
4.1.1 Context Diagram
Checking should be done if there is a sensible assumption of external entities to fulfil the needs of the system and
arrow direction is proper in terms of input/output.
6
Figure 1 : Context Level Diagram
19030680
20049392
20049419
20049019
20049086
10
CS5002NI
Software Engineering
4.2 Internal Model Specification
4.2.1 Level 1 Data Flow Diagram
Checking should be done whether the level 1 DFD represents the whole functional requirements, whether basic DFD rules are
followed or not , whether flows are logical and attempt to balancing(level1-----> level 2) has been done or not. Also there
should be significant number of decomposition bubbles(3-4 suggested) in level 2
8
Figure 2 : Level 1 DFD
19030680
20049392
20049419
20049019
20049086
11
CS5002NI
Software Engineering
4.2.2 Level 2 Data Flow Diagram
Level 2 Data Flow Diagram for 1. Register Member
Figure 3 : Level 2 DFD for Register Member
19030680
20049392
20049419
20049019
20049086
12
CS5002NI
Software Engineering
Level 2 Data Flow Diagram for 6. Take Exam
Figure 4 : Level 2 DFD for Take Exam
19030680
20049392
20049419
20049019
20049086
13
CS5002NI
Software Engineering
Level 2 Data Flow Diagram for 5. Create Report
Figure 5 : DFD for Create Report
19030680
20049392
20049419
20049019
20049086
14
CS5002NI
Software Engineering
4.2.3 Entity Relationship Diagram
Checking should be done whether the right entities for data modelling has been figured out or not and multiplicities,
entity-attributes are proper or not.
An Entity Relationship Diagram or an ERD is a kind of a flowchart which shows how realworld entities such as people, objects or concepts interact with one another within a
system. ER diagrams are often used to design relational databases in fields of Software
Engineering, Information System and so on (Lucidchart, 2021). An ER diagram is
composed of the following components:
•
Entity – An entity in simple terms can be considered as a noun, which can be a
person, place, or an object. Generally, Entities are represented by a rectangle
•
Attribute – Attributes are the properties or characteristics of an entity. Attributes
help define entity and their behaviour. Generally, Attributes are represented by an
oval.
•
Relationship – Relationships help define how entities interact with each other.
Relationships can also be thought off as verbs. Generally, relationships are
represented by a diamond shape.
From studying the scenario and data flow diagrams above, we have identified the
following objects as relevant entities – Members, Staffs, Products, Member_Reports,
Payments, Test_Papers, and Exams. The entity along with their attributes are as follows:
Members
–
member_ID,
member_Name,
member_Contact,
member_Address,
training_Type, member_JoinDate, member_RegisterExpireDate
Staffs
–
staff_ID,
staff_Name,
staffContact,
staff_Address,
staff_Department,
staff_Salary
19030680
20049392
20049419
20049019
20049086
15
CS5002NI
Software Engineering
Products – product_ID, product_Name, product_Description, product_Type, unit_Price
Member_Reports
–
report_ID,
staff_ID(FK),
member_ID(FK),
member_Name,
grade_Written, grade_Physical, grade_Overall, eligibility_Status, remarks
Payments – payment_ID, member_ID(FK), product_ID(FK), order_items, order_total,
payment_Type
Test_Papers
–
test_ID,
staff_ID(FK),
test_Type,
test_Marks,
test_Question,
test_Answer, test_Materials
Exams – exam_ID, test_ID(FK), member_ID(FK), exam_Score
19030680
20049392
20049419
20049019
20049086
16
CS5002NI
Software Engineering
7
Figure 6 : Entity Relationship Diagram
19030680
20049392
20049419
20049019
20049086
17
CS5002NI
Software Engineering
4.2.4 Data Dictionary
Checking whether there is a definition for major data flows, data store and whether there is an attempt to show all the
notations of data dictionary whenever necessary.
Data Dictionary for the whole system is as follows:
4
Members = member details + member records *DATA STORE*
Member records = {member details} *
Member details = member_ID + member_Name + member_Contact + member_Address
+ training_Type
Member_ID = String
Member_Name = String
Member_Contact = Big Integer
Member_Address = String
Training_Type = String
Payment = payment details + payment records *DATA STORE*
Payment records = {payment details} *
Payment details = payment_ID + member_ID + product_ID + order_Items +
payment_Type + payment_Total
Payment_ID = String
Member_ID = String
Product_ID = String
Order_Items = {product_ID} *
Payment_Type = String
19030680
20049392
20049419
20049019
20049086
18
CS5002NI
Software Engineering
Payment_Total = Float
Product = product details + product records *DATA STORE*
Product records = {product details} *
Product details = product_ID + product_Name + product_Description + product_Type +
unit_Price
Product_ID = String
Product_Name = String
Product_Description = String
Product_Type = String
Unit_Price = Float
Test Paper = test_Details + test_Paper_Records *DATA STORE*
Test_Paper_Records = {test_Paper_Details} *
Test_Paper_Details/Test_Details = test_ID + staff_ID + test_Type + test_Marks +
test_Questions + test_answers + test_Materials
Test_Id = String
Staff_ID = String
Test_Type = String
Test_Marks = Integer
Test_Questions = ArrayList<String>
Test_Answers = ArrayList<String>
Test_Materials = BLOB
19030680
20049392
20049419
20049019
20049086
19
CS5002NI
Software Engineering
Exam Results = exam details + exam records *DATA STORE*
Exam records = {exam details} *
Exam details = exam_ID + test_ID + member_ID + exam_Score
Exam_ID = String
Test_ID = String
Member_ID = String
Exam_Score = Integer
Member Report = Report details + Report records *DATA STORE*
Report Records = {Report details} *
Report details = report_ID + member_ID + staffID + member_ID + member_Name +
grade_Written + grade_Physical + eligibility_Status + Remarks
Report_ID = String
Grade_Written = Integer
Grade_Physical = Integer
Eligibility_Status = [“True”, “False”]
Staffs = staff details + staff records *DATA STORE*
Staff records = {staff details} *
Staff_Details = staff_ID + staff_Name + staff_Contact + staff_Address + staff_Department
+ staff_Salary
Staff_ID = String
19030680
20049392
20049419
20049019
20049086
20
CS5002NI
Software Engineering
Staff_Name = String
Staff_Contact = Big Integer
Staff_Address = String
Staff_Department = String
Staff_Salary = Float
Member Register = command
Registration Status = [“Registration Successful”, “Registration Failed“]
Enrol Staff = command
Enrolment Status = [“Enrolment Successful”, “Enrolment Failed”]
Make Purchase = command
Payment Invoice = payment_ID + product_ID + payment_Type + payment_Total +
System.CurrentDate as “ORDER DATE”
Product Price = unit_Price
Design Test = command
Generate Report = command
Member ID = member_ID
Member Name = member_Name
Give Exam = command
Test ID = test_ID
Exam Results = exam_ID + test_ID + member_ID + exam_Score
Make Announcement = command
Announcement = announcement message + announcement type
19030680
20049392
20049419
20049019
20049086
21
CS5002NI
Software Engineering
Announcement message = String
Announcement type = A_notification + [A_result, A_report]
A_notification = String
A_Result = Char
A_Report = Char
Update/Delete Member = command
Update/Delete Staff = command
Staff ID = staff_ID
Manage Product = command
Product ID = product_ID
View Request = command
19030680
20049392
20049419
20049019
20049086
22
CS5002NI
Software Engineering
5
4.2.4 Process Specification
Normally students score full in this section and generally follow this format of
narrative text for Process-spec(for 5 bubbles encouraged). But use of other
formats is also not a matter of problem as long as it makes sense and can act a
mini-spec.
Process A
Number: 6.1
Title: Verify Test Paper
Description: This process checks whether the test that user (Member) wants to take exists
in database or not.
Input Data Flow: Give Exam + Test ID (From input) + Test ID (From Database)
Output Data Flow: Test Paper Verification (Boolean)
Process Logic: The logic for this process is as follows
a. Get Test ID input from user
b. Search for user provided Test ID in database.
c. If Test ID matches, set Test Paper Verification to True, else False
d. Forward Test Paper Verification to process 6.2
19030680
20049392
20049419
20049019
20049086
23
CS5002NI
Software Engineering
Process B
Number: 5.3
Title: Calculate Eligibility
Description: This process checks whether the user is eligible for intermediate level
training or not.
Input Data Flow: Report Information
Output Data Flow: Report Information + Eligibility Status
Process Logic: The logic for this process is as follows
a. Get Report Information from process 5.2
b. From report information, calculate overall marks
c. If overall marks > 60, set Eligibility Status to true, else False
d. Forward Report Information and Eligibility Status to process 5.4
19030680
20049392
20049419
20049019
20049086
24
CS5002NI
Software Engineering
Process C
Number: 5.4
Title: Compile Report
Description: This process compiles/generates report for member based on given
information provided by previous processes
Input Data Flow: Report Information, Eligibility Status
Output Data Flow: Report Details
Process Logic: The logic for this process is as follows
a. Get Report Information and Eligibility Status from process 5.3
b. Stich together all the data from/of Report Information and Eligibility Status
c. Store the compiled report (Report Details) in Member Report database
19030680
20049392
20049419
20049019
20049086
25
CS5002NI
Software Engineering
Process D
Number: 1.2
Title: Verify Payment
Description: This process checks whether the user has made payment necessary for
registration or not.
Input Data Flow: Payment Details, Member Information
Output Data Flow: Member Information, Register Status
Process Logic: The logic for this process is as follows
a. Get Member Information from process 1.1
b. Using data of Member_ID, which is in Member Information, get payment
details of that particular member ID from the database Payment Details
c. If the member_ID of member Information and payment Details matches and
order_items = “Membership”, then set Register Status to true, else False
d. Display the value of Register Status to user
e. Forward Member Information to process 1.3
19030680
20049392
20049419
20049019
20049086
26
CS5002NI
Software Engineering
Process E
Number: 1.3
Title: Generate Member ID
Description: This process generates a unique identification data (ID) for users.
Input Data Flow: Member Information
Output Data Flow: Member Information, Member ID
Process Logic: The logic for this process is as follows
a. Get Member Information from process 1.2
b. Generate a unique identification data (ID) for current user.
c. Check whether the generated ID already exists or not, if it exists, repeat
logic b, else proceed to d.
d. Forward Member Information and newly generated Member ID to process
1.4
19030680
20049392
20049419
20049019
20049086
27
CS5002NI
Software Engineering
4.3 Design Specification
Structure Chart
Check should be done whether top-down alignment of modules is done or
not and how sub-modules are arranged . The use of all notations(loop,
selection, and others) of structure chart should be used wherever
necessary and has to be checked whether that has been used at least once
in group portion.
3
19030680
20049392
20049419
20049019
20049086
28
CS5002NI
Software Engineering
4.5 Assignment Diary
Checking whether there are sensible assumptions to balance the flow and tackle inconsistencies by the students.
Whether there is significant number of meeting minutes and have a reasonable amount of work distributed among them
during group-work.
4.5.1 Assumptions
8
The T-14 Training Academy's provided specifications are reviewed and worked on in
order to design a system that meets the requirements. To enhance the logic and design
of the system, just a few assumptions are made during the design phase. The following
are the assumptions made by the group members for the design of T-14 Training
Academy:
The assumptions for database to store system data:
Member Record: This database stores all the personal details of the
members in the training academy.
Staff Record: This database stores all the details of the staff working in
the training academy.
Payment Record: This database stores all the payments done by
members while buying the football kits and
accessories.
Store Record: This database stores the details of the products that is
stored in the academy shop.
19030680
20049392
20049419
20049019
20049086
29
CS5002NI
Software Engineering
Test Paper Record: This database stores the details of all the test papers created for the
examination of the players.
Exam Result Record: This database stores the record of the player test result.
Member Report Record: This database stores the overall performance report of the
members of the training academy.
The requirements gathered by the team from the submitted specification, on which the
above assumptions are based, are as follows:
- Maintain record of all the members and staff.
- Member must register to join the training academy.
- Payment should be done while registering for the membership.
- Member Details
Full name of member
Date of birth
Location
Age group
Date of registration
Payment type
- Staff design the test paper for the examination.
- Staff generates report of the members.
- Staff manages teams in the training academy.
19030680
20049392
20049419
20049019
20049086
30
CS5002NI
Software Engineering
- Admin manages the store of the academy.
- Admin announces notice and publish the result of the members.
- Members can purchase the football kits and accessories in the store.
- Member can appear for the mock examination.
- Admin can view the record of members in the academy.
- Staff can register itself in the academy.
- For process except register and enrol, user is logged in.
19030680
20049392
20049419
20049019
20049086
31
CS5002NI
Software Engineering
4.5.2 Group Member Responsibilities
While working on the system's design, each group member actively collaborated.
Members of the group assisted one another in reviewing their specific tasks, and there
were also talks and exchanges concerning the entire system so that each group member
understood the systems complete workflow. Individual group members have the following
responsibilities:
19030680
20049392
20049419
20049019
20049086
32
CS5002NI
Software Engineering
Group Member
Responsibilities
Avash Bhandari
•
Work on individual task for Registration of member.
•
Work on Entity Relationship Diagram.
•
Design the Entity Relationship diagram.
•
Contributed to assumptions part of the report.
Umesh Shahu Shrestha •
•
•
Work on individual task for Enrol Staff Members.
Work on Module Specification.
Mock of the designs of DFD level 0 and level 2 of the whole
system.
Aastha Khatri
•
Contributed to edit few things of the report documentation.
•
Work on individual task for Purchase football kits.
•
Work on Data Flow Diagram.
•
Make the design of DFD level 0 of the whole system.
•
Contributed
to
summary
portion
of
the
report
documentation.
Sandesh Bhurtyal
•
Work on individual task for Take a mock exam.
•
Work on Structure Chart
•
Contributed to level 0, 1 DFD
•
Make the design of Structure Chart of the whole systems.
•
Contributed to the assignment diary portion of the report.
•
Contributed
to
summary
portion
of
the
report
documentation.
Sampanna Pokharel
•
Work on individual task for Report Preperation.
•
Worked on level 1, level 2 DFD
•
Worked on Data Dictionary.
•
Worked on Process Specification.
•
Worked
on
Introduction
portion
of
the
report
documentation.
•
19030680
20049392
Monitor the work progress and re-align the project on track.
20049419
20049019
20049086
33
CS5002NI
Software Engineering
•
Provide direction, instructions and guidance to team
members.
4.5.3 Meeting Minute (Group Meetings)
Meeting 1:
19030680
20049392
20049419
20049019
20049086
34
CS5002NI
19030680
Software Engineering
20049392
20049419
20049019
20049086
35
CS5002NI
Software Engineering
Meeting 2:
19030680
20049392
20049419
20049019
20049086
36
CS5002NI
Software Engineering
Meeting 3:
19030680
20049392
20049419
20049019
20049086
37
CS5002NI
Software Engineering
Meeting 4:
19030680
20049392
20049419
20049019
20049086
38
CS5002NI
Software Engineering
Meeting 5:
19030680
20049392
20049419
20049019
20049086
39
CS5002NI
Software Engineering
5. Individual Task
5.1 Register Membership – Aastha Khatri
a) Environmental Model Specification
Context Level Diagram
Figure 7 : Context Diagram for Register membership
19030680
20049392
20049419
20049019
4
20049086
40
CS5002NI
Software Engineering
b) Internal Model Specification
Data Flow Diagram Level 1
Figure 8 : Level 1 DFD for register member
Note: No Descriptions of diagrams can be seen.
Data Flow Diagram Level 2
numberings missing that creates problem
for understanding the decompostion but
decent amount of bubbles while
decompostion.
8
Figure 9 : Level 2 DFD for register member
19030680
20049392
20049419
20049019
20049086
41
CS5002NI
Software Engineering
c) Design Specification
Structure Chart
3
Figure 10 : Structure Chart for register Member
19030680
20049392
20049419
20049019
20049086
42
CS5002NI
Software Engineering
Module Specs
MODULE NAME: Register Member
PURPOSE: This module obtains member details and add these data to member record
database.
PSEUDOCODE:
Checking if the module description is enough and
logical(pseudocode definition should be sensible)
and every components have been properly
addressed.
FUNCTION
DO
var Member_Name = INPUT (“Enter Your Name”)
var Age_Group = INPUT (“Enter Your Age”)
8
var Address = INPUT(“Enter Your Address”)
var Phone_Number = INPUT(“Enter Your Number”)
var Date_Of_Registration = INPUT(“Enter Date Of Registration”)
var Payment_Type = INPUT(“Enter Payment Type”)
IF (Payment_Verify = “Success”) THEN
Var Member_ID = Database.Member_Record (Member_Details)
END IF
Print (“Registration Complete”)
Print (“Member ID”)
END DO
INPUT PARAMETERS: Member_Details
OUTPUT PARAMETERS: Member_ID, Registration_Complete
GLOBAL VARIABLES: Database
CALLS: Get Member Details, Get Payment Details, Verify Payment, Generate Member
ID
CALLED BY: Main
19030680
20049392
20049419
20049019
20049086
43
CS5002NI
Software Engineering
5.2 Enroll Staff Members – Umesh Shahu Shrestha
Environmental model Specification
Context level diagram
4
Figure 11 : Context level diagram for enroll staff members
19030680
20049392
20049419
20049019
20049086
44
CS5002NI
Software Engineering
Internal Module Specification
Level 1 Data flow Diagram
7
Figure 12 : Level 1 DFD for enroll staff members
19030680
20049392
20049419
20049019
20049086
45
CS5002NI
Software Engineering
Level 2 Data Flow Diagram
Figure 13 : Level 2 DFD for enroll staff members
19030680
20049392
20049419
20049019
20049086
46
CS5002NI
Software Engineering
Design Specification
Structure Diagram
3
Figure 14 : Structure chart for enroll staff members
19030680
20049392
20049419
20049019
20049086
47
CS5002NI
Software Engineering
Module specs
MODULE NAME: Enroll Staff Members
PURPOSE: This module obtains enrolls staff’s members, add qualified enrolls staff to the
staff database and the management of staff database respectively.
8
PSEUDOCODE:
var first_name = input(“Enter First Name of Staff”)
var last_name = input(“Enter Last Name of Staff”)
var DOEnroll = input(“Enter Date of Enroll Staff”)
var address = input(“Enter address of Staff ”)
DO
IF(validate(first_name, last_name, DOEnroll, address)) THEN
var EnrollID = DB.Staff_Records(first_name, last_name, DOEnroll,
address)
DO
IF((Requirement(Staff)) = (Qualification (EnrollID))) THEN
DISPLAY (“Enroll Successful”)
DISPLAY(“StaffID”+StaffID)
END DO
END DO
INPUT PARAMETERS: EnrollStaff_list
OUTPUT PARAMENTERS: Staff_ID
19030680
20049392
20049419
20049019
20049086
48
CS5002NI
Software Engineering
GLOBAL VARIABLES: DB(Database)
LOCAL VARIABLES: EnrollID, date
CALLS: validate data, requirement data, staff records, Display staff status
CALLED BY: Main
19030680
20049392
20049419
20049019
20049086
49
CS5002NI
Software Engineering
5.3 Purchase Football Kits – Avash Bhandari
a) Environmental Model Specification
Context Level Diagram
4
Figure 15 : Context diagram for purchase Football Kits
19030680
20049392
20049419
20049019
20049086
50
CS5002NI
Software Engineering
b) Internal Model Specification
Data Flow Diagram Level 1
Figure 16 : Level 1 DFD for purchase football kits
Data Flow Diagram Level 2
7
Figure 17 : Level 2 DFD for purchase Football Kits
19030680
20049392
20049419
20049019
20049086
51
CS5002NI
Software Engineering
c) Design Specification
Structure Chart
3
Figure 18 : Structure chart of purchase products
19030680
20049392
20049419
20049019
20049086
52
CS5002NI
Software Engineering
Module Specs
MODULE NAME: Purchase Football Kits
PURPOSE: This module obtains the details of the product purchased and payment
details. The payment details are added to the database of payment record.
PSEUDOCODE:
FUNCTION
DO
var Product_Details = INPUT (“Enter Products You Want To Buy”)
8
var Payment_Amount = INPUT (“Enter Total Amount”)
var Payment_Type = INPUT (“Enter Payment Type”)
IF (Payment_Verify = “Success”) THEN
Var Payment_Envoice = Database.Payment_Record (Payment_Details)
END IF
Print (“Payment Success”)
Print (“Payment Envoice”)
END DO
INPUT PARAMETERS: Product_Details, Payment_Details
OUTPUT PARAMETERS: Payment_Envoice
GLOBAL VARIABLES: Database
CALLS: Get Product Details, Get Payment Details, Validate Product, Verify Payment,
Generate Envoice
CALLED BY: Main
19030680
20049392
20049419
20049019
20049086
53
CS5002NI
Software Engineering
5.4 Report Preparation – Sampanna Pokharel
Note: Description for diagrams can be seen . 5 for description
As per client requirement, we have designed a feature for creating a member report based
on their performance on written and physical test. This portion of the report contains
design details of this portion of the system. We design the inner workings for report
generation module and look into its workings in detail.
5.4.1 Environmental Model Specification
Context Diagram
3
Figure 19 : Context Diagram of Report Preparation
This is the context diagram for the module of report generation. Here we can see that a
single command of create Report is given to the system. The result of this module is
utilized by the user – Admin, who can publish this report.
19030680
20049392
20049419
20049019
20049086
54
CS5002NI
Software Engineering
5.4.2 Internal Model Specification
Level 1 Data Flow Diagram
Figure 20 : Level 1 DFD of Report Preparation
This is the level 1 DFD for our module of generate report. In this diagram, we can look at
the process in detail and see entities, processes, and data stores that it interacts with.
Along with that, we can also see the flow of data.
19030680
20049392
20049419
20049019
20049086
55
CS5002NI
Software Engineering
Level 2 Data Flow Diagram
8
Figure 21 : Level 2 DFD of Report Preparation
This is the level 2 DFD for our module of generate report. In this diagram, we can see the
process in even more detail, showing all the sub processes along with their data flow and
interaction with other entities, processes and data stores. There are a total of four sub
processes within the process of report generation.
19030680
20049392
20049419
20049019
20049086
56
CS5002NI
Software Engineering
5.4.3 Design Specification
Structure Chart
4
Figure 22 : Structure chart of Report Generation
19030680
20049392
20049419
20049019
20049086
57
CS5002NI
Software Engineering
Module Specification
In this section of the report, we look at implementation of our process. This section is
mainly used as a reference on how the process works. The following module specification
consists of all the sub processes inside a single function.
MODULE NAME: Report Preparation
PURPOSE: This module takes data stored in different databases and complies them to
create a report of a member specified by the user (Staff). This report along, generated by
the system is then stored to a database of “Member Records”. During the process of
creating report, member id verification and eligibility check also takes place. In member
ID verification, the system checks whether the member id given by the user (Staff) is a
valid one or not (exists or not). Then, In Eligibility check, an overall score of a member is
calculated, and the system determines whether the user is eligible for intermediate
training or not.
9
PSEUDOCODE:
FUNCTION
DO
LET, mID = MemberID_TextField.getText()
LET, sID = Session.getID()
LET, idExists = False
LET, isEligible = false
/* Verifying Member ID */
19030680
20049392
20049419
20049019
20049086
58
CS5002NI
Software Engineering
IF DB_Members.getMemberID(mID) == NULL
THEN, ExitFromFunction
ELSE, idExists = True
/* Fetching Data*/
LET, memberRecord = DB_Members.getMemberRecord()
LET, examRecord = DB_ExamResults.getExamRecord()
PRINT “Enter Marks obtained in physical test”
LET, marksPhysical = Input ()
/* Calculating Eligibility*/
LET, marksWritten = DB_ExamResults.getMarks(mID)
LET, overallPeformance = 60 % of marksPhysical + 40% of marksWritten
IF overallPeformance > 60
THEN, isEligible = True
ELSE, isEligible = False
/*Compiling Report */
PRINT “Enter Feedback For Member”
LET, staffFeedback = Input ()
CreateReport
(mID,
sID,
DB_Members.getMemberName(mID),
marksWritten,
marksPhysical, overallPeformance, isEligible, staffFeedback)
END DO
INPUT PARAMETERS: Generate Report , Member ID, Member Name, Exam Details
OUTPUT PARAMETERS: Report Details
19030680
20049392
20049419
20049019
20049086
59
CS5002NI
Software Engineering
GLOBAL VARIABLES: DB_Members, DB_ExamResults, Session
CALLS: getText(), getID(), getMemberName(), getMemberRecord(), getExamRecord(),
getMemberID, Input(), createReport()
CALLED BY: Main
19030680
20049392
20049419
20049019
20049086
60
CS5002NI
Software Engineering
5.5 Take Mock Exam – Sandesh Bhurtyal
Name: Sandesh Bhurtyal
Student ID: 20049019
Introduction
This module is about taking mock tests, which is one of T-14 Training Academy's key
responsibilities. T-14 is a new venture spearheaded by a group of former national team
football players. It is a football-specific training facility. There are two sorts of training
categories available for each age group: basic and intermediate. There are no specified
requirements for enrolling in Basic Training. However, some qualifications must be met
before enrolling in intermediate training. Members must take some football IQ related
examinations and score a particular number of points to be considered for subsequent
tests to start intermediate training. At the conclusion, the trainer team determines whether
or not the members are entitled to participate in the Intermediate training by comparing
their total performance in all written and physical assessments.
The major function of this module is that everyone who wants to enter intermediate
training must view football-related videos and then take mock tests with the assistance of
the videos and see results.
19030680
20049392
20049419
20049019
20049086
61
CS5002NI
Software Engineering
Environmental Model Specification
Context Diagram
A context diagram represents the relationship between data and business
operations visually. External entities, system operations, and data flows are the three key
components of this diagram. It outlines the factors and events to think about when
creating a system. We'll be able to figure out the scope, boundaries, and system needs
with it. It does not, however, provide the order of events, time, or technological details. As
a result, it's a terrific tool for helping business analysts, stakeholders, and developers
understand the system. To further illustrate, we have created a T-14 Training Academy
context diagram to help in the creation of a visual model of our project's process and data
flow (Opinaldo, 2021).
Figure 23: DFD Components
19030680
20049392
20049419
20049019
20049086
62
CS5002NI
•
Software Engineering
T-14 Training Academy's context diagram is given below :
4
Figure 24: Context Diagram of Taking Exam
The diagram above demonstrates the context diagram of the taking mock exam function.
In this system, the exam is taken online and members must pass it to be eligible for
Intermediate Training at T-14 Training Academy. For taking the exam, firstly Staff
designed the test papers and members must take exams on given test papers that have
been designed by the Academy Staff.
19030680
20049392
20049419
20049019
20049086
63
CS5002NI
Software Engineering
Internal model specification for the system
The Level 1 DFD fragments
Level 1 DFD dismantles the main process into sub-processes, which can later be
examined at a deeper level. In addition, level 1 DFD comprises data storage that the
primary process uses.
The following are the steps to making a Level 1 DFD:
The first step is to define the processes (the main process and the sub-processes).
Step 2: Make a list of all external entities that we are aware of (all people and systems).
Step 3: Make a list of the data storage locations.
Step 4: Make a list of the different data flows.
Step 5: Make a diagram (Valcheva, 2021).
19030680
20049392
20049419
20049019
20049086
64
CS5002NI
•
Software Engineering
T-14 Training Academy's Level 1 DFD diagram is given below :
Figure 25: Level 1 DFD to Take Mock Exam
The above picture represents the level 1 DFD of taking the mock exam. In
our scenario, Staff design the test papers where their data are in the Test Paper Records
data store. For taking the mock exam process give exam and test paper details inputs
are included. In where give exams command gives member id and test details input gives
test id and staff id who generates a report. Where member id represents the details of
members who are taking the exam and Test Id represents a specific test. After giving the
exam exams reports are formed which are then stored in a data store called Exam Result
Record.
19030680
Note : Description can be seen . 7 for overall description
20049392
20049419
20049019
20049086
65
CS5002NI
Software Engineering
Level 2 DFDs for the particular function
A level 2 data flow diagram (DFD) shows the processes that make up an
information system in greater depth than a level 1 DFD. It can be used to plan or record
a system in a particular structure.
8
Figure 26: DFD Level 2 of Taking Mock Exam
19030680
20049392
20049419
20049019
20049086
66
CS5002NI
Software Engineering
Assumptions Made
•
User is already logged into the system.
•
Member Details is given by Give Exams Command.
•
After logging into the system, give exam button will be available.
•
After Clicking the give exam button, the system will verify test papers whether it is
valid or not.
•
Exam questions are stored in a data store called Test paper and after verifying test
paper, papers are loaded in the system.
•
Members give loaded test papers of the system online.
•
Reports of the exam are compiled in a system where it will be stored in a database
called Exam Result.
The above diagram illustrates the DFD level 2 of the Take exam Function. Here
the main process is divided further into three bubbles where at first test papers are
verified. Where certain inputs are given for the extra detail of that function. Give exam
command gives the member id which gives the member details who already registered
to the system and test details provide the staff id who generates a test paper and test
detail gives the test id who represents the certain test. With the help of these inputs, test
papers are verified and further moved into the next process. After that, verified test papers
are then loaded for exams. The load Test Paper function provides the exam questions to
members that have been verified. After giving the loaded exam, the process is further
moved into the next process called Compiled Result, where the given exam report is
compiled and checked and its data are stored in the Exam Result data store.
19030680
20049392
20049419
20049019
20049086
67
CS5002NI
Software Engineering
Design Specification
Structure chart for the Take Mock Exam function.
The hierarchical organization of modules is represented by the Structure Chart. It
deconstructs the entire system into the smallest functional modules and describes the
functions and sub-functions of each module in more depth. The System Structure Chart
divides the system into black boxes (functionality of the system is known to the users but
inner details are unknown). The black boxes are provided inputs and appropriate outputs
are generated.
Modules at the top level are referred to as top-level modules. Components are read from
left to right and from top to bottom. When one module calls another, the called module is
treated as a black box, with the called module giving required parameters and getting
results (Johnson, 2019).
19030680
20049392
20049419
20049019
20049086
68
CS5002NI
Software Engineering
4
Figure 27: Structure Chart of Taking Mock Exam
19030680
20049392
20049419
20049019
20049086
69
CS5002NI
Software Engineering
In this module, the Take Exam is one of the particular functions of our T-14 Training
Academy. The main aim of this module is to take mock exams of members and see the
results of exams who are willing to join the Intermediate training in T-14 Training
Academy. The main module called Main, which is T-14 Training Academy, has its subfunctions, one of which takes exams. The Take exam has further sub-functions called
Staff ID, Get Test paper, Mock Exam. These sub-modules act as input and output where
firstly get staff id module is called by Take exam function where staff id returns staff
details. After its parameter is passed into design test paper where with the help of staff
parameters test papers are designed and after the design test paper module, it further
goes to the exam module where it has sub-modules called member id and print result.
Member id module returns the output of member details and where its parameters are
further passed into Print Result Module which helps to know the result of members. In
Print Result Module has a decision that helps to split the chart sequence into multiple
paths. It has two possible outcomes pass or fail. If members fail, then they are not eligible
for training. But if members passed the exam, then they are eligible for intermediate
training at T-14 Training Academy.
19030680
20049392
20049419
20049019
20049086
70
CS5002NI
Software Engineering
Module specifications (MSpecs) for Taking Mock Exam modules
MODULE NAME: Taking Mock Exam
PURPOSE: Willing to join Intermediate training members have to watch the footballrelated videos and give mock exams and see results.
PSEUDOCODE
Get staff_id, test_id, member_id
Function take exam ()
IF staff_id is equal to valid then
Design test paper
Else
Staff id is not valid
IF test_id is equal to valid then
Specified exam
Else
Not valid exam
End if
End function
Function exam ()
IF member_id is equal to valid then
Can give exam
Else
Member is not valid
19030680
20049392
20049419
20049019
20049086
71
CS5002NI
Software Engineering
End if
End function
Function print ()
IF member_id is equal to pass then
Member is eligible to Join Training
Else IF member_id is equal to fail then
Member is not eligible
End if
End function
INPUT PARAMETERS: Staff_id, Test_id, member_id
OUTPUT PARAMETERS: None
7
GLOBAL VARIABLES: Member_id
LOCAL VARIABLES: staff_id, test_id, member_id
CALLS: None
CALLED BY: None
19030680
20049392
20049419
20049019
20049086
72
CS5002NI
Software Engineering
Conclusion
In our first group project, I was tasked with completing the mock exam module.
The main goal of this module is to conduct mock exams for members who want to join
the Intermediate training at T-14 Training Academy and to review the results of exams.
This task was initially confusing, but with the assistance of the module leader and group
partners, the work became convenient and was completed on time. Furthermore, I
learned about the details of various levels of data flow diagrams, structured charts, and
other types of charts throughout the project.
19030680
20049392
20049419
20049019
20049086
73
CS5002NI
Software Engineering
6. Summary
We successfully finished the design for the 'T-14 Training Academy' system, which is
used to create a football training academy in accordance with the scenario's
requirements. We used the concept, Data Flow Diagram, Structure Chart, Data
Dictionary, Module Specification, Process Modules, and ER-diagram when creating the
required system. It can be employed in a real-life situation. This job was completed with
the help of all members of the group.
Environmental model specification, internal model specification, data dictionary, and
system design specification are all included in the group work. The designs on group
tasks are for the overall system's general surface layer design, which is then expanded
and designed on the individual tasks part. In addition, each group member worked on
environmental model specification, internal model specification, and design specification
for particular functions in the individual tasks area.
While working on the group, we ran into a number of problems with various areas of the
report. We addressed the issues we were facing among the group members in order to
find solutions. We held a group discussion to discuss the issues and try to come up with
solutions. We conducted study on software engineering concepts. This work was
completed with the help of various books, websites, newspapers, and other sources of
information. We met with the module tutor on a regular basis and discussed our progress.
Without the contributions of the group members, the work would not have been finished.
We learned to design the entire system using the DFD, data dictionary, structure chart,
E-R Diagram module requirements, and process specs while working on the group
project, which improved our comprehension of the topics covered in the Software
Engineering module. The system design is completed in accordance with the group's
19030680
20049392
20049419
20049019
20049086
74
CS5002NI
Software Engineering
requirements, but it can be revised to meet the needs of the users in order to be
implemented in a real-world scenario.
To recapitulate, Software engineering abilities such as requirement analysis, project
management, structured software engineering, and issue solving will be developed after
this project is completed. As a result, by working in a small group, properly managing the
project, and reaching the deadline, this project was completed successfully
19030680
20049392
20049419
20049019
20049086
75
CS5002NI
Software Engineering
2. References
javatpoint, 2020. Software Engineering | Software Requirement Specifications javatpoint.
Available
[Online]
at:
https://www.javatpoint.com/software-requirement-specifications
[Accessed 29 December 2021].
Lucidchart, 2021. ER Diagram (ERD) - Definition &amp; Overview | Lucidchart. [Online]
Available
at:
https://www.lucidchart.com/pages/er-diagrams
[Accessed 28 December 2021].
Project-Management, 2021. What is a Project Charter? | Complete Guide &amp;
Template
Available
2022.
at:
[Online]
https://project-management.com/what-is-a-project-charter/
[Accessed 28 December 2021].
19030680
20049392
20049419
20049019
20049086
76