Catatan UTS Sistem Informasi IF3141 · Teknik Informatika ITB · 2025/26
IF3141 · Sistem Informasi · Teknik Informatika ITB

UTS Sistem Informasi
Comprehensive Study Notes

Konsep SI · Data & Organisasi · Strategi · BPMN · SDLC · Requirements
Konsep SI Data & Informasi Strategi Organisasi Proses Bisnis & BPMN SDLC Requirement Engineering
References: Lecture slides IF3141 ITB · Laudon & Laudon · Ward & Peppard · Whitman & Mattord
01 · Konsep Sistem Informasi

Pengenalan & Konsep Dasar Sistem Informasi

Memahami apa itu SI, komponen-komponennya, tujuan, dan posisinya dalam organisasi.

Definisi Sistem Informasi

Sistem Informasi (SI) adalah kombinasi dari berbagai komponen pendukung baik teknologi, organisasi, maupun proses bisnis yang dibangun manusia untuk mengumpulkan, mengkreasikan, dan mendistribusikan informasi khususnya dalam suatu organisasi agar organisasi tersebut bertahan dan berkembang secara kompetitif.

Poin Kunci

Tidak semua SI menggunakan Teknologi Informasi. SI bisa berjalan dengan prosedur manual — TI hanya salah satu komponen pendukungnya, bukan syarat mutlak.

Empat Komponen SI

SI terdiri dari empat komponen utama yang saling berinteraksi:

Sistem Informasi TEKNOLOGI (Technoware) HW, SW, Jaringan Data + Teknologi Pendukung ORGANISASI (Organoware) Struktur, Kebijakan, Prosedur Bisnis (SOP) SUMBER DAYA DATA Raw data, processed info SDM (Brainware) Pengguna (customer, pelayan, kasir...) Pengelola (sysadmin) Pengembang
Gambar 1. Empat Komponen Utama Sistem Informasi

Terminologi Kunci: Komponen SI

TechnowareTeknologi yang digunakan — HW, SW, jaringan (Infoware) + teknologi pendukung lainnya OrganowareDimensi organisasional: struktur, kebijakan, dan prosedur bisnis (SOP) BrainwareSumber daya manusia: pengguna, pengelola (sysadmin, helpdesk), dan pengembang sistem InfowareData — baik raw data maupun informasi yang sudah diolah — sebagai sumber daya kritis

Tujuan Sistem Informasi

SI harus menyediakan informasi bagi organisasi dengan memenuhi tujuh kriteria kualitas informasi (COBIT-based):

Efektif Informasi relevan, tepat waktu, konsisten Efisien Sumber daya optimal / tidak boros Kerahasiaan (C) Perlindungan dari akses tidak sah Integritas Akurasi & kelengkapan informasi Ketersediaan (A) Siap setiap saat dibutuhkan Kepatuhan Sesuai hukum & regulasi Keterpercayaan (Reliability) Informasi tepat untuk tata kelola mgmt
Gambar 2. Tujuh Tujuan / Kriteria Kualitas Sistem Informasi

Fungsi dan Peran Dasar SI

SI menjalankan tiga fungsi fundamental yang mendukung seluruh lapisan organisasi:

Fungsi SI (by layer)
  • Pelaksana (Operasional): Mengolah transaksi harian
  • Manajemen Menengah: Pelaporan & analisis untuk keputusan
  • Manajemen Puncak: Analisa bisnis kompetitif & strategis
Tiga Misi Utama SI
  • Mengingat yang lalu — menyimpan data histori sebagai rekaman
  • Mengatasi keadaan saat ini — merekam transaksi & automasi
  • Menyiapkan untuk masa depan — fasilitasi pengambilan keputusan & perencanaan

Sistem Informasi dan Sistem Kerja (Alter)

Sistem Kerja adalah sistem di mana orang dan/atau mesin membentuk proses bisnis menggunakan informasi, teknologi, dan sumber daya lainnya untuk menghasilkan produk/layanan. Sistem Informasi adalah subset dari sistem kerja, di mana proses bisnisnya berfokus pada menangkap, mengirim, menyimpan, mengambil, memanipulasi, dan menayangkan informasi.

Penyelarasan SI, TI, dan Bisnis

STRATEGI BISNIS • Keputusan bisnis • Objectives & arahan • Perubahan Dimana arah bisnis & Mengapa? STRATEGI SI • Berbasis bisnis • Orientasi permintaan • Fokus pada aplikasi Apa yang dibutuhkan? STRATEGI TI • Berbasis aktivitas • Orientasi suplai • Fokus pada teknologi Bagaimana caranya?
Gambar 3. Penyelarasan Bisnis – SI – TI (Ward & Peppard)
02 · Data, Informasi & Pengetahuan

Hierarki Data → Informasi → Pengetahuan

Memahami perbedaan data, informasi, dan pengetahuan, serta bagaimana organisasi dan manajemen beroperasi.

Hierarki Data–Informasi–Pengetahuan–Kebijaksanaan

WISDOM KNOWLEDGE INFORMATION DATA Pengetahuan yang diakumulasikan & diaplikasikan Info + pola, pengalaman Data + konteks & makna Fakta mentah VOLUME VALUE
Gambar 4. Piramida Data — semakin ke atas semakin bernilai, semakin kecil volumenya

Definisi Lengkap

Data (Datum)Satu atau lebih simbol yang merepresentasikan sesuatu — fakta mentah, belum terformat. Bentuknya bisa berupa: nilai terformat, teks, citra (image), audio, dan video. InformasiData yang telah diolah menjadi bentuk yang berarti bagi penerimanya dan bermanfaat dalam pengambilan keputusan (Davis, 1999). Shannon & Weaver: informasi = jumlah ketidakpastian yang dikurangi. PengetahuanKombinasi dari naluri, gagasan, aturan, dan prosedur yang mengarahkan tindakan atau keputusan (Alter, 1992). Informasi + pengalaman masa lalu + keahlian. WisdomPengetahuan yang diakumulasikan dan diaplikasikan secara bijaksana untuk situasi tertentu.
Contoh Klasik (Midterm Favourite!)

Data: 1.30 35 · 2.45 37 · 3.15 39
Informasi: Waktu dan suhu badan seseorang (dengan konteks/label)
Pengetahuan: Pasien ini mengalami kenaikan suhu progresif → kemungkinan demam
Wisdom: Berdasarkan pola ini + pengalaman klinis → berikan obat X dosis Y

Kandungan Informasi (Davis, 1999)

Informasi dapat bersifat: Benar/Salah, Baru (sepenuhnya baru bagi penerima), Tambahan (memperbaharui info yang ada), Korektif (mengoreksi info sebelumnya), atau Penegas (mempertegas info yang ada).

Atribut Kualitas Informasi

Dimensi Personal (3 dimensi)
  • Waktu — dapat diakses kapan diperlukan, menggambarkan periode yang relevan
  • Lokasi — dapat diakses di mana pun berada
  • Bentuk — dapat digunakan dan dimengerti (audio, video, citra, dll), bebas kesalahan
Dimensi Organisasional
  • Akurasi & presisi
  • Kelengkapan (completeness)
  • Ketepatan waktu (timeliness)
  • Relevansi dengan konteks bisnis
  • Konsistensi antar sumber

Siklus Informasi (Burch & Grudnitski, 1989)

MASUKAN (Data) PROSES (Model) KELUARAN (Informasi) PENERIMA → Tindakan → Keputusan Data (Ditangkap kembali) — Feedback BASIS DATA
Gambar 5. Siklus Informasi — Data masuk, diproses jadi informasi, digunakan untuk keputusan, menghasilkan data baru

Organisasi: Definisi dan Tipe

Organisasi adalah entitas yang memiliki tujuan bersama, terstruktur (tugas & tanggung jawab terbagi), berkomunikasi melalui struktur, dan diarahkan oleh manajemen [Mullins 1996].

Level Manajemen

TOP LEVEL — Strategic Planning CEO, COO, CIO, VP — Survival, pertumbuhan, efektivitas MIDDLE LEVEL — Management Control General Manager, Dept Manager — Implementasi kebijakan LOW / OPERATIONAL LEVEL Supervisor — Kegiatan operasional harian langsung KEAHLIAN Conceptual Human / Interpersonal Technical Skills
Gambar 6. Level Manajemen dan Keahlian yang Dibutuhkan

Proses Manajemen (POLC)

PlanningMenetapkan apa yang akan dikerjakan — penentuan tujuan dan cara pencapaian terbaik OrganizingMembuat pengaturan — penentuan bagaimana penyusunan organisasi dan aktivitas LeadingMemberikan arahan — proses memotivasi anggota organisasi agar planning dapat dijalankan ControllingMembuat aksi sesuai yang diinginkan — monitoring dan perbaikan aktivitas agar tujuan tercapai
Tujuan Manajemen

Pencapaian Tujuan Organisasi secara EFISIEN dan EFEKTIF

Efektif = mengerjakan pekerjaan yang benar (doing the right things)

Efisien = mengerjakan pekerjaan dengan benar (doing things right) — minimal sumber daya, tidak boros

Peran Manajer (Mintzberg)

Informational
  • Monitor
  • Disseminator
  • Spokesperson
Interpersonal
  • Figurehead
  • Leader
  • Liaison
Decisional
  • Entrepreneur
  • Disturbance handler
  • Resource allocator
  • Negotiator
03 · SI untuk Strategi Organisasi

Value Chain, Generic Strategies & Five Forces

Bagaimana SI digunakan sebagai senjata kompetitif untuk bertahan dan berkembang.

Value Chain Model (Porter, 1985)

Model Rantai Nilai menggambarkan bagaimana sebuah perusahaan menciptakan nilai bagi pelanggannya melalui serangkaian aktivitas yang saling berkaitan.

Konsep Margin

Margin = Value − Cost

Value = total pendapatan yang bersedia dibayar pembeli. Margin = selisih antara value dan biaya produksi.
FIRM INFRASTRUCTURE (Finance, Legal, Management) HUMAN RESOURCE MANAGEMENT TECHNOLOGY DEVELOPMENT (R&D, SI, IT) PROCUREMENT INBOUND LOGISTICS Receive & store OPERATIONS Transform inputs→outputs OUTBOUND LOGISTICS Distribute to customers MARKETING & SALES Attract & sell SERVICE After-sales support MARGIN ◀ AKTIVITAS PRIMER (Langsung buat nilai untuk pelanggan) AKTIVITAS PENDUKUNG (Fasilitasi aktivitas primer) ▶
Gambar 7. Value Chain Model — Porter (1985)

Tiga Strategi Generik (Porter)

StrategiDeskripsiCaraContoh
Cost Leadership Menawarkan produk serupa dengan harga lebih rendah dari pesaing Economies of scale, teknologi ekslusif, akses bahan baku, kurangi level layanan AirAsia, Walmart, Costco
Differentiation Menawarkan fitur unik/pembeda sehingga konsumen mau bayar lebih mahal Fitur khusus, kualitas unggul, desain inovatif, layanan luar biasa Apple iPhone, FedEx, McD
Focused Niche Menarget segmen kecil dengan preferensi khusus Cost focus (hemat di segmen) atau Differentiation focus (unik di segmen) Butik vintage plus-size, konsultan energi terbarukan startup

Five Forces Model (Porter)

Perusahaan harus memahami 5 kekuatan yang mempengaruhi industrinya untuk bertahan dan berkembang:

RIVALRY AMONG EXISTING COMPETITORS Kekuatan 1 THREAT OF NEW ENTRANTS Pendatang baru dengan kapasitas & ambisi baru THREAT OF SUBSTITUTES Produk/jasa yang memenuhi fungsi serupa BARGAINING POWER OF SUPPLIERS Kekuatan tawar pemasok BARGAINING POWER OF BUYERS Kekuatan tawar pembeli
Gambar 8. Porter's Five Forces Model — Lima kekuatan yang mempengaruhi industri
RivalryIntensitas persaingan — tergantung jumlah pesaing, pertumbuhan industri, hambatan keluar, komitmen pesaing New EntrantsHambatan masuk: economies of scale, switching costs, capital requirements, regulasi pemerintah, akses distribusi SubstitutesProduk yang memenuhi fungsi yang sama dengan cara berbeda (e.g., video call = substitute perjalanan bisnis) Supplier PowerKuat jika: sedikit pemasok, tidak ada pengganti, pemasok bisa integrasi ke depan Buyer PowerKuat jika: sedikit pembeli besar, banyak pemasok alternatif, pembeli bisa pindah dengan mudah
04 · Proses Bisnis & BPMN

Business Process Modeling Notation

Memahami proses bisnis, cara memodelkannya, dan semua simbol BPMN yang penting untuk ujian.

Definisi Proses Bisnis

Proses bisnis adalah kumpulan task atau aktivitas yang dilakukan secara sekuensial maupun paralel oleh orang maupun sistem, baik di dalam maupun di luar organisasi, untuk mencapai satu tujuan/goal bisnis tertentu [Butler Group]. Task terdefinisikan sebelumnya dan proses dapat dilakukan berulang.

Proses Bisnis yang Baik harus:

Efektif (capai tujuan), Efisien (minimal sumber daya), dan Adaptif (bisa beradaptasi dengan perubahan kebutuhan bisnis & pasar).

Elemen Kunci Proses Bisnis

CustomerOrang yang menerima dan menggunakan manfaat langsung dari produk/layanan hasil proses Products/ServicesKeluaran yang dihasilkan dari proses untuk customer Business ProcessKumpulan langkah/aktivitas yang dibangun dalam sistem ParticipantOrang yang melakukan langkah kerja dalam proses InformationYang digunakan partisipan untuk melakukan pekerjaannya TechnologyTI dan perangkat lain yang digunakan partisipan selama mengerjakan pekerjaan ContextLingkungan organisasional, kompetitif, teknikal & pengaturan sistem kerja InfrastructureSumber daya orang dan teknikal yang terkait sistem

Standar Pemodelan: Perbandingan

StandarKelebihan UtamaKekurangan UtamaBest For
BPMNStandar ISO, mudah dipahami bisnis & IT, mendukung automasiBisa rumit untuk proses besar, perlu pelatihanWorkflow bisnis, automasi
IDEF0Hierarkis, ICOM model (Input, Control, Output, Mechanism)Tidak intuitif, tidak ada timeline/flowEngineering & manufaktur besar
FlowchartPaling simple, mudah dibuat, fleksibelTidak standar, lemah representasi tanggung jawabHigh-level overview
ASMEStandar manufaktur, fokus efisiensi & waste reductionTidak untuk IT/automasi, tidak ada peran organisasiIndustrial/manufacturing

BPMN — Business Process Modeling Notation

Dikembangkan oleh BPMI, dikelola oleh OMG sejak 2005. Current version: 2.0. BPMN menghubungkan desain proses bisnis dan implementasinya, mendukung baik pengguna teknis maupun bisnis.

Core Elements BPMN

EVENTS Start Intermediate End Msg Start Timer Start ACTIVITIES Task Atomic work Sub-Process + Compound Service Task ⚙ Automated User Task 👤 Human actor GATEWAYS × XOR (Exclusive) One path only + AND (Parallel) All paths trigger OR (Inclusive) One or more paths POOL Lane A (Dept/Role) Lane B (Dept/Role) Pool = Participant/Org
Gambar 9. Simbol-simbol utama BPMN — Events, Activities, Gateways, Pools & Lanes

Terminologi BPMN Lengkap

Start EventLingkaran tipis — menandai dimulainya proses. Tidak ada incoming sequence flow. End EventLingkaran tebal — menandai berakhirnya proses. Tidak ada outgoing sequence flow. Intermediate EventLingkaran ganda — terjadi selama proses berlangsung (timer, message, error, dll). TaskKotak rounded — unit kerja atomic yang tidak dapat dipecah lebih lanjut dalam konteks ini. Sub-ProcessKotak dengan tanda "+" — aktivitas compound yang memiliki proses internal sendiri. Hanya reusable dalam parent process. XOR GatewayBerlian dengan "×" — exclusive decision, hanya satu path yang dipilih berdasarkan kondisi. AND GatewayBerlian dengan "+" — parallel split/join, semua path aktif secara bersamaan (paralel). OR GatewayBerlian dengan lingkaran — inclusive, satu atau lebih path bisa aktif berdasarkan kondisi. PoolKotak besar = graphical representation of a Participant in a Collaboration. Sequence flow tidak bisa keluar dari Pool. Lane (Swimlane)Sub-partisi dalam Pool — merepresentasikan departemen, peran, atau sistem (misal: Manager, ERP, CRM). Sequence FlowPanah solid — urutan eksekusi aktivitas dalam satu Pool. Message FlowPanah putus-putus — aliran pesan antar dua Pool yang berbeda. TIDAK boleh menghubungkan dalam Pool yang sama. Data ObjectIkon dokumen — informasi yang dibutuhkan/dihasilkan oleh aktivitas. AnnotationKomentar/catatan tambahan untuk klarifikasi elemen diagram.

Naming Conventions BPMN

  • Untuk task: gunakan verb + business object (contoh: "Issue Driver Licence", "Process Payment")
  • Untuk message events: object + past participle (contoh: "Invoice Received", "Claim Settled")
  • Untuk XOR split: beri label kondisi (contoh: "Stock Available?", "Policy Valid?")
  • Hindari generic verbs seperti "Handle", "Record", "Manage"

Contoh BPMN: Order-to-Cash Process

Deskripsi Proses

Purchase order masuk → cek stok → jika tersedia: konfirmasi, kirim invoice & kirim barang (paralel) → arsip pesanan. Jika tidak tersedia: tolak pesanan → arsip pesanan.

PO Received Check Stock × Available? Yes Confirm Order + Issue Invoice Ship Goods + Archive Order No Reject Order End
Gambar 10. BPMN Diagram: Order-to-Cash Process dengan XOR & AND Gateway

Common BPMN Mistakes

  • Missing start/end events — setiap proses HARUS punya start dan end event
  • Incorrect use of gateways — XOR ≠ AND, pastikan pilih yang tepat
  • Confusing message flow dengan sequence flow — message flow hanya antar Pool berbeda
  • Overcomplicated diagrams — modularisasi dengan sub-process jika perlu
  • Inconsistent naming conventions — ikuti standar verb+noun
05 · System Development Life Cycle

SDLC: Metodologi Pengembangan Sistem Informasi

Memahami tahapan, model-model, dan elemen SDLC dalam konteks pengembangan SI.

Definisi SDLC

System Development Life Cycle (SDLC) adalah metodologi terstruktur yang digunakan untuk mengembangkan sistem informasi, mencakup seluruh komponennya: Infrastructure, Applications & Software, Business Processes, Data & Information Management, Organizational Structure, dan Brainware.

Alasan Proyek Sistem Baru

  • Permintaan sistem dari user/organisasi
  • Peningkatan layanan (improved service)
  • Dukungan produk dan layanan baru
  • Peningkatan performa (better performance)
  • Kebutuhan informasi lebih banyak/akurat

Tahapan SDLC

PLANNING Feasibility Study ANALYSIS Requirements Engineering DESIGN Architecture & UI/UX DEVELOPMENT Coding & Infrastructure TESTING Unit, System, Acceptance IMPLEMENTATION Go-Live, Training MAINTENANCE Monitor & Upgrade
Gambar 11. Tahapan SDLC — dari Planning hingga Maintenance

Feasibility Study

Studi kelayakan adalah investigasi untuk mengevaluasi potensi keberhasilan proyek sebelum mulai dibangun. Hanya proyek yang memberikan ROI yang reasonable akan didukung.

TechnicalCan we build it? — Apakah teknologi yang dibutuhkan tersedia dan tim mampu menggunakannya? EconomicIs it worth it? — TCO (Total Cost of Ownership) vs tangible & intangible benefits OperationalWill users accept it? — Apakah pengguna akan mengadopsi sistem ini? RegulatoryIs it legal? — Apakah sesuai regulasi dan hukum yang berlaku? ScheduleCan we do it in time? — Apakah bisa diselesaikan dalam batasan waktu yang ada?

Elemen SDLC

Context

Aspek yang mempengaruhi bagaimana sistem dikembangkan: skill tim, lokasi tim, regulatory requirements, apakah persyaratan likely to change, kompleksitas sistem.

Lifecycle

Tahapan yang diikuti: Linear (sequential, step-by-step) atau Evolutionary (berkembang melalui prototyping progressif).

Tipe-tipe Model SDLC

WATERFALL Requirements Design Implementation Testing Deployment V-MODEL Requirements Architecture Module Design Coding Unit Test Integration Test Acceptance Test SPIRAL Plan Risk Analysis Evaluate Engineering
Gambar 12. Tiga model SDLC: Waterfall (linear cascade), V-Model (verification-driven), Spiral (risk-driven)
ModelTipeBest ForPros KunciCons Kunci
WaterfallLinearRequirements & solusi jelas, stabilTerstruktur, mudah manage milestoneKaku, software baru tersedia di akhir
V-ModelLinearSafety-critical, quality-intensive systemsTesting terencana sejak awal, kualitas tinggiMahal, lambat, perubahan cost-intensive
IncrementalLinear+Early partial releases dibutuhkanSoftware kerja lebih cepat, risiko bisa dimanageHard to manage parallel deliveries
IterativeEvolutionaryRequirements evolving, uncertainKolaborasi user tinggi, change lebih mudahScope creep risk, cost bisa lebih tinggi
SpiralEvolutionaryHigh-risk projectsRisk reduction, working system earlyScope creep, dokumentasi bisa terlupakan
AgileEvolutionaryFast-changing needs, startupFleksibel, delivery cepat, user involvementHard to control scope & cost

Roles dalam SDLC

Business Roles
  • Project Sponsor / SRO
  • Business Analyst
  • Domain Expert
  • End Users
Project Roles
  • Project Manager
  • Team Leader
  • Work Package Manager
Technical Roles
  • Technical Architect
  • Solution Developer
  • Solution Tester
  • Release Manager
  • DBA, SysAdmin
06 · Requirement Engineering

Rekayasa Kebutuhan

Framework untuk menemukan, menganalisis, mendokumentasikan, dan memvalidasi kebutuhan sistem.

Mengapa Requirement Engineering Penting?

Sekitar 60–70% kegagalan proyek IT disebabkan karena lemahnya penentuan kebutuhan, analisis, dan manajemen (Meta Group, 2003). Ketidaktepatan kebutuhan punya efek domino: kekeliruan user → kekeliruan sistem → kekeliruan desain → kekeliruan fungsi → kegagalan.

Cost of Errors — Prinsip 10x

Error yang ditemukan saat requirements = 1x cost. Error yang ditemukan saat design = 10x. Saat implementation = 100x. Saat operation = 1000x. Fix requirements early!

Framework Requirement Engineering

ELICITATION Discover & uncover requirements ANALYSIS Examine & refine "raw" requirements VALIDATION Review & sign-off before development further elicitation often needed
Gambar 13. Framework Requirement Engineering — tiga tahap yang sering berjalan iteratif

Peran dalam Requirements Engineering

Project SponsorPemilik proyek, pengambil keputusan final. Accountable for delivery of business benefit. ManagersOwners dari requirements individual — memiliki input ke proses dan otoritas atas relevansi requirement. Users (Process Workers)Yang bekerja dengan sistem existing — sumber informasi kunci tentang kebutuhan aktual. Domain ExpertsOrang dengan pandangan luas — bisa dari pengalaman di organisasi serupa atau konsultan domain. Project ManagerMenjaga scope, cost, dan timeline proyek — mengendalikan scope creep. Business AnalystsBertanggung jawab eliciting, documenting, analysing, dan managing requirements. TestersMereview requirements untuk memastikan mereka pada akhirnya testable. DevelopersMembutuhkan requirements yang baik dan jelas. Dalam Agile, mereka membantu detail requirements.

Requirements Elicitation

Elicitation adalah proses menemukan, mengungkap, dan memahami apa yang stakeholders butuhkan dari sistem. Bukan hanya bertanya "apa yang Anda inginkan?" — tapi mendengarkan, menginterpretasi, dan memvalidasi untuk menemukan "the why" behind each request.

Langkah Proses Elicitation

  1. Identify Stakeholders — siapa yang menggunakan, siapa yang diuntungkan, siapa yang mengelola?
  2. Select Elicitation Techniques — pilih teknik yang sesuai konteks
  3. Prepare for Elicitation — pahami domain, siapkan pertanyaan, set objectives
  4. Conduct Elicitation — gunakan teknik yang dipilih, tangkap cues verbal & non-verbal
  5. Document Requirements — tulis requirements yang jelas dan terstruktur
  6. Confirm & Refine — kembali ke stakeholders untuk validasi interpretasi

Teknik Elicitation

TeknikCaraTerbaik UntukProsCons
InterviewsOne-on-one dengan stakeholderIn-depth individual perspectivePersonal, bisa probe dalamTime-consuming, miss group dynamics
WorkshopsSesi kolaboratif multi-stakeholderResolving conflicts, building consensusFast, good for prioritizationPerlu fasilitasi cermat, tidak semua suara terdengar
Focus GroupsDiskusi kelompok dengan moderatorUser attitudes, opinions, expectationsVariety of views, ide baru munculGroupthink, dominant personalities
ObservationWatch users dalam natural environmentActual workflows, pain pointsReveals tacit knowledgeIntrusive, users may act differently
ShadowingAnalyst mengikuti user sepanjang hariDeep insight complex/expert workflowsHigh-detail understandingResource-intensive, uncomfortable
ScenariosNarasi deskriptif bagaimana user berinteraksi"What-if" cases, validate requirementsHelps imagine future system useHypothetical, may not reflect actual behavior
PrototypingMock-up atau model kerja systemFeedback on design & usabilityVisual & interactiveCan set false expectations

Tipe Requirements

Functional Requirements

Apa yang sistem harus lakukan — perilakunya, fungsinya.

Contoh: "Sistem harus mengidentifikasi ketika invoice terlambat bayar dan notifikasi financial controller."

Non-Functional Requirements

Bagaimana sistem harus beroperasi — kualitasnya:

  • Usability, Reliability, Performance
  • Supportability, Operations, Interface
  • Legal, packaging, hardware

Klasifikasi PIECES

P — PerformanceThroughput, response time — "sistem harus merespons dalam 2 detik" I — InformationAkurasi, relevansi, ketepatan waktu informasi yang dihasilkan/disimpan E — EconomyBiaya, profitabilitas — pengurangan cost atau peningkatan revenue C — ControlKeamanan, kontrol — mencegah fraud, memastikan compliance E — EfficiencyEfisiensi proses, pengurangan redundansi, automasi S — ServiceLayanan ke pelanggan, partner, karyawan — reliabilitas, konvenisnsi

Requirements Analysis

Analisis kebutuhan adalah proses mengkaji, merafining, menyusun, dan memprioritaskan requirements agar jelas, lengkap, dan actionable untuk desain sistem.

Prioritisasi: MoSCoW Method

Must HaveFundamental/wajib — tanpa ini, solusi tidak bisa diterima. Contoh: kemampuan merekam item masuk/keluar di inventory system. Should HaveWajib tapi tidak harus di Day 1 — bisa delay atau workaround manual sementara waktu. Could HaveNice to have — akan diimplementasikan jika mudah dilakukan bersama Must & Should haves, otherwise dilewatkan. Won't HaveTidak dalam scope sekarang — mungkin akan dipertimbangkan di future release.

Karakteristik Requirements yang Baik

Checklist Requirement yang Baik

Categorised Relevant Prioritised Achievable Understandable & Unambiguous Testable Requirement (bukan Solution) Consistent Owned Unique & Atomic Traceable Concise Complete Correct Conformant

❌ Requirement Buruk
  • "System should be easy to use"
  • "System must be totally secure" + "must be readily accessible to anyone" — kontradiksi!
  • "Field sales force shall be provided with laptop computers" — ini solution, bukan requirement
✅ Requirement Baik
  • "80% of first-time users shall complete a task within 5 minutes without external help"
  • "Response time shall not exceed 2 seconds after hitting ENTER key"
  • "Field sales force needs a means to check product information and record orders when on the move" — opens up solutions

Requirements Validation

Validasi memastikan bahwa requirements yang terdokumentasi benar, lengkap, konsisten, dan disetujui stakeholders. Ini adalah pengecekan apakah kita membangun produk yang tepat — sebelum benar-benar dibangun.

Perbedaan Verification vs Validation

Verification: Apakah requirements memenuhi standar yang ditetapkan? (Are we building it right?)

Validation: Apakah requirements ini benar-benar apa yang dibutuhkan? (Are we building the right thing?)

Tujuan Validasi

  • Konfirmasi sistem akan memenuhi kebutuhan nyata stakeholders
  • Mendapatkan formal approval dari users, managers, dan sponsors
  • Menemukan dan memperbaiki kesalahan sebelum development dimulai (cost jauh lebih murah!)
  • Memastikan setiap requirement dipahami, testable, dan diterima semua pihak

Output dari Validasi

  • Signed-off Requirement Specification (SRS atau BRD)
  • Requirements Traceability Matrix (RTM) — melacak dari source sampai implementasi
  • Record of feedback and revisions
  • List of approved and rejected requirements
Golden Rule of Validation

Validation is your last chance to prevent misunderstandings before development starts. Don't assume silence = agreement — get confirmation in writing.

Requirements Management

Requirements CatalogueRepository (database) untuk semua requirements — central source of truth Glossary of TermsMenghilangkan ambiguitas dari dokumen requirements — definisikan apa arti "customer" dalam konteks proyek ini Functional ModelsDFD, use case diagram — melengkapi functional requirements secara visual Data ModelsERD atau class model — menangkap business rules terkait data Config ManagementVersion control untuk requirements — siapa mengubah apa, kapan, kenapa Change ControlsProses untuk mendokumentasikan perubahan requirements beserta impact pada scope, cost, schedule TraceabilityMampu melacak requirement dari source → implementasi, dan sebaliknya
07 · Rekap

High-Yield Summary untuk UTS

Yang paling penting untuk diingat — rangkuman per topik dalam 1 halaman.

Quick Reference: Konsep SI

  • SI = Technoware + Organoware + Brainware + Data — bukan hanya teknologi!
  • 7 tujuan SI: Efektif, Efisien, Confidentiality, Integrity, Availability, Compliance, Reliability
  • SI mendukung 3 layer: Operasional (transaksi), Manajemen (laporan), Puncak (strategi)
  • SI harus selaras: Strategi Bisnis → Strategi SI → Strategi TI (Ward & Peppard)

Quick Reference: Data & Organisasi

  • Hierarki: Data → Informasi → Knowledge → Wisdom (volume ↓, value ↑)
  • Informasi = data + konteks + makna. Kualitas: waktu, lokasi, bentuk
  • 3 level manajemen: Top (strategic), Middle (tactical), Low (operational)
  • POLC: Planning, Organizing, Leading, Controlling
  • Efektif = doing right things, Efisien = doing things right

Quick Reference: Strategi Organisasi

  • Value Chain: Aktivitas Primer (inbound, ops, outbound, marketing, service) + Aktivitas Pendukung
  • Margin = Value − Cost
  • 3 Generic Strategies: Cost Leadership / Differentiation / Focused Niche
  • 5 Forces: Rivalry / New Entrants / Substitutes / Supplier Power / Buyer Power

Quick Reference: BPMN

  • Events: Start (tipis), Intermediate (ganda), End (tebal)
  • Gateways: XOR (× — satu path), AND (+ — semua path), OR (○ — satu atau lebih)
  • Pool = satu organisasi/participant. Lane = departemen/peran di dalam Pool
  • Sequence Flow = dalam Pool, Message Flow = antar Pool berbeda
  • Naming: Task = verb + noun, XOR split = kondisi sebagai pertanyaan

Quick Reference: SDLC

  • Tahapan: Planning (Feasibility) → Analysis (RE) → Design → Development → Testing → Implementation → Maintenance
  • Feasibility: Technical, Economic, Operational, Regulatory, Schedule
  • Waterfall: stabil, linear. Spiral: risk-heavy. Agile: fast-changing. V-Model: quality-critical
  • Linear = step-by-step, semua dikunci di awal. Evolutionary = berkembang iteratif

Quick Reference: Requirement Engineering

  • Framework RE: Elicitation → Analysis → Validation
  • 60–70% kegagalan IT = lemahnya requirements. Fix early = fix cheap!
  • Teknik elicitation: Interview, Workshop, Focus Group, Observation, Shadowing, Scenarios, Prototyping
  • Types: Functional (apa yang dilakukan) vs Non-Functional (bagaimana beroperasi)
  • PIECES: Performance, Information, Economy, Control, Efficiency, Service
  • MoSCoW: Must Have, Should Have, Could Have, Won't Have
  • Good requirement: Unambiguous, Testable, NOT a solution, Consistent, Owned, Unique, Traceable
  • Verification = build it right? Validation = build the right thing?