PROSES REKAYASA PERSYARATAN Chapt er 6 PRODI PENDIDIKAN TEKNIK INFORMATIKA DAN KOMPUTER JURUSAN PENDIDIKAN TEKNIK ELEKTRO FAKULTAS TEKNIK UNIVERSITAS NEGERI MAKASSAR
Jan 23, 2016
PROSES REKAYASA PERSYARATAN
Chapter 6
PRODI PENDIDIKAN TEKNIK INFORMATIKA DAN KOMPUTER
JURUSAN PENDIDIKAN TEKNIK ELEKTROFAKULTAS TEKNIK
UNIVERSITAS NEGERI MAKASSAR
092904006 SYAPUTRI ARTAMI S092904010 AYU ANGGRIANI H092904011 RUDI DIAN SYAH092904030 ZUL FADLY SULTHAN092904035 JUMIATI092904041 HUSNAENI092904043 NURHALIMAH
KELOMPOK 3
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
6.1. STUDI KELAYAKAN
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 ?
6.2. ELISITASI DAN ANALISIS
PERSYARATAN
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 : ini merupakan proses interaksi dengan 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.
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 yang mendapatkan informasi manajemen dari sistem;
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 yang bertanggung jawab untuk memelihara sistem dan meng-upgrade perangkat keras dan lunak.
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 .
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.
Tahap Utama metode VORD:
Peraga 6.3 Metode VORD
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.4. Form template sudut pandang dan layanan
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
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.
6.2.2 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 adalah teknik berdasarkan skenario untuk elisitasi persyaratan. Use case sekarang telah menjadi fitur dasr notasi UML untuk mendeskripsikan model sistem berorientasi objek
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.
USE-CASE
Peraga 6.11 Use-Case peminjaman
Peraga 6.12 Use-Case Perpustakaan
Pearaga 6.13. Diagram sekuensial untuk manajeman katalog
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.
6.2.3.ETNOGRAFI
Peraga 6.14 Etnografi dan pembuatan prototipe untuk analisis persyaratan
6.3. VALIDASI 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
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.
6.3.1. PENINJAUAN PERSYARATAN
6.4. MANAJEMEN 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.
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.
6.4.1 PERSYARATAN YANG BERTAHAN LAMA DAN BERUBAH-UBAH
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 sebagai konsekuensi
Persyaratan yang diakibatkan dari pengenalan sistem komputer
Persyartan kompatibitas Persyaratan yang bergantung pada proses sistem atau bisnis yang khusus dalam organisasi
Peraga 6.17 Klasifikasi persyaratan yang berubah-ubah
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 ).
6.4.2. PERENCANAAN MANAJEMEN PERSYARATAN
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
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.
6.4.3. MANAJEMEN PERUBAHAN PERSYARATAN
Terima Kasih
“SEMOGA BERMANFAAT”