Sheet A-00 · Cover

Building a Modern Information System

A developer's thought process before a single line of code gets written — from business problem to production.

Business First

Understand the problem.

Design

Plan before coding.

Build

Laravel + MySQL + API.

Maintain

Improve continuously.

PROJECT: SYSTEM DEV. LIFECYCLE DRAWN BY: M. A. HAIKAL SHEET: A-00 OF A-10 REV: 03

Sheet A-01

System Development Workflow

Ten stages, followed in order. Each one produces an artifact the next stage depends on — skip a stage and the ones after it inherit its gaps.

flowchart TB subgraph R1[ ] direction LR A(Business Problem) --> B(Requirement Gathering) --> C(PRD) --> D(SRS) end subgraph R2[ ] direction LR E(UI/UX) --> F(Database) --> G(API Design) --> H(Development) end subgraph R3[ ] direction LR I(Testing) --> J(Deployment) --> K(Maintenance) end D -.-> E H -.-> I style R1 fill:transparent,stroke:none style R2 fill:transparent,stroke:none style R3 fill:transparent,stroke:none

01 · PROBLEM

02 · REQUIREMENTS

03 · PRD

04 · SRS

05 · UI/UX

06 · DATABASE

07 · API DESIGN

08 · DEVELOPMENT

09 · TESTING

10 · DEPLOY / MAINTAIN

Sheet A-02

Business Analysis

No system is built in a vacuum. Before any schema or endpoint exists, the actual problem — and who feels it — has to be nailed down, or the build solves the wrong thing well.

What I Analyze

→Identify business pain points — the cost of doing nothing, in time or money.
→Interview stakeholders — the request and the real need rarely match.
→Study current workflow — including the spreadsheets and workarounds already patching the gap.
→Define success metrics — a number or outcome the system is measured against later.
→Prioritize value over features — cut anything that doesn't move the metric above.

Questions I Ask

?Who are the users, and how technical are they day to day?
?What problem are we solving — and for whom, specifically?
?What data is required, and who owns it today?
?Any integration needed with systems already in place?
?How will success be measured once this ships?

Sheet A-03

PRD & SRS

Two documents, two audiences. The PRD is written so a stakeholder can approve it; the SRS is written so a developer can build from it without asking follow-up questions.

PRD

Product Requirement Document — focuses on business goals. Answers "why are we building this" and "what does done look like".

· Objectives
· Target users
· Features
· Timeline

SRS

Software Requirement Specification — focuses on technical implementation. Translates the PRD into constraints a system has to satisfy.

· Functional requirements
· Non-functional requirements
· Database
· API
· Security

Sheet A-04

Database Design

The schema is the load-bearing wall. A relationship modeled wrong here is expensive to unwind later — every query, migration, and feature above it inherits the mistake.

erDiagram USER ||--o{ ORDER : creates ORDER ||--|{ ORDER_ITEM : contains PRODUCT ||--o{ ORDER_ITEM : referenced

Primary Key

Uniquely identifies each row.

Foreign Key

Enforces the relationship between tables.

Normalization

Removes duplicate data, keeps updates consistent.

Indexes

Trades write speed for faster reads on lookups.

Sheet A-05

REST API

The contract between frontend and backend. Predictable verbs and status codes mean the client can guess how the API behaves before reading a single line of its code.

sequenceDiagram Browser->>Laravel: GET /users Laravel->>MySQL: Query MySQL-->>Laravel: Result Laravel-->>Browser: JSON

Method	Purpose	Typical response
GET	Retrieve data	200 OK
POST	Create data	201 Created
PUT / PATCH	Update data	200 OK
DELETE	Delete data	204 No Content

Sheet A-06

Typical Laravel Architecture

MVC keeps concerns apart: routes decide where a request goes, controllers decide what happens, models own the data, and views or JSON decide what comes back.

flowchart LR U(User)-->F(Frontend) F-->R(Route) R-->C(Controller) C-->M(Model) M-->DB[(MySQL)] C-->V(View/API)

Route

Matches a URL to logic.

Controller

Coordinates the request.

Model

Owns data and validation.

Sheet A-07

Deployment

Shipping is a pipeline, not a moment. Every commit runs the same checks before it's allowed anywhere near production, so a bad push is caught upstream instead of by a user.

flowchart LR Git-->GitHub-->CICD[CI/CD]-->Server-->Production

GIT · commit & version

GITHUB · code review

CI/CD · test & build

SERVER · provision

PRODUCTION · monitor

Sheet A-08

Testing & QA

Confidence in a system is measured, not assumed. Each layer of testing catches a different class of mistake — the fewer tests at the bottom, the more expensive the ones caught at the top.

01 · FAST, MANY

Unit Tests

Checks one function or method in isolation. Runs in milliseconds, so it runs on every save.

02 · MODERATE

Integration Tests

Confirms the controller, model, and database actually agree with each other.

03 · SLOW, FEW

End-to-End Tests

Drives the real UI like a user would, catching what the layers below can't see together.

RULE OF THUMB — MOST TESTS AT THE UNIT LEVEL, FEWEST AT END-TO-END.

Sheet A-09

Security

Named once in the SRS, checked at every stage after. Security isn't a feature to bolt on before launch — it's a constraint that shapes the schema, the API, and the deploy pipeline from the start.

Authentication

Confirms who is making the request.

Authorization

Confirms what that user is allowed to do.

Input Validation

Never trusts data arriving from the client.

Encryption in Transit

HTTPS everywhere, no exceptions.

Rate Limiting

Slows down brute-force and abuse attempts.

Audit Logging

Keeps a record of who changed what, when.

Sheet A-10 · Closing Note

Developer Mindset

01 Understand before coding.
02 Design before implementation.
03 Keep code maintainable.
04 Validate data early.
05 Think about security and scalability.
06 Documentation is part of development.