PART 2 : ANALYSIS PHASE
Chapter 3 : Requirements Determination
The Analysis PhaseFase analisis berfokus pada menangkap kebutuhan bisnis untuk sistem yang baru, menentukan ruang lingkup proyek, menilai kelayakan proyek, dan menyediakan rencana kerja awal.
Pada fase ini, seorang analis membutuhkan kemampuan berpikir secara kritis. Pemikiran kritis adalah kemampuan untuk mengenali kelebihan dan kekurangan dan menyusun kembali gagasan dalam bentuk yang lebih baik.
Proses dasar analisis melibatkan tiga langkah :
- Pahami situasi yang ada (sistem as - is)
- Identifikasi perbaikan
- persyaratan yang jelas untuk sistem baru (sistem to - be)
Pada akhir tahap analisis, proposal sistem dipresentasikan ke komite persetujuan, biasanya dalam bentuk sistem walk-through. Tujuan walk-through adalah untuk menjelaskan sistem secara moderat sehingga pengguna, manajer, dan pengambil keputusan utama memahaminya dengan jelas sehingga dapat mengidentifikasi modifikasi yang diperlukan dan dapat membuat keputusan tentang apakah proyek harus dilanjutkan atau tidak.
Requirements Determination
Apa itu persyaratan? persyaratan hanyalah pernyataan tentang apa yang harus dilakukan sistem atau karakteristik apa yang harus dimiliki.
Selama proyek pengembangan sistem, persyaratan akan dibuat yang menggambarkan kebutuhan bisnis (bisnis requirements); apa yang pengguna perlu lakukan (user requirements); software apa yang harus dilakukan (functional requirements); karakteristik yang harus dimiliki sistem (nonfunctional requirements); dan bagaimana sistem harus dibangun (system requirements).
Contoh functional requirements :
Contoh nonfunctional requirements :
Penentuan persyaratan dilakukan untuk mengubah pernyataan kebutuhan tingkat tinggi permintaan sistem menjadi daftar yang lebih terperinci dan tepat mengenai apa yang harus dilakukan sistem baru untuk memberikan nilai yang dibutuhkan bagi bisnis. Daftar persyaratan yang rinci ini didukung, dikonfirmasi, dan diklarifikasi oleh kegiatan lain dari tahap analisis: membuat use cases, model proses pembangunan dan membangun model data.
The Requirements Definition Statement
Pernyataan definisi persyaratan atau definisi persyaratan adalah laporan teks langsung yang hanya mencantumkan persyaratan fungsional atau nonfungsional dalam format garis besar.
Contoh : definisi persyaratan untuk Holiday Travel Vehicles, dealer kendaraan rekreasi yang fiktif.
Tujuan paling jelas dari definisi persyaratan adalah untuk memberikan pernyataan yang jelas tentang apa yang harus dilakukan sistem baru untuk mencapai visi sistem yang dijelaskan dalam permintaan sistem.
Use cases, model proses dan model data memberikan konten penjelasan tambahan dalam format yang berbeda. Namun, tujuan penting dari definisi persyaratan adalah menentukan lingkup sistem. Dokumen tersebut menjelaskan kepada analis tentang apa yang harus dilakukan akhir sistem. Selain itu, ini berfungsi untuk menetapkan harapan pengguna terhadap sistem. Jika dan ketika terjadi ketidaksesuaian atau kesalahpahaman, dokumen tersebut berfungsi sebagai sumber untuk klarifikasi.
Requirements Elicitation Techniques
Terdapat lima teknik yang dapat digunakan untuk memperoleh kebutuhan bisnis untuk sistem yang diusulkan :
1. Interviews
Wawancara melibatkan pertemuan satu atau banyak orang untuk mengajukan pertanyaan kepada mereka. Ada lima langkah dasar untuk proses wawancara, yaitu memilih orang yang diwawancarai, merancang pertanyaan wawancara, mempersiapkan wawancara, melakukan wawancara, dan tindak lanjut pasca wawancara.
2. Joint Application Development (JAD)
JAD adalah teknik pengumpulan informasi yang memungkinkan tim proyek, pengguna, dan manajemen bekerja sama untuk mengidentifikasi kebutuhan sistem.
3. Questionnaires
kuesioner adalah serangkaian pertanyaan tertulis yang dikembangkan untuk mendapatkan informasi dari individu
4. Document Analysis
Analisis dokumen memerlukan pengajian dokumentasi yang ada dan memeriksa sistem itu sendiri.
5. Observation
Observasi, tindakan mengamati proses yang sedang di lakukan, adalah alat yang ampuh untuk mengumpulkan informasi tentang sistem seperti apa dan memungkinkan analisis untuk melihat realitas suatu situasi secara langsung
Requirements Analysis Strategies
Fase analisis sering kali mengharuskan pengguna bisnis untuk berpikir kritis tentang kebutuhan bagi sistem baru mereka. Ada beberapa startegi dapat membantu analis untuk mencapai tujuan tersebut.
Problem Analysis dan Root Cause Analysis adalah dua strategi yang dapat membantu pengguna bisnis dalam memahami permasalahan pada sistem saat ini yang memerlukan perbaikan.
Duration Analysis, Activity-Based Costing, dan Informal Benchmarking adalah 3 strategi analisis populer yang dapat membantu tim menemukan proses yang paling membutuhkan perancangan ulang.
Outcome Analysis, Technologi Analysis, dan Activity Elimination 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 CasesUse cases menggambarkan serangkaian kegiatan yang dilakukan untuk menghasilkan beberapa output. Setiap usecase menggambarkan bagaimana 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. Dafter 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
Creating Use Cases
Saat membuat use case, hal pertama yang harus dikenali adalah kejadian pemicu (eksternal atau temporal) dan aktor 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 utuk setiap langkah. Terakhir, minta pengguna untuk memainkan peran sesuai use case untuk memverifikasi bahwa use case yang dibuat sudah benar
Chapter 5 : Process Modeling
Data Flow Diagram SyntaxEmpat 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 menunjukan dimana hal itu terhubung dengan proses lain dan proses anak-anaknya. Setiap proses harus 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 san memiliki nama (kata benda) dan deskripsi. setiap rangkaian DFD dimulai dengan diagram konteks dan DFD tingkat 0 dan mimiliki tingkat 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.
Creating Data Flow Diagrams
DFD dibuat dari use case.
Pertama, tim membangun diagram konteks yang menunjukan semua entitas eksternal dan data flow masuk dan keluar dari sistemnya.
Kedua, tim membuat fragmen DFD untuk setiap use case yang menunjukan 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 memastikannya lengkap dan benar dan tidak mengandung kesalahan sintaks atau semantik.
Analis jarang membuat DFD secara sempurna untuk pertama kalinya. jadi iterasi penting untuk memastikan DFD satu halaman atau lebih, jelas dan mudah di baca
Chapter 6 : Data Modeling
Basic Entity Relationship Diagram SyntaxDiagram hubungan entitas (entity relationship diagram / ERD) adalah teknik yang paling umum untuk menggambarkan model data, cara formal untuk mewakili data yang digunakan dan diciptakan oleh sistem bisnis.
Ada tiga elemen dasar dalam bahasa pemodelan data, masing-masing diwakili oleh simbol grafis yang berbeda, yaitu
1. Entitas adalah blok bangunan dasar untuk model data. ini adalah orang, tempat atau hal tentang
data yang dikumpulkan.
2. Atribut adalah beberapa jenis informasi yang ditangkap tentang suatu entitas. Atribut yang secara
unik dapat mengidentifikasi satu instance dari suatu entitas disebut identifier.
3. Hubungan (relationship), yang menyampaikan hubungan antar entitas. Hubungan memiliki
kardinalitas (rasio contoh orang tua terhadap kejadian di anak) dan modalitas (orang tua perlu jika
ada anak).
Informasi tentang semua komponen ditangkap oleh metadata dan kamus data.
Creating an Entity Relationship Diagram
Langkah dasar dalam membangun ERD adalah
1. mengidentifikasi entaitas,
2 menambahkan atribut yang sesuai ke setiap entitas, dan
3. menarik hubungan antar entitas untuk menunjukan bagaimana hubungan mereka satu sama lain.
Ada tiga jenis entitas khusus yang mengandung ERD. Sebagian besar entitas independen, karena satu atribut (atau lebih) dapat digunakan untuk mengidentifikasi instance secara unik. Entitas yang mengandalkan atribut dari entitas lain untuk mengidentifikasi sebuah instance yang bergantung dengan lainnya. Sebuah persimpangan entitas ditempatkan di antara dua entitas untuk menangkap informasi tentang hubungannya. secara umum, model data didasarkan pada interpretasi. Oleh karena itu, penting untuk menyatakan dengan jelas asumsi-asumsi yang mencerminkan peraturan bisnis
Validating an Entity Relationship Diagram
Normalisasi, proses dimana serangkaian peraturan diterapkan pada model data logis untuk menentukan seberapa baik terbentuknya.
Model data logis ada dalam bentuk normal pertama (1NF) jika tidak mengandung atribut berulang, yang merupakan atribut menangkap beberapa nilai untuk satu instance.
Bentuk normal kedua (2NF) mensyaratkan bahwa semua entitas berada dalam 1NF dan hanya berisi atribut yang nilainya bergantung pada keseluruhan pengenal (yaitu, tidak ada ketergantungan persial).
Bentuk normal ke tiga (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 dari entitas yang ada. akhirnya ERD harus diimbangi dengan data flow diagram (DFD) dengan memastikan bahwa entitas model data dan atribut sesuai dengan data store dan data flow pada model proses. matriks CRUD adalah alat yang berharga untuk digunakan saat menyeimbangkan proses dan model data.
Tidak ada komentar:
Posting Komentar