CS5002NI Software Engineering

McGregor Institute

20% Group Coursework

AY 2023-2024

Group Name:
SN Student Name College ID University ID
01 Jayavir Basnet NP01CP4A220236 22067852
02 Dipesh Devkota NP01CP4A220302 22068182
03 Siddharth Thapa NP01CP4A220239 22067857
04 Gajendra Prasad Chaudhary NP01CP4A220494 22068143
05 Bardan Malla NP01CP4S230110 22085511

I confirm that I understand my coursework needs to be submitted online via MySecondTeacher 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.
Table of Contents
1. Introduction ............................................................................................................ 1
1.1. Objectives: ........................................................................................................ 2
2. Project Charter ....................................................................................................... 2
• Problem Statement:............................................................................................. 2
• Business Case: .................................................................................................... 2
• Goal Statement: ................................................................................................... 2
• Timeline:............................................................................................................... 3
• Scope: .................................................................................................................. 3
• Team Members: ................................................................................................... 3
3. Software Requirements Specification (SRS) ....................................................... 4
3.1. Functional Requirements: ............................................................................... 4
3.1.1. User Management: .................................................................................... 4
3.1.2. Community Forum:.................................................................................... 5
3.1.3. Plant Marketplace (BUY/SELL): ................................................................ 5
3.1.4. Expert Q&A: ............................................................................................... 5
3.1.5. Notification Centre: ................................................................................... 6
3.1.6. Event Management: ................................................................................... 6
3.1.7. Certification and Courses: ........................................................................ 6
3.2. Non-Functional Requirements: ....................................................................... 6
3.2.1. Performance: ............................................................................................. 6
3.2.2. Security: ..................................................................................................... 7
3.2.3. Usability: .................................................................................................... 7
3.2.4. Reliability: .................................................................................................. 7
3.2.5. Community Engagement: ......................................................................... 7
3.2.6. Plant Sale Platform: ................................................................................... 7
3.2.7. Certification Courses: ............................................................................... 8
3.3. Design and Implementation Constraints: ...................................................... 8
3.3.1. Budget and Resources: ............................................................................ 8
3.3.2. Technology and Stack: ............................................................................. 8
3.3.3. Data Management: ..................................................................................... 8
3.3.4. Third Party Dependencies: ....................................................................... 8
 3.4. External Interfaces Required: ......................................................................... 9
3.4.1. User Interface: ........................................................................................... 9
3.4.2. Payment Gateway: ..................................................................................... 9
3.4.3. Social Media Integration: .......................................................................... 9
3.4.4. Communication APIs: ............................................................................... 9
3.5. Other Non-Functional Requirements: ............................................................ 9
3.5.1. Localization:............................................................................................... 9
3.5.2. SEO Optimization: ..................................................................................... 9
3.5.3. Analytics and Reporting: .......................................................................... 9
3.5.4. Data Backup and Recovery: ..................................................................... 9
4. Detailed Specification of Group Task ................................................................. 10
4.1. Environmental model specifications: ........................................................... 10
4.1.1. Context Level / Level 0 Data Flow Diagram (DFD): ............................... 10
4.1.2. Level 1 Data Flow Diagram (DFD): ......................................................... 11
4.1.3. Level 2 Data Flow Diagram (DFD) for 3 Processes: .............................. 11
4.2. Internal Model Specification for the System:............................................... 13
4.2.1. Entity Relationship Diagram (ERD): ....................................................... 13
4.2.2. Data Dictionary: ....................................................................................... 13
4.2.3. Process Specifications (Pspecs): .......................................................... 16
4.3. Design Specification: ..................................................................................... 19
4.3.1. Structure Diagram: .................................................................................. 20
4.4. Assignment Diary: ......................................................................................... 23
4.4.1. Assumptions: ........................................................................................... 23
4.4.2. Omissions / Inconsistencies: ................................................................. 24
4.4.3. Group members responsibilities: .......................................................... 25
4.4.4. Group Meetings: ...................................................................................... 27
5. Detailed Specification of Individual Task ........................................................... 28
5.1. Report Preparation Individual Task .............................................................. 28
5.1.1. Environmental Model Specification: ...................................................... 28
5.1.2. Internal Model Specifications: ................................................................ 29
5.1.3. Design Specification: ................................................................................. 32
5.2. Join the Program Individual Task ................................................................. 37
5.2.1. Environmental model specification: ...................................................... 37
 5.2.2. Internal model specification: .................................................................. 38
5.2.3. Design specification ................................................................................ 40
5.3. Take Certification Exam Individual Task ...................................................... 43
5.3.1. Environmental Model Specification: ...................................................... 43
5.3.2. Internal Model Specification: .................................................................. 44
5.3.3. Design Specification: .............................................................................. 46
5.4. Purchase Plant Individual Task .................................................................... 50
5.4.1. Environmental Model Specification: ...................................................... 51
5.4.2. Internal Model Specification: .................................................................. 52
5.4.3. Design Specification: .............................................................................. 54
5.5. Make Payment Individual Task: .................................................................... 57
5.5.1. Environmental Model Specification: ...................................................... 57
5.5.2. Internal Model Specification: .................................................................. 59
5.5.3. Design Specification: .............................................................................. 61
6. Summary ............................................................................................................... 65
References .................................................................................................................... 66
Table of Figures:

Figure 1 Context Level DFD for whole system .............................................................. 10

Figure 2 Level 1 DFD for the whole system .................................................................. 11
Figure 3 Level 2 DFD for course management process ................................................ 11
Figure 4 Level 2 DFD for Plant Marketplace process .................................................... 12
Figure 5 Level 2 DFD for payment processing process................................................. 12
Figure 6 ER Diagram for whole system ......................................................................... 13
Figure 7 Data Structure for the whole system ............................................................... 22
Figure 8 Level 0 report preparation DFD ....................................................................... 28
Figure 9 Level 1 Report Preparation DFD ..................................................................... 29
Figure 10 Level 2 DFD for Report Preparation .............................................................. 31
Figure 11 Structure Chart for report preparation ........................................................... 32
Figure 12: Level 0 Diagram of join the program ............................................................ 37
Figure 13: Level 1 DFD of join the program .................................................................. 38
Figure 14: Level 2 DFD of "join the program" ................................................................ 39
Figure 15: Structure Chart of "join the program" ........................................................... 40
Figure 16: Module Specification of "Join the program" .................................................. 42
Figure 17: Level 0 DFD of "Take certification exam" ..................................................... 43
Figure 18: Level 1 DFD of "Take certification Exam"..................................................... 44
Figure 19: Level 2 DFD of "Take Certification Exam" .................................................... 45
Figure 20: Take Certification Exam "Structure Chart" ................................................... 46
Figure 21: Lvel 0 DFD of "Purchase plant" .................................................................... 51
Figure 22: Level 1 DFD of "Purchase plant" .................................................................. 52
Figure 23: Level 2 DFD of "purchase plant" .................................................................. 53
Figure 24: Structure Chart of "Purchase plant" ............................................................. 54
Figure 25: Level 0 DFD of "Make Payment" .................................................................. 58
Figure 26: Level 1 DFD of "Make payment" .................................................................. 59
Figure 27: Level 2 DFD of "Make payment" .................................................................. 60
Figure 28: Structure Chart of "Make Payment" ............................................................. 61
Table of Tables:

Table 1 Group Member Responsibilities ....................................................................... 25

Table 2: Purchase plant "Module Specification ............................................................. 56
CS5002NI Software Engineering

1. Introduction
McGregor Institute of Botanical Training, which is located at Godawari, Lalitpur is a
Ireland based training institute which is affiliated to Dublin City University and has been 7
years since they are operating in Nepal, as their primary focus on agriculture and
horticulture. With the recent escalating interest shown by many peoples in the field of
agriculture, McGregor institute wants to expand its offerings by introducing a range of
short-term certification courses related to horticulture for the individuals who are seeking
for the knowledge.

Apart from the educational programs, McGregor Institute aims to provide a platform for
the plant enthusiasts for building a community and making interactions. This initiative
includes selling varieties of different plants, for minimum fees and even for free in some
cases. Individuals can share and discuss their ideas as well as organize a program for
the protection of rare plants and forests through the community. This platform can also
be useful for those people who have less knowledge about plants and where they can
post their queries to be answered by the experts.

McGregor is institute wants to create a project that involves the development of an

integrated system. The system comprises of registration of new users, program
enrollment, plant purchases, payment processing, expert’s recommendations, detailed
information report generation, enrollment in certification exams, forum discussions and
notification services.

In this document, we present a detailed project charter and software requirements

specification (SRS) which will serve as a roadmap to bring the McGregor Institute vision
to reality which will help to educate, help, inspire and connect plant lovers.

1
CS5002NI Software Engineering

1.1. Objectives:
The objective of this project is to demonstrate practical knowledge of “Structured Software
Engineering” by using the Yourdon methodology and also to showcase our ability to work
collaboratively and successfully within a small group and meeting the specific deadlines.

2. Project Charter

• Problem Statement:
McGregor Institute of Botanical Training aims to address the growing interest of
people in agriculture and horticulture by introducing short-term certification and
providing a platform for plant enthusiasts to share and discuss their ideas about
plants.

• Business Case:
With the increase in demand for agricultural knowledge, the institute also sees an
opportunity to expand its offerings by introducing short-term courses related to
agriculture and horticulture and a plant marketplace which will help the institute to
attract audiences and generate revenue.

• Goal Statement:
The main goal is to establish the McGregor Institute as a leading supplier of
botanical education and resources in Nepal which offers variety of short term
courses related to agriculture and horticulture, marketplace to sell plants and a
forum for plant enthusiasts to discuss and share ideas related to plants with expert
recommendations.

2
CS5002NI Software Engineering

• Timeline:
The project is set to be completed within a reasonable time frame and ensuring
that all the functionalities are operating within next year. The certification courses
will be implemented as soon as possible followed by forums and plant marketplace
thereafter.

• Scope:
The scope of this project includes implementation of a system for McGregor
Institute that comprises of user registration, course enrollment, plant purchases,
payment processing, forum where the users can share and discuss their ideas and
get expert recommendations, generates detailed report for administrators,
conducting certification exams and sends notifications to users.

• Team Members:
This project is undertaken collaboratively by the groups of 5 students, each
contributing towards the successful completion of the project within the given
deadlines.

Group Members:

(i) Jayavir Basnet

(ii) Dipesh Devkota
(iii) Gajendra Prasad Chaudhary
(iv) Siddhartha Thapa
(v) Bardan Malla

3
CS5002NI Software Engineering

3. Software Requirements Specification (SRS)

Software Requirements Specification (SRS) is a document that describes the functional

and non-functional requirements of a software to be developed. It serves as a basis for
an agreement between the customer and the developers on how the software should
function and perform. It also helps to prevent software project failure by reducing the risk
of redesigning and reworking on the project (Romani, 2022).

3.1. Functional Requirements:

A functional requirement is the specific functionalities or features that a software
system must possess. They define what actions the system needs to perform, what
information it needs to process, and what results it needs to produce. These
requirements serve as a blueprint for developers, ensuring the system is designed
and built to meet the essential needs of its users (altexsoft, 2023).

3.1.1. User Management:

• User Registration and Login:
➔ Users can register and log in securely.

• User Profile:
➔ Profiles includes information like personal details, interests and location.
➔ Users can create and manage their profiles.

• Account Management:
➔ Features include the ability to edit profiles.
➔ Users can change passwords and manage other account settings.

4
CS5002NI Software Engineering

3.1.2. Community Forum:

➔ Create and join discussion threads on various plant-related topics.
➔ Post comments and replies within threads.
➔ Upvote/downvote threads and comments.
➔ Search for specific topics or discussions.
➔ Report inappropriate content.

3.1.3. Plant Marketplace (BUY/SELL):

➔ Browse and search for different plant varieties available for sale.
➔ View detailed information about each plant (species, care requirements,
benefits, name, and price).
➔ Order plants with online payment option for paid varieties.
➔ The system must support secure payment transactions.
➔ Users should be able to add plants to their cart and make online purchases.
➔ The platform should handle different pricing models, include minimal fees, and
free distribution for specific plants.
➔ Request free plants when available.

3.1.4. Expert Q&A:

➔ Experts should have the ability to respond to queries posted by community
members.
➔ The system must notify users of expert responses.
➔ Post questions related to plant care, identification, problems.
➔ Experts answer questions with relevant information and advice.
➔ Upvote/downvote answers to promote helpful ones.

5
CS5002NI Software Engineering

3.1.5. Notification Centre:

➔ The platform should have a notification system to alert users about course
enrolment’s, plant purchases, and forum interactions.

3.1.6. Event Management:

➔ Create and manage events related to plant conservation and protection.
➔ Register for events and manage participant lists.
➔ Communicate with event attendees through announcements and messaging.
➔ The system must allow users to post details and manage event logistics.

3.1.7. Certification and Courses:

➔ The system must authenticate users securely.
➔ Users should browse available certification courses.
➔ The system must allow users to enroll in selected courses.
➔ The platforms should facilitate secure online payments for course enrollment.

3.2. Non-Functional Requirements:

Non-functional requirements are the attributes and characteristics that define the
overall behaviour of the system rather than specific functionalities. They focus on
qualities such as performance, security, usability, reliability and many more (altexsoft,
2023).

3.2.1. Performance:

➔ The platform should provide a responsive user experience, with an average

page load time that is under three seconds.
➔ The system should have scalability and it should be able to handle several
users.
➔ The platform should be accessible all the time, except for scheduled
maintenance.

6
CS5002NI Software Engineering

3.2.2. Security:

➔ Secure user authentication and authorization techniques should be built to

secure user data and ensure access control.
➔ Secure login mechanism with password hashing.

3.2.3. Usability:

➔ The interface should be simple to use and navigate.

➔ All functionalities should have clear and straightforward instructions.
➔ Responsive design for different screen sizes and devices.

3.2.4. Reliability:

➔ The system should be strong and reliable, with no more than 1 hour of outage
each month for maintenance.
➔ Data backups should be done daily, and disaster recovery plans should be in
place.

3.2.5. Community Engagement:

➔ The forum should be able to handle 1,000 users at once viewing, writing, and
replying to topics with a response time of no more than 2 seconds.
➔ Events and initiatives aimed at promoting regular community interaction should
be encouraged without degrading platform functionality.

3.2.6. Plant Sale Platform:

➔ The system for selling plants should have a secure payment gateway to ensure
financial transactions are protected.
➔ The platform needs to facilitate the display of a variety of plant photographs,
captions, and costs.

7
CS5002NI Software Engineering

3.2.7. Certification Courses:

➔ All learning materials and multimedia content (videos, audio, and photos)
should be easily accessible to registered students through the platform.
➔ Alternative formats should be provided for accessibility (e.g., transcripts for
videos, downloadable files for documents).
➔ Create a user-friendly interface that allows students to simply traverse course
materials and find specific topics.
➔ Include an efficient search function in the course materials to enable effective
keyword-based searches.
➔ Monitor and adjust server resources to ensure consistent performance during
peak usage times.
➔ Consider allowing students to download specific materials for offline access
and study.

3.3. Design and Implementation Constraints:

3.3.1. Budget and Resources:

➔ Develop and maintain platform within available budget and manpower.

3.3.2. Technology and Stack:

➔ Choose appropriate technology considering development time, security, and
scalability.

3.3.3. Data Management:

➔ Develop effective data structures that handle and store user information, plant
data, forum posts, and other types of data.

3.3.4. Third Party Dependencies:

➔ Minimize reliance on external services to ensure platform stability and control.

8
CS5002NI Software Engineering

3.4. External Interfaces Required:

3.4.1. User Interface:

➔ Web-based interface accessible through web browsers on various devices.

3.4.2. Payment Gateway:

➔ Integration of a secure payment channel for online sales of plants.

3.4.3. Social Media Integration:

➔ Permit users to share events and forum content on social media.

3.4.4. Communication APIs:

➔ Connect email and notification systems to provide updates and notifications.

3.5. Other Non-Functional Requirements:

3.5.1. Localization:
➔ Consider supporting additional languages in the future.

3.5.2. SEO Optimization:

➔ Improve visibility by optimizing platform content for search engines.

3.5.3. Analytics and Reporting:

➔ Develop systems for monitoring user activity, forum participation, and event
attendance.

3.5.4. Data Backup and Recovery:

➔ Create appropriate backup and recovery processes for data to guarantee data
integrity.

9
CS5002NI Software Engineering

4. Detailed Specification of Group Task

4.1. Environmental model specifications:

Environmental model specifications show the context level data flow diagram including
level 1 and level 2 DFD. A data flow diagram (DFD) is a visual representation of how
information flows through a system or process. DFD helps to gain a deeper understanding
of process or system operations to identify possible issues, improve efficiency and
develop better processes. The DFD may range from simple to complex overview of the
system and processes (Chi, 2023).

4.1.1. Context Level / Level 0 Data Flow Diagram (DFD):

Figure 1 Context Level DFD for whole system

10
CS5002NI Software Engineering

4.1.2. Level 1 Data Flow Diagram (DFD):

Figure 2 Level 1 DFD for the whole system

4.1.3. Level 2 Data Flow Diagram (DFD) for 3 Processes:

Figure 3 Level 2 DFD for course management process

11
CS5002NI Software Engineering

Figure 4 Level 2 DFD for Plant Marketplace process

12
Figure 5 Level 2 DFD for payment processing process
CS5002NI Software Engineering

4.2. Internal Model Specification for the System:

4.2.1. Entity Relationship Diagram (ERD):

An entity relationship diagram (ERD) shows the relationship between entities that will
be recorded in the database. The ER diagram is basically a structural design of a
database. It acts as a framework with specific symbols to show the relationship
between the database entities. The ER Diagram is created on the basis of three
principal components: Entities, Attributes and Relationships (S, 2023).

Figure 6 ER Diagram for whole system

4.2.2. Data Dictionary:

A data dictionary is a collection of names, definitions, and attributes for data
components which are utilized or stored in a database, information system or in a
research project. It describes the meaning and goals of data elements within the
framework of the project, and offers guidance on interpretation, accepted meanings
and representation. Metadata of data elements are also provided via data dictionary.
Data Dictionaries Metadata can help to define the scope, properties, and application
guidelines for different type of data components (Library, 2023).

13
CS5002NI Software Engineering

View Plants: Plant_ID + Name + Description + Price

Request Plants Purchase: Command

Provide Purchase Response: Invoice

Store recommendation: Location + Responses + Soil Condition image +

UserID+Payment ID

Retrieve recommendation: Location + Responses + Soil Condition image +

UserID+Payment ID

Request recommendation: Location + Soil Condition image + UserID+Payment ID

Give expert responses: Response+ UserID + Payment ID

Shows post details: Post ID + User ID + Contents + Comments + Date + Upvotes

Retrieve Forum Details: Post ID + User ID + Contents + Comments + Date + Upvotes

Store Forum Details: Post ID + User ID + Contents + Comments + Date + Upvotes

Forum Database: {Post ID + User ID + Contents + Comments + Date + Upvotes }*

User registration data: Username + Password + Email

Registration response: User ID

View Courses: Course ID + Name + Duration + Cost

Enrollment request: Username + Password + Email + User ID

Enrollment confirmation: Course ID + Name + Duration + Cost

See Results: Result + Course ID + Score + Exam ID + User ID + Date

Give Exams: Course ID + User ID + Exam ID

Retrieve exam details: Result + Course ID + Score + Exam ID + User ID + Date

Stores exam details: Result + Course ID + Score + Exam ID + User ID + Date

Stores user data: User ID + Username + Password + Email

14
CS5002NI Software Engineering

Retrieve user data: User ID + Username + Password + Email

User Database: {User ID + Username + Password + Email}*

Verify Payment: Command

Stores Course Data: Course ID + Name + Duration + Cost

Provide Access to Course Details: Command

Edit Course Details: Course ID + [Name, Duration, Cost]

Edit Plants Marketplace: Plant ID + [Name, Description, Image, Price]

Provide Plants Details: Plant ID +Name + Description + Image + Price

Provide Reports: User Report + Report ID + Staff Report + Financial Report

Requests Reports: Command

Retrieve Reports: User Report + Report ID + Staff Report + Financial Report

Stores Reports: User Report + Report ID + Staff Report + Financial Report

Retrieve Transaction Details: Payment ID + User ID + Plant ID/Course ID + Amount +

Date + Status

Transaction database: {Payment ID + User ID + Plant ID/Course ID + Amount + Date +

Status} *

Store Payment Details: Payment ID + User ID + Plant ID/Course ID + Amount + Date +

Status

Verify Payment: Command

Stores Plant Details: Plant ID + Name + Description + Image + Price

Provide Plant Details: Plant ID + Name + Description + Image + Price

Plants database: {Plant ID + Name + Description + Image + Price} *

Recommendation database: {Location + Responses + Soil Condition image +

UserID+Payment ID} *

15
CS5002NI Software Engineering

Certification database: {Result + Course ID + Score + Exam ID + User ID + Date} *

Course database: {Course ID + Name + Duration + Cost} *

Reports database: {User Report + Report ID + Staff Report + Financial Report} *

Transaction database: {Payment ID + User ID + Plant ID/Course ID + Amount + Date +

Status} *

Plants database: {Plant ID + Name + Description + Image + Price} *

4.2.3. Process Specifications (Pspecs):

Process A: Course Information

Number: 2.1

Name: Course Information Retrieval

Description: This process gets and displays the information about a course that a user is
interested in. It serves as the first step in the enrollment process.

Input Data Flow: User request for course information

Output Data Flow: Course details presented to the user.

Process Logic:

➔ The system receives a request for information from the user.

➔ It retrieves the course information from the course data store.
➔ The course details are then formatted and displayed to the user.

16
CS5002NI Software Engineering

Process B: Enrollment

Number: 2.2

Name: Enrollment Validation

Description: This process manages the enrollment of the user into a course after verifying
the necessary details

Input Data Flow: Enrollment request with user details

Output Data Flow: Confirmation of enrollment or request for payment.

Process Logic:

➔ The user submits an enrollment request with their details.

➔ The system checks the availability of the course and verifies the user’s
information.
➔ If the validation is successful, the system either confirms the enrollment or
proceeds to payment processing.

Process C: Payment

Number: 2.3

Name: Payment Processing

Description: This process handles the payment transactions required for course
enrollment.

Input Data Flow: Payment details from the user.

Output Data Flow: Payment confirmation or rejection notice.

Process Logic:

➔ The user provides payment details

➔ The system process the payment through the financial data store.

17
CS5002NI Software Engineering

➔ If the payment is successful, the system confirms enrollment and stores the
details and if not it rejects the payment and notifies the user.

Process D: Payment

Number: 5.3

Name: Execute Payment Transaction

Description: This process manages the payment for the plants purchased. It is
responsible for handling the financial transactions, verifying payments, and updating the
purchase records.

Input Data Flow: Payment details from the user.

Output Data Flow: Payment confirmation or rejection

Process Logic:

➔ The user provides payment details.

➔ The payment is processed and verified against the financial database.
➔ If the payment is successful, the plants purchase details are stored; if the
payment is rejected, the user is notified, and the transaction is cancelled.

Process E: Purchase

Number: 5.2

Name: Process Purchase Request

Description: This process handles the purchasing actions of the user. It includes
validation the purchase request and preparing the transaction for payment processing.

Input Data Flow: Purchase request with selected plant processing.

Output Data Flow: Validation of purchase and initiation of payment process.

18
CS5002NI Software Engineering

Process Logic:

➔ The user selects plants and submits a purchase request

➔ The system validates the availability and details of the plants.
➔ Upon successful validation, the system proceeds to the payment process.

4.3. Design Specification:

Design Specification is a medium which provides information about the system to help
with the creation and implementation of a good software. It provides the software
development process, acting as a connection between the concept and development
process. It helps to explore the boundaries of the software, explaining what the
software main goal, objectives are. It provides the outline of the methods to achieve
steps in identifying any specific parts on the design (Emdad Khan, Mohammed
Alawairdhi, 2013).

Design Specifications is an important aspect for developers, project managers, clients,

and users because it helps them to ensure clear understanding of what they are
building and provides overview of overall system. It will help them to evaluate project
budget, time, and resources.

19
CS5002NI Software Engineering

4.3.1. Structure Diagram:

The structure diagram is a hierarchical representation of a system that simplifies the
complexity of a system by breaking it down into its most basic and controllable
elements. It specifies specific symbols to demonstrate the various processes,
pathways of data flow, decision points, and other pertinent details. This diagram
serves as a useful tool for tracing data movement and understanding the inner
workings of the system, making it easier to manage and analyze more efficiently
(geeksforgeeks, 2023).

20
CS5002NI Software Engineering

Symbols:
Symbol Name Description
It is used for a process or a
Process function in the system where task
is carried out

It helps to call module

Call Line

It helps to pass parameters

Parameter between the module

It is used to identify the flow of

Decision operation based on a condition

Control Parameter It indicates the completion of

condition

It is used in process where

Repetition repetition of task is necessary

21
CS5002NI Software Engineering

Structure Chart for the whole system:

22

Figure 7 Data Structure for the whole system

CS5002NI Software Engineering

4.4. Assignment Diary:

Our group members have engaged in in-depth discussion and analysis during the
process of developing the requirements for McGregor Institute of Botanical Training
system. This Assignment Diary provides the assumptions, omissions/inconsistencies,
and group member responsibilities throughout the process.

4.4.1. Assumptions:

(i) Registration and Authentication of the User:

We will be implementing a secure and user-friendly registration and authentication

system and allow new users to seamlessly register and access the system’s features.
We will ensure a straightforward registration process which will give a positive user
experience.

(ii) Course Enrollment:

The course enrollment process will be a very user-friendly interface for easy browse,
selection, and enrollment. Specific details regarding the course selection criteria,
payment processes and confirmation will be presented for ensuring clarity and
customer satisfaction.

(iii) Payment Security:

A safe and secure payment processing will be implemented for plant purchases,
course enrollment or any other transaction within the system. Payment data will be
stored securely. It will support the secure handling of financial details which will build
strong faith among users while generating revenue for the institute.

(iv) Location/Geographical Information and recommendations:

Users will have the access to give geographical data like site location and soil
condition images for expert recommendations on suitable plants. Incorporating
geographical data will improve the accuracy of the advice given by the expert.

23
CS5002NI Software Engineering

(v) Notification Feature:

The system will include a notification mechanism to message or inform users about
relevant information such as course enrollments, purchase, forum, and certifications.
Implementing such feature will ensure timely communication with users and will inform
them about updates and changes within the system.

(vi) Certification Exam Prerequisites:

Before attempting certification exams, users will be required to fulfill specific required
details and prerequisites to ensure they have required knowledge or experience.

4.4.2. Omissions / Inconsistencies:

(i) Forum Functionality:

Although the presence of a forum is acknowledged, precise information about its

features, moderation controls, and user interactions are not clearly defined. Additional
discussions and clarifications are necessary to define the forum's scope and
functionalities effectively.

(ii) User Roles:

The specifications don’t define the different roles that users can have clearly, such as
administrators and regular users. We need to discuss and figure out the various levels
of access and what permissions each role should have.

24
CS5002NI Software Engineering

4.4.3. Group members responsibilities:

Group Responsibilities
Members
GROUP TASK
Jayavir Basnet • Research and lead the team members.
• Combining Pdf and reviewing the work of fellow team
members.
• Design the Entity Relationship Diagram.
• Data Flow Diagram (DFD) for Context Level and Environmental
Specification
INDIVIDUAL TASK
• Report Generation
GROUP TASK
Dipesh Devkota • Design Specification: Structure Chart
• Process Specification
• Review of Report preparation
INDIVIDUAL TASK
• Take Certification Exam.

Table 1 Group Member Responsibilities

25
CS5002NI Software Engineering

GROUP TASK
Bardan Malla • Contributed to assumptions and keeping records.
• Assist all group members.
• Assignment Diary
INDIVIDUAL TASK
• Make Payment.
GROUP TASK
Gajendra Prasad • Contributed designing SRS.
Chaudhari • Review internal model specification.
INDIVIDUAL TASK
• Purchase Plant.
GROUP TASK
Siddhartha • Summary and Conclusion.
Thapa • Project Charter.
• Data Dictionary
INDIVIDUAL TASK
• Join the Program.

26
CS5002NI Software Engineering

4.4.4. Group Meetings:

Date Time Location Discussion

18th Dec / 23 Noon Brit Caffe Formation of Team and discussion about the
coursework.
20th Dec/ 23 10 A.M. London Discussion and distribution of topics for
Block research.
21st Dec/ 23 11:30 A.M. Nepal Block Even distribution and negotiation for the topics
and workload.
22nd Dec/ 23 1 P.M. Skill Block Chosen the group leader and cleared queries
Parking and doubts.
24th Dec/ 23 8 A.M. Brit Study Discussed the project and wrote started the
Room documentation by all group members.
25th Dec/ 23 10 A.M. Brit Study Worked on Group task Context diagram and
Room Level 1 DFD.
27th Dec/ 23 1 P.M. Kumari Reviewed the Context diagram and Level 1
DFD and finished.
29th Dec/ 23 10:30 A.M. Brit Study Started working on ERD and Data Dictionary.
Room
31st Dec/ 23 11:30 A.M. Online Call Started reviewing each other’s Individual work.
1st Jan/ 24 10 P.M. Online Call Completed ERD and Data Dictionary, also
started taking feedback on documentation
from every member.
2nd Jan/ 24 11 A.M. Brit Study Reviewed group members DFD and combined
Room the completed tasks.
3rd Jan/24 3 P.M Brit Study Wrote Summary and improved any
Room documentation errors after adding all the
remaining individual work.
4th Jan/24 1 PM Kumari Combined all tasks

5th Jan/24 11PM Kumari Finished all task and submission

27
CS5002NI Software Engineering

5. Detailed Specification of Individual Task

5.1. Report Preparation Individual Task

Name: Jayavir Basnet (GL)

LMU ID: 22067852
Report preparation function provides detailed report of Users, Tranasactions and
Staffs to the administration. In the system, the user provides information while
registering and then their information is stored in the user database similarly for staffs,
their details are stored in the staff database. The administrator requests the system
for the required reports and the system fetches the information from the required
databases, user, transactions, and staff database and then the system creates the
report and provides it to the administrator.

5.1.1. Environmental Model Specification:

• Context Level Data Flow Diagram (DFD) for Report Preparation:

Figure 8 Level 0 report preparation DFD

28
CS5002NI Software Engineering

Explanation:

(i) User enters registration details, and the report preparation process sends back
the registration status to user.
(ii) Admin requests for financial, user and staff reports, and report preparation
process sends back the requested reports to admin.
(iii) Staff requests for access to reports, and report preparation process allows the
staff to access the reports.

5.1.2. Internal Model Specifications:

• Level 1 Data Flow Diagram (DFD):

Figure 9 Level 1 Report Preparation DFD

29
CS5002NI Software Engineering

Explanation:

(i) During the registration process of users and staffs they provide their
information. The registration process verifies the information and stores in the
respective database (user or staff). If the information is stored successfully in
the database, it provides the final details of the user or staff to registration
process and the registration process provides registration confirmation to user
or staff.

(ii) During the payment process, the user provides the payment details, and the
process verifies the details and stores it into the transaction database. After the
information is verified the database sends the payment details to the payment
process and the process sends the payment confirmation to the user.

(iii) The report process requests user details, staff details and transaction details
from the respective databases. The databases then provide details to the report
process.

30
CS5002NI Software Engineering

Level 2 Data Flow Diagram (DFD):

Figure 10 Level 2 DFD for Report Preparation

Explanation:

(i) Admin requests for user reports then create user report process access the
user details in the user database. User Database provides user details to create
user report process which will generate user report and provides it to the admin.

(ii) Admin requests for financial reports then create user report process access the
financial details in the transaction database. Transaction Database provides
transaction details to create financial report process which will generate
financial report and provides it to the admin.

(iii) Admin requests for staff reports then create staff report process access the
staff details in the staff database. Staff Database provides staff details to create
staff report process which will generate staff report and provides it to the admin.

31
CS5002NI Software Engineering

5.1.3. Design Specification:

• Structure Chart:

The structure chart represents the hierarchical structure of modules. It breaks down
the whole system or functional into its lowest functional modules and gives a more
thorough explanation of the functions and sub-functions of each module
(geeksforgeeks, 2023).

Figure 11 Structure Chart for report preparation

32
CS5002NI Software Engineering

Explanation:
Firstly, the main system executes the report generation functions. The report generation
functions then provide an option to select the report to be generated, whether it is
financial, staff or user report. It then requests the required report and then the desired
report is generated after that it provides the generated report for data analysis after the
report is analyzed it then verifies the analyzed report and lastly it displays the final report.

• Module Specification (MSpecs):

Module Name: Report Generation

Purpose: The purpose of this module is to provide administrator with the detailed reports
of users, staffs and transaction details.

Pseudocode:

START

DISPLAY “Please select the report you want to generate: 1. User Report, 2. Financial
Report, 3. Staff Report.”

Admin_input = Prompt admin for selection

IF Admin selects 1 then,

DISPLAY “User Report selected.”

CALL Generate_User_Report (user_details)

ELSE IF Admin selects 2 then,

DISPLAY “Financial Report selected.”

CALL Generate_Financial_Report (transaction_details)

ELSE IF Admin selects 3 then,

DISPLAY “Staff Report selected.”

CALL Generate_Staff_Report (staff_details)

33
CS5002NI Software Engineering

ELSE

DISPLAY “Invalid Selection”

PROMPT admin for selection

END IF

END

Generate_User_Report:

REQUEST “Request User Report”

Generated_Report = Generate user report data from the user database

PROVIDE Generated_Report

Analyzed_Report = CALL Data_Analysis (Generated_Report)

DISPLAY “User Report Verified”

CALL Display_Report (Analyzed_Report)

Generate_Financial_Report:

REQUEST “Request Financial Report”

Generated_Report = Generate financial report data from the transaction database

PROVIDE Generated_Report

Analyzed_Report = CALL Data_Analysis (Generated_Report)

DISPLAY “Financial Report Verified”

CALL Display_Report (Analyzed_Report)

Generate_Staff_Report:

REQUEST “Request Staff Report”

Generated_Report = Generate staff report data from the staff database

PROVIDE Generated_Report

34
CS5002NI Software Engineering

Analyzed_Report = CALL Data_Analysis (Generated_Report)

DISPLAY “Staff Report Verified”

CALL Display_Report (Analyzed_Report)

Data_Analysis(report):

//Assuming that there is a function to analyze the report

Analyzed_Report = Analyze the report data

RETURN Analyzed_Report

Display_Report (report):

Display the analyzed report to the admin.

• Main Function:

INPUT PARAMETERS: admin_input

OUTPUT PARAMETERS: None
GLOBAL VARIABLES: None
LOCAL VARIABLES: None
CALLS: Generate_User_Report (user_details), Generate_Financial_Report
(transaction_details), Generate_Staff_Report (staff_details).
CALLED BY: None

• Generate_User_Report, Generate_Financial_Report, Generate_Staff_Report

Function:
INPUT PARAMETERS: None
OUTPUT PARAMETERS: Generated_Report, Analyzed_Report
GLOBAL VARIABLES: None
LOCAL VARIABLES: Generated_Report, Analyzed_Report
CALLS: Data_Analysis (Generated_Report), Display_Report (Analyzed_Report)
CALLED BY: None

35
CS5002NI Software Engineering

• Data_Analysis Function:

INPUT PARAMETERS: report

OUTPUT PARAMETERS: Analyzed_Report
GLOBAL VARIABLES: None
LOCAL VARIABLES: Analyzed_Report
CALLS: None
CALLED BY: Generate_User_Report, Generate_Financial_Report and
Generate_Staff_Report

• Display_Report Function:

INPUT PARAMETERS: report

OUTPUT PARAMETERS: None
GLOBAL VARIABLES: None
LOCAL VARIABLES: None
CALLS: None
CALLED BY: Generate_User_Report, Generate_Financial_Report and
Generate_Staff_Report

36
CS5002NI Software Engineering

5.2. Join the Program Individual Task

Name: Siddhartha Thapa

LMU ID: 22067857

In this individual task, I chose “Join the program” function, among the five functions
for detailed specification of our task. Here, I have presented the detailed specifications
of Join the program function.

In the platform there is “Join the program” function where interested individuals can
join the program. There are different types of courses graduate, postgraduate and
certificate. The following courses are both paid and unpaid.

5.2.1. Environmental model specification:

• Context Level Data Flow Diagram:
The context level diagram shows how a system functions around the business. Level
0 data flow diagram shows a data system.

Figure 12: Level 0 Diagram of join the program

The figure shown above represents the flow of data between the Users and Admin within
“Join the Program” function. The arrows indicate the direction of data flow, showing how
Users select and enroll in the courses and how Admin manages the courses.

37
CS5002NI Software Engineering

5.2.2. Internal model specification:

• Level 1 Data Flow Diagram:

Figure 13: Level 1 DFD of join the program

The above figure shows the level 1 Data Flow Diagram of join the program. This figure
shows a detailed view of the system than the context diagram. By showing the main sub-
process and stores of data which makes up the system as a whole. Based on this
diagram, we know that Register User provides registration details, Users provides course
confirmation details and User details. join the program provides program details and
course details to admin and Enrollment details and Enrollment status to Enrollment
confirmation. Admin manages program and provides enrollment details to View
enrollment details. User_details database stores user detais provides User details to User
and User_Enrollment logs database stores enrollment logs and provides enrollment
details to View enrollment details.

38
CS5002NI Software Engineering

• Level 2 Data Flow Diagram:

Figure 14: Level 2 DFD of "join the program"

User details data flows from the User Database to Collect Application process and the
Application details flow from the Collect application process to Verify information process.
Enrollment details flow from Verify information process to the Log Enrollment process and
from the Log Enrollment process to the Enrollment Details store and the user. Rejected
applications flow from Verify Information process to the Rejected queue and Enrollment
confirmation details flow from the Log Enrollment process to the user.

39
CS5002NI Software Engineering

5.2.3. Design specification

• Structure Chart:

Figure 15: Structure Chart of "join the program"

Structure chart shows the breakdown of a system to its lowest manageable forms. First
of all, from Registration module registration details are passed to the User module. From
Users module user details are passed to enrollment module and from enrollment module
CourseEnrollment Confirmation details are passed to Payment Module and from payment
module Payment details are passed to get access to program from which user gets
access to the chosen course. From Enrollment another two parameters are passed i.e.
CourseEnrollment Confirmation and enrollment details to enrollment details Database.
Enrollment details Database sends request enrollment details update database
parameter to Update enrollment details database.

40
CS5002NI Software Engineering

• Module Specification:

Module Name Join the program

Purpose To Enroll in the program.
Pseudocode START
FUNCTION MAIN
DO
CALL DisplayProgram()
EnrollmentDetails = GET Enrollment details
CALL Enrollinselectedprogram(EnrollmentDetails)
CALL Confirmation()
END DO
FUNCTION DisplayProgram()
DO
programdetails = GET program details
RETURN programdetails
END DO
FUNCTION Enrollinselectedprogram(EnrollmentDetails)
DO
IF selected course is paid
Paymentdetails = GET Payment details
Purchasedcoursedetails = Paymentdetails +
EnrollmentDetails
CALL Confirmation (Purchasedcoursedetails)
ELSE
CALL Confirmation (EnrollmentDetails)
END IF
END DO
FUNCTION Confirmation (PLurchasedCourseDetails)
DO
RETURN PurchasedCourseDetails

41
CS5002NI Software Engineering

END DO
Input Parameters EnrollmentDetails, PurchasedCourseDetails
Output Parameters PurchasedCourseDetails, programdetails
Global Variables None
Local Variables Programdetails, Purchasedcoursedetails, Paymentdetails
Calls Display program, Enroll in selected program, Confirmation
Called by Main
Figure 16: Module Specification of "Join the program"

• Conclusion:
Join the program is one of the most important functions for any platform. In this project
the organization is having problems in maintaining records of the new users who are
joining the course with their details. So, above information is the solution for the
problem.
Users join the program themselves. After choosing the course and completing the
payment process user will be registered and user details will be stored in database.

42
CS5002NI Software Engineering

5.3. Take Certification Exam Individual Task

Name: Dipesh Devkota
LMU ID: 22068182

As an individual task, I was assigned to “take Certification exam” function model

specifications and structure chart with pseudo code. In this function candidate will
have interface where they will have to provide their details and must give an answer
to certain questions. Certification exam will be based on Multiple Choice Questions
“MCQ” so there may be one or multiple choices to answer.

After exam will be finished, certificate will be checked by certification authority and
students will be provided with the certificate of their subject.

5.3.1. Environmental Model Specification:

• Context Level Data Flow Diagram:

Context Level Diagram, it also is well known as fundamental system model or 0-level
DFD. It provides entire software requirements inside a bubble with input and output
which is represented by inflow and outflow of arrow.
In this level of Diagram, it shows how users interact with the function “Take
Certification Exam” and how the function will interact with other parts of the system.
The DFD below shows data flow where a user logs in, takes an exam by answering
questions which is then is sent to authenticate and results are sent for validation to an
admin.

Figure 17: Level 0 DFD of "Take certification exam"

43
CS5002NI Software Engineering

5.3.2. Internal Model Specification:

• Level 1 Data Flow Diagram:

In level 1 DFD, the main bubble is broken down into multiple bubbles to provide more
detailed and tiny view of the system. Like that, given diagram is a level 1 DFD of “Take
Certification Exam” which is broke down into 3 bubbles. Here is the breakdown of the
components:
➔ User and Amin: User and Admin are external entities who will interact with the
processes.
➔ Exam Management: It is a process who will manage exam including login
details of user.
➔ Question Management: It is also a process who will manage exam questions
then sends it to user to answer the questions.
➔ Validate Answer: At the end answer to the questions is verified here which will
also send result to user and admin.

44"Take certification Exam"

Figure 18: Level 1 DFD of
CS5002NI Software Engineering

• Level 2 Data Flow Diagram:

In this level of diagram, each process from the level 1 is broken down into more
detailed parts. Here, User is an external entity who interacts with the system for
certification exam. User will proceed to sub-process for login then user will select
certification exam. After certification exam answer is checked through process
validation check.

Figure 19: Level 2 DFD of "Take Certification Exam"

45
CS5002NI Software Engineering

5.3.3. Design Specification:

• Structure Chart:

MC Gregor Institute is the main system that provides certification exam process
where Certification Exam is the sub-component of the MC Gregor institute and
represents the certification exam system. From the Certification Exam registration
inquery is passed down to Exam registration the inquery is sent to provide student
details after that studeent will register the registration detail is sent to confirmation.
After registration is completed, Examination is held where user will attend the exam,
examinee details is passed for question delivery then student will be acknowledged
for answer request. Answer will be delivered to certification exam which will send
result to display result module.

Figure 20: Take Certification Exam "Structure Chart"

46
CS5002NI Software Engineering

• Module Specification:

MODULUE NAME: Take Certification Exam:

→PURPOSE: To manage the examination process for students at MCGregor
Institute from registration to result display.

→PSEUDOCODE:

FUNCTION MAIN
DO
CALL Exam_Registration
CALL Certification_Exam
CALL Display_Result
END DO
FUNCTION Exam_Registration
DO
GET Input parameter for student_details as ‘student details’
GET confirmation from REGISTER ‘student details’
DISPLAY ‘registration confirmation’
END DO
RETURN ‘confirmation’
FUNCTION Certification_Exam
DO
IF ‘confirmation’ IS successful
SET exam_session by Attend_Exam
SET questions by Question_Delivery ‘exam session’
SET student_answers by Answer_Submission ‘questions’
SET results by Examination ‘questions’, ‘student_answers’
END IF
ELSE
DISPLAY “Registration required to attend exam.”
END IF
END DO
RETURN ‘results’
FUNCTION Display_Result
DO
GET ‘results’ from Certification_Exam
IF ‘results’ ARE available THEN
DISPLAY ‘results’
END IF
ELSE
DISPLAY “Results are not available yet”

47
CS5002NI Software Engineering

END IF
END DO
FUNCTION Attend_Exam
DO
DISPLSY “exam started”
END DO
RETURN ‘exam session’
FUNCTION Qestion_Delivery
DO
GET ‘questions’ From Database using ‘exam session’
DISPLAY ‘questions’
END DO
RETURN ‘question’

FUNCTION Answer_Submisssion
DO
DISPLAY ‘Please submit your answers’
GET ‘answers’ from Student using ‘questions’
END DO
RETURN ‘questions’
FUNCTION Answer_Submission
DO
DISPLAY ‘Please submit your answers’
END DO
RETURN ‘student answers’
FUNCTION Examination
DO
DISPLAY “Evaluating answers”
GET ‘results’ by evaluating ‘student answers’ with ‘questions’
END DO
RETURN ‘results’

48
CS5002NI Software Engineering

→ INPUT PARAMETERS: - student_details

-confirmation
-exam_session
-questions
-student_answers
-results

→OUTPUT PARAMETERS:
-confirmation
–results
→GLOBAL VARIABLES: none
→LOCAL VARIABLES:
-student_details
-exam_session
-questions
-student_anwers
→CALLS:
-Exam_Registration
-Certification_Exam
-Display_Resut

→CALLED BY:
-Main function

49
CS5002NI Software Engineering

5.4. Purchase Plant Individual Task

Name: Gajendra Prasad Chaudhary
LMU ID: 22068143
The McGregor Institute of Botanical Training, an Ireland-based institute with a
significant presence in Nepal for nearly seven years, specializes in providing extensive
courses in agriculture and horticulture. The institute, which is associated with Dublin
City University, plans to expand its services by adding short-term horticultural
certification courses. These courses will involve essential topics such as plant
identification, propagation, cultivation, pest management, and landscape design.

In addition to instructional programs, the institute is seeking to enter an online

marketplace, where it will sell a range of plants at low prices or even for free in some
situations. Aside from business, the institute hopes to develop a dynamic community
of plant enthusiasts. This community will serve as an opportunity for people to share
ideas, organize initiatives to protect rare species and forests, and provide a venue for
people to ask questions and get answers from specialists. The McGregor Institute
aspires to build an inclusive and knowledgeable community of plant enthusiasts.

Now, in this individual project, I specialize in the Purchase Plant function. In our
collaborative initiative, each of the five team members is assigned to a specific project
aspect, including Make Payment, Report Preparation, Join the Program, and Take
Certification Exam. My role in the Purchase Plant section is centered on crafting a
streamlined and efficient process for users to obtain plants, thereby contributing
significantly to the overall success of our collective project.

Furthermore, Users must create an account on the institute's website to purchase

plants online from the institute. Users can browse a huge variety of available plants
after registering. After adding desired plants to the cart, the user can proceed to the
checkout process. During the checkout process, users are asked for information such
as their delivery address, preferred payment method, and contact information.
Following the transaction's completion, the institute will immediately transport the
selected plants to the given location, ensuring timely delivery within a few days. The

50
CS5002NI Software Engineering

goal of this streamlined approach is to improve the customer experience and make
purchasing plants from the McGregor Institute more convenient and efficient.

5.4.1. Environmental Model Specification:

• Context Level Diagram (Level 0):

A context diagram is a type of data flow diagram that shows the boundaries and scope
of a system and its external entities. It provides a general overview of the system and
its interaction with outside elements (Chi, 2023).

Figure 21: Lvel 0 DFD of "Purchase plant"

51
CS5002NI Software Engineering

The above diagram represents the process of purchasing a plant from McGregor
Institute. It provides various steps and action that are engaged for both the admin and
the user. The admin can edit plant details and provide plant details. The user can
request and confirm the payment for the plant. The purchase plant step is the main
hub where the data flows between the admin and the user. The diagram uses various
shapes and arrows to indicate the type and direction of the data.

5.4.2. Internal Model Specification:

• Level 1 DFD:

Figure 22: Level 1 DFD of "Purchase plant"

This flowchart illustrates the process of users purchasing plants from an online
marketplace, including payment processing and interactions with the admin. Users
choose plants to get started, and the marketplace handles the rest, sending information
to the admin and payment system. The payment system verifies and confirms payments,
storing details in the transaction database. Admin provides plant details stored in the plant
database, and users receive payment confirmation, completing the order.

52
CS5002NI Software Engineering

• Level 2 DFD:

Figure 23: Level 2 DFD of "purchase plant"

53
CS5002NI Software Engineering

The flowing diagram gives: -

• The diagram shows the process of an online payment system, from cart
product pricing to validating payment.

• The flowchart has five main oval-shaped steps connected by arrows that
show the process flow.

• The steps are: Calculate cart Product Pricing, Payment method, Payment
portal, Validate payment, and Purchase invoice.

• The flowchart also shows the interaction between the user, the payment
processing system, and the transaction and plant databases.

5.4.3. Design Specification:

• Structure Chart:

54
Figure 24: Structure Chart of "Purchase plant"
CS5002NI Software Engineering

This structure chart shows the purchase plant process, from selecting to completing the
purchase (free or paid). Starting with the "main" box, it leads to the central hub, "Plant
Purchase," with paths to stages like "plant details," "Display plant," "Add to cart," and
"Checkout." The "Display plant" box has outcomes for "Free" or "Paid," indicating
payment options. It illustrates user-system interaction and key data like the selected plant
and payment details at each step.

• Module Specifications:

Module Name Purchase Plant

Purpose Selling plant
Pseudocode CALL PlantPurchase()

FUNCTION PlantPurchase()
DISPLAY Plant options
PlantSelected = GET User plant
selection
IF PlantPrice is "Free"
DISPLAY Plant confirmation
details
ELSE
CALL Checkout(PlantSelected)
END IF
ENDFUNCTION

FUNCTION Checkout (PlantSelected)

PaymentDetails = GET Paymentdetails
from user
PROCESS Payment
IF Payment successful
DISPLAY Payment confirmation

55
CS5002NI Software Engineering

Returm
Purchaseconfirmationdetails
ELSE
DISPLAY Payment error
message
END IF
END FUNCTION

Input Parameters PlantSelected

Output Parameters Purchaseconfirmationdetails
Global Variables None
Local Variables PlantSelected, PaymentDetails
Calls Display plant, Checkout
Called by Main
Table 2: Purchase plant "Module Specification

Conclusion:

In conclusion, my role in the individual project is focused on enhancing the Purchase

Plant function within our collaborative initiative at McGregor Institute. As part of a
dedicated team, each member is assigned specific responsibilities, and my expertise lies
in optimizing the user experience for obtaining plants. The process involves user
registration, browsing a diverse plant selection, adding items to the cart, and a
streamlined checkout procedure. During checkout, users provide essential details for
delivery and payment. The ultimate aim is to facilitate a seamless and efficient customer
experience, ensuring timely delivery of selected plants and contributing significantly to the
overall success of McGregor Institute's online plant purchasing platform.

56
CS5002NI Software Engineering

5.5. Make Payment Individual Task:

Name: Bardan Malla
LMU ID: 22085511
Introduction of Make Payment:
The Make Payment function servers an important role within the McGregor institute of
Botanical Training’s system. It enables users during the financial transaction service. As
users start their transaction this process becomes the gateway to accessing various
resources. This function is a series of subprocesses which also includes the collection
and verification of payment details which assures a seamless and secure transaction
experience. This function is very important and needs to be efficient and reliable to make
a positive user experience and make the payment processes easier for the company.

5.5.1. Environmental Model Specification:

A Data Flow Diagram (DFD) is a visual representation of how a data flow works in a
system. It shows processes, entities, data streams and data storage. DFD also helps
us identify the information that is input and output by user in the system and, the
processes and data involved while completing tasks for the process. Additionally, it
highlights the information that needs to be stored and retrieved.

Context Level Diagram:

Context level diagram is a basic level diagram which is also called level 0 DFD are the
type of diagram which provides a high-level overview of a system’s major processes and
their interrelationships without going too much into detailed subprocesses. It is also called
context diagram often because it shows how the system interacts with external entities.

57
CS5002NI Software Engineering

Figure 25: Level 0 DFD of "Make Payment"

In the above diagram, the system helps users pay for course or plant they selected by
sending Plant purchase Payment or Course Fee payment and Payment Details. After the
System receives this information, it processes and sends details to Admin for
Confirmation. Once the system receives an approval it sends the user an invoice for the
payment.

58
CS5002NI Software Engineering

5.5.2. Internal Model Specification:

Level 1 Data Flow Diagram:

Figure 26: Level 1 DFD of "Make payment"

This is a further break down of Payment Process. It starts after Collect Payment system
retrieves appropriate Details from User. It stores User data and sends payment type to
Process Payment process. It then checks for stock and sends Transaction Details to
Admin. Admin approves the Transaction then the verification process stores data then
generates invoice if everything is verified.

59
CS5002NI Software Engineering

Level 2 Data Flow Diagram:

Figure 27: Level 2 DFD of "Make payment"

In the collect payment system, there are 3 breakdown processes. After payment
information process gets Payment and Customer Details. It first stores information, then
if it’s Plant purchase payment it goes to plant purchase process. Then the system checks
if the plant description matches with of the database, then the plant fee amount is
retrieved. If the payment happens to be for course fee, then the system would go to course
fee system then it would check for the course fee amount and details from the data base.
After the process completes it sends Payment type data to next process.

60
CS5002NI Software Engineering

5.5.3. Design Specification:

Structure Chart:
A structure chart in software engineering servers like a program’s family free. It maps out
the hierarchical connections or relationships among different types of functions or
subroutines. Each module is a box which are connected by lines showing which modules
call or utilize other ones. It essentially functions as a blueprint outlining how to build the
program by assembling smaller and specialized building blocks into a whole program.

Figure 28: Structure Chart of "Make Payment"

In the start the main function will run one of the two payment system according to the
user’s payment details. If it is for course fee payment, it will go to Course Fee Payment
Function. Then it checks if the data is valid or not by going to the validation check function.
Then confirmation details are sent to course payment function then it sends details to
procced the payment. If the payment details happen to be for plant’s purchase. Then the
transaction details will flow to plant payment. Then it checks if the data is appropriate by
flowing into the validation check function, if conformed the details are sent to order
payment confirmation. Later confirmation details are sent to payment details.

61
CS5002NI Software Engineering

Module Specifications (Mspecs):

Module Name: Make Payment

Purpose: The purpose of this module is to make financial transactions and keep records
of user.

Pseudocode:
START

DISPLAY "Welcome to The Payment System"

DISPLAY "Please enter your payment details:"

DISPLAY "Enter payment type (Plant/Course):"

paymentType = GET_USER_INPUT()

DISPLAY "Enter payment amount:"

paymentAmount = GET_USER_INPUT()

IF paymentType == "Plant" THEN

DISPLAY "Enter plant name:"

plantName = GET_USER_INPUT()

ELSE IF paymentType == "Course" THEN

DISPLAY "Enter course name:"

courseName = GET_USER_INPUT()

ELSE

DISPLAY "Invalid payment type. Please try again."

END PROGRAM

END IF

DISPLAY "Verifying payment information..."

62
CS5002NI Software Engineering

IF paymentType == "Plant" THEN

DISPLAY "Checking stock availability..."

IF CHECK_STOCK_AVAILABILITY(plantName) THEN

DISPLAY "Stock available. Processing Plant Payment..."

DISPLAY "Plant Payment successful!"

ELSE

DISPLAY "Insufficient stock. Plant Payment failed."

END IF

ELSE IF paymentType == "Course" THEN

DISPLAY "Processing Course Payment..."

DISPLAY "Course Payment successful!"

END IF

END

FUNCTION CHECK_STOCK(plantName)

IF plantName exists in stock THEN

RETURN true

ELSE

RETURN false

END IF

END FUNCTION

Main Function:

LOCAL VARIABLES: paymentType, paymentAmount, plantName, courseName

CALLS: CHECK_STOCK_AVAILABILITY(plantName)

63
CS5002NI Software Engineering

CHECK_STOCK_AVAILABILITY Function:

INPUT PARAMETERS: plantName

OUTPUT PARAMETERS: Boolean

CALLED BY: Main Function

64
CS5002NI Software Engineering

6. Summary

In this coursework, we were assigned a series of tasks, and the tasks were divided into
two types i.e. group tasks and individual tasks. This coursework consisted of 20% of the
overall marks from this module. This coursework consisted of various types of practical
knowledge of Software Engineering. In this coursework we have designed an educational
platform focusing on botanical studies.

In the coursework we were asked to design Project Charter, Software Requirement

Specification, Environmental model specification, Internal model specification, Design
specification and Assignment Diary. There were many difficulties and errors while doing
the coursework, but our module leader, mentors and group members constantly guided
us by which we were able to complete this coursework effectively. Our group leader and
team members were so hardworking and helpful to each other, and we were able to
complete this task on time. After the completion of the tasks, we were able to understand
the coursework in depth and overcome all the difficult factors. After all the hard work,
dedication, and teamwork our coursework was completed.

After completing this group project, we gained knowledge about software engineering and
its contributing components as well as group collaboration skills. We discovered each
other's advantages and disadvantages. Time management and division of tasks were the
most essential factors to complete it properly. This coursework will help us a lot in future
and in our professional life.

65
CS5002NI Software Engineering

References
altexsoft, 2023. Functional and Nonfunctional Requirements: Specification and Types.
[Online]
Available at: https://www.altexsoft.com/blog/functional-and-non-functional-requirements-
specification-and-types/
[Accessed 24 12 2023].
Browning, T. R., 2001. Applying the design structure matrix to system decomposition
and integration problems: a review and new directions. IEEE Transactions on
Engineering Management, , 48(3), pp. 292-306.
Chi, C., 2023. A Beginner's Guide to Data Flow Diagrams. [Online]
Available at: https://blog.hubspot.com/marketing/data-flow-diagram
[Accessed 25 12 2023].
Emdad Khan, Mohammed Alawairdhi, 2013. Intelligent Agent Based Mapping of
Software Requirement. Journal of Software Engineering and Applications, VI(12), pp.
630-637.
geeksforgeeks, 2023. Structure Charts – Software Engineering. [Online]
Available at: https://www.geeksforgeeks.org/software-engineering-structure-charts/
[Accessed 01 01 2024].
Library, U. M., 2023. What Is a Data Dictionary?. [Online]
Available at: https://library.ucmerced.edu/data-dictionaries
[Accessed 29 12 2023].
Romani, E., 2022. What Is a Software Requirement Specification?. [Online]
Available at: https://builtin.com/software-engineering-perspectives/software-
requirement-specification
[Accessed 23 12 2023].
S, R. A., 2023. ER Diagrams in DBMS: Entity Relationship Diagram Model. [Online]
Available at: https://www.simplilearn.com/tutorials/sql-tutorial/er-diagram-in-dbms
[Accessed 28 12 2023].

66