Senin, 16 Februari 2026

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

Software Development

https://drive.google.com/file/d/1kBUG7fVYyf5bSGaSaFPjeLYBEqUaIJZ9/view?usp=drive_link

https://notebooklm.google.com/notebook/aa90cb8a-990f-46a7-aa65-fdf54cf21e0c?artifactId=eac3296b-2923-4ed2-84c5-172a3f551baf

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

PROSES PENGEMBANGAN PERANGKAT LUNAK (END-TO-END SDLC)

Pengembangan perangkat lunak bukan sekadar coding, tetapi proses rekayasa sistem yang terstruktur dan terdokumentasi.

Secara umum mengikuti tahapan:


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

1️⃣ IDENTIFIKASI MASALAH

🎯 Tujuan

Memahami masalah bisnis sebelum menulis satu baris kode pun.

🔍 Aktivitas

Observasi proses bisnis
Interview stakeholder
Identifikasi pain point
Analisis gap sistem lama

📌 Output

Problem statement
Business objective
High-level solution

⚠️ Prinsip Penting

Jangan langsung menawarkan solusi teknis sebelum memahami masalah bisnis.

2️⃣ REQUIREMENT GATHERING

Tahapan mengumpulkan kebutuhan sistem dari stakeholder.

🎭 Stakeholder

User
Owner
Admin
IT team
Regulator

🛠 Metode

Interview
Workshop
Kuesioner
Prototyping
Observasi lapangan

📌 Output

Daftar kebutuhan sistem
Prioritas kebutuhan
Dokumen requirement awal

3️⃣ SRS (Software Requirements Specification)

SRS adalah dokumen formal yang menjelaskan apa yang harus dilakukan sistem, bukan bagaimana caranya.

📑 Struktur Umum SRS

1. Pendahuluan

Tujuan dokumen
Ruang lingkup sistem
Definisi istilah

2. Deskripsi Umum

Perspektif produk
Karakteristik pengguna
Batasan sistem

3. Functional Requirements

Contoh:

ID	Requirement
FR1	Sistem harus memungkinkan user login
FR2	Sistem harus menyimpan transaksi

4. Non-Functional Requirements

Kategori	Contoh
Performance	Response < 2 detik
Security	Enkripsi password
Availability	99% uptime
Scalability	10.000 user concurrent

5. Use Case Specification

Menjelaskan interaksi user dengan sistem.

📌 Output

Dokumen SRS lengkap (baseline kontrak antara client dan developer).

4️⃣ ANALISIS SISTEM

Tahapan menguraikan requirement menjadi model sistem.

🎭 Identifikasi Aktor

Primary actor
Secondary actor

🔄 Use Case Analysis

Menentukan:

Main success scenario
Alternate flow
Exception flow

📊 Activity Diagram (Deskriptif)


User Login
↓
Validasi
↓
Akses Dashboard

⚠️ Constraint Analysis

Budget
Timeline
Infrastruktur
Regulasi

5️⃣ PERANCANGAN ARSITEKTUR SISTEM

Menentukan struktur teknis sistem.

📌 Pilihan Arsitektur

Arsitektur	Kapan digunakan
Monolith	Sistem kecil-menengah
MVC	Web application
Microservices	Enterprise & scalable
Clean Architecture	Maintainability tinggi

🏗 Client-Server Model


Client (Browser)
    ↓
Application Server
    ↓
Database Server

🌐 REST Architecture

Karakteristik:

Stateless
JSON-based
HTTP method (GET, POST, PUT, DELETE)

☁ Deployment Model

On-premise
Cloud (AWS/GCP/Azure)
Containerized (Docker)
CI/CD pipeline

6️⃣ DESAIN DATABASE

Database design bertujuan memastikan:

Konsistensi data
Integritas relasi
Efisiensi query

📊 ERD (Konsep)


User (1) ────< Order (1) ────< OrderDetail >──── (1) Product

📌 Normalisasi

1NF → Data atomic
2NF → No partial dependency
3NF → No transitive dependency

📌 Contoh Struktur Tabel

Users

id (PK)
name
email (unique)
password_hash
role

7️⃣ DESAIN BACKEND

Backend bertanggung jawab pada:

Business logic
Validasi
Data processing
Security

📌 Pilihan Teknologi

Node.js + Express
Java Spring Boot
PHP Laravel
Python Django

📂 Struktur MVC


/controllers
/models
/routes
/middlewares
/config

📌 Contoh Endpoint


GET    /api/products
POST   /api/login
POST   /api/orders

🔐 Security Layer

JWT authentication
Password hashing (bcrypt)
Role-based access control
Input sanitization

8️⃣ DESAIN FRONTEND

Frontend bertanggung jawab pada:

UI/UX
Interaksi user
Integrasi API

🎨 UI/UX Principle

Simplicity
Consistency
Accessibility
Responsive design

📌 Arsitektur Frontend

Multi-page application
SPA (Single Page Application)

Modern enterprise → SPA (React/Vue/Angular)

📦 Komponen

Navbar
Form
Table
Modal
Dashboard

🔄 Integrasi API


fetch('/api/products')
.then(res => res.json())
.then(data => render(data));

9️⃣ INTEGRASI SISTEM

Menjamin komunikasi antar layer berjalan baik.

🔁 Alur Request-Response


Frontend → HTTP Request → Backend
Backend → Query DB → Response JSON
Frontend → Render UI

📦 Struktur JSON Standar


{
  "status": "success",
  "data": {},
  "message": ""
}

🔟 TESTING STRATEGY

Testing dilakukan berlapis.

🧪 1. Unit Testing

Mengujicoba fungsi secara individual.

Contoh:

Validasi login
Perhitungan total transaksi

🔗 2. Integration Testing

Mengujicoba antar modul:

API ↔ Database
Frontend ↔ Backend

👥 3. System Testing

Menguji sistem secara keseluruhan.

✔ 4. User Acceptance Testing (UAT)

Checklist berbasis requirement di SRS.

E Arsip

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

Prompt Sheet to Web

https://script.google.com/macros/s/AKfycbxWvvE6mCfdYD52dTdCk5iEU_8J7idMWlrEvRPfgB_WNJsqckuhz3pVMl7Mc8ZmcUg9UQ/exec

https://docs.google.com/spreadsheets/d/1kTa9kzd1ah2D563XtigCw9Wsu1SrbXWXWBLIwJJCHgw/edit?gid=0#gid=0

Code.gs

// ===============================

// CONFIG

// ===============================

const SPREADSHEET_ID = "ISI_SPREADSHEET_ID";

const SHEET_NAME = "ISI_NAMA_SHEET";

// ===============================

// ENTRY POINT (SPA)

// ===============================

function doGet(e) {

const page = e.parameter.page || "home";

return HtmlService

.createHtmlOutput(htmlGenerate(page))

.setTitle("SPA Spreadsheet App")

.setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL);

}

// ===============================

// HTML GENERATOR

// ===============================

function htmlGenerate(page) {

return `

<!DOCTYPE html>

<html>

<head>

<title>SPA Spreadsheet</title>

<style>

body {

margin:0;

font-family: Arial, sans-serif;

background:#f4f6f9;

}

header {

background:#2c3e50;

color:white;

padding:15px;

display:flex;

justify-content:space-between;

}

nav a {

color:white;

margin-left:15px;

text-decoration:none;

}

.container {

padding:20px;

max-width:1200px;

margin:auto;

}

.card {

background:white;

padding:20px;

border-radius:10px;

box-shadow:0 4px 10px rgba(0,0,0,0.1);

}

.grid {

display:grid;

grid-template-columns: repeat(auto-fit,minmax(250px,1fr));

gap:20px;

}

table {

width:100%;

border-collapse:collapse;

}

th,td {

padding:10px;

border-bottom:1px solid #ddd;

}

th {

background:#2c3e50;

color:white;

}

.loading {

text-align:center;

padding:20px;

}

.error {

color:red;

text-align:center;

}

</style>

</head>

<body>

<div>Spreadsheet SPA</div>

<nav>

<a href="#" onclick="navigate('table')">Table</a>

<a href="#" onclick="navigate('cards')">Cards</a>

</nav>

</header>

</div>

// ===============================

// SPA ROUTER

// ===============================

function navigate(page){

history.pushState({}, "", "?page=" + page);

renderPage(page);

}

window.onpopstate = function(){

const params = new URLSearchParams(window.location.search);

const page = params.get("page") || "home";

renderPage(page);

};

// ===============================

// INITIAL LOAD

// ===============================

document.addEventListener("DOMContentLoaded", function(){

const params = new URLSearchParams(window.location.search);

const page = params.get("page") || "${page}";

renderPage(page);

});

// ===============================

// RENDER PAGE

// ===============================

function renderPage(page){

const app = document.getElementById("app");

if(page === "home"){

app.innerHTML = \`

<h2>Welcome</h2>

<p>Aplikasi SPA berbasis Google Spreadsheet.</p>

</div>

\`;

}

if(page === "table"){

app.innerHTML = '<div class="loading">Loading...</div>';

loadData("table");

}

if(page === "cards"){

app.innerHTML = '<div class="loading">Loading...</div>';

loadData("cards");

}

// ===============================

// FETCH DATA

// ===============================

function loadData(viewType){

google.script.run

.withSuccessHandler(function(response){

if(response.status !== "success"){

showError(response.message);

return;

}

if(viewType === "table"){

renderTable(response.data);

} else {

renderCards(response.data);

}

})

.withFailureHandler(function(error){

showError(error.message);

})

.getData();

}

function showError(message){

document.getElementById("app").innerHTML =

'<div class="error">Error: '+ message +'</div>';

}

// ===============================

// TABLE VIEW

// ===============================

function renderTable(data){

if(data.length === 0){

document.getElementById("app").innerHTML = "No Data";

return;

}

const headers = Object.keys(data[0]);

let html = '<div class="card"><table><thead><tr>';

headers.forEach(h => html += '<th>'+h+'</th>');

html += '</tr></thead><tbody>';

data.forEach(row => {

html += '<tr>';

headers.forEach(h => html += '<td>'+row[h]+'</td>');

html += '</tr>';

});

html += '</tbody></table></div>';

document.getElementById("app").innerHTML = html;

}

// ===============================

// CARD VIEW

// ===============================

function renderCards(data){

let html = '<div class="grid">';

data.forEach(row => {

html += '<div class="card">';

for(let key in row){

html += '<p><strong>'+key+':</strong> '+row[key]+'</p>';

}

html += '</div>';

});

html += '</div>';

document.getElementById("app").innerHTML = html;

}

</script>

</body>

</html>

}

// ===============================

// API METHOD

// ===============================

function getData(){

try{

const sheet = SpreadsheetApp

.openById(SPREADSHEET_ID)

.getSheetByName(SHEET_NAME);

const values = sheet.getDataRange().getValues();

const headers = values.shift();

const data = values.map(row => {

let obj = {};

headers.forEach((h,i)=> obj[h] = row[i]);

return obj;

});

return { status:"success", data:data };

} catch(err){

return { status:"error", message: err.toString() };

}

Senin, 16 Februari 2026

Belajar Python 1

Minggu, 15 Februari 2026

Software Development - Tahapan Requirement Engineering

TAHAPAN REQUIREMENT ENGINEERING

1️⃣ ELICITATION (Penggalian Kebutuhan)

📌 Definisi

🎯 Tujuan

🎭 Aktivitas Utama

📌 Jenis Kebutuhan yang Dikumpulkan

⚠️ Tantangan

📌 Output

2️⃣ ANALYSIS (Analisis Kebutuhan)

📌 Definisi

🎯 Tujuan

🔍 Aktivitas

📊 Contoh Klasifikasi

Functional Requirement

Non-Functional Requirement

⚠️ Risiko Jika Tidak Dianalisis

📌 Output

3️⃣ SPECIFICATION (Spesifikasi Kebutuhan)

📌 Definisi

🎯 Tujuan

📑 Format Umum

1. Functional Requirement (FR)

2. Non-Functional Requirement (NFR)

📌 Karakteristik Requirement yang Baik (SMART)

📌 Output

4️⃣ VALIDATION (Validasi Kebutuhan)

📌 Definisi

🎯 Tujuan

🛠 Metode Validasi

📋 Checklist Validasi

📌 Output

5️⃣ MANAGEMENT (Manajemen Requirement)

📌 Definisi

🎯 Tujuan

🔄 Proses Change Management

📊 Contoh Perubahan

📌 Tools Requirement Management

🔁 Sifat Iteratif Requirement Engineering

📊 RINGKASAN TAHAPAN

Software Development - Requirement Engineering

REQUIREMENT ENGINEERING

📌 Definisi

🎯 Tujuan Requirement Engineering

🔄 TAHAPAN REQUIREMENT ENGINEERING

🎯 Tahapan Mengumpulkan Kebutuhan Sistem dari Stakeholder

🎭 STAKEHOLDER

1️⃣ User

2️⃣ Owner / Business Owner

3️⃣ Admin

4️⃣ IT Team

5️⃣ Regulator

🛠 METODE PENGUMPULAN REQUIREMENT

1️⃣ Interview

📌 Definisi

📌 Tujuan

📌 Kelebihan

📌 Kekurangan

2️⃣ Workshop

📌 Definisi

📌 Tujuan

📌 Output

3️⃣ Kuesioner

📌 Definisi

📌 Cocok untuk:

📌 Kelebihan

📌 Kekurangan

4️⃣ Prototyping

📌 Definisi

📌 Tujuan

📌 Manfaat

5️⃣ Observasi Lapangan

📌 Definisi

📌 Tujuan

📌 Kelebihan

📌 OUTPUT REQUIREMENT ENGINEERING

1️⃣ Daftar Kebutuhan Sistem