Rangkuman buku System Analysis and Design 5th Edition Chapter 3-6

BAB 3: Requirements Determination

• Fase Analisis

Fase analisis akan menentukan garis besar tujuan bisnis untuk sistem, menentukan ruang lingkup proyek, menilai kelayakan proyek, dan menyediakan rencana kerja awal. Pada fase ini, seorang system analyst bekerja secara ekstensif dengan klien untuk mengetahui kebutuhan apa saja yang diperlukan untuk sistem yang baru. Adapun proses dasar fase analisis memiliki tiga langkah:

1. Memahami situasi yang ada (as-is system)
2. Identifikasi perbaikan
3. Menentukan kebutuhan untuk sistem yang baru

• Penentuan Kebutuhan

Penentuan kebutuhan dilakukan untuk mengubah penjelasan tingkat tinggi mengenai kebutuhan bisnis yang tercantum dalam permintaan sistem ke dalam daftar kebutuhan yang lebih tepat. Daftar kebutuhan ini didukung, dikonfirmasi, dan diklarifikasi oleh kegiatan lain dalam fase analisis: membuat use case, membangun proses model, dan membangun data model. Kebutuhan bisnis menggambarkan sistem “apa” dan kebutuhan sistem menggambarkan “bagaimana” sistem akan diterapkan. Kebutuhan fungsional berhubungan langsung dengan proses  yang harus dilakukan atau informasi yang harus ada. Kebutuhan non-fungsional mengacu pada sifat perilaku yang harus dimiliki sistem, seperti kinerja dan kegunaan.

• Requirements Elicitation Techniques

Lima teknik dapat digunakan untuk memperoleh kebutuhan bisnis untuk sistem yang diusulkan: wawancara, pengembangan aplikasi gabungan, kuesioner, analisis dokumen, dan observasi. Wawancara melibatkan pertemuan dengan satu atau banyak orang dan mengajukan pertanyaan kepada mereka. Ada lima langkah dasar dalam proses wawancara: memilih orang yang diwawancarai, merancang pertanyaan wawancara, mempersiapkan wawancara, melakukan wawancara, dan tindak lanjut pasca wawancara. Joint Application Development (JAD) memungkinkan tim proyek, pengguna, dan manajemen bekerja sama untuk mengidentifikasi persyaratan sistem. JAD elektronik mencoba mengatasi masalah umum yang terkait dengan kelompok dengan menggunakan groupware. Kuesioner adalah serangkaian pertanyaan tertulis yang dikembangkan untuk mendapatkan informasi dari individu. Kuesioner sering digunakan bila dibutuhkan pendapat dan informasi dari banyak orang. Analisis dokumen memerlukan pengkajian dokumentasi yang ada dan memeriksa sistem itu sendiri. Ini bisa memberi wawasan tentang sistem formal dan informal. Pengamatan, tindakan mengamati proses yang sedang dilakukan, adalah alat yang ampuh untuk mengumpulkan informasi tentang sistem seperti apa dan memungkinkan analis untuk melihat realitas suatu situasi secara langsung.

• Strategi Kebutuhan Analisis

Fase analisis seringkali mengharuskan pengguna bisnis untuk berpikir kritis tentang kebutuhan bagi sistem baru mereka. Beberapa strategi dapat membantu, analisis masalah dan analisis akar permasalahan adalah dua strategi yang dapat membantu pengguna bisnis dalam memahami permasalahan pada sistem saat ini yang memerlukan perbaikan. Analisis waktu, activity-based costing, dan benchmarking informal adalah tiga strategi analisis populer yang dapat membantu tim menemukan proses yang paling membutuhkan perancangan ulang. Analisis hasil, analisis teknologi, dan penghapusan aktivitas adalah tiga strategi yang dapat digunakan untuk “memaksa” pengguna bisnis memikirkan proses bisnis dengan cara baru, memungkinkan untuk menemukan cara baru untuk menyelesaikan proses bisnis.

BAB 4: Use Case Analysis

• Use Cases

Use Cases menggambarkan serangkaian kegiatan yang dilakukan untuk menghasilkan beberapa output. Setiap use case menggambarkan bagaimana pengguna eksternal memicu suatu kejadian dimana sistem harus menanggapi. Use Case memiliki nama, nomor, tingkat kepentingan, deskripsi singkat, actor utama, trigger, precondition, postcondition, input utama dan output, dan daftar langkah utama yang diperlukan untuk menjalankannya. Use case dapat diidentifikasi dengan meninjau persyaratan fungsional. Daftar kejadian dan respon juga berguna dalam mengidentifikasi peristiwa penting yang harus dijelaskan dalam use case. Setelah use case selesai, seringkali persyaratan fungsional baru dan perluasan dapat diturunkan.

• Membuat Use Cases

Saat membuat use case, hal pertama yang harus dikenali adalah kejadian pemicu (eksternal atau temporal) dan actor utama. Selanjutnya, kembangkan daftar langkah-langkah utama yang terlibat dalam menggunakan input untuk menghasilkan output yang dibutuhkan dan respon yang diinginkan terhadap kejadian tersebut. Sekarang, pikirkan lebih dalam tentang setiap langkah dan identifikasi input dan output spesifik untuk setiap langkah. Terakhir, minta pengguna untuk memainkan peran sesuai use case untuk memverifikasi bahwa use case yang dibuat sudah benar.

Bab 5: Process Modeling

• Data Flow Diagrams

Empat simbol digunakan pada data flow diagram (proses, data flow, data store, dan entitas eksternal). Proses adalah aktivitas yang melakukan sesuatu. Setiap proses memiliki nama (frase kata kerja), deskripsi, dan angka yang menunjukkan dimana hal itu terhubung dengan proses lain dan proses anak-anaknya. Setiap proses harus memiliki setidaknya satu keluaran dan biasanya memiliki setidaknya satu masukan. Data flow adalah sepotong data atau objek dan memiliki nama (kata benda) dan deskripsi yang dimulai atau berakhir pada suatu proses (atau keduanya). Data store adalah file manual atau komputer, dan memiliki nomor, nama (kata benda), dan setidaknya satu data flow masukan dan satu data flow keluaran (kecuali jika penyimpanan data dibuat oleh proses di luar data flow diagram [DFD]). Entitas eksternal adalah orang, organisasi, atau sistem di luar ruang lingkup sistem dan memiliki nama (kata benda) dan deskripsi. Setiap rangkaian DFD dimulai dengan diagram konteks dan DFD tingkat 0 dan memiliki DFD tingkat 1, DFD tingkat 2, dan seterusnya. Setiap elemen pada DFD tingkat tinggi (yaitu, data flow, data store, dan entitas eksternal) harus muncul di DFD tingkat rendah, atau tidak seimbang.

•  Membuat Data Flow Diagrams

DFD dibuat dari use cases. Pertama, tim akan membuat konteks diagram yang menunjukkan semua entitas eksternal dan data flows yang masuk dan keluar dari sistemnya. Kedua, tim membuat fragmen DFD untuk setiap use case yang menunjukkan bagaimana use case mentransformasikan data flow dengan entitas eksternal dan data store. Ketiga, fragmen DFD ini disusun ke dalam DFD level 0. Keempat, tim mengembangkan DFD tingkat 1 berdasarkan langkah-langkah dalam setiap kasus penggunaan untuk menjelaskan dengan lebih baik bagaimana mereka beroperasi. Kelima, tim memvalidasi kumpulan DFD untuk memastikan kelengkapan dan kebenaran serta tidak mengandung kesalahan sintaks atau semantik. Iterasi menjadi penting untuk memastikan DFD satu halaman atau lebih jelas dan mudah dibaca.

Bab 6: Data Modeling

• Basic Entity Relationship Diagram Syntax

Entity Relationship Diagram (ERD) adalah teknik yang paling umum untuk menggambarkan data model, sebuah cara formal untuk merepresentasikan data yang digunakan dan dibuat oleh sistem bisnis. Ada tiga elemen dasar dalam bahasa pemodelan data, masing-masing diwakili oleh simbol grafis yang berbeda. Entitas adalah blok bangunan dasar untuk model data. Dapat berupa orang, tempat, atau hal tentang data yang dikumpulkan. Sebuah atribut adalah tipe informasi yang ditangkap tentang sebuah entitas.
Atribut yang secara unik dapat mengidentifikasi satu instance dari suatu entitas disebut identifier. Komponen model data ketiga adalah relasi, yang menyampaikan hubungan antar entitas. Relasi memiliki kardinalitas (rasio instance parent dan instance child) dan modalitas (parent harus ada ketika child ada). Informasi mengenai semua komponen lainnya ditangkap oleh metadata dalam kamus data.

• Membuat Entity Relationship Diagram

Langkah dasar dalam membuat ERD adalah (1) mengidentifikasi entitas, (2) menambahkan atribut yang sesuai ke setiap entitas, dan (3) menggambarkan relasi antar tiap entitas untuk menunjukkan bagaimana hubungan satu sama lain. Ada tiga jenis entitas khusus yang dimiliki ERD. Kebanyakan entitas adalah independen, karena satu (atau lebih) atribut dapat digunakan secara unik untuk mengidentifikasi sebuah instance. Entitas yang bergantung pada atribut dari entitas lain adalah dependen. Sebuah persimpangan entitas ditempatkan di antara dua entitas untuk menangkap informasi tentang relasinya. Secara umum, data model didasarkan pada interpretasi; maka dari itu, penting untuk menyatakan dengan jelas asumsi-asumsi yang mencerminkan peraturan bisnis.

• Validasi Entity Relationship Diagram

Normalisasi, proses dimana serangkaian peraturan diterapkan pada model data logis untuk menentukan seberapa baik proses terbentuknya. Sebuah data model logis dalam bentuk normal pertama (1NF) jika tidak mengandung atribut berulang, yang merupakan atribut untuk menangkap beberapa nilai untuk satu instance. Bentuk normal kedua (2NF) mensyaratkan bahwa semua entitas dalam 1NF dan hanya berisi atribut yang nilainya bergantung pada keseluruhan pengenal (yaitu, tidak ada ketergantungan parsial). Bentuk normal ketiga (3NF) terjadi ketika sebuah model berada dalam 1NF dan 2NF dan tidak ada atribut yang dihasilkan bergantung pada atribut non-identifier (yaitu, tidak ada ketergantungan transitif). Dengan setiap pelanggaran, entitas tambahan harus dibuat untuk menghapus atribut yang berulang atau ketergantungan yang tidak semestinya ada pada entitas. Akhirnya, ERD harus diimbangi dengan DFD untuk memastikan bahwa entitas data model dan atribut sesuai dengan data store dan data flow pada model proses. Matriks CRUD adalah alat yang berharga untuk digunakan saat proses penyeimbangan dan model data.