SYSTEM ANALYSISFEATURED

Six Integrated Academic Systems

System analysis for six interconnected academic sub-systems at Institut Teknologi Sains Bandung — authoring the full PRD and building all prototype screens that doubled as the project's gap-analysis instrument.

Our team at ITSB when go live ceremonial

CONTEXT / PROBLEM

Six systems, one institution, and an accreditation domain I had to learn first.

Institut Teknologi Sains Bandung ran its academic operations across separated processes, much of it still not digital at all. The institution wanted what a modern campus runs on: integrated systems that make life easier for administrative staff, lecturers, and students at the same time. Six interconnected web sub-systems were scoped — LP3B, SPM (internal quality assurance), SARPRAS (facilities), Tracer Study, LMS, and Library. I joined as System Analyst on a three-month contract within the Cyber Campus delivery team.

The hard part wasn't the volume. It was LP3B. The system had to run accreditation simulations, and I didn't know how accreditation worked. Not vaguely — not at all. That meant learning the PPEPP quality cycle under Permendikbud No. 5/2020, how internal standards map onto BAN-PT and LAM instruments, how evidence validity and expiry are tracked, and how a readiness score is even calculated, before I could write a single functional requirement. The module pulls data from across the entire system, so getting the domain wrong wouldn't have produced a small bug. It would have produced a system that told a rector their institution was ready when it wasn't.

APPROACH

Document first, prototype second, and let the prototype find what the document missed.

Decompose the PRD into function-grouped modules

Rather than documenting six systems as six monoliths, I broke each into modules grouped by function, so the structure of the document matched the structure the developers would build. The SPM PRD alone carries a domain glossary, four personas with explicit access limits, 19 user stories with acceptance criteria, 74 functional requirements, 12 non-functional requirements, a five-role access matrix, system integration mapping, and a risk-and-assumption register.

Prototype every module in HTML

The project had no UI/UX designer. I built the prototype layer myself, using Claude to generate working HTML screens directly from my own specifications — 50 screens for SARPRAS and 58 for SPM, covering asset management, stock opname, borrowing and penalties, electronic signature with QR verification, the PPEPP cycle, internal audit findings and follow-up, accreditation simulation, and reporting.

Run gap analysis iteratively

Each prototype round exposed functions the document hadn't handled. Two to three iterations per module before sign-off. The prototype wasn't decoration; it was the instrument that found the gaps.

RESULT / IMPACT

Delivered on schedule — and invited back to the go-live five months after the contract ended.

Interconnected sub-systems specified

108

HTML prototype screens across SARPRAS and SPM

Functional requirements in the SPM PRD alone

The project delivered on schedule. My contract ended in February 2026 at the three-month mark; development continued and the systems went live. In July 2026 the client invited me back to attend the go-live ceremony at the ITSB campus in person — five months after I'd stopped being paid. The systems are now in institutional change management, with additional features being identified in live operation. What I'd carry forward: prototyping from your own PRD is the fastest gap-analysis instrument I've used, and it removed the need for a separate design role on this project. But it also means the analyst is grading their own homework. On a project with real design capacity I'd want the prototype reviewed by someone who didn't write the requirements.

HAVE SOMETHING SIMILAR?

Let's talk about the scope