MZUZU UNIVERSITY

Faculty Of Science, Technology & Innovation

Department Of Information & Communication Technology

TOWERBIZHUB BUSINESS DIRECTORY

System Documentation

Developed By:

Emmanuel Mwangupili (BICTU1120)

Supervised By:

Mr. Nayeja.

System Project Submitted in Partial Fulfillment of The Award of Bachelors of Science Degree in

Information & Communication Technology (ICT)

February 2024
ABSTRACT

Mzuni Student-Sponsor Connect (MSSC) is a web-based application that is used by Mzuni

students to raise funds for their various needs. It connects these students with potential people
that want to donate whatever amount of money they have to the students. the system
encompasses features like Campaign creation, Profile building, Making Payments, Withdraws,
social sharing, notifications, fundraising Metrics and campaign termination. The system has used
the Design science research Methodology. It has been developed in a Laravel environment to
incorporate the MVC architecture, has payment gateways. Vue, Breeze, PHP are some of the
technologies used in the application.

Table Contents

i
PROPOSAL ....................................................................................................................................
1
1.1 Introduction ...............................................................................................................................
2
1.1.1 Project History................................................................................................................... 2
1.1.2 Problem Definition .............................................................................................................
2
1.1.3 Project Justification/rationale .............................................................................................
2
1.1.4 Scope ..................................................................................................................................
2
1.1.5 Objectives. ..........................................................................................................................
3
1.2 Literature Review...................................................................................................................... 3
1.3 Design Science Research Methodology.................................................................................... 6
1.4 Timeline ....................................................................................................................................
7
1.5 Deliverables ..............................................................................................................................
8
1.6 Resources and Budget ...............................................................................................................
9
SYSTEM REQUIREMENTS SPECIFICATIONS. ..................................................................... 11
2.1 Introduction .............................................................................................................................
12
2.1.0 Background ......................................................................................................................
12
2.1.1 Problem Statement ...................................................................................................... 12
2.1.2 Scope of development Project .................................................................................... 12
2.1.3 System Personnel future ............................................................................................. 13
2.2 System Requirements......................................................................................................... 14
2.2.0 System Overview .............................................................................................................
14
2.2.1 Functional Requirements ............................................................................................ 15
2.2.2 Interface Requirements ............................................................................................... 17
2.2.3 Non-Functional Requirements .................................................................................... 17
2.2.3.1 System-Related Non-Functional Requirements ...................................................... 17

ii
 2.2.3.2 User-Related Non-Functional Requirements............................................................. 20
2.3 Project Plan ........................................................................................................................ 21 a.
Development Cost .............................................................................................................. 21
b.Software Life-Cycle
Constraints........................................................................................ 21
c. System
Delivery ...................................................................................................
.............. 21
d.Installation..........................................................................................
................................ 22
e. Reporting............................................................................................
................................ 22 DETAILED
DESIGN ...................................................................................................
................ 23
3.1 Introduction .............................................................................................................................
24
3.1.1 Background ......................................................................................................................
24
3.1.2 Goals and objectives......................................................................................................... 24
3.1.3 Scope of solution ..............................................................................................................
24
3.1.4 Constraints ........................................................................................................................
25
3.2. Architectural and Component-Level Design .........................................................................
25
3.2.1 Introduction ......................................................................................................................
25
3.2.2 system architecture ...........................................................................................................
25
3.2.3 Description of components............................................................................................... 27
3.2.4 External system interfaces ................................................................................................
33
3.3 Data Architecture ....................................................................................................................
33
3.3.1 Data dictionary .................................................................................................................
33

iii
 3.2 Entity-relationship diagram .................................................................................................
35
3.4 Graphical User Interface .........................................................................................................
35
3.4.1. Description of the user interface .....................................................................................
35
3.4.1.1 Screen images ............................................................................................................
35
3.4.1.2 objects and actions .....................................................................................................
40
3.4.2 Description of Reports .....................................................................................................
44
3.5. Quality Assurance ..................................................................................................................
44
3.5.1 Detailed Test plans ...........................................................................................................
45
3.5.1.1 Test Plan for Campaign Creation .............................................................................. 45
3.5.1.2 Test Plan for Contribution Process ............................................................................
45
3.5.1.3 Test Plan for User Profile Management ....................................................................
46
5.1.4Test Plan for Notifications System ................................................................................
46
3.6. Summary ................................................................................................................................
47 USER
MANUAL .......................................................................................................................... 48
4.1 System Technical Overview ................................................................................................... 49
4.2 Student ....................................................................................................................................
49
4.2.1 Registration and Log In ....................................................................................................
49
4.4.2 Campaign Creation ...........................................................................................................
50
4.2.3 Terminate Campaign and Request Money Withdraw ......................................................
50
4.2.4 Share Campaign ...............................................................................................................
50

iv
 4.2.5 Edit Profile and View Notifications .................................................................................
50
4.3 Sponsor ...................................................................................................................................
51
4.3.1 Donate to Campaign ......................................................................................................... 51
4.4 Admin ..................................................................................................................................... 52
4.4.1 Approve campaigns and money
withdraws ..................................................................... 52
4.4.2 Manage
Categories ........................................................................................................... 52
References .....................................................................................................................................
53
Appendices ....................................................................................................................................
54

v
Section One

PROPOSAL

Page 1 of 54
1.1 Introduction
1.1.1 Project History
Having seen how some Mzuni students still struggle despite having other sponsorships, it
seemed needful to introduce a platform that can help them to somehow overcome this.
Almost every semester a number of students withdraw on financial grounds. Even worse
some only get to have one meal a day due to lack of finances. This has caused so many
emotional breakdowns among students affecting their education. Mzuni student-Sponsor
Connect comes in as a tool to bridge the gap between the needy and well-to-do students.
Good education is for all, finance should not be a reason for one to fail or face problems
whilst undergoing their academic journey.

1.1.2 Problem Definition

Potential sponsors do not really have a platform where they can directly reach out to students
at any time. And students lack direct access to people who are willing to help. This widens the
gap between students and sponsors to actually reach out to each other. It is really crucial to
bridge this gap and create a way for sponsors and students to interact directly

1.1.3 Project Justification/rationale

This project will be very handy to students as they will have a ready platform to source
money for their needs. It is also handy as it will have a big audience of capable sponsors who
are readily willing to help. Having people contribute any amount they have will make it
easier to reach a target, because when all the money is summed up its results in bigger
amounts. Students will not have a tough time hunting for sponsors.

1.1.4 Scope
The system being proposed aims to bridge the gap between sponsors and students so that they
should easily reach out to each other.

It will include the development of a web-based crowdfunding site that will allow students to raise
funds. The system will give the beneficiaries (students) a space to build their profiles and share

Page 2 of 54
their stories and the purpose of fundraising with the general public. Sharing of a campaign to
other social media pages.

It will also incorporate payment which are the donations that will be made. The payment system
will not be manually designed by the system builder but will use already existing payment
systems by using API’s.

Generally, a fundraiser is supposed to provide their account details. But this crowdfunding platform
will only have one account to where the money will be channeled and that is the Mzuni account. A
student will not be the one adding the account but the system will have the school’s bank account
already put in place.

It will also extend to the physical handling of money by the social welfare department so that
only those really deserving the money will be helped.

1.1.5 Objectives.
Develop a project that will allow students to raise funds by receiving donations from potential
sponsors.

Secondly is to make a ready platform that is accessible anytime by the students and provide
long-term financial solutions to give individual, non-government and government Sponsors a
platform to reach out to Mzuni students

Another objective is to increase academic performance among needy students by removing

the financial barrier.

Finally, the project aims to give students a chance to publicize their campaigns to other social media
platforms for a bigger audience.

1.2 Literature Review

The proposed Mzuni Student-Sponsor Connect (MSSC) project aims to develop a web-based
crowdfunding platform to bridge the gap between needy students at Mzuzu University (Mzuni)

Page 3 of 54
and potential sponsors. To inform the project design, a literature analysis was conducted to explore
existing research on crowdfunding platforms and financial support systems for needy students.

[1] Conducted an empirical study that analyzed existing crowdfunding platforms and their
impact on educational initiatives. The study provides insights into the potential benefits and
limitations of crowdfunding in an educational setting. While the study's credibility is established,
its generalizability to the context of Mzuni's needy students requires further investigation to
develop a tailored crowdfunding platform that effectively addresses the financial needs of Mzuni
students. By addressing this gap, the MSSC project can contribute to enhancing financial support
and opportunities for success among needy students at Mzuni.

By examining the findings of [2]in the context of the MSSC project, we can derive insights and
implications for the effectiveness of crowdfunding initiatives in improving the academic
outcomes of financially struggling students at Mzuni. The study by [2]highlighted several
potential benefits of crowdfunding, such as increased access to financial resources, improved
engagement and motivation among students, and enhanced community support. These findings
align with the objectives of the MSSC project, which aims to provide a platform for Mzuni
students to raise funds for their educational needs. By facilitating direct communication and
interaction between potential sponsors and needy students, the MSSC platform can increase
financial support and foster a sense of community and connection among the Mzuni student body.

Moreover, [2]discussed the importance of effective campaign management and engagement

strategies in crowdfunding initiatives. This emphasizes the need for the MSSC platform to
incorporate features that enable students to create compelling campaigns, build engaging
profiles, and effectively share their stories with potential sponsors. By integrating social sharing
functionalities and leveraging the power of social media platforms, the MSSC platform can
amplify the reach and impact of student campaigns, thereby increasing the likelihood of
successful fundraising. However, the study by [2] did not address the potential limitations or
challenges that may arise in the context of crowdfunding platforms specifically tailored to
supporting needy students at Mzuni. Therefore, it is crucial for the MSSC project to conduct
further research and evaluation to understand and address these unique challenges. For example,
the project should explore factors such as the cultural and social dynamics at Mzuni, financial

Page 4 of 54
literacy among students, and potential privacy and security concerns in handling financial
transactions.

Kickstarter launched in April 2009 as a web-based crowdfunding mechanism supporting the

creative arts [3] This platform is a crowdfunding platform that focuses on entrepreneurs. The
MSSC will carter for students which the latter website although a crowdfunding platform does
not carter. Payments take time to process for sites like GoFundMe because it uses USD [4] this
can be a challenge for a Mzuni student to use sites like these to find sponsors. With MSSC it will
not have a huge delay in processing and it will eliminate the associated fees when dealing with
different currencies on the money, making it simpler to implement it.

MSSC will be a non-profit making platform such that it will only be deducting transaction fees
from the donation money whereas platforms like GoFundMe [5] are profit-making platforms
such that they deduct the transaction fees and also a little profit for their money from the
donations. According to [6] they discovered that financial hardships play a big role in a student’s
academic journey, and how it negatively affects them. This cements the idea of creating a
platform that will allow students to easily reach out to people who would want to help so that the
negative impact that comes with financial burdens will be removed.

Review of Existing Platforms

In addition to the literature analysis, a review of existing crowdfunding platforms was conducted
to identify their limitations and highlight the need for a dedicated platform like MSSC.

Platform A: General Crowdfunding Platforms

Existing general crowdfunding platforms, such as Kickstarter and GoFundMe, provide

opportunities for individuals to raise funds for various causes, including education. However,
these platforms lack a specific focus on needy students at the university level. Additionally, the
large user base and diverse range of campaigns on these platforms make it challenging for
students to gain visibility and attract potential sponsors. MSSC aims to address these
limitations by providing a dedicated platform exclusively for Mzuni students, increasing their
chances of obtaining support for their educational needs. Platform B: Local Sponsorship
Programs

Page 5 of 54
Some universities and organizations have local sponsorship programs that offer financial
assistance to students. While these programs can be beneficial, they often have limited reach and
resources, making it difficult to meet the needs of all financially struggling students. MSSC
intends to complement existing local sponsorship programs by providing an additional platform
for students to connect with sponsors beyond the confines of the university, thereby increasing the
available opportunities for financial support.

Platform C: Pemphero Mphande's Fundraising Page

The Pemphero Mphande's fundraising page is an example of an individual initiative to raise

funds for needy students. While such initiatives can be impactful, they rely on the efforts of a
single person and lack the scalability and long-term sustainability that a dedicated platform like
MSSC can offer. MSSC aims to provide a structured and accessible platform that can cater to a
broader range of needy students and attract a larger pool of potential sponsors

1.3 Design Science Research Methodology

The problem at hand is that apart from the contributions that are organized by a limited
number of individuals to raise funds, there is no fixed platform where an activity to raise
funds for needy students. potential sponsors and students don’t have direct
communication to link up so that they may help out.
The artifact that will be produced is a new web-based system for Mzuni, where students will
easily source sponsors and raise funds through campaigns.

This project will follow the MVC model design pattern.

The model will handle the students’ profiles, sponsorship information, and crowdfunding
data. The view component will be responsible for the presentation layer of the system.
My views will include the web pages, the forms, and the user interfaces that will allow
the students to create the campaigns, view progress and manage their profiles. The
sponsors will browse through the student’s profiles, select candidates to support and make
contributions. The controller is the intermediary between the view and the model for
example when a sponsor selects a student to support, the controller handles the request
and updates the model accordingly. This model will be adopted to build a modular and

Page 6 of 54
 wellorganized student-sponsor connect system that will facilitate the crowdfunding
activities effectively.

For the High-level design architecture, the user interface layer will provide registration
and login for students who want to start a fundraiser campaign, build their profile, share
the campaign, and provide a user interface for donors to make their donations to the
specific student projects. There will be user authentication and authorization for the
students signing up for the project, processing of payments by implementing a gateway to
securely process sponsor donations, and notifications to keep students informed about
sponsor donations. For the database, there will be the student database and the payment
database.

Laravel will be used as the PHP framework and also because it incorporates MVC
architecture. HTML and CSS for front-end web design and styling. Vue framework for
interactive features and client-side validation. PHP for back-end server-side scripting and
handling of user data. MySQL for database management and storage of user data. APIs
for integrating with payment gateways in this case local payment gateway (e.g. first
Capital bank) will be used.

For this project, secondary data will be used to implement the system. This data will be
sourced from the internet and other existing sites that are similar to the system being
proposed. the system will be monitored and evaluated after its deployment.

1.4 Timeline
Table 1: Projects proposed timeline.
START FINISH
TASK DATE DATE DURATION

Proposal writing 5/18/2023 5/28/2023 10

proposal presentation and submission 6/2/2023 6/7/2023 5

Writing SRS and supervisor review 6/8/2023 6/16/2023 8

SRS presentation 6/20/2023 7/22/2023 32

Corrections and SRS submission 6/23/2023 7/17/2023 24

Page 7 of 54
Data Collection and Analyzing 7/17/2023 7/31/2023 14

1.5 Deliverables
Table 2: A list of expected project deliverables.
Deliverable Name Description Stakeholders

Proposal Document A high-level description of the problem and Client, Project supervisor,
solution domain
ICT

Department

Software Requirement A description of the software system to beClient, Project supervisor,

developed, this includes functional and non- ICT
Specification (SRS)

Page 8 of 54
 functional requirement. Department

Detailed Design A description of the data, architectural and Client, Project supervisor,
component level designs for the project.
Document (DDD) ICT

Department

Primary versions and/or the system under

development and the progress during coding.
Project Prototypes Project Supervisor

Mzuni Student-Sponsor Final system Client, Project supervisor,

Connect ICT

Department

1.6 Resources and Budget

Table 3: A list of the projects proposed budget.
ITEM DESCRIPTION ESTIMATED COST(MWK)

Laptop For coding, designing and 400,000

writing documents for the system

API For payment gateway 30,000

Internet Data Bundle For internet research and 12,000(monthly for 6 months)
platform development and
downloading necessary materials

Page 9 of 54
Final Documentation Printing and CDs for submission 20,000

Others Airtime, food, transport 35,000

Total 557,000

Proposal Summary

The Mzuni Student-Sponsor connect (MSSC) is a proposed web-based cloud funding

platform solution. It will be used by Mzuni needy students to raise funds for their various
school needs.
The MSSC project is expected to run for six months and attracts a proposed initial budget
of up to MWK 557 ,000.

Page 10 of 54
Section Two

SYSTEM REQUIREMENTS SPECIFICATIONS.

2.1 Introduction

Page 11 of 54
 2.1.0 Background
MSSC is an online cloud platform that allows students from Mzuni to raise funds online.
A student creates and account where he builds his profile and creates a campaign, these
campaigns are displayed in the home page of the web application. It enables sponsors to
donate money to students locally by using local payment gateways. A student has a goal
on how much he wants to be donated to him, the system allows multiple sponsors to
donate to one student and manage to reach the target accumulatively. The admins approve
the campaigns and also manages the users. The system also shows the statistics of the
overall money that has been donated and the number of students helped. It further
promotes interactive Ness by allowing the donors send word of encouragements, show
success stories and gives the students a chance to explain their story by even uploading
short videos for authenticity.

2.1.1 Problem Statement

Potential sponsors do not really have a platform where they can directly reach out to students
at any time. And students lack direct access to people who are willing to help. This widens
the gap between students and sponsors to actually reach out to each other. It is really crucial
to bridge this gap and create a way for sponsors and students to easily reach out to each other.

2.1.2 Scope of development Project

The system being proposed aims to bridge the gap between sponsors and students so that they
should easily reach out to each other. Currently there is no computer-based support that is in
use prior to the installation of MSSC. The existing way for students to raise funds is Manual.
A student in need reaches out to the Dean of students who then calls out for help and in some
cases the stuff Members contributes to help the student.

Page 12 of 54
 This system will automate the manual way and add more advanced features and also reach out
to a bigger community.
It will include the development of a web-based crowdfunding site that will allow students to
raise funds. The system will give the beneficiaries (students) a space to build their profiles and
share their stories and the purpose of fundraising with the general public. Sharing of a
campaign to other social media pages.
It will also incorporate payment which are the donations that will be made. The payment system
will not be manually designed by the system builder but will use already existing payment
systems by using API’s.
Generally, a fundraiser is supposed to provide their account details. But this crowdfunding
platform will only have one account to where the money will be channeled and that is the Mzuni
account. A student will not be the one adding the account but the system will have the school’s
bank account already put in place.
It will also extend to the physical handling of money by the social welfare department so that only
those really deserving the money will be helped.

2.1.3 System Personnel future

1. System End Users

1 Students
2 Sponsors
3 System administrator

2. Developer’s Name
a. Mildred Mandawala

3. Owner
b. Mzuzu university

Page 13 of 54
 2.2 System Requirements

2.2.0 System Overview

Figure 2: USE CASE diagram for current system

Figure 3: USE CASE diagram for Proposed system

Page 14 of 54
 2.2.1 Functional Requirements
Table 3: shows the system functional requirenments
Requirement Requirement Description
Number
1 The system shall provide a Students will be able to register using their
registration interface for users. email addresses, registration number, name
and a password

2 The system shall allow User log in The system will verify user credentials to
grant access only to authorized users. The
admin and the student will log in

Page 15 of 54
3 The system shall allow students to The system will allow student to create
create Campaigns campaigns where they write their personal
details, goals and their story

4. The system shall allow sponsors to The system will have a local payment
donate money gateway where donors can be donating
money via the platform

5 The system shall allow termination The system will allow a student to terminate
of campaigns his campaign before or after the goal has
been reached

6 The system shall show fundraising The system will show the total statistics of
Metrics the fundraisers including the total number of
fundraisers and money raised so far

7 The system shall allow money Upon reaching the goal or before the system
withdraws will allow the student to make a withdraw
request which will then be approved by the
admin and the money will be withdrawn by
the admin from the central account

8 The system shall allow sharing of A campaign URL will be generated upon
creation of campaign which will be shared
campaign URLS
to different social media sites

9 The system shall allow categorizing The admin will create the categories of the
of campaigns fundraisers which students will select and
donors can search and find the category they
want

10 The system shall allow notifications It will notify user when campaign has
reached its goal, when withdraw request has
been approved, when donations have been
made and when withdraw

Page 16 of 54
 request has been made notify management

11 The system shall show testimonials The system will show success stories of
people who have been helped before

12 The system shall select and show The system will automatically select stories
feature stories to feature on home page

13 The system shall allow sending A sponsor can type a word of

encouragements encouragement to send to the student they
are donating to.

14 The system shall send automated When a student wants to create an account,
email notification. the system shall send an email to approve
the creation

2.2.2 Interface Requirements

Table 4: shows the interface requirements.
Requirement Requirement Description External System(S)
Number
4 The system shall MSSC will interface with TNM Payment gateway
allow sponsors to payment gateway to allow users to
donate money make payments

2.2.3 Non-Functional Requirements

2.2.3.1 System-Related Non-Functional Requirements

• Performance:

Page 17 of 54
 Table 5: shows the performance requirements.
Requirement Non-Functional Description Affected
Number Requirements
15 The system shall load within The quick loading times will All requirements
10 seconds
be necessary to promote a
better user experience

16 The system shall support The system will be handling All user interaction
concurrent users.
simultaneous user Requirements
interactions during usage
time.

17 Scalability The system will be able to All requirements

handle growing number of
users and campaigns
without a significant drop in
performance

18 Responsiveness The system will ensure that All requirements

it is responsive and
functions very well on
different devices and screen
sizes

• Operational Environment

a. Hardware Platform:

Table 6: shows the hardware operational environment.

Page 18 of 54
Requirement Non-Functional Description Affected
Number Requirenment
19 Web based The system will run seamlessly All user device
Requirements
on all devices loaded on

b. Software Platform:
Table 7: shows the software operational environment.

Requirement Non-Functional Description Affected

Number Requirement
20 The system supports the The system will function All user
latest versions of web optimally across modern interface
browsers. browsers for consistent user Requirements
experience.

• General Characteristics

a. Reliability:
Table 8: general characteristics.

Requirement Non-Functional Description Affected

Number Requirement
21 The system shall have The system will be dependable All system
an uptime of at least and available at most times the availability
99.7%. user needs to access it Requirements.

Page 19 of 54
2.2.3.2 User-Related Non-Functional Requirements

• Skills level
Requirement Non-Functional Description
Number Requirement
22 Users shall be required The students, sponsors and system
administrator will have basic skills to use a
to have digital literacy
digital device and have basic internet literacy
to navigate the website

23 Users shall be able to users should know how payment is done using
have financial literacy their respective digital devices

24 Users shall have social Users will be familiar with social media
media awareness platforms for promoting their campaigns

• Training
Requirement Non-Functional Description
Number Requirement
25 The system shall This is where users can do
provide help and enquiries to know more about
support section the platform

2.3 Project Plan

a. Development Cost
The table below shows project resources and their associated cost
ITEM DESCRIPTION ESTIMATED COST(MWK)

Page 20 of 54
Laptop For coding, designing and 400,000
writing documents for the system

API For payment gateway 30,000

Internet Data Bundle For internet research and 12,000(monthly for 6 months)
platform development and
downloading necessary materials

Final Documentation Printing and CDs for submission 20,000

Others Airtime, food, transport 35,000

Total 557,000

b. Software Life-Cycle Constraints

• Limited time
• Difficult to be given payment gateway APK
• High cost for internet connection

c. System Delivery

i. Extent of deliverables
i. Feasibility reports
ii. Software requirements specifications (SRS)
iii. Detailed design document (DDD)
iv. Software Product
v. System user manual / documentation

ii. deliverable formats

Page 21 of 54
 a. CD
b. Hard copy

d. Installation
a. The proposed system will gradually replace the existing system
b. Developer of the system will have full access to the system in the installed environment

e. Reporting

System Requirements specification summary

The MSSC purpose is for students to be raising funds online and it is implemented at Mzuzu University

The MSSC system must satisfy the following requirements: user registration, user login,
campaign creation, money donation, showing fundraising metrics, money withdraws, sharing of
campaign URLs, notification, testimonials and acknowledgements.

Section Three

Page 22 of 54
 DETAILED DESIGN

3.1 Introduction
3.1.1 Background
This document presents a detailed description for Mzuni student sponsor connect
system (MSSC). The database design for this crowdfunding system is grounded in an
Entity-Relationship Diagram (ERD) outlining key entities, their attributes, and
relationships. Some essential entities include Users, Campaigns, and Donations Vue.js
and Breeze are utilized to create a dynamic and responsive user interface, ensuring an
engaging user experience. Laravel is employed to manage business rules,
authentication, and authorization. Payment APIs are being used to make the payment
process a success. This document shows the architectural design, database and also
the user interface.

Page 23 of 54
 3.1.2 Goals and objectives
i. Develop a project that allows students to raise funds by receiving donations from potential
sponsors.
ii. Secondly is to make a ready platform that is accessible anytime by the students and provide
long-term financial solutions to give individual, non-government and government Sponsors a
platform to reach out to Mzuni students
iii. Another objective is to increase academic performance among needy students by removing the
financial barrier.
iv. Finally, the project aims to give students a chance to publicize their campaigns to other social
media platforms for a bigger audience.

3.1.3 Scope of solution

The system aims to bridge the gap between sponsors and students so that they should easily
reach out to each other. Currently there is no computer-based support that is in use prior to the
installation of MSSC. The existing way for students to raise funds is Manual. A student in
need reaches out to the Dean of students who then calls out for help and in some cases the
stuff Members contributes to help the student.

This system automates the manual way and add more advanced features and also reach out to
a bigger community.
It includes the development of a web-based crowdfunding site that allows students to raise funds.
The system gives the beneficiaries (students) a space to build their profiles and share their stories
and the purpose of fundraising with the general public. Sharing of a campaign to other social
media pages.
It also incorporates a payment which the donations are made. The payment system is not manually
designed by the system builder but uses already existing payment systems by using
API’s.
Generally, a fundraiser is supposed to provide their account details. But this crowdfunding
platform only has one account to where the money is channeled to and that is the Mzuni account.

Page 24 of 54
 A student is not the one adding the account but the system has the school’s bank account already
put in place. It also extends to the physical handling of money by the social welfare department
so that only those really deserving the money are helped.

3.1.4 Constraints
i. The system was to implement local payment gateways, but to access them it is a challenge
especially the mobile payments like Mpamba and Airtel Money. They would only be
implemented when the system wants to be commercialized. So currently we do not have
these implemented.

3.2. Architectural and Component-Level Design

3.2.1 Introduction
This section showcases the architecture and the component level design in diagrams. A
comprehensive breakdown of how components of the system are connecting.

3.2.2 system architecture

This project follows the MVC model design pattern.
The model handles the students’ profiles, sponsorship information, and crowdfunding
data. The view component is responsible for the presentation layer of the system. My
views include the web pages, the forms, and the user interfaces that allows the students to
create the campaigns, view progress and manage their profiles. The sponsors browse
through the student’s profiles, select candidates to support and make contributions. The
controller is the intermediary between the view and the model for example when a
sponsor selects a student to support, the controller handles the request and updates the
model accordingly. This model has been adopted to build a modular and well-organized
student-sponsor connect system that facilitates the crowdfunding activities effectively.

3.2.2.1 Architectural diagram

Page 25 of 54
3.2.3 Description of components

Page 26 of 54
 Use Case Name: Account Management

Attributes : Username, reg-number(student ID), Email.

Precondition:

• The user must be on the website and connected to the internet. • For registration, the user should

provide a valid email address.

• The Registration number must be unique.

• Passwords should meet security requirements.

• Users must consent to terms and conditions during registration.

Postcondition:

• User details are securely stored in the database.

• Users can log in using their credentials.

• Profile information can be updated, including the password.

• Users can recover their accounts through email verification.

• Notifications are sent for successful login, password changes, and account recovery.

• initiate Login:

a. IF user enters valid credentials (username and password) THEN

Proceed to authenticate the user.

IF authentication is successful THEN

Grant access to the user.

Update last login date.

ELSE Display login error message.

GOTO 1a.

• Initiate Registration:

Page 27 of 54
 a. IF user provides valid registration information (username, email, password)

THEN Check if the chosen Email is unique.

• IF the Email is unique THEN

Proceed to email verification.

IF email verification is successful THEN

Create the user account.

Send a welcome email.

ELSE Display email verification error message.

GOTO 2a.

• ELSE

• Display email error message. GOTO 2a.

Use case name : Campaign management

Attributes: Campaign ID, Campaign Title, Campaign Description, Funding Goal,

Current Funds Raised, Campaign Start Date, Campaign End Date, Campaign
Creator/User ID,Campaign Status (e.g., Active, Completed, Cancelled), Campaign

Page 28 of 54
 Category, Campaign Media (Images, Videos)

Precondition : The user must be logged in to initiate a new campaign.

• The system should be connected to the internet to handle real-time updates.

• The user should have necessary permissions to create and manage campaigns.

Post condition : Campaign details are stored in the database.

• The campaign is listed on the platform.

• Users can start contributing to the campaign.

• The system reflects updated funds raised in real-time.

• Notifications are sent to the campaign creator about campaign status.

1. Student Log-in to Dashboard

a. IF student provides valid credentials THEN

Authenticate the student.

IF authentication is successful THEN

Proceed to the student dashboard.

IF the student has an existing campaign THEN

GOTO 3.

ELSE GOTO 2.

ELSE Display login error message.

GOTO 1a.

2. Create Campaign:

a. IF the student decides to create a new campaign THEN

Provide necessary campaign details (Title, Description, Funding Goal, Category, Media).

Page 29 of 54
 Submit the campaign for admin approval.

b. ELSE

Continue to the view the student dashboard

3. Admin Approval:

a. IF the admin receives a new campaign for approval THEN

Review the campaign details.

IF the campaign is valid and meets guidelines THEN

Approve the campaign.

ELSE Deny the campaign.

4. Campaign Activation:

a. IF the admin approves the campaign THEN

Display the campaign on the platform.

Set the campaign status to "Active."

GOTO 5.

5. Display Campaign:

a. Display the approved and active campaign on the platform for public viewing.

b. Allow sponsors to contribute to the campaign.

Page 30 of 54
Use case name : Money Transfer Management

• Attributes: Campaign ID, Donor ID, Amount, Transfer Date, Bank/Payment

Gateway Details, Transaction ID

Precondition : The campaign must be active.

• Sufficient funds must be available in the donor's account.

• The payment gateway or bank connection must be established

Post condition : The campaign's total funds raised are updated.

• Notifications are sent to the campaign owner and contributor

Algorithm: Money Transfer Management

• Initiate Money Transfer:

a. IF user is a sponsor THEN

Proceed to donation process.

b. ELSE IF user is a student (campaign creator) THEN

Receive donations from numerous donors until the goal is reached.

IF the student decides to terminate the campaign THEN

Page 31 of 54
 Proceed to withdraw request.

ELSE IF the goal is reached THEN

Automatically terminate the campaign and proceed to withdraw request.

ELSE Continue receiving donations.

• Withdraw Request Process:

a. IF the student decides to withdraw funds THEN

Submit a withdraw request.

b. ELSE IF the student terminates the campaign without reaching the goal THEN

Submit a withdraw request.

c. ELSE

Continue receiving donations.

• Admin Approval:

a. IF admin receives a withdraw request THEN

Review the request.

IF the request is valid THEN

Approve the request.

Finalize the payment to the student.

ELSE Deny the request.

b. ELSE

Continue monitoring withdraw requests.

3.2.4 External system interfaces

Stripe Payment Gateway Integration Interface

Name: StripePaymentAPI

Page 32 of 54
 Functions:

Process Donation Transaction

• Endpoint: /process-donation

• Method: POST

• Parameters: campaign_id (int), amount (float), card_token (string) (Stripe-specific token for
card information)

Retrieve Transaction History

• Endpoint: /transaction-history

• Method: GET

• Parameters:

o user_id (int)

3.3 Data Architecture

This section describes the data dictionary, explaining how data items are passed among different
components of the software and the database schema.

3.3.1 Data dictionary

a. Data Items Passed Among Components
Component Passed between usage
User authentication User Interface, Authentication To validate user credentials
data during login and maintain
Module, Database
user sessions

Campaign data User Interface, Campaign Retrieving and updating

campaign information during
Management Module, Database
creation, editing, and viewing.

Page 33 of 54
 Contribution data User Interface, Payment Gateway, Facilitating contributions,
confirming transactions, and
Database
updating campaign funds.

Transaction log data Contribution Module, Logging Logging financial transactions

for auditing and historical
Module, Database
purposes.

Configuration data Configuration Module, Database Retrieving and updating

system configuration settings.

b. Temporary data items

Component Attributes usage
Session data Session ID, User ID, Timestamp Temporary storage of user
session information during
their interaction with the
system.

Form data Temporary storage for data entered in forms Holds data temporarily until
it is validated and stored in
the appropriate persistent data
structures.

3.2 Entity-relationship diagram

Page 34 of 54
3.4 Graphical User Interface
3.4.1. Description of the user interface
This section shows the user interface and a description of its major components.

3.4.1.1 Screen images

Page 35 of 54
Page 36 of 54
Page 37 of 54
Page 38 of 54
Page 39 of 54
3.4.1.2 objects and actions
Screen Object Event Description
LOG IN
Username placeholder User input
and text box

Login button Click The student or admin

is directed to the
homepage where
more options are
offered

Password User input Accepts at least six

characters
placeholder and text
box

Page 40 of 54
 HOME PAGE

Campaign Cards: Click Clicking on a

Campaign Card
redirects to the
campaign details page

Testimonial section Shows featured

testimonials

CREATE Campaign Title User input his captures the title

CAMPAIGN the campaign creator
wants to give to their
PAGE crowdfunding project.

Campaign User input his allows the

campaign creator to
Description
provide a detailed
(textarea) description of their
campaign, explaining
its purpose, and any
other relevant
information.

Goal amount User input The campaign

creator specifies the
target amount they
aim to raise through
the crowdfunding
campaign.

Page 41 of 54
 Upload User action(click) The campaign creator
uploads multimedia
Images/Video
content (images or
videos) that help
convey the campaign's
message or showcase
its purpose.

Category Selection User selection The campaign

creator selects a
category that best
represents the nature
of their crowdfunding
campaign (e.g.,
Medical, Education,
Technology).

PAYMENT PAGE Payment method User selection(radio The contributor

buttons) selects the preferred
selection
payment method, such
as credit/debit card,
stripe, mpamba, airtel
money or other
options.

Page 42 of 54
 Contribution amount User input Allows the contributor
to specify the amount
they want to
contribute to the
campaign.

Make payment User action(clicking Initiates the payment

button) process, where the
entered payment
information is sent
securely to the
payment gateway for
processing. The
system validates the
information, deducts
the contributed
amount, and updates
the campaign's total
funds.

Payment System-generated After a successful

configuration page payment, the
contributor is
redirected to a
confirmation page,
displaying details of
the contribution and
thanking them for
their support.

Page 43 of 54
 Share encouragement User input A donor shares word
of encouragement to
the student they are
donating to

3.4.2 Description of Reports

a. Platform Overview Report:

• Total Funds Raised: Large, prominent display of the total amount of

funds raised across all campaigns.

• Number of Students Helped: Displayed as a counter or numerical value.

Purpose of reports

• Provides a high-level overview of the platform's overall performance

and impact.

• Allows administrators to quickly assess the platform's success and reach.

• Give students hope that the platform is really helping a lot

b. students Dashboard:

• Number of Campaigns Created: A numerical count or graphical representation of the total number
of campaigns created by the campaign creators.

• Total Donations Received: Displays the sum of all donations received by a specific campaign
creator.

Purpose of reports:

• Empowers students with insights into their individual performance.

• Motivates students by showcasing their impact on the platform

3.5. Quality Assurance

Page 44 of 54
 The test for the system will involve the input of sample data and see if it is working and
the report will be requested. If it behaves to the expectations then it will be ready for
implementation.

UNIT TESTING: The individual components of the system shall be tested with the designated
data to see if they are working. For example, on the login screen the sample users shall first
register and then try to login. If the result will be positive, then the conclusion will be made that
the system is working.

LINK TESTING: After unit testing, link testing will be conducted to see if the
components are able to communicate with each other. Here all the links will be tested and
if the expectations will be met, this phase will be through otherwise the system will be
revised.

SYSTEM TESTING: The system as a whole also shall be tested. This will include
entering of sample data while making sure that the integrity constraints are not violated.
This will also include requesting of the reports. After being successful during this stage the
system shall now be ready for user acceptance testing whereby the actual users will
interact with the system

3.5.1 Detailed Test plans

Certainly! Below is a sample test plan for a crowdfunding system similar to GoFundMe,
based on the information you provided:

3.5.1.1 Test Plan for Campaign Creation

Simple Case:

• Verify the creation of a campaign with a basic set of information.

Legal Input Values:

• Test creating a campaign within the specified goal amount and timeline. Illegal Input Values:

• Attempt to create a campaign with an unrealistic goal or a big video file

Special Cases:

• Create a campaign with additional special characters in the title or description.

Page 45 of 54
 • Test creating a campaign with multimedia files exceeding specified limits.

3.5.1.2 Test Plan for Contribution Process

Simple Case:

• Verify a contribution to a campaign.

Legal Input Values:

• Test contributing an amount within the allowed range.

Illegal Input Values:

• Attempt to contribute a negative amount or zero.

Special Cases:

• Contribute using different payment methods (simulate PayPal, credit card, etc.).

• Test contributing multiple times to the same campaign.

3.5.1.3 Test Plan for User Profile Management

Simple Case:

• Verify the creation and editing of a user profile.

Legal Input Values:

• Test creating a profile with valid information.

Illegal Input Values:

• Attempt to create a profile with incomplete or invalid details.

Special Cases:

• Edit the profile to change personal information.

5.1.4Test Plan for Notifications System

Simple Case:

Page 46 of 54
 • Verify the receipt of a notification for a new contribution.

Legal Input Values:

• Test receiving notifications for campaign updates.

Illegal Input Values:

• Attempt to trigger notifications with invalid data.

Special Cases:

• Test opting in/out of different notification types.

• Verify the display of notifications on various devices

3.6. Summary

This Detailed Design Document outlines the development and implementation plan for
the Mzuni Student Sponsor Connect System (MSSCS). The system has been developed
using Laravel and MVC architecture, it incorporates Vue.js, Breeze, and PHP. Key
features include campaign creation, profile building, payments, withdrawals, and social
sharing. The system aims to automate manual fundraising, enhance academic support,
and provide a user-friendly experience. Despite constraints in local payment gateways,
MSSC ensures a secure and efficient process. The detailed design encompasses an
architectural overview, data architecture, graphical user interface details, and a
comprehensive quality assurance plan. And it provides a comprehensive understanding
for the Mzuni student sponsor connect system.

Page 47 of 54
Section Four

USER MANUAL

Page 48 of 54
4.1 System Technical Overview
Mzuni Student-Sponsor Connect (MSSC) system is an online cloud funding platform that allows
students to raise funds. Sponsors donate money to various needs of a student based on a
campaign they have created.

This system has three categories of users which are the Student (the campaign creator), the
Administrator and the Sponsor(the one who donates money). This user manual will guide on
how to use this system based on what type of a user they are and their core functionalities.

Below is an outline of system functionalities

1. Students account creation (registration and login)
2. Creation of Campaign
3. Donations (making payments)
4. Requesting money Withdraws (withdraw Approvals)
5. Notifications
6. Campaign sharing (generating link)
7. Fundraising metrics
8. Campaign termination

4.2 Student
This is a Mzuni student that is creating campaigns to raise funds
4.2.1 Registration and Log In
When a student is connected to the network and types the host address in a browser, they are
taken to the home page where they can find a login and a registration button as shown in the
image below. If they are not registered then they register and proceed to login. Which will take
them to their dashboard.

Page 49 of 54
Figure: login and registration page

4.4.2 Campaign Creation

A student can proceed to create a campaign in their dashboard by clicking on the button
“Campaigns” on the top bar, which will take them to the create campaign page and they can
create a campaign by clicking on a button as shown below.

4.2.3 Terminate Campaign and Request Money Withdraw

A student can terminate their campaign and request their withdraw by clicking the button as shown
below, to find this features they should

• Be at their dashboard
• Click on campaigns on the upper bar
• Select view campaign by clicking the 3 dots on the right side of the campaign
• Then go ahead to click the button as shown below to do either of the two actions

4.2.4 Share Campaign

Can share campaign URL by clicking on the “Share Campaign” button found when they have viewed
their campaign4.2.5 Edit Profile and View Notifications

To edit profile and view system notifications, click the button as shown in the image below

Page 50 of 54
4.3 Sponsor
When a sponsor is connected to the network and types the host address in a browser, they are taken
to the home page.
4.3.1 Donate to Campaign a sponsor can donate to a campaign by clicking the Donate Now
button found below a campaign. They can find a Campaign on the landing page and by clicking
on the Campaign button on the upper bar of the landing page which will take them to the
campaigns page as show below

1. After this it will take them to the campaign with all details , from which the will click
on the Donate button as it will be shown below, and that button will take them to the
page where they can make the payment.
2. Then select on the mode of payment they will use
3. For Visa it will take them to where they can enter their card details and process
payment
4. They can also write a word of encouragement at that page as they are entering payment
details

4.4 Admin
When the admin is connected to the network and types the host address in a browser, they are
taken to the home page. Where they will enter their credentials at login to go to admin
dashboard.

Page 51 of 54
4.4.1 Approve campaigns and money withdraws
• For a campaign to run, the admin needs to approve the campaign by clicking on the 3 dots
on a campaign at actions and then approve or deny the campaign.
• For withdraws they will click the withdraw tab and it will take them to the withdraws
page and then click on the 3 dots too to approve or deny a campaign

4.4.2 Manage Categories

To add a category of campaigns the admin will click on the Manage Categories Button and then add
categories as shown below

Page 52 of 54
References
[1] V. Kalulu, "Over 1000 Mzuni Students face withdrawal," Kulinji News, 2019. [Online]. Available:
https://www.kulinji.com/article/news/2019/over-1-000-mzuni-students-facewithdrawal-over-fees.
Accessed: May 20, year.

[2] Nofer, M., Hinz, O., & Gollan, C. (2017). The Economics of Crowdfunding Platforms.
Business & Information Systems Engineering, 59(4), 253-259. Available:
https://doi.org/10.1007/s12599-017-0486-4. Accessed May 16,2023.

[3 ]Igra, M., Kenworthy, N., Luchsinger, C., & Jung, J.-K. (2021). Crowdfunding as a response to
COVID-19: Increasing inequities at a time of crisis. Social Science & Medicine, 282, 114105.
Available: https://doi.org/10.1016/j.socscimed.2021.114105. Accessed May 17, 2023.

[4] Madeo, E. (2021). The Role of Crowdfunding for New Funding Challenges in Public
Universities: An Italian Case Study. Journal of Education for Sustainable Development, 15(2),
186–205. https://journals.sagepub.com/doi/10.1177/09734082211062657.

[5] Stephen, Annie. (2017). Prospects of Crowd funding Education: A Conceptual Framework.
International Journal Of Engineering And Computer Science. 10.18535/ijecs/v6i5.21.
Available:https://www.researchgate.net/publication/317287933_Prospects_of_Crowd_funding_E
ducation_A_Conceptual_Framework

[6] T. A. Voelker and R. McGlashan, "What is Crowdfunding? Bringing the Power of

Kickstarter to Your Entrepreneurship Research and Teaching Activities," Small Business
Institute®,vol.9,no.2,pp.11-22,2013.[Online].Available:
https://sbij.scholasticahq.com/api/v1/articles/26235-what-is-crowdfunding-bringing-the-powerof-
kickstarter-to-your-entrepreneurship-research-and-teaching-activities.pdf

Appendices

Page 53 of 54
TERMS DEFINITION

SRS System Requirements Specification

DDD Detailed Design Document

API Application programming interface

[email protected]

Page 54 of 54