Chapter Four

System Design

4.0 Introduction

This chapter presents the system design of the Super Mums Chama Information System, a
platform developed to streamline and support the operations of a women’s savings and
investment group, commonly referred to as a chama. The design phase translates the
requirements gathered in earlier stages into a structured blueprint that guides the actual
development and implementation of the system.

The system is intended to provide a reliable and user-friendly solution for managing core
chama activities, including member registration, savings contributions, loan applications
with interest, loan repayment tracking, and generation of comprehensive financial and
membership reports. By formalizing these processes into a digital system, the chama can
achieve greater efficiency, transparency, and accountability in its financial management.

This chapter outlines the architectural framework, data flow models, entity-relationship
diagrams, database schema, input and output designs, user interface considerations,
security mechanisms, and navigation structure. Each component is carefully designed to
ensure that the system is scalable, secure, and easy to use, while meeting the functional and
non-functional requirements identified during system analysis.

The design provides a clear roadmap for developers and stakeholders, ensuring that the
system’s objectives are met and that the chama’s operations are supported by a robust
technological foundation.

4.1 System Architecture Design

The Super Mums Chama Information System is developed using a three-tier architecture,
which separates the system into distinct layers: the presentation layer, the application layer,
and the data layer. This architectural choice ensures that the system is modular, scalable, and
easier to maintain, while promoting clear separation of concerns between user interaction,
business logic, and data management.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Presentation Layer

• Technologies Used: HTML, CSS, and JavaScript.

• Role: This layer provides the user interface through which members and administrators
interact with the system. It includes web pages and forms for member registration,
savings submission, loan applications, loan repayments, and report viewing.
• Key Features:
o Responsive design for accessibility on both desktop and mobile devices.
o Input validation at the client side to enhance user experience.
o Clear navigation menus and dashboards tailored for members and
administrators.

Application Layer

• Technology Used: PHP.

• Role: This layer contains the business logic that processes user requests and enforces
system rules. It acts as the intermediary between the presentation layer and the data
layer.
• Key Functions:

• Validating member details during registration.

• Recording savings and updating the shared kitty.
• Checking loan eligibility, calculating interest, and managing loan approval
workflows.
• Tracking loan repayments and updating balances.
• Generating financial and membership reports based on stored data.

Data Layer

• Technology Used: MySQL Database.

• Role: This layer is responsible for storing and managing all system data in a structured
format.
• Data Stored:
o Member details (e.g., names, ID numbers, phone contacts, join dates).
o Savings transactions (amounts and dates).

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

 o Loan applications (loan amounts, interest rates, statuses).
o Loan repayments (amounts paid and repayment dates).
o User credentials and roles for system security.

Justification for the Three-Tier Architecture

The three-tier architecture was chosen because it provides several advantages:

• Scalability: Each layer can be modified or expanded independently without affecting

the others, making it easier to accommodate future growth.
• Maintainability: Clear separation of responsibilities simplifies debugging, updates,
and enhancements.
• Security: Sensitive data is isolated in the database layer, while access control and
validation are enforced in the application layer.
• Separation of Concerns: The architecture ensures that user interface design, business
logic, and data management remain distinct, reducing complexity and improving
system reliability.

4.2 Data Flow Diagrams (DFDs)

The data flow diagrams illustrate how information flows within the Super Mums Chama
Information System, highlighting the interaction between members, administrators, and
system processes. Two levels of DFDs are presented: the Level 0 Context Diagram and the
Level 1 Diagram of Major Processes.

Level 0 – Context Diagram

At this level, the system is represented as a single process interacting with external entities.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

 • External Entities:

• Members – provide registration details, submit savings, request loans, make

repayments, and view reports.
• Chama Administrator – manages member records, approves loans, and
generates reports.

• System:

• Super Mums Chama Information System – processes all inputs and produces
outputs such as loan status, savings updates, and financial reports.

• Main Processes:

• Member Registration
• Savings Submission
• Loan Request
• Loan Repayment
• Report Generation
•

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Data Flows:

• Members → Registration details, savings amounts, loan requests, repayment details.

• System → Loan status, savings updates, reports.
• Administrator → Requests reports, approves loans.
• System → Generates reports, updates records.

Level 1 – Major Processes

This level expands the system into its core processes and data stores.

Here is the Level 1 Data Flow Diagram (DFD) for the Super Mums Chama Information
System, now expanded to show the five major processes and their associated data stores and
flows.

Breakdown of the Diagram

External Entities

• Members: Provide inputs for registration, savings, loan requests, repayments, and
report requests.
• Chama Administrator: Requests reports and reviews loan status.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Processes

Process Process Name Inputs Outputs / Data Stores

ID
1.0 Register Member Member details (Name, ID, Stored in Member
Phone, Join Date) Database
2.0 Submit Savings Savings amount and date Updates Savings/Kitty
Fund
3.0 Request Loan Loan request details (amount, Loan record in Loan
date) Database, status
4.0 Repay Loan Repayment amount and date Updates Loan Database
5.0 Generate Reports Request from member or Retrieves from Reports
administrator Repository

Data Stores

• Member Database
• Savings/Kitty Fund
• Loan Database
• Reports Repository

This diagram helps visualize how each core function interacts with both users and internal data
repositories.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Level 2 DFD

Request Loan Breakdown

External Entity

• Member: Initiates loan request and receives loan status.

Sub-processes
Sub- Sub-process Name Description
process ID
3.1 Receive Loan Request Accepts loan amount and date from member

3.2 Check Eligibility Verifies member’s savings and repayment

history
3.3 Calculate Interest Computes interest based on amount and duration

3.4 Record Loan Stores loan details in Loan Database

3.5 Return Loan Status Sends approval or rejection status to member

Data Stores

• Member Database: Used to verify eligibility.

• Loan Database: Stores approved loan records.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

4.3 Entity Relationship Diagrams

The Entity-Relationship Diagram (ERD) provides a conceptual model of the data structures
used in the Super Mums Chama Information System. It identifies the key entities, their
attributes, and the relationships between them. This ensures that data is stored efficiently,
avoids redundancy, and supports the system’s functional requirements such as member
registration, savings management, loan processing, repayment tracking, and reporting.

Entities and Attributes

1. Members
o MemberID (Primary Key)
o FullName
o IDNumber
o PhoneNumber
o JoinDate
2. Savings
o SavingID (Primary Key)
o MemberID (Foreign Key → [Link])
o Amount
o Date
3. Loans
o LoanID (Primary Key)
o MemberID (Foreign Key → [Link])
o LoanAmount
o InterestRate
o TotalAmount
o LoanDate
o Status
o

4. Repayments
o RepaymentID (Primary Key)
o LoanID (Foreign Key → [Link])
o AmountPaid
o RepaymentDate
SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA
 5. Users (for system administration)
o UserID (Primary Key)
o Username
o Password
o Role

Relationships

• Members → Savings: One member can make many savings contributions.

• Members → Loans: One member can apply for multiple loans.
• Loans → Repayments: One loan can have multiple repayments.
• Users → System: Administrators manage members, savings, loans, and reports.

Cardinality

• Members to Savings: 1-to-Many

• Members to Loans: 1-to-Many
• Loans to Repayments: 1-to-Many
• Users: Independent entity managing system operations

Entity-Relationship Diagram for Super Mums Chama Information System

OR

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

4.4 Database Schema Design

The database schema defines the logical structure of the Super Mums Chama Information
System database. It translates the conceptual ERD into actual tables, columns, data types, and
constraints. This schema ensures data integrity, eliminates redundancy, and supports efficient
querying and reporting.

1. Members Table

Table Name: Members

Column Name Data Type Constraints

MemberID INT Primary Key

FullName VARCHAR(100) NOT NULL

IDNumber VARCHAR(20) UNIQUE, NOT NULL

PhoneNumber VARCHAR(15)

JoinDate DATE DEFAULT CURRENT_DATE

Figure 4.2: Members Table Schema

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

2. Savings Table

Table Name: Savings

Column Name Data Type Constraints

SavingID INT Primary Key

MemberID INT Foreign Key → Members(MemberID)

Amount DECIMAL(10,2) NOT NULL

Date DATE DEFAULT CURRENT_DATE

Figure 4.3: Savings Table Schema

3. Loans Table

Table Name: Loans

Column Name Data Type Constraints

LoanID INT Primary Key

MemberID INT Foreign Key → Members(MemberID)
LoanAmount DECIMAL(10,2) NOT NULL
InterestRate DECIMAL(4,2) NOT NULL
TotalAmount DECIMAL(10,2) NOT NULL (calculated from LoanAmount + Interest)

LoanDate DATE DEFAULT CURRENT_DATE

Status VARCHAR(20) e.g., 'Pending', 'Approved', 'Completed'

Figure 4.4: Loans Table Schema

4. Repayments Table

Table Name: Repayments

Column Name Data Type Constraints

RepaymentID INT Primary Key
LoanID INT Foreign Key → Loans(LoanID)

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

 AmountPaid DECIMAL(10,2) NOT NULL
RepaymentDate DATE DEFAULT CURRENT_DATE

Figure 4.5: Repayments Table Schema

5. Users Table

Table Name: Users

Column Name Data Type Constraints

UserID INT Primary Key
Username VARCHAR(50) UNIQUE, NOT NULL
Password VARCHAR(255) NOT NULL (hashed for security)
Role VARCHAR(20) e.g., 'Admin', 'Finance'

Figure 4.6: Users Table Schema

4.4.1 Normalization

In designing the database for the Super Mums Chama Information System, normalization
played a critical role in ensuring that the data structure is efficient, consistent, and scalable.
Normalization is a systematic approach to organizing data in a relational database to minimize
redundancy and dependency. It involves decomposing complex tables into simpler, well-
structured ones that adhere to specific rules known as normal forms.

Given the nature of the chama’s operations—tracking member details, savings contributions,
loan applications, repayments, and administrative access—the system handles a variety of
interconnected data. Without proper normalization, the database would be prone to anomalies
such as inconsistent updates, duplicate records, and inefficient queries. These issues could
compromise the integrity of financial records and hinder the system’s reliability.

This section discusses how normalization principles were applied to the database schema,
progressing through the first, second, and third normal forms (1NF, 2NF, and 3NF). Each stage
of normalization is illustrated with examples drawn directly from the system’s core entities,
such as Members, Savings, Loans, and Repayments. The goal was to ensure that:

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

 • Each field contains atomic values (1NF),
• All non-key attributes are fully dependent on the primary key (2NF),
• There are no transitive dependencies between non-key attributes (3NF).

By applying these principles, the resulting schema supports accurate data entry, efficient
reporting, and secure financial management. It also lays a solid foundation for future
enhancements such as mobile integration, cloud hosting, and advanced analytics.

• First Normal Form (1NF) - All attributes are atomic (e.g., each savings entry is stored
in a separate row, avoiding multiple values in one field).
• Second Normal Form (2NF) - Non-key attributes depend fully on the primary key
(e.g., loan details depend on LoanID, not partially on MemberID).
• Third Normal Form (3NF) - No transitive dependencies (e.g., TotalAmount is derived
from LoanAmount and InterestRate, but stored only for reporting efficiency).

4.4.2 Normalization Diagrams

First Normal Form (1NF)

Problem: Savings table contains repeating groups (multiple amounts and dates in one row).
Solution: Break down into atomic values, one savings per row.

Before 1NF (UNF Savings Table):

SavingID MemberID Amounts Dates

101 1 5000, 3000 2023-01-12, 2023-02-10
102 2 4000 2023-03-05

After 1NF (Normalized Savings Table):

SavingID MemberID Amount Date

101 1 5000 2023-01-12

102 1 3000 2023-02-10

103 2 4000 2023-03-05

Conversion of Savings Table into 1NF (atomic values per row)

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Second Normal Form (2NF)

Problem: Non-key attributes depend only partially on a composite key.

Example: Loan details tied to both MemberID and LoanID, but attributes like LoanAmount
depend only on LoanID.

Solution: Ensure all non-key attributes depend fully on the primary key.

Before 2NF (UNF Loan Table):

MemberID LoanID LoanAmount InterestRate Status

1 201 10000 0.1 Approved

1 202 8000 0.1 Pending

After 2NF (Split Tables):

Members Table:

MemberID FullName PhoneNumber

1 Sarah Wanjiru 0712345678

Loans Table:

LoanID MemberID LoanAmount InterestRate Status

201 1 10000 0.1 Approved

202 1 8000 0.1 Pending

Conversion of Loan Table into 2NF (removing partial dependency)

Third Normal Form (3NF)

Problem: Transitive dependency exists (e.g., TotalAmount depends on LoanAmount and

InterestRate). Solution: Remove derived attributes and store only base values.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Before 3NF (UNF Loan Table):

LoanID LoanAmount InterestRate TotalAmount

201 10000 0.1 11000

202 8000 0.1 8800

After 3NF (Normalized Loan Table):

LoanID LoanAmount InterestRate LoanDate Status

201 10000 0.1 2023-03-01 Approved

202 8000 0.1 2023-04-15 Pending

Conversion of Loan Table into 3NF (removing transitive dependency)

This normalization ensures:

• Atomicity: Each field contains a single value.

• Consistency: Relationships are enforced through foreign keys.
• Efficiency: Queries and updates are faster and less error-prone.

4.4.3 Schema Diagram

This diagram should visually show all tables, their columns, and relationships (PK/FK links).

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Explanation of the Diagram

• Members Table
o Primary Key: MemberID
o Attributes: FullName, IDNumber (Unique), PhoneNumber, JoinDate
o Relationships: Connects to Savings and Loans via MemberID.
• Savings Table
o Primary Key: SavingID
o Foreign Key: MemberID → Members(MemberID)
o Attributes: Amount, Date
• Loans Table
o Primary Key: LoanID
o Foreign Key: MemberID → Members(MemberID)
o Attributes: LoanAmount, InterestRate, TotalAmount, LoanDate, Status
o Relationships: Connects to Repayments via LoanID.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

 • Repayments Table
o Primary Key: RepaymentID
o Foreign Key: LoanID → Loans(LoanID)
o Attributes: AmountPaid, RepaymentDate
• Users Table
o Primary Key: UserID
o Attributes: Username (Unique), Password, Role
o Independent entity for system administration.

The schema works due to the following:

• Referential Integrity: Foreign keys enforce relationships between members,

savings, loans, and repayments.
• Atomicity: Each transaction (savings or repayment) is stored as a separate row.
• Normalization: Redundancy is minimized (e.g., loan details stored separately from
member details).
• Security: User accounts are isolated in the Users table with hashed passwords.

4.5 Input and Output Design

The input and output design defines how users interact with the system through forms and
reports. Input forms are used to capture data from members and administrators, while output
reports present processed information in a structured format for review, analysis, and record-
keeping.

Input Forms
1. Member Registration Form

• Purpose: Capture new member details.

• Fields: Full Name, ID Number, Phone Number, Join Date.
• Validation: Required fields, unique ID number, valid phone format.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Figure 4.8: Member Registration Form

2. Savings Submission Form

• Purpose: Record member savings contributions.

• Fields: Member Name (dropdown), Amount, Date.
• Validation: Positive numeric value, valid date.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Figure 4.9: Savings Entry Form

3. Loan Application Form

• Purpose: Allow members to apply for loans.

• Fields: Member Name, Loan Amount, Interest Rate, Loan Date.
• Validation: Eligibility check, interest calculation, status default to “Pending”.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Figure 4.10: Loan Application Form

4. Loan Repayment Form

• Purpose: Record installment payments.

• Fields: Loan ID (dropdown), Amount Paid, Repayment Date.
• Validation: Amount must not exceed remaining balance.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Figure 4.11: Loan Repayment Form

5. Login Form

• Purpose: Authenticate users before accessing the system.

• Fields: Username, Password.
• Validation: Password hashing, role-based access control.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Figure 4.12: System Login Page

Output Reports
1. Member List Report

• Purpose: Display all registered members.

• Contents: MemberID, Full Name, ID Number, Phone Number, Join Date.

Figure 4.13: Member List Report

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

2. Savings Contribution Report

• Purpose: Show savings history per member.

• Contents: Member Name, Amount, Date, Total Savings.

Figure 4.14: Savings Report

3. Loan Summary Report

• Purpose: Summarize loan applications and statuses.

• Contents: Member Name, Loan Amount, Interest Rate, Total Amount, Status.

Figure 4.15: Loan Summary Report

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

4. Repayment Report

• Purpose: Track loan repayments.

• Contents: Loan ID, Member Name, Amount Paid, Repayment Date, Remaining
Balance.

Figure 4.16: Repayment Report

5. Chama Financial Statement

• Purpose: Provide a consolidated financial overview.

• Contents: Total Savings, Total Loans Issued, Total Repayments, Outstanding Balances.

Figure 4.17: Financial Statement Report

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

4.6 User Interface Design

The user interface (UI) design defines how users interact with the Super Mums Chama
Information System. It emphasizes clarity, usability, and accessibility to ensure that both
members and administrators can efficiently perform their tasks. The design follows a
web-based layout with responsive features for desktop and mobile devices.

4.6.1 Design Principles

• Simplicity: Forms and dashboards use clear labels and minimal clutter.
• Consistency: Uniform color schemes, fonts, and button styles across modules.
• Responsiveness: Layout adapts to different screen sizes (desktop, tablet, mobile).
• Accessibility: Dropdowns, tooltips, and error messages guide users.
• Security: Login screens and restricted menus enforce role-based access.

4.6.2 Navigation Structure

• Top Navigation Bar: Provides quick access to modules (Members, Savings, Loans,
Reports).
• Side Menu (Admin Dashboard): Displays role-specific options such as “Manage
Members” or “Generate Reports.”
• Breadcrumbs: Show the user’s current location within the system.
• Logout Button: Always visible for secure exit.

Figure 4.18: Navigation Menu Layout

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

4.6.3 Role-Based Views
1. Member View

• Access limited to personal savings and loan records.

• Can submit savings and loan applications.
• Can view repayment history and financial reports relevant to their account.

Figure 4.19: Member Dashboard

2. Administrator View

• Full access to all modules.

• Can register members, approve loans, record repayments, and generate reports.
• Dashboard includes system statistics (e.g., total savings, active loans).

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

Figure 4.20: Administrator Dashboard

3. Finance Officer View (Optional Role)

• Focused access to financial modules.

• Can record savings, manage loans, and track repayments.
• Cannot edit member personal details.

Figure 4.21: Finance Officer Dashboard

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

4.7 Security Design

Security is a critical aspect of the Super Mums Chama Information System, given that it handles
sensitive financial and personal data. The security design focuses on authentication,
authorization, data protection, and secure communication to safeguard the system against
unauthorized access and malicious activities.

4.7.1 Authentication

• Login Credentials: Users must provide a valid username and password to access the
system.
• Password Hashing: Passwords are stored in the database using hashing algorithms
(e.g., SHA-256 or bcrypt) to prevent exposure of plain text passwords.
• Session Management: Secure sessions are created upon login and automatically expire
after inactivity to prevent hijacking.

Figure 4.22: Secure Login Page with Authentication

4.7.2 Authorization

• Role-Based Access Control (RBAC):

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

 o Members: Limited access to personal savings, loan applications, and
repayment history.
o Administrators: Full access to all modules, including member registration,
loan approvals, and reporting.
o Finance Officers (optional role): Access restricted to financial transactions
without permission to edit member details.
• Access Restrictions: Each role is mapped to specific privileges, ensuring users only
perform authorized actions.

Figure 4.23: Role-Based Dashboard Access

4.7.3 Data Protection

• Input Validation: Prevents SQL injection and cross-site scripting (XSS) attacks by
sanitizing user inputs.
• Database Security:
o Foreign keys enforce referential integrity.
o Restricted database access ensures only authorized applications can connect.
• Encryption: Sensitive data (e.g., passwords, financial records) is encrypted both in
storage and during transmission.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

4.7.4 Secure Communication

• HTTPS Protocol: Ensures encrypted communication between client and server.

• Firewall and Antivirus: Protects the hosting environment from external threats.
• Audit Logs: Records user activities (logins, transactions, updates) for monitoring and
accountability.

4.7.5 Backup and Recovery Security

• Automated Backups: Weekly backups stored in secure external storage.

• Recovery Procedures: MySQL dump files used to restore data in case of system
failure.
• Disaster Recovery Plan: Ensures minimal downtime and data loss during unexpected
events.

4.8 System Navigation Design

System navigation design defines the logical flow of activities for different user roles. It ensures
that members and administrators can easily access the functions they need, with clear steps and
intuitive transitions between modules.

4.8.1 Member Workflow

Steps:

1. Register → Fill in personal details to become a member.

2. Login → Authenticate using username and password.
3. Dashboard → Access personalized dashboard showing savings and loan status.
4. Submit Savings → Record contributions into the system.
5. Apply Loan → Request a loan, with automatic interest calculation.
6. Repay Loan → Record repayments against outstanding loans.
7. View Reports → Access savings history, loan summary, and repayment records.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

4.8.2 Administrator Workflow

Steps:

1. Login → Authenticate with admin credentials.

2. Manage Members → Register new members, edit details, and view member lists.
3. Monitor Transactions → Track savings and loan activities.
4. Approve Loans → Review loan applications and update status.
5. Generate Reports → Produce financial summaries, savings reports, and loan
repayment reports.

4.8.3 Flowchart Representation

Both workflows can be represented using navigation maps or flowcharts:

• Member Flowchart:
o Start → Register → Login → Dashboard → Savings → Loan Application →
Repayment → Reports → End

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

 • Admin Flowchart:
o Start → Login → Manage Members → Monitor Transactions → Approve
Loans → Generate Reports → End

Figure 4.26: System Navigation Flowchart for Members and Administrators

4.8.4 Navigation Design Summary

• Member Workflow: Designed to be linear but flexible. After login, members can
access their dashboard and perform financial activities (savings, loans, repayments)
before viewing reports. This ensures transparency and accountability.
• Administrator Workflow: More management-oriented. Admins log in, manage
member records, monitor transactions, approve loans, and generate reports. This
workflow emphasizes oversight and control.
• Flowcharts: Provide a clear visual representation of navigation paths, making the
system intuitive for users and easy to document for auditors or developers.

This workflow ensures that administrators follow a structured path for managing chama
operations. Each step is clearly defined and role-specific, supporting transparency,
accountability, and efficient system use.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA

4.9 Conclusion

This chapter has presented the detailed design of the Super Mums Chama Information System,
covering the entity–relationship model, database schema, input and output design, user
interface design, security considerations, and system navigation workflows. The design phase
translated the requirements gathered earlier into a structured blueprint that ensures the system
is robust, scalable, and user-friendly.

The Entity–Relationship Diagram (ERD) provided a conceptual view of the data entities and
their relationships, forming the foundation for the database schema. The Database Schema
Design then translated this conceptual model into normalized tables with defined attributes,
primary keys, and foreign keys, ensuring data integrity and eliminating redundancy.

The Input and Output Design demonstrated how users interact with the system through forms
and reports, while the User Interface Design emphasized clarity, consistency, and role-based
access to enhance usability. Security was addressed through authentication, authorization,
encryption, and validation measures, ensuring confidentiality and protection of sensitive
financial data. Finally, the System Navigation Design illustrated workflows for both members
and administrators, showing how the system supports operational efficiency and transparency.

In summary, Chapter Four has laid out a comprehensive design framework that bridges the gap
between requirements analysis and system implementation. The design ensures that the system
will not only meet current operational needs but also remain adaptable to future enhancements
such as mobile integration, cloud deployment, and advanced analytics. This foundation sets the
stage for Chapter Five, which will focus on the actual implementation, testing, deployment,
and maintenance of the system.

SOFTWARE DEVELOPMENT- SYSTEM DESIGN PREPARED BY GABRIEL MBUGUA