Skripsi Mini Series Part 4: System Analysis and Design (Analisis dan Perancangan Sistem)

1. What is Chapter 4: System Analysis and Design (BAB IV: Analisis dan Perancangan Sistem)?

Chapter 4 is usually the longest chapter in a JTI Polinema thesis (skripsi), and for good reason: it is where a vague idea becomes a buildable blueprint. It has four subsections:

This chapter is pure software engineering: everything you learned in the UML Mini Series applies directly here. If you have not read that series yet, start there. This part assumes you already know how to read a Use Case, Activity, Sequence, and Class diagram, and it assumes you remember two of that series’ key lessons: login belongs in a diagram as a precondition, not as its own use case, and CRUD operations should never be modelled as separate use cases.

1. Apa Itu BAB IV: Analisis dan Perancangan Sistem?

BAB IV biasanya adalah bab terpanjang dalam skripsi JTI Polinema, dan dengan alasan yang jelas: di sinilah ide yang kabur menjadi cetak biru yang dapat dibangun. Bab ini memiliki empat subbab:

Bab ini murni rekayasa perangkat lunak: semua yang Anda pelajari di Seri Mini UML berlaku langsung di sini. Jika Anda belum membaca seri itu, mulailah dari sana; bagian ini mengasumsikan Anda tahu cara membaca diagram Use Case, Activity, Sequence, dan Class, termasuk bagaimana seri itu memperlakukan login sebagai prasyarat bukan use case, dan mengapa operasi CRUD tidak boleh dimodelkan sebagai use case terpisah.

2. Why Getting System Analysis and Design Right Matters

What is it?

This chapter translates Chapter 1’s scope and Chapter 3’s methodology into diagrams and specifications precise enough that Chapter 5 can be built directly from them, with no ambiguity left to resolve mid-implementation.

Why does it matter?

• It is the contract between design and code. Every class in your Class Diagram should appear in Chapter 5; if implementation invents classes never designed here, your design was incomplete.
• It is where the case for Action Pattern becomes visible, not just asserted. Showing the Fat Controller alternative as a conceptual Class Diagram, side by side with the Action Pattern design you will actually build, makes the structural difference concrete before a single line of code exists.
• Scope and Limitations (Batasan Masalah) from Chapter 1 is enforced here. Anything outside your stated scope should not appear in a single diagram in this chapter; if it does, your scope has silently grown.
• A stated precondition must be implemented consistently, or it is a self-claim. If Chapter 4 declares “User is authenticated” as a precondition, the database schema and code in Chapter 5 must actually scope data to that user; otherwise the precondition is decoration, not a real constraint on the design.
• Test scenarios planned here (Section 4.4) prevent test-after-the-fact bias. Defining “what correct behaviour looks like” before writing code keeps your Black Box tests honest.

When do you use it?

Draft this immediately after Chapter 3 is stable, since architecture and metric decisions in Chapter 3 directly shape what you diagram here.

Where does it fit?

Chapter 4’s output is consumed entirely by Chapter 5: every diagram of the implemented design here should map to a corresponding class, method, or view built there. The conceptual Fat Controller diagrams are not built anywhere; they exist only to make Chapter 6’s later discussion concrete.

How do you create one?

1. Identify actors, state any preconditions (such as authentication), and turn Research Questions (Rumusan Masalah) into functional/non-functional requirements.
2. Draw the system architecture you will actually build, grouped into clear layers rather than a flat chain of boxes.
3. Draw one Use Case Diagram. Group CRUD operations under one use case (e.g. “Manage X”), not one bubble per operation, and keep the behaviour identical to the user regardless of internal architecture. Add a short Use Case Description table (actor, description, precondition, postcondition) for immediate context.
4. Draw one Activity Diagram per use case, and let that single diagram carry the use case’s genuine decision logic (for example, a switch/case fork for a use case that bundles several operations). Do not mechanically produce one diagram per functional requirement, and do not force every branch to repeat the same level of detail when that would only make the diagram harder to read.
5. Draw a Sequence Diagram contrasting how responsibility flows for a representative scenario.
6. Draw two Class Diagrams as the finalisation of the design: one conceptual illustration of the Fat Controller alternative (clearly labelled as not implemented or measured), and one for the Action Pattern design you will actually build and measure. Class comes last because it synthesises everything the Activity and Sequence diagrams established into one static structure, exactly the order the UML Mini Series itself uses (Activity, then Sequence, then Class).
7. Sketch interface wireframes.
8. Write Blackbox and UAT test-scenario tables.

2. Mengapa Menulis Analisis dan Perancangan dengan Benar Itu Penting?

Apa itu?

Bab ini menerjemahkan ruang lingkup BAB I dan metodologi BAB III menjadi diagram dan spesifikasi yang cukup presisi sehingga BAB V dapat dibangun langsung darinya, tanpa menyisakan ambiguitas yang harus diselesaikan di tengah implementasi.

Mengapa penting?

• Ini adalah kontrak antara desain dan kode. Setiap kelas di Class Diagram Anda seharusnya muncul di BAB V; jika implementasi mengarang kelas yang tidak pernah dirancang di sini, desain Anda tidak lengkap.
• Di sinilah alasan pemilihan Action Pattern menjadi terlihat, bukan sekadar diklaim. Menampilkan alternatif Fat Controller sebagai Class Diagram konseptual, berdampingan dengan desain Action Pattern yang benar-benar akan Anda bangun, membuat perbedaan struktural menjadi konkret sebelum satu baris kode pun ada.
• Batasan Masalah (BAB I) ditegakkan di sini. Apa pun di luar ruang lingkup yang dinyatakan seharusnya tidak muncul di satu pun diagram bab ini; jika muncul, ruang lingkup Anda diam-diam telah berkembang.
• Prasyarat yang dinyatakan harus diimplementasikan secara konsisten, atau itu hanya klaim sepihak. Jika BAB IV menyatakan “User terautentikasi” sebagai prasyarat, skema database dan kode di BAB V harus benar-benar membatasi data ke user tersebut; jika tidak, prasyarat itu hanya hiasan, bukan batasan nyata pada desain.
• Skenario pengujian yang direncanakan di sini (Bagian 4.4) mencegah bias pengujian yang dilakukan setelah implementasi. Mendefinisikan “seperti apa perilaku yang benar” sebelum menulis kode menjaga Black Box test Anda tetap objektif dan valid.

Kapan digunakan?

Susun segera setelah BAB III stabil, karena keputusan arsitektur dan metrik di BAB III langsung membentuk apa yang Anda gambarkan di sini.

Di mana tempatnya?

Keluaran BAB IV sepenuhnya digunakan oleh BAB V (Implementasi): setiap diagram desain yang diimplementasikan di sini seharusnya terpetakan ke kelas, method, atau view yang dibangun di sana. Diagram Fat Controller konseptual tidak dibangun di mana pun; diagram itu hanya ada agar pembahasan BAB VI nanti menjadi konkret.

Bagaimana membuatnya?

1. Identifikasi aktor, nyatakan prasyarat apa pun (seperti autentikasi), dan ubah Rumusan Masalah menjadi kebutuhan fungsional/nonfungsional.
2. Gambar arsitektur sistem yang benar-benar akan Anda bangun, dikelompokkan ke dalam lapisan yang jelas, bukan rantai datar berupa kotak-kotak.
3. Gambar satu Use Case Diagram. Kelompokkan operasi CRUD di bawah satu use case (mis. “Kelola X”), bukan satu oval per operasi, dan jaga perilakunya identik bagi pengguna terlepas dari arsitektur internal. Tambahkan tabel Use Case Description singkat (aktor, deskripsi, prasyarat, pascasyarat) untuk konteks langsung.
4. Gambar satu Activity Diagram per use case, merinci logika keputusan sesungguhnya di dalam satu diagram itu (mis. melalui percabangan switch/case untuk use case yang menggabungkan beberapa operasi); hindari secara mekanis menghasilkan satu diagram per kebutuhan fungsional, dan hindari memaksa setiap cabang mengulang detail yang sama jika itu hanya akan membuat diagram lebih sulit dibaca.
5. Gambar Sequence Diagram yang mengontraskan bagaimana tanggung jawab mengalir untuk skenario yang representatif.
6. Gambar dua Class Diagram sebagai finalisasi desain: satu ilustrasi konseptual alternatif Fat Controller (diberi label jelas sebagai tidak diimplementasikan maupun diukur), dan satu untuk desain Action Pattern yang benar-benar akan Anda bangun dan ukur. Class diletakkan terakhir karena mensintesis semua yang ditetapkan Activity dan Sequence Diagram menjadi satu struktur statis, persis urutan yang digunakan Seri Mini UML sendiri (Activity, lalu Sequence, lalu Class).
7. Sketsa wireframe antarmuka.
8. Tulis tabel skenario pengujian Blackbox dan UAT.

3. 4.1 Requirements Analysis (Analisis Kebutuhan)

Actor Identification (Identifikasi Aktor)

Precondition (Prasyarat)

User is authenticated. Every use case below assumes a logged-in User, using Laravel’s default authentication scaffolding. Following the same pattern taught in the UML Mini Series, login is not modelled as its own use case: it is a precondition, checked once per request via middleware, rather than a goal the User pursues for its own sake. A full registration or account-management system falls outside Scope and Limitations (Part 1); what is in scope is making sure every todo is correctly scoped to its owning User. That is why the database schema (Chapter 5, Section 5.2) includes a user_id column, and why every Action queries only the authenticated User’s data.

Functional Requirements (Kebutuhan Fungsional)

Directly traced from the core functionalities named in Part 1’s continuous-example section:

FR-1 through FR-4 are grouped under a single use case, Manage Todos, in the design below (Section 4.2); modelling each as its own use case bubble would repeat the CRUD-as-use-case mistake the UML Mini Series warns against.

Non-Functional Requirements (Kebutuhan Nonfungsional)

Common mistake to avoid: NFRs describe the system’s quality attributes (performance, usability, compatibility). They are not the same as the research metrics defined in Chapter 3, Section 3.5. Cyclomatic complexity, coupling, and test coverage are your research instruments for evaluating the implementation against literature thresholds; they are not requirements the finished system must satisfy on their own. Keep the two lists separate.

Naming a verification method for every NFR matters: an NFR with no way to check it is an unverifiable claim, not a requirement.

3. 4.1 Analisis Kebutuhan

Identifikasi Aktor

Prasyarat (Precondition)

User telah terautentikasi. Setiap use case di bawah mengasumsikan User yang sudah login, menggunakan scaffolding autentikasi default Laravel. Mengikuti pola yang sama yang diajarkan di Seri Mini UML, login tidak dimodelkan sebagai use case tersendiri: login adalah prasyarat, diperiksa sekali per request melalui middleware, bukan tujuan yang dikejar User demi dirinya sendiri. Membangun sistem registrasi/manajemen akun lengkap berada di luar Batasan Masalah (Bagian 1); yang ada dalam ruang lingkup adalah memastikan setiap todo dibatasi dengan benar ke User pemiliknya, itulah mengapa skema database (BAB V, Bagian 5.2) menyertakan kolom user_id dan setiap Action hanya mengueri data milik User yang terautentikasi.

Kebutuhan Fungsional

Ditelusuri langsung dari fungsionalitas inti yang disebutkan di bagian contoh berkelanjutan Bagian 1:

FR-1 hingga FR-4 dikelompokkan di bawah satu use case, Kelola Todo, dalam desain di bawah (Bagian 4.2); memodelkan masing-masing sebagai oval use case tersendiri akan mengulangi kesalahan CRUD-sebagai-use-case yang diperingatkan Seri Mini UML.

Kebutuhan Nonfungsional

Kesalahan umum yang harus dihindari: NFR mendeskripsikan atribut kualitas sistem (performa, usability, kompatibilitas). Ini bukan hal yang sama dengan metrik penelitian yang didefinisikan di BAB III, Bagian 3.5. Cyclomatic complexity, coupling, dan test coverage adalah instrumen penelitian Anda untuk mengevaluasi implementasi terhadap ambang batas literatur; bukan kebutuhan yang harus dipenuhi sistem jadi dengan sendirinya. Jaga kedua daftar tetap terpisah.

Menyebutkan metode verifikasi untuk setiap NFR itu penting: NFR tanpa cara untuk memeriksanya adalah klaim yang tidak dapat diverifikasi, bukan kebutuhan.

4. 4.2 System Design (Perancangan Sistem)

Architecture Diagram (Arsitektur Diagram)

This is the architecture we actually build, grouped into explicit layers rather than a flat chain of same-styled boxes, so the grouping itself communicates the layered structure.

In the conceptual Fat Controller alternative discussed in Chapter 2, the Application Layer would not exist at all: TodoController in the Presentation Layer would call the Model directly, absorbing all validation and business logic itself.

Use Case Diagram

The behaviour below is identical regardless of internal architecture: a Use Case Diagram describes what the user can do, not how the system is structured internally. Login is not shown as a use case; it is the precondition stated in Section 4.1, and access control (a User can only see and act on their own todos) is enforced by every use case, not a use case in its own right.

Why only two use cases, not five: Create, Edit, Toggle completion, and Delete are all facets of one goal, managing one’s todo list, so they are grouped under Manage Todos and detailed as one Activity Diagram below, exactly the fix the UML Mini Series recommends for the “CRUD as separate use cases” mistake. Filter Todos stays separate because it is a distinct goal (organising/viewing), not a mutation of data.

Why no <<include>> or <<extend>>: the original Campus Registration example (UML Mini Series, Part 1) had a genuine mandatory sub-step (Make Payment, included by Enrol in Course) and a genuine optional extension (Manage Registration Period extends Manage Courses). This Todo application, by deliberate design (Scope and Limitations, Part 1), has neither: there is no external mandatory step comparable to payment, and no optional variant of Manage Todos worth its own bubble. Forcing an <<extend>> relationship in order to demonstrate the notation would itself repeat the over-modelling mistakes the UML Mini Series warns against. Not every system needs these relationships, and a simple one honestly shouldn’t have them.

Use Case Description

A short description table gives each use case immediate context, without needing the full step-by-step Use Case Scenario technique from the UML Mini Series, Part 2.

Activity Diagram: Manage Todos

One diagram, one use case. A switch/case fork represents the User’s choice of action, and each branch gets only as much detail as it needs. Create and Delete carry real decision logic (validation, plus a confirm/cancel step), so they are shown in full. Edit follows the identical validation shape as Create, so it is noted rather than redrawn; toggling completion has no branching worth showing, it flips whichever way the todo currently isn’t.

Activity Diagram: Filter Todos

Filter Todos has no real branching, so its diagram is honestly short: it would be dishonest padding to invent decision logic that does not exist just to make the diagram look more substantial.

Sequence Diagram: Create Todo (Fat Controller Illustration vs. Action Pattern Implementation)

Create is the representative scenario for the Sequence Diagram, since it shows the clearest contrast in how far each design delegates responsibility.

Class Diagram: Fat Controller (Conceptual Illustration, Not Implemented or Measured)

This is the finalisation of the conceptual alternative: everything the Activity and Sequence diagrams implied about it, synthesised into one static structure. It is never built, tested, or measured.

Class Diagram: Action Pattern (Implemented and Measured)

This is the finalisation of the design we actually build in Chapter 5 and measure in Chapter 6: the static structure that the Manage Todos / Filter Todos Activity Diagrams and the Create Todo Sequence Diagram all converge on.

Notice the qualitative difference already visible before writing a line of code: the Fat Controller illustration has one class doing everything, including its own ad hoc user-scoping; the Action Pattern design distributes responsibility across five single-purpose classes, each depending on only Todo, with the authenticated user’s ID passed in explicitly rather than assumed. This is exactly what Chapter 6’s metrics will later quantify, against literature thresholds rather than against the conceptual illustration directly.

4. 4.2 Perancangan Sistem

Arsitektur Diagram

Ini adalah arsitektur yang benar-benar dibangun oleh penelitian ini, dikelompokkan ke dalam lapisan eksplisit alih-alih rantai datar berisi kotak-kotak bergaya sama, sehingga pengelompokan itu sendiri mengomunikasikan struktur berlapis.

Pada alternatif Fat Controller konseptual yang dibahas di BAB II, Application Layer ini tidak akan ada sama sekali: TodoController di Presentation Layer akan memanggil Model secara langsung, menangani sendiri semua validasi dan business logic.

Use Case Diagram

Perilaku di bawah ini identik terlepas dari arsitektur internal: Use Case Diagram mendeskripsikan apa yang bisa dilakukan pengguna, bukan bagaimana sistem terstruktur secara internal. Login tidak ditampilkan sebagai use case; login adalah prasyarat yang dinyatakan di Bagian 4.1, dan kontrol akses (User hanya bisa melihat dan bertindak atas todo miliknya sendiri) ditegakkan oleh setiap use case, bukan use case tersendiri.

Mengapa hanya dua use case, bukan lima: Buat, Edit, Ubah Status Selesai, dan Hapus semuanya adalah segi dari satu tujuan, mengelola daftar todo miliknya sendiri, sehingga dikelompokkan di bawah Kelola Todo dan dirinci sebagai satu Activity Diagram di bawah, persis perbaikan yang direkomendasikan Seri Mini UML untuk kesalahan “CRUD sebagai use case terpisah”. Filter Todo tetap terpisah karena merupakan tujuan yang berbeda (mengorganisasi/melihat), bukan mutasi data.

Mengapa tidak ada <<include>> atau <<extend>>: contoh Sistem Pendaftaran Kampus asli (Seri Mini UML, Bagian 1) memiliki sublangkah wajib sesungguhnya (Lakukan Pembayaran, di-include oleh Daftar Mata Kuliah) dan ekstensi opsional sesungguhnya (Kelola Periode Pendaftaran memperluas Kelola Mata Kuliah). Aplikasi Todo ini, karena desain yang disengaja (Batasan Masalah, Bagian 1), tidak memiliki keduanya: tidak ada langkah wajib eksternal yang sebanding dengan pembayaran, dan tidak ada varian opsional dari Kelola Todo yang layak mendapat oval sendiri. Memaksakan relasi <<extend>> demi mendemonstrasikan notasinya akan mengulangi kesalahan over-modelling yang diperingatkan Seri Mini UML. Tidak semua sistem membutuhkan relasi ini, dan sistem sederhana memang sebaiknya tidak memilikinya.

Use Case Description

Tabel deskripsi singkat memberi setiap use case konteks langsung, tanpa membutuhkan teknik Use Case Scenario langkah-demi-langkah lengkap dari Seri Mini UML, Bagian 2.

Activity Diagram: Kelola Todo

Satu diagram, satu use case. Percabangan switch/case merepresentasikan pilihan aksi User; setiap cabang mendapat detail sebanyak yang dibutuhkannya saja. Buat dan Hapus memiliki logika keputusan sesungguhnya (validasi, dan langkah konfirmasi/batal), sehingga ditampilkan lengkap; Edit mengikuti bentuk validasi yang identik dengan Buat, sehingga dicatat alih-alih digambar ulang, dan Ubah Status Selesai tidak memiliki percabangan yang layak ditampilkan, statusnya cukup dibalik ke kondisi sebaliknya.

Activity Diagram: Filter Todo

Filter Todo tidak memiliki percabangan sesungguhnya, sehingga diagramnya memang singkat: akan menjadi penambahan yang menyesatkan jika mengarang logika keputusan yang tidak ada hanya agar diagram terlihat lebih substansial.

Sequence Diagram: Buat Todo (Ilustrasi Fat Controller vs. Implementasi Action Pattern)

Buat adalah skenario representatif untuk Sequence Diagram, karena menunjukkan kontras paling jelas seberapa jauh masing-masing desain mendelegasikan tanggung jawab.

Class Diagram: Fat Controller (Ilustrasi Konseptual, Tidak Diimplementasikan Maupun Diukur)

Ini adalah finalisasi alternatif konseptual: semua yang disiratkan Activity dan Sequence Diagram tentangnya, disintesis menjadi satu struktur statis. Diagram ini tidak pernah dibangun, diuji, atau diukur.

Class Diagram: Action Pattern (Diimplementasikan dan Diukur)

Ini adalah finalisasi desain yang benar-benar dibangun oleh penelitian ini di BAB V dan diukur di BAB VI: struktur statis tempat Activity Diagram Kelola Todo / Filter Todo dan Sequence Diagram Buat Todo semuanya bermuara.

Perhatikan perbedaan kualitatif yang sudah terlihat sebelum menulis satu baris kode: ilustrasi Fat Controller memiliki satu kelas yang melakukan segalanya, termasuk pembatasan user secara ad hoc miliknya sendiri; desain Action Pattern mendistribusikan tanggung jawab ke lima kelas bertujuan tunggal, masing-masing hanya bergantung pada Todo, dengan ID user terautentikasi dilewatkan secara eksplisit, bukan diasumsikan. Inilah persis yang akan dikuantifikasi oleh metrik BAB VI nanti, terhadap ambang batas literatur, bukan terhadap ilustrasi konseptual secara langsung.

5. 4.3 Interface Design (Perancangan Desain Antarmuka)

A thesis typically includes actual mockup screenshots (Figma, Balsamiq). For this series we describe the wireframe structurally: translate this into a real mockup tool for your own report.

The interface is a controlled constant, and it does not change between the conceptual Fat Controller illustration and the built Action Pattern implementation, since only the backend structure varies between them.

6. 4.4 Test Scenario Design (Rancangan Skenario Pengujian)

Plan test scenarios before implementation. These scenarios validate the Action Pattern implementation, the only thing actually built and run.

Blackbox Testing Scenario Plan (Rencana Skenario Blackbox Testing)

UAT Scenario Plan (Rencana Skenario UAT)

5. 4.3 Perancangan Desain Antarmuka

Skripsi biasanya menyertakan tangkapan layar mockup nyata (Figma, Balsamiq). Untuk seri ini, wireframe dideskripsikan secara struktural: terjemahkan ini ke tool mockup nyata untuk laporan Anda sendiri.

Antarmuka adalah konstanta terkontrol, dan tidak berubah antara ilustrasi konseptual Fat Controller dan implementasi Action Pattern yang dibangun, karena hanya struktur backend yang bervariasi di antara keduanya.

6. 4.4 Rancangan Skenario Pengujian

Rencanakan skenario pengujian sebelum implementasi. Skenario ini memvalidasi implementasi Action Pattern, satu-satunya hal yang benar-benar dibangun dan dijalankan.

Rencana Skenario Blackbox Testing

Rencana Skenario UAT

7. Common Mistakes in Chapter 4

7. Kesalahan Umum dalam BAB IV

8. What Comes Next?

With the design fully worked out (a layered architecture, the consolidated Use Case Diagram with its description table, one Activity Diagram per use case, the Sequence Diagram, and the conceptual-versus-implemented Class Diagrams as the finalisation, plus wireframes and test scenarios), we are ready to build. Part 5 covers Chapter 5: Implementation and Testing (BAB V: Implementasi dan Pengujian): setting up the environment, implementing the database (including the user_id scoping designed here), and writing the actual PHP code for the Action Pattern implementation. That chapter will show exactly where the low complexity we designed here comes from.

8. Apa yang Akan Datang Selanjutnya?

Dengan desain yang tuntas dikerjakan (arsitektur berlapis, Use Case Diagram yang telah dikonsolidasikan beserta tabel deskripsinya, satu Activity Diagram per use case, Sequence Diagram, dan Class Diagram konseptual-versus-diimplementasikan sebagai finalisasi, ditambah wireframe dan skenario pengujian), penelitian ini siap memasuki tahap membangun. Bagian 5 membahas BAB V (Implementasi dan Pengujian): menyiapkan lingkungan, mengimplementasikan database termasuk pembatasan user_id yang dirancang di sini, dan menulis kode PHP sesungguhnya untuk implementasi Action Pattern, menunjukkan persis dari mana kompleksitas rendah yang dirancang di sini berasal.