Chapter 3: Requirements Determination
Fase analisis
Fase analisis 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. Proses dasar fase analisis memiliki tiga langkah:
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
Terdapat lima teknik yang 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 untuk mengajukan pertanyaan kepada mereka. Joint Application Development (JAD) memungkinan tim proyek, pengguna, dan manajemen bekerja sama untuk mengidentifikasi kebutuhan sistem. Kuesioner adalah serangkaian pertanyaan tertulis yang dikembangkan untuk mendapatkan informasi dari individu. Analisis dokumen memerlukan pengkajian dokumentasi yang ada dan memeriksa sistem itu sendiri. Observasi, tindakan mengamati proses yang sedang dilakukan, adalah alat yang ampuh untuk mengumpulkan informasi tentang sistem seperti apa dan memungkinkan analisis 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.
Chapter 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.
Chapter 5: Process Modelling
Data Flow Diagrams
Empat simbol digunakan dalam DFD (proses, data flows, data stores, dan entitas eksternal). Proses adalah aktivitas yang melakukan sesuatu. Setiap proses memiliki nama (frasa kata kerja), sebuah deskripsi, dan sebuah nomor yang menunjukkan relasi dengan proses lain dan proses anaknya. Setiap proses harus memiliki setidaknya satu output dan biasanya satu input. Sebuah data flow adalah sepotong data atau sebuah objek yang memiliki nama (kata benda) dan sebuah deskripsi yang dimulai atau berakhir pada suatu proses. Sebuah data store adalah file manual atau komputer yang memiliki nomor, nama (kata benda), serta memiliki setidaknya satu input data flow dan satu output data flow (kecuali jika penyimpanan data dibuat oleh proses di luar DFD). Entitas eksternal adalah orang, organisasi, atau sistem yang berada di luar ruang lingkup sistem dan memiliki nama (kata benda), dan sebuah deskripsi. Setiap rangkaian DFD dimulai dengan sebuah konteks diagram dan DFD tingkat 0 dan memiliki DFD tingkat 1, DFD tingkat 2, dan seterusnya. Setiap elemen pada DFD tingkat tinggi (yaitu, data flows, data stores, dan entitas eksternal) harus muncul pada DFD tingkat rendah atau akan 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.
Untuk lebih detailnya, dapat dilihat di
Chapter 6: Data Modelling
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 DiagramLangkah dasar dalam membuat ERD adalah
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.
Fase analisis
Fase analisis 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. Proses dasar fase analisis memiliki tiga langkah:
- Memahami situasi yang ada (as-is system)
- Identifikasi perbaikan
- 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
Terdapat lima teknik yang 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 untuk mengajukan pertanyaan kepada mereka. Joint Application Development (JAD) memungkinan tim proyek, pengguna, dan manajemen bekerja sama untuk mengidentifikasi kebutuhan sistem. Kuesioner adalah serangkaian pertanyaan tertulis yang dikembangkan untuk mendapatkan informasi dari individu. Analisis dokumen memerlukan pengkajian dokumentasi yang ada dan memeriksa sistem itu sendiri. Observasi, tindakan mengamati proses yang sedang dilakukan, adalah alat yang ampuh untuk mengumpulkan informasi tentang sistem seperti apa dan memungkinkan analisis untuk melihat realitas suatu situasi secara langsung.
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.
Chapter 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.
Chapter 5: Process Modelling
Data Flow Diagrams
Empat simbol digunakan dalam DFD (proses, data flows, data stores, dan entitas eksternal). Proses adalah aktivitas yang melakukan sesuatu. Setiap proses memiliki nama (frasa kata kerja), sebuah deskripsi, dan sebuah nomor yang menunjukkan relasi dengan proses lain dan proses anaknya. Setiap proses harus memiliki setidaknya satu output dan biasanya satu input. Sebuah data flow adalah sepotong data atau sebuah objek yang memiliki nama (kata benda) dan sebuah deskripsi yang dimulai atau berakhir pada suatu proses. Sebuah data store adalah file manual atau komputer yang memiliki nomor, nama (kata benda), serta memiliki setidaknya satu input data flow dan satu output data flow (kecuali jika penyimpanan data dibuat oleh proses di luar DFD). Entitas eksternal adalah orang, organisasi, atau sistem yang berada di luar ruang lingkup sistem dan memiliki nama (kata benda), dan sebuah deskripsi. Setiap rangkaian DFD dimulai dengan sebuah konteks diagram dan DFD tingkat 0 dan memiliki DFD tingkat 1, DFD tingkat 2, dan seterusnya. Setiap elemen pada DFD tingkat tinggi (yaitu, data flows, data stores, dan entitas eksternal) harus muncul pada DFD tingkat rendah atau akan 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.
Untuk lebih detailnya, dapat dilihat di
Chapter 6: Data Modelling
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 DiagramLangkah dasar dalam membuat ERD adalah
- Mengidentifikasi entitas,
- Menambahkan atribut yang sesuai ke setiap entitas, dan
- 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.
Komentar
Posting Komentar