proses rekayasa persyaratan

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”