Transcript KLP3_Chapter6_Proses Rekayasa Persyaratan
PROSES REKAYASA PERSYARATAN Chapter 6
PRODI PENDIDIKAN TEKNIK INFORMATIKA DAN KOMPUTER JURUSAN PENDIDIKAN TEKNIK ELEKTRO FAKULTAS TEKNIK UNIVERSITAS NEGERI MAKASSAR
KELOMPOK 3
092904006 092904010 092904011 092904030 092904035 092904041 092904043 SYAPUTRI ARTAMI S AYU ANGGRIANI H RUDI DIAN SYAH ZUL FADLY SULTHAN JUMIATI HUSNAENI NURHALIMAH
TUJUAN
Memehami kegiatan-kegiatan rekayasa persyaratan dan hubungan-hubungannya Mengetahui beberapa teknik elisitasi dan analisis persyaratan Memahami arti penting validasi persyaratan dan bagaimana peninjauan persyaratan digunakan pada proses ini Memahami mengapa manajemen persyaratan diperlukan dan bagaimana manajemen tersebut mendukung rekayasa persyaratan lain
POKOK PEMBAHASAN
6.1. Studi Kelayakan 6.2. Elisitasi dan analisis persyaratan 6.3. Validasi persyaratan 6.4. Manajemen persyaratan
Rekayasa persyaratan adalah proses yang melibatkan semua kegiatan yang dibutuhkan untuk membuat dan memelihara dokumen persyaratan sistem.
Ada empat kegiatan proses rekayasa persyaratan tingkat tinggi yang generik adalah : 1. Studi kelayakan sistem 2. Elisitasi dan analisis persyaratan 3. Validasi persyaratan 4. Manajemen persyaratan
Peraga 6.1. Proses rekayasa persyaratan
Untuk semua sistem baru, proses rekayasa persyaratan harus dimulai dengan studi kelayakan. Input bagi studi kelayakan adalah deskripsi garis besar sistem dan bagaimana sistem akan digunakan dalam organisasi. Hasil studi kelayakan berwujud laporan yang merekomendasikan apakah kegiatan tersebut layak diteruskan dengan rekayasa persyaratan dan proses pengembangan sistem.
Studi kelayakan merupakan studi singkat dan terfokus yang bertujuan untuk menjawab sejumlah pertanyaan berikut : 1. Apakah sistem memberikan konstribusi bagi tujuan organisasi secara keseluruhan.
2. Apakah sistem dapat diimplementasi dengan menggunakan teknologi terbaru dan dalam batasan biaya dan jadwal ?
3. Apakah sistem dapat diintegrasi dengan sistem lain yang sudah ada ?
Setelah studi kelayakan awal, tahap berikutnya dari proses rekayasa persyaratan adalah elisitasi dan analisis persyaratan. Pada tahap ini, staf pengembangan perangkat lunak teknis bekerja dengan pelanggan dan end-user sistem untuk mencari domain aplikasi, layanan apa yang harus diberikan sistem, kinerja sistem yang diharapkan, batasan perangkat keras, dan seterusnya.
Elisistasi dan analisis persyaratan dapat melibatkan berbagai macam orang dalam organisasi. Stakeholder mencakup end-user yang berinteraksi dengan sistem dan orang lain pada organisasi yang akan dipengaruhi oleh sistem tersebut.
Perekayasa yang mengembangkan atau memelihara sistem lain yang berhubungan, manajer bisnis, pakar domain, representatif badan perdagangan, dan seterusnya juga bisa merupakan stakeholder sistem.
Elisitasi dan analisis merupakan proses yang sulit karena sejumlah alasan : 1. Stakeholder seringkali tidak tahu apa yang mereka inginkan dari sistem komputer kecuali dalam hal-hal yang paling umum.
2. Stakeholder pada suatu sistem biasanya menyatakan persyaratan dalam pemikiran mereka dan dengan pengetahuan imlisit mengenai pekerjaan mereka.
3. Beda stakeholder,beda pula persyaratanya, dan mereka mungkin menyatakannya dengan cara yang berbeda pula.
4. Faktor-faktor politis dapat mempengaruhi persyaratan sistem.
5. Lingkungan ekonomi dan bisnis di mana analisis dilakukan bersifat dinamis. Lingkungan ini tentu berubah pada saat proses analisis. Dengan demikian, arti penting dari persyaratan tentu bisa berubah. Persyaratan baru munngkin muncul dari stakeholder yang baru yang pada awalnya tidak dihubungi.
Peraga 6.2. Proses elisitasi dan analisis persyaratan
Kegiatan-kegiatan proses tersebut adalah:
1. Pemahaman domain
: analisis harus mengembangkan pemahaman mereka mengenai domain aplikasi.
2. Pengumpulan persyaratan
stakeholder pada sistem untuk mendapatkan persyaratan mereka.
3. Klasifikasi
: kegiatan ini mengambil kumpulan persyaratan yang tidak terstruktur dan mengaturnya menjadi kelompok-kelompok yang bertalian secara logis.
: ini merupakan proses interaksi dengan
4. Resolusi konflik
: kegiatan ini berkenaan dengan menemukan dan menyelesaikan konflik jika banyak stakeholder yang terlibat,dan terjadi konflik persyaratan.
5. Prioritasi
: tahap ini mencakup interaksi dengan stakeholder untuk menemukan persyaratan yang paling penting,karena dalam beberapa hal akan lebih penting dari yang lain.
6. Pemeriksaan persyaratan
: tahap ini, persyaratan diperiksa untuk mengetahui apakah sudah lengkap, konsisten, dan mengikuti apa yang benar-benar diinginkan stakeholder dari sistem tersebut.
6.2.1. Elisitasi Berorientasi sudut pandang
Untuk sistem berukuran menengah atau besar, biasanya terdapat beberapa end user dengan tipe berbeda. Banyak stakeholder yang memiliki kepentingan terhadap persyaratan sistem. Berikut kami berikan contoh, stakeholder sistem untuk sistem ATM bank mencakup :
Nasabah bank
pada saat itu yang menerima jasa dari sistem;
Representatif dari bank lain
yang memiliki perjanjian timbal balik yang memungkinkan menggunakan ATM bersama;
Manajer cabang-cabang bank
sistem; yang mendapatkan informasi manajemen dari
Staf counter pada cabang-cabang bank
yang terlibat dalam pengoperasian sistem dari hari ke hari, menangani keluhan nasabah, dll;
Administrator database
yang bertanggung jawab terhadap integrasi sistem dengan database nasabah bank;
Manajer keamanan bank
yang harus menjamin bahwa sistem tidak akan menimbulkan kekacauan keamanan dalam bentuk apapun;
Departemen pemasaran bank
yang mungkin tertarik untuk menggunakan sistem sebagai cara untuk pemasaran bank;
Perekayasa pemeliharaan perangkat keras dan lunak
jawab untuk memelihara sistem dan meng-upgrade perangkat keras dan lunak.
yang bertanggung
Setiap metode memiliki gagasan yang berbeda mengenai apa yang dimaksud dengan “sudut pandang”. Suatu sudut pandang dapat dianggap sebagai : Sumber atau tempat masuknya data.
Kerangka kerja representasi.
Penerima layanan.
Keuntungan jenis sudut pandang ini adalah: Sudut pandang bersifat eksternal terhadap sistem sehingga merupakan cara yang natural untuk membentuk struktur proses elisitasi persyaratan.
Relatif mudah untuk memutuskan apakah suatu sudut pandang bersifat valid.
Sudut pandang dan layanan merupakan cara yang berguna dalam penstrukturan persyaratan non-fungsional. Setiap layanan bisa memiliki persyaratan non-fungsional yang berhubungan.
Metode VORD ( viewpoint oriented requirments definition/definisi persyaratan berorientasi sudut pandang) telah dirancang sebagai kerangka kerja berorientasi layanan untuk elisitasi dan analisis persyaratan .
Tahap Utama metode VORD:
Identifikasi sudut
, yang mencakup pencarian sudut pandang yang menerima layanan sistem dan pengidentifikasian layanan-layanan khusus yang diberikan bagi setiap sudut pandang.
Penstrukturan sudut pandang
, yang mencakup pengelompokkan sudut pandang yang berhubungan menjadi suatu hierarki. Layanan layanan yang umum diberikan pada tingkatan yang lebih tinggi pada hierarki dan diwarisi oleh sudut pandang tingkat rendah.
Dokumentasi sudut pandang
, yang mencakup penyempurnaan deskripsi sudut pandang dan layanan yang teridentifikasi.
Pemetaan sistem sudut pandang
, yang mencakup pengidentifikasian objek pada desain berorientasi objek dengan menggunakan informasi layanan yang dicakup dalam sudut pandang.
Peraga 6.3 Metode VORD
Peraga 6.4. Form template sudut pandang dan layanan Template Sudut Pandang Template Layanan Referensi: Nama Sudut pandang Atribut : Atribut yang menyediakan informasi sudut pandang Event : Referensi ke satu set skenario event yang mendeskripsikan bagaimana sistem bereaksi terhadap event sudut pandang.
Layanan : Referensi ke satu set deskrripsi layanan Sub-V: Nama sub- viewpoint (sub-sudut pandang) Referensi: Nama layanan Dasar pemikiran:Alasan mengapa layanan ini disediakan Spesifikasi: Referensi ke sejumlah spesifikasi layanan. Ini bisa dinyatakan dengan notasi yang berbeda-beda Sudut pandang: Daftar nama sudut pandang yang menerima layanan Persyaratan: Referensi ke satu set persyaratan Non- fungsional: Non-fungsional yang membatasi layanan.
Provider: Referensi ke sejumlah objek sistem yang menyediakan layanan tersebut.
Peraga 6.5. Brainstorming untuk identifikasi sudut pandang
Peraga 6.6. Informasi layanan sudut pandang
Peraga 6.8 Hierarki sudut pandang
Peraga 6.9. Sudut Pandang nasabah dan deskripsi penarikan
6.2.2 SKENARIO
Skenario adalah deskripsi sesi interaksi contoh. Skenario bisa sangat berguna untuk menambahkan detail garis besar deskripsi persyaratan. Sknario dimulai dengan garis besar interaksi dan pada saat elisitasi, detil ditambahkan untuk menyusun deskripsi yang lengkap mengenai interaksi tersebut. Skenario yang umum dapat mencakup : • • • • • Deskripsi status sistem pada awal skenario; Deskripsi aliran event yang normal pada skenario; Deskripsi mengenai apa yang bisa salah dan bagaimana penanganannya; Informasi mengenai kegiatan lain yang bisa berlangsung pada saat yang sama; Deskripsi status sistem setelah berakhirnya skenario.
Skenario Event
Skenario event digunakan paa VORD untuk mendokumentasikan prilaku sistem jika dihadapkan pada event-event tertentu.
Aturan diagramatik yang dipakai pada skenario event adalah : Data yang diberikan dari sudut pandang atau diberikan ke sudut pandang digambarkan dengan elips.
Informasi kontrol masuk dan keluar ada di atas setiap kotak.
Data keluar dari kanan setiap kotak. Jika tidak tertutup, ini berarti bahwa data tersebut bersifat internal bagi sistem.
Eksepsi digambarkan di dasar kotak. Jika ada beberapa eksepsi yang mungkin, seluruhnya dimasukkan dalam satu kotak.
Nama event berikutnya yang diharapkan setelah skenario selesai ditunjukkan pada kotak yang diarsir.
Peraga 6.10. Skenario event Mulai transaksi
Pada gambar diatas menunjukkan bahwa ketika kartu dimasukkan, diminta nomor identifikasi pribadi (PIN) nasabah. Nasabah memasukkan kartunya beserta PIN. Jika kartu tersebut merupakan kartu valid yang dapat diproses oleh mesin, kontrol berlanjut ketahap berikutnya.
Pada tahap pertama ada tiga perkecualian (eksepsi) yang mungkin: 1. Waktu habis 2. Kartu invalid 3. Kartu curian
USE-CASE
Use-case adalah teknik berdasarkan skenario untuk elisitasi persyaratan. Use case sekarang telah menjadi fitur dasr notasi UML untuk mendeskripsikan model sistem berorientasi objek Peraga 6.11 Use-Case peminjaman Gambar diatas mengilustrasikan hal-hal penting pada notasi use-case.aktor pada proses ini direpresentasikan sebagai gambar orang dan setiap kelas interqaksi direpresentasikan sebagai elips nama.
Peraga 6.12 Use-Case Perpustakaan
Pearaga 6.13. Diagram sekuensial untuk manajeman katalog
6.2.3.ETNOGRAFI
Etnografi adalah teknik observasi yang dapat dipakai untuk memahami persyaratan sosial dan organisasional. Nilai etnografi membantu menemukan persyaratan sistem yang implisit yang merefleksikan proses sebenarnya, bukan proses formal, dimana orang orang terlibat.
Etnografi terutama efektif untuk menemukan 2 tipe persyaratan: Persyaratan yang berasal dari cara orang bekerja yang sebenarnya dan bukan cara yang ditentukan oleh definisi proses.
Persyaratan yang berasal dari kerja sama dan kesadaran akan kegiatan orang lain.
Peraga 6.14 Etnografi dan pembuatan prototipe untuk analisis persyaratan
Validasi persyaratan berkenaan dengan pengidentifikasian bahwa persyaratan benar-benar mendefinisikan sistem yang diinginkan pelanggan.
Validasi persyaratan penting karena error pada dokumen persyaratan dapat menimbulkan biaya pengerjaan ulang yang ekstensif jika ditemukan pada saat pengembangan atau setelah sistem dipakai.
Biaya melakukan perubahan sistem, yang merupakan akibat dari masalah persyaratan, lebih besar dari perbaikan desain atau kesalahan pengkodean.
Pada saat proses validasi persyaratan tipe pemeriksaan yang berbeda harus diterapkan pada persyaratan-persyaratan di dokumen persyaratan. Pemeriksaan ini meliputi : Pemeriksaan validitas.
Pemeriksaan konsistensi.
Pemeriksaan kelengkapan.
Pemeriksaan realisme.
Kemampuan dapat diverifikasi.
Ada sejumlah teknik validasi persyaratan yang dapat digunakan secara bersamaan atau berdiri sendiri: 1. Peninjauan persyaratan 2. Pembuatan prototipe 3. Pembuatan test-case 4. Analisis konsistensi terotomasi
Peraga 6.15 Pemerikasaan konsistensi persyaratan otomatis
6.3.1. PENINJAUAN PERSYARATAN
Peninjauan persyaratan biasanya merupakan proses manual yang melibatkan banyak pembaca, baik dari staf pelanggan maupun kontraktor yang memeriksa dokumen persyaratan untuk menemukan kejanggalan dan hal-hal yang terlewatkan.
Peninjauan persyaratan dapat bersifat informal atau formal. Peninjauan informal hanya melibatkan kontraktor yang membahas persyaratan dengan sebanyak mungkin stakeholder sistem. Sedangkan dalam peninjauan formal, tim pengembang harus “menuntun” pelanggan melalui persyaratan sistem, menjelaskan akibat dari setiap persyaratan.
Manajemen persyaratan adalah proses pemahaman dan pengendalian perubahan pada persyaratan sistem.
Proses manajemen persyaratan dilakukan bersama dengan proses rekayasa persyaratan yang lainnya.
Perencanaan dimulai pada saat yang sama dengan elisitasi persyaratan awal dan manajemen persyaratan aktif harus dimulai segera setelah versi draft dokumen persyaratan tersedia.
6.4.1 PERSYARATAN YANG BERTAHAN LAMA DAN BERUBAH-UBAH
Dari sudut pandang evolusi, persyaratan terbagi menjadi dua kelas: o Persyaratan bertahan . ini merupakan persyaratan yang relatif stabil, yang berasal dari kegiatan inti organisasi dan berhubungan langsung dengan domain sistem.
o Persyaratan yang berubah-ubah. Ini merupakan persyaratan yang mungkin berubah pada saat pengembangan sistem, atau setelah sistem dipakai.
Peraga 6.16 Evolusi Persyaratan
Jenis Persyaratan Keterangan Persyaratan yang dapat diubah Persyaratan yang berubah karena perubahan lingkungan di mana organisasi beroperasi Persyaratan yang baru muncul Persyartan yang muncul dengan berkembangnya pemahaman pelanggan akan sistem pada saat pengembangan sistem.
Persyaratan yang diakibatkan dari pengenalan sistem komputer Persyaratan sebagai konsekuensi Persyartan kompatibitas Persyaratan yang bergantung pada proses sistem atau bisnis yang khusus dalam organisasi Peraga 6.17 Klasifikasi persyaratan yang berubah-ubah
6.4.2. PERENCANAAN MANAJEMEN PERSYARATAN
Perencanaan merupakan tahap pertama yang penting pada pada proses manajemen persyaratan. Manajemen persyaratan sangat mahal dan untuk setiap proyek, tahap perencanaan menetapkan tingkat rincian manajemen persyaratan yang diperlukan. Pada tahap ini, kita harus membuat keputusan mengenai : Identifikasi persyaratan.
Proses manajemen perubahan.
Kebijakan agar dapat ditelusuri.
Dukungan alat bantu CASE ( CASE tool ).
Ada banyak hubungan antara persyaratan dan persyaratan lainnya dan antara persyaratan dan desain sistem.
Ada tiga tipe informasi kemampuan penelusuran yang dapat dipertahankan: • Informasi kemampuan penelusuran sumber.
• Informasi penelusuran persyaratan.
• Informasi ke-mamputelusuran-an (traceability) desain.
Peraga 6.18 Matriks Penelusuran
Manajemen persyaratan membutuhkan pendukung terotomasi dan alat bantu CASE (CASE tool) yang dipakai harus dipilih pada saat fase perencanaan . Alat bantu (tool) dibutuhkan untuk: 1. Penyimpanan persyaratan 2. Manajemen perubahan 3. Manajemen penelusuran
Peraga 6.19. Manajemen perubahan persyaratan
6.4.3. MANAJEMEN PERUBAHAN PERSYARATAN
Manajemen perubahan persyaratan harus diterapkan pada semua perubahan yang diusulkan untuk perubahan.
Ada tiga tahapan utama untuk proses manajemen perubahan : Analisis masalah dan spesifikasi perubahan.
Analisis dan perhitungan biaya perubahan.
Implementasi perubahan.