CHAPTER FOUR
SYSTEM DESIGN AND DEVELOPMENT
4.1 Overview
This chapter presents the design and development of the proposed system. It describes the
architectural blueprint of the system through Data Flow Diagrams (DFDs), Entity-Relationship
Diagrams (ERDs), and Use Case Diagrams. It further outlines the functional and non-functional
requirements, the chosen software development methodology, the tools and technologies
employed, the system modules, database design, and the activities carried out during
implementation, testing, and deployment. The goal is to translate the requirements gathered in
the previous chapters into a working, reliable, and maintainable software solution.
4.2 System Design
System design is the process of defining the architecture, components, modules, interfaces, and
data of the system to satisfy the specified requirements. This section uses standard structured-
analysis tools to model the proposed system.
4.2.1 Data Flow Diagrams (DFD)
Data Flow Diagrams visualize how information moves through the system, the processes that
transform it, the data stores that hold it, and the external entities that interact with it.
[Link] Context Diagram
The context diagram (Level-0 in some notations) shows the system as a single process and
highlights its boundaries with external entities.
+------------+ +-------------+
| | ---- credentials/data ---> | |
| User | | PROPOSED |
| | <---- reports/results ---- | SYSTEM |
+------------+ | |
+------+------+
+------------+ |
| Admin | <---- mgmt reports / config ------> |
+------------+ |
+------------+ |
| 3rd-Party | <----- API requests / responses --> |
| Services | |
+------------+ |
Page 1 of 7
[Link] Level 0 DFD
The Level-0 DFD decomposes the single context process into its major sub-processes and
identifies the principal data stores.
User ---> [1.0 Authenticate] ---> (D1: Users)
|
v
[2.0 Manage Records] <---> (D2: Records)
|
v
[3.0 Process Transactions] <---> (D3: Transactions)
|
v
[4.0 Generate Reports] ---> Admin
[Link] Level 1 DFD
Level-1 DFDs expand each Level-0 process. For example, the "Manage Records" process is
decomposed into Create, Read, Update, Delete, and Validate sub-processes, each interacting
with the Records data store and returning confirmation messages to the user.
4.2.2 Entity-Relationship Diagram (ERD)
The ERD models the data persisted by the system. The main entities, their key attributes, and
relationships are summarized below.
Entity Key Attributes Relationship
User user_id (PK), name, email, password_hash, 1..* Transactions
role
Record record_id (PK), title, description, created_at *..1 User
Transaction transaction_id (PK), user_id (FK), amount, *..1 User
date, status
Report report_id (PK), generated_by (FK), type, *..1 User
file_path
4.2.3 Use Case Diagram
The use case diagram identifies the actors of the system and the goals they achieve while
interacting with it.
Actor: User Actor: Administrator
| |
|--( Register / Login ) |--( Manage Users )
|--( View Dashboard ) |--( Configure System )
|--( Create Record ) |--( View All Reports )
|--( Update Record ) |--( Audit Logs )
Page 2 of 7
|--( Generate Personal Report ) |
|--( Logout ) |--( Logout )
4.2.4 System Requirements Specification
[Link] Functional Requirements
• The system shall allow users to register and authenticate securely.
• The system shall allow authenticated users to create, read, update, and delete their
records.
• The system shall allow administrators to manage user accounts and roles.
• The system shall process transactions and persist them to the database.
• The system shall generate downloadable PDF and CSV reports.
• The system shall log all critical user actions for audit purposes.
[Link] Non-Functional Requirements
• Performance: 95% of requests shall return a response in under 2 seconds.
• Security: Passwords shall be hashed; all traffic shall be served over HTTPS.
• Reliability: The system shall maintain at least 99.5% monthly uptime.
• Usability: The interface shall be responsive and follow modern UX guidelines.
• Scalability: The architecture shall support horizontal scaling of the backend.
• Maintainability: Code shall follow consistent style guides and be fully documented.
4.3 System Development
4.3.1 Choice of Development Methodology
[Link] Waterfall Model
The Waterfall model was adopted for the development of this system. It is a linear and
sequential software development methodology in which each phase must be completed before
the next phase begins. The phases include Requirements Analysis, System Design,
Implementation, Integration and Testing, Deployment, and Maintenance.
[Link] Explanation of the Chosen Methodology
The Waterfall model was chosen because the requirements of the system were well
understood and stable at the onset of the project. Its structured nature makes it easy to
manage, document, and review at each stage. Each phase produces tangible deliverables that
serve as inputs to the next, ensuring traceability from requirements through to deployment.
Additionally, it suits academic projects with defined timelines and supervisor checkpoints.
Page 3 of 7
4.3.2 Software Development Tools and Technologies
Category Tool / Technology Purpose
Frontend Framework React 19 with TanStack Start Building the user interface and routing
Styling Tailwind CSS v4 Utility-first responsive styling
Build Tool Vite 7 Bundling and development server
Language TypeScript Type-safe application code
Backend TanStack Server Functions Server-side business logic and RPC
Database PostgreSQL (Lovable Cloud) Persistent relational data storage
Authentication Lovable Cloud Auth User identity and session management
Version Control Git / GitHub Source code management
IDE Visual Studio Code Code editing and debugging
Diagramming [Link] / Lucidchart DFD, ERD, and Use Case diagrams
4.3.3 System Modules / Components
[Link] Authentication Module
Functionality Description: Handles user registration, login, logout, password reset, and session
management. It enforces password policies, hashes credentials, and issues secure tokens used
by other modules to authorize requests.
[Link] Record Management Module
Functionality Description: Provides full CRUD operations on the core records of the system. It
validates user input, enforces ownership rules, and updates the database through the data
access layer.
[Link] Transaction Module
Functionality Description: Processes business transactions, maintains their state, and ensures
consistency through database transactions and validation rules.
[Link] Reporting Module
Functionality Description: Aggregates data and produces user-facing and administrative reports
in PDF and CSV formats. It supports filtering by date range, user, and status.
Page 4 of 7
[Link] Administration Module
Functionality Description: Provides administrators with the ability to manage users, configure
system parameters, and review audit logs.
4.3.4 Database Design and Implementation
[Link] Database Schema
The database is implemented in PostgreSQL. The following tables represent the principal
entities of the system.
Table Column Type Constraints
users user_id UUID PRIMARY KEY
users name VARCHAR(120) NOT NULL
users email VARCHAR(160) UNIQUE, NOT NULL
users password_hash TEXT NOT NULL
users role VARCHAR(20) DEFAULT 'user'
records record_id UUID PRIMARY KEY
records user_id UUID FK -> users(user_id)
records title VARCHAR(200) NOT NULL
records description TEXT
records created_at TIMESTAMP DEFAULT now()
transactions transaction_id UUID PRIMARY KEY
transactions user_id UUID FK -> users(user_id)
transactions amount NUMERIC(12,2) NOT NULL
transactions status VARCHAR(20) NOT NULL
transactions date TIMESTAMP DEFAULT now()
4.4 System Implementation
4.4.1 Development Environment Setup
The development environment was configured on a Windows/Linux workstation with the
following components installed: [Link] (LTS), the Bun package manager, Git, Visual Studio
Page 5 of 7
Code with TypeScript and ESLint extensions, and access to a Lovable Cloud project for the
backend, database, and authentication services. The repository was cloned, dependencies
installed via the package manager, and the development server started locally for iterative
development.
4.4.2 Module / Component Integration
After each module was implemented and unit-tested in isolation, it was integrated with the
others through clearly defined interfaces. The frontend communicates with the backend via
typed server functions, and the backend communicates with the database through a single
data-access layer. Integration was carried out incrementally to allow early detection of
interface mismatches and data inconsistencies.
4.4.3 Data Population
To enable realistic testing, the database was seeded with representative sample data, including
a small number of users with different roles, a set of records owned by those users, and a series
of historical transactions. Seed scripts were written so that the dataset could be regenerated on
demand.
4.4.4 Testing and Quality Assurance
[Link] Unit Testing
Each function and component was tested in isolation using an automated testing framework.
Tests verified input validation, edge cases, and expected return values. A target of at least 80%
code coverage was set for critical modules.
[Link] Integration Testing
Integration tests verified that the modules cooperate correctly. For example, tests ensured that
creating a transaction through the API correctly updates the database and that the reporting
module retrieves the updated values.
[Link] System Testing
System testing was performed on the fully integrated application to validate end-to-end
scenarios against the requirements specification. This included functional flows, performance
checks under expected load, and security checks such as authentication bypass attempts.
4.4.5 Bug Fixing and Issue Resolution
Defects discovered during testing were logged in an issue tracker with a clear description, steps
to reproduce, severity, and priority. Each issue was assigned, fixed on a separate branch,
reviewed, and merged after passing the relevant tests. Regression tests were re-run after every
fix.
Page 6 of 7
4.4.6 User Acceptance Testing (UAT)
Selected end users were invited to test the system in a staging environment that mirrored
production. They executed predefined scenarios and provided structured feedback through a
UAT form. Issues raised were triaged and addressed before final deployment, and the users
formally signed off the system once their acceptance criteria were met.
4.4.7 System Deployment
The system was deployed to a production environment hosted on Lovable Cloud. The
deployment process involved building the optimized production bundle, applying database
migrations, configuring environment variables and secrets, and publishing the application to a
public URL. Post-deployment smoke tests were carried out to verify that the live system
behaves identically to the staging environment, and monitoring was enabled to observe
runtime health, errors, and performance.
Page 7 of 7