Rangkuman Buku "Sistem Analysis and Design

PART 2 : ANALYSIS PHASE  

Chapter 3 : Requirements Determination

The Analysis Phase

Fase 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)

Penyampaian tahap akhir analisis berupa proposal sistem yang meyusun pernyataan definisi persyaratan rinci, use cases, model proses, dan model data bersamaan dengan analisis kelayakan dan rencana kerja yang di revisi. 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 :

a.     User dapat mencari semua kumpulan database inisial atau memilih subset dari database tersebut.

b.  Sistem menyediakan tampilan yang tepat untuk user yang membaca dokumen dalamm penyimpan dokumen. 

 c.  Setiap pesanan dapat dialokasikan sebagai identifier yang unik (ORDER_ID) dimana user dapat meng-copy daerah penyimpan account permanen.

Contoh kasus peminjaman buku

a. Pengguna bisa mencari semua informasi tentang buku atau bisa memilih salah satu dari informasi tentang buku. 

b.    Semua peminjam memiliki pengenal yang unik  

c.    Sistem mencatat transaksi peminjaman, pengembalian dan denda secara lengkap  

d.    Hari libur bisa di­set sejak awal, dan bisa menerima perubahan otoritas khusus  

e.   Harus komplit (kebutuhan layanan jelas dan lengkap) dan konsisten (tidak kontradiksi dengan yang didefinisikan)

Contoh nonfunctional requirements :     

 a. Kebutuhan Produk berkaitan dengan kehandalan,kecepatan,kemudahan digunakan,kapasitas memori yang di butuhkan dan efisisensi sistem.
b.  Kebutuhan Organisasi berkaitan dengan standar, bahasa pemograman dan metode rancangan yang digunakan
c.  Kebutuhan Eksternal berkaitan dengan masalah etika penggunaan, interoperabilitas dengan sistem lain, legalitas, dan privasi.

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 Cases

Use 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 Syntax

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 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 Syntax 

Diagram 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.