Senin, 16 Februari 2026

https://www.youtube.com/watch?v=uAEpLatfHMM

https://www.youtube.com/watch?v=oqae5CChqhw

Import Data

https://www.youtube.com/watch?v=l2yErmeFQE0&list=PLjF3Xd4E0q3rLERjL35WN55N3V3E4y7Ak

https://www.youtube.com/watch?v=ybYUwEFRYF0&list=PLjF3Xd4E0q3rLERjL35WN55N3V3E4y7Ak&index=3

Belajar Python 1

https://www.youtube.com/watch?v=HSAm6s10G7g&list=PLZS-MHyEIRo59lUBwU-XHH7Ymmb04ffOY&index=3

https://www.python.org/

https://id.wikihow.com/Menjalankan-Berkas-Python-dengan-Command-Prompt-di-Windows

https://www.youtube.com/watch?v=EmbRUPtRAXk&list=PL3uuG4lYbnOyIHDsoSd5kn-Am-ZchdMJy

https://www.youtube.com/watch?v=Bty__TK2u6w

Minggu, 15 Februari 2026

Software Development - Tahapan Requirement Engineering

https://drive.google.com/file/d/1f2j6nSxcs2PgGNtjNovshjCO-0HaRRlM/view?usp=drive_link

https://chatgpt.com/c/69911a01-4cb8-8324-a4e0-93730503d826

Problem Identification ↓ Requirement Engineering ↓ SRS ↓ System Analysis ↓ Architecture Design ↓ Database Design ↓ Backend & Frontend Design ↓ Integration ↓ Testing & Deployment

TAHAPAN REQUIREMENT ENGINEERING

Requirement Engineering terdiri dari lima tahap utama:


Elicitation → Analysis → Specification → Validation → Management

Kelima tahap ini bersifat iteratif, bukan linear kaku. Dalam praktik nyata, sering terjadi pengulangan antar tahap.

1️⃣ ELICITATION (Penggalian Kebutuhan)

📌 Definisi

Proses mengidentifikasi dan mengumpulkan kebutuhan sistem dari stakeholder.

🎯 Tujuan

Memahami kebutuhan bisnis
Menggali ekspektasi stakeholder
Mengidentifikasi masalah sistem lama
Menemukan kebutuhan eksplisit & implisit

🎭 Aktivitas Utama

Interview
Workshop
Observasi lapangan
Kuesioner
Prototyping awal
Analisis dokumen lama

📌 Jenis Kebutuhan yang Dikumpulkan

Business Requirement
User Requirement
System Requirement

⚠️ Tantangan

Stakeholder tidak mampu menjelaskan kebutuhan secara jelas
Kebutuhan saling bertentangan
Kebutuhan tersembunyi (implicit requirement)

📌 Output

Raw requirement list
Stakeholder list
Catatan wawancara
Daftar masalah sistem

2️⃣ ANALYSIS (Analisis Kebutuhan)

📌 Definisi

Proses menyaring, mengklarifikasi, dan memodelkan requirement agar tidak ambigu.

🎯 Tujuan

Menghilangkan duplikasi
Mengatasi konflik requirement
Mengidentifikasi prioritas
Memastikan feasibility (teknis & bisnis)

🔍 Aktivitas

Requirement classification (FR & NFR)
Conflict resolution
Prioritization (MoSCoW)
Modeling (Use Case, Activity Diagram)
Feasibility analysis

📊 Contoh Klasifikasi

Functional Requirement

Sistem harus menyimpan data transaksi

Non-Functional Requirement

Response time < 2 detik

⚠️ Risiko Jika Tidak Dianalisis

Ambiguity
Scope creep
Sistem tidak realistis

📌 Output

Requirement yang telah diperjelas
Prioritas requirement
Model analisis (Use Case list)

3️⃣ SPECIFICATION (Spesifikasi Kebutuhan)

📌 Definisi

Tahap mendokumentasikan requirement dalam format formal dan terstruktur.

🎯 Tujuan

Membuat dokumen resmi
Menghindari interpretasi berbeda
Menjadi kontrak antara client & developer

📑 Format Umum

1. Functional Requirement (FR)

FR-01: Sistem harus menyediakan login pengguna.

2. Non-Functional Requirement (NFR)

NFR-01: Sistem harus memiliki uptime 99%.

📌 Karakteristik Requirement yang Baik (SMART)

Specific
Measurable
Achievable
Relevant
Testable

📌 Output

Dokumen SRS
Requirement specification document
Requirement Traceability Matrix

4️⃣ VALIDATION (Validasi Kebutuhan)

📌 Definisi

Memastikan requirement benar, lengkap, dan sesuai kebutuhan stakeholder.

🎯 Tujuan

Menghindari kesalahan sebelum coding
Memastikan semua stakeholder sepakat
Mengurangi rework

🛠 Metode Validasi

Requirement review meeting
Walkthrough document
Prototype demonstration
Checklist verification
Test-case derivation

📋 Checklist Validasi

Kriteria	Pertanyaan
Lengkap?	Semua kebutuhan sudah dicatat?
Konsisten?	Tidak ada konflik?
Testable?	Bisa diuji?
Jelas?	Tidak ambigu?

📌 Output

Requirement yang disetujui (baseline)
Dokumen final untuk tahap desain

5️⃣ MANAGEMENT (Manajemen Requirement)

📌 Definisi

Mengelola perubahan requirement selama siklus hidup proyek.

🎯 Tujuan

Mengendalikan perubahan
Menghindari scope creep
Menjaga stabilitas proyek

🔄 Proses Change Management


Change Request
   ↓
Impact Analysis
   ↓
Approval
   ↓
Update Document

📊 Contoh Perubahan

Awal:

Tidak ada fitur diskon

Owner meminta:

Tambah fitur promo

Tim melakukan:

Analisis dampak database
Update SRS
Update estimasi waktu

📌 Tools Requirement Management

Jira
Trello
Azure DevOps
Git issue tracking

🔁 Sifat Iteratif Requirement Engineering

Requirement Engineering tidak berhenti setelah SRS selesai.

Dalam Agile:


Backlog Refinement → Sprint Planning → Review → Update Requirement

Dalam Waterfall:
Perubahan dilakukan melalui formal change request.

📊 RINGKASAN TAHAPAN

Tahap	Fokus	Output
Elicitation	Menggali kebutuhan	Raw requirement
Analysis	Klarifikasi & prioritas	Requirement terstruktur
Specification	Dokumentasi formal	SRS
Validation	Verifikasi & persetujuan	Baseline requirement
Management	Mengelola perubahan	Updated requirement

Software Development - Requirement Engineering

https://drive.google.com/file/d/13WOXwYPHIxrWh9R9vjVJAmMC0ZwHdM-A/view?usp=drive_link

Problem Identification ↓ Requirement Engineering ↓ SRS ↓ System Analysis ↓ Architecture Design ↓ Database Design ↓ Backend & Frontend Design ↓ Integration ↓ Testing & Deployment

REQUIREMENT ENGINEERING

📌 Definisi

Requirement Engineering adalah proses sistematis untuk:

Mengidentifikasi kebutuhan sistem
Mengumpulkan kebutuhan dari stakeholder
Menganalisis dan menyaring kebutuhan
Mendokumentasikan kebutuhan secara formal
Memvalidasi kebutuhan sebelum sistem dikembangkan

Requirement Engineering menjawab pertanyaan:
“Apa yang harus dibangun?” sebelum masuk ke “Bagaimana cara membangunnya?”

🎯 Tujuan Requirement Engineering

Memastikan sistem sesuai kebutuhan bisnis
Menghindari kesalahan desain sejak awal
Mengurangi risiko perubahan besar di tengah proyek
Menjadi dasar penyusunan SRS
Menjadi referensi tim developer, tester, dan stakeholder

🔄 TAHAPAN REQUIREMENT ENGINEERING

Requirement Engineering bukan hanya mengumpulkan kebutuhan, tetapi melibatkan beberapa tahap:


Elicitation → Analysis → Specification → Validation → Management

Pada pembahasan ini fokus pada tahap awal:

🎯 Tahapan Mengumpulkan Kebutuhan Sistem dari Stakeholder

🎭 STAKEHOLDER

Stakeholder adalah pihak yang memiliki kepentingan terhadap sistem.

1️⃣ User

Contoh:

Pelanggan
Operator sistem

Fokus:

Kemudahan penggunaan
Kecepatan akses
Kejelasan informasi

2️⃣ Owner / Business Owner

Fokus:

Efisiensi operasional
Peningkatan pendapatan
Laporan dan analitik
Return on Investment (ROI)

3️⃣ Admin

Fokus:

Kemudahan pengelolaan data
Kontrol sistem
Monitoring transaksi

4️⃣ IT Team

Fokus:

Maintainability
Scalability
Security
Integrasi sistem

5️⃣ Regulator

Fokus:

Kepatuhan hukum
Perlindungan data pribadi
Standar keamanan sistem

🛠 METODE PENGUMPULAN REQUIREMENT

Berikut metode yang umum digunakan dalam praktik profesional.

1️⃣ Interview

📌 Definisi

Percakapan terstruktur dengan stakeholder untuk menggali kebutuhan.

📌 Tujuan

Mendapatkan informasi mendalam
Memahami pain point
Mengetahui ekspektasi sistem

📌 Kelebihan

Detail dan kontekstual
Bisa menggali kebutuhan tersembunyi

📌 Kekurangan

Subjektif
Bergantung pada kemampuan interviewer

2️⃣ Workshop

📌 Definisi

Diskusi kelompok terstruktur dengan berbagai stakeholder.

📌 Tujuan

Menyamakan persepsi
Menghindari konflik requirement
Mendapatkan konsensus

📌 Output

Requirement yang disepakati bersama

3️⃣ Kuesioner

📌 Definisi

Pengumpulan data melalui pertanyaan tertulis.

📌 Cocok untuk:

Banyak responden
User skala besar

📌 Kelebihan

Efisien
Terstruktur

📌 Kekurangan

Kurang mendalam

4️⃣ Prototyping

📌 Definisi

Membuat model awal sistem (mockup/wireframe).

📌 Tujuan

Memvalidasi kebutuhan
Mengurangi kesalahan interpretasi

📌 Manfaat

Stakeholder lebih mudah memahami sistem
Mengurangi ambiguity

5️⃣ Observasi Lapangan

📌 Definisi

Mengamati langsung proses bisnis yang sedang berjalan.

📌 Tujuan

Memahami sistem AS-IS
Menemukan masalah nyata

📌 Kelebihan

Data objektif
Mengungkap kebutuhan yang tidak disadari stakeholder

📌 OUTPUT REQUIREMENT ENGINEERING

Setelah proses pengumpulan selesai, hasilnya harus terdokumentasi secara formal.

1️⃣ Daftar Kebutuhan Sistem

Contoh format:

Functional Requirement

Sistem harus menyediakan login
Sistem harus menyimpan transaksi

Non-Functional Requirement

Sistem harus responsif
Sistem harus aman

2️⃣ Prioritas Kebutuhan

Menggunakan metode seperti:

MoSCoW Method

Kategori	Arti
Must Have	Wajib
Should Have	Penting
Could Have	Tambahan
Won’t Have	Tidak sekarang

Contoh:

Requirement	Prioritas
Login	Must
Dashboard laporan	Should
Dark mode	Could

3️⃣ Dokumen Requirement Awal

Dokumen ini biasanya berisi:

Ringkasan kebutuhan bisnis
Daftar functional requirement
Daftar non-functional requirement
Stakeholder list
Constraint
Assumption

Dokumen ini menjadi dasar penyusunan SRS formal.

Software Development - Problem Identification

https://drive.google.com/file/d/1rrCrkrHp0IjhcuD2D3iRztYD9njL-kpH/view?usp=drive_link

Problem Identification ↓ Requirement Engineering ↓ SRS ↓ System Analysis ↓ Architecture Design ↓ Database Design ↓ Backend & Frontend Design ↓ Integration ↓ Testing & Deployment

Sistem Pemesanan Makanan Online untuk UMKM

Tahap ini adalah fondasi rekayasa perangkat lunak.
Kesalahan di tahap ini akan berdampak ke seluruh siklus pengembangan.

🎯 TUJUAN IDENTIFIKASI MASALAH

Memahami:

Masalah bisnis yang sebenarnya
Proses operasional saat ini (AS-IS)
Hambatan pertumbuhan
Kebutuhan nyata stakeholder

Prinsip penting:
Jangan membangun sistem berdasarkan asumsi teknis, tetapi berdasarkan masalah bisnis yang terverifikasi.

🔍 AKTIVITAS IDENTIFIKASI MASALAH

1️⃣ Observasi Proses Bisnis (AS-IS Analysis)

📌 Tujuan

Memahami bagaimana sistem berjalan saat ini.

📋 Kondisi UMKM (Manual System)

Alur pemesanan yang terjadi:


Pelanggan kirim pesan WhatsApp
        ↓
Admin membalas manual
        ↓
Pesanan dicatat di buku
        ↓
Dapur menerima informasi via lisan
        ↓
Admin hitung total manual
        ↓
Pelanggan transfer
        ↓
Admin konfirmasi manual

🔎 Temuan Observasi

1. Proses Tidak Terstandarisasi

Format pesanan berbeda-beda
Admin harus membaca chat satu per satu

2. Human Error Tinggi

Salah catat jumlah
Salah hitung total
Lupa mencatat pesanan

3. Tidak Ada Database Terpusat

Data pelanggan tidak tersimpan
Riwayat transaksi tidak terdokumentasi

4. Tidak Real-Time

Dapur sering terlambat menerima pesanan
Tidak ada notifikasi otomatis

📊 Dampak Operasional

Masalah	Dampak
Manual input	Lambat
Tidak terstruktur	Sulit analisis
Tidak ada laporan	Owner tidak tahu performa
Chat menumpuk	Customer experience buruk

2️⃣ Interview Stakeholder

Stakeholder utama:

Owner UMKM
Admin kasir
Pelanggan tetap
Staff dapur

🎙 Hasil Interview – Owner

Keluhan utama:

Tidak tahu menu mana paling laris
Sulit menghitung omzet harian
Tidak ada laporan bulanan otomatis
Ketergantungan pada admin

🎙 Hasil Interview – Admin

Keluhan:

Chat terlalu banyak saat jam sibuk
Sering salah hitung
Harus copy-paste alamat manual

🎙 Hasil Interview – Pelanggan

Keluhan:

Lama dibalas
Tidak tahu status pesanan
Tidak ada katalog menu rapi

3️⃣ Identifikasi Pain Point

Dari observasi dan interview, ditemukan pain point berikut:

🔴 Pain Point 1: Inefisiensi Operasional

1 admin hanya mampu menangani ±20 order/jam
Pada jam sibuk terjadi bottleneck

🔴 Pain Point 2: Kesalahan Perhitungan

Total salah
Diskon lupa diterapkan
Ongkir tidak konsisten

🔴 Pain Point 3: Tidak Ada Insight Bisnis

Owner tidak memiliki:

Data penjualan per hari
Produk terlaris
Repeat customer rate

🔴 Pain Point 4: Skalabilitas Rendah

Jika pesanan meningkat:

Admin harus ditambah
Biaya operasional meningkat

🔴 Pain Point 5: Customer Experience Rendah

Tidak ada tracking
Tidak ada konfirmasi otomatis
Tidak ada sistem terstruktur

4️⃣ Analisis Gap Sistem Lama (Gap Analysis)

📊 Perbandingan AS-IS vs TO-BE

Aspek	AS-IS (Manual)	TO-BE (Digital System)
Pencatatan	Buku/Chat	Database
Perhitungan	Manual	Otomatis
Laporan	Tidak ada	Real-time dashboard
Proses	Lambat	Otomatis
Skalabilitas	Rendah	Tinggi

📌 Gap Utama

Tidak ada sistem terpusat
Tidak ada automasi
Tidak ada analitik
Tidak ada integrasi data

📌 OUTPUT TAHAP IDENTIFIKASI MASALAH

1️⃣ Problem Statement

UMKM mengalami inefisiensi operasional dalam proses pemesanan makanan karena sistem masih dilakukan secara manual melalui WhatsApp dan pencatatan buku, sehingga menyebabkan kesalahan pencatatan, lambatnya pelayanan, tidak tersedianya data analitik, serta keterbatasan skalabilitas bisnis.

2️⃣ Business Objective

Tujuan bisnis yang ingin dicapai:

Meningkatkan efisiensi pemrosesan pesanan minimal 50%
Mengurangi human error hingga <5%
Menyediakan laporan penjualan real-time
Meningkatkan kapasitas order tanpa menambah SDM
Meningkatkan kepuasan pelanggan

3️⃣ High-Level Solution

Mengembangkan sistem pemesanan makanan berbasis web dengan fitur:

Registrasi & login pelanggan
Katalog produk digital
Keranjang belanja otomatis
Checkout otomatis
Dashboard admin
Laporan penjualan real-time
Database terpusat