Requirement Engineering

 Josua Siregar_11321012_D3TI

Requirement Engineering

REQUIREMENT

Persyaratan untuk sebuah sistem adalah:

• Deskripsi tentang apa yang harus dilakukan sistem
• Layanan yang diberikannya dan batasan operasinya

Persyaratan ini mencerminkan kebutuhan pelanggan untuk sistem yang melayani tujuan tertentu tujuan seperti mengendalikan perangkat, menempatkan pesanan, atau mencari informasi.

Proses menemukan, menganalisis, mendokumentasikan, dan memeriksanya layanan dan kendala disebut rekayasa persyaratan (RE).

(Sommerville, Software Engineering 9th Edition)

1. Requirement

Contoh dari sistem manajemen pasien perawatan kesehatan mental (MHC-PMS) ini menunjukkan bagaimana persyaratan pengguna dapat diperluas menjadi beberapa persyaratan sistem.

1.1. USER REQUIREMENT AND SYSTEM REQUIREMENT

Perbedaan PERSYARATAN PENGGUNA DAN KEBUTUHAN SISTEM

'persyaratan pengguna/(user requirement)' berarti persyaratan abstrak tingkat tinggi

'persyaratan sistem/(system requirement)' berarti deskripsi rinci tentang apa yang harus dilakukan sistem.

Persyaratan pengguna dan persyaratan sistem dapat didefinisikan sebagai berikut:

1. Persyaratan pengguna (user requirement) adalah pernyataan, dalam bahasa alami ditambah diagram, layanan apa yang diharapkan dari sistem berikan kepada pengguna sistem dan batasan yang harus beroperasi.
2. Persyaratan sistem (system requirement) adalah deskripsi yang lebih rinci tentang fungsi, layanan, dan operasional sistem perangkat lunak kendala. Dokumen persyaratan sistem (terkadang disebut spesifikasi fungsional) harus menentukan dengan tepat apa yang akan diimplementasikan. Ini mungkin bagian kontrak antara pembeli sistem dan pengembang perangkat lunak.

2.1. FUNCTIONAL REQUIREMENT

Functional requirements untuk suatu sistem menggambarkan apa yang harus dilakukan sistem. Ini persyaratan tergantung pada jenis perangkat lunak yang dikembangkan, pengguna yang diharapkan perangkat lunak, dan pendekatan umum yang diambil oleh organisasi saat menulis persyaratan.

Ketika dinyatakan sebagai kebutuhan pengguna, functional requirements biasanya dijelaskan secara abstrak yang dapat dipahami oleh pengguna sistem. Namun, persyaratan sistem fungsional yang lebih spesifik menggambarkan fungsi sistem, input dan output, pengecualian, dll., secara rinci

2.1. FUNCTIONAL REQUIREMENT

Persyaratan sistem fungsional bervariasi dari persyaratan umum yang mencakup apa yang sistem harus dilakukan untuk persyaratan yang sangat spesifik yang mencerminkan cara kerja lokal atau sistem organisasi yang ada.

Misalnya, berikut adalah contoh persyaratan fungsional untuk sistem MHC-PMS, yang digunakan untuk menjaga informasi tentang pasien yang menerima perawatan untuk masalah kesehatan mental:

• Pengguna dapat mencari daftar janji temu untuk semua klinik.
• Sistem akan menghasilkan setiap hari, untuk setiap klinik, daftar pasien yang diharapkan untuk menghadiri janji hari itu.
• Setiap anggota staf yang menggunakan sistem harus diidentifikasi secara unik dengan delapan digit nomor karyawannya.

2.2. NON-FUNCTIONAL REQUIREMENT

Persyaratan non-fungsional, seperti namanya, adalah persyaratan yang tidak berhubungan langsung dengan layanan spesifik yang diberikan oleh sistem kepada penggunanya. Mereka mungkin berhubungan dengan properti sistem yang muncul seperti kendala, waktu respons, dan kapasitas. Atau, mereka dapat menentukan batasan pada sistem implementasi seperti kemampuan perangkat I/O atau representasi data digunakan dalam antarmuka dengan sistem lain. Persyaratan non-fungsional, seperti kinerja, keamanan, atau ketersediaan, biasanya menentukan atau membatasi karakteristik sistem secara keseluruhan.

Persyaratan non-fungsional muncul melalui kebutuhan pengguna, karena anggaran kendala, kebijakan organisasi, kebutuhan akan interoperabilitas dengan pihak lain perangkat lunak atau sistem perangkat keras, atau faktor eksternal seperti peraturan keselamatan atau undang-undang privasi.

Jenis kebutuhan non-fungsional:

Metrik untuk menentukan kebutuhan non-fungsional:

(Dennis, Alan, Wixom, Barbara Haley, Roth, Roberta M, 2011, Systems Analysis and Design 5th Edition,USA, John Wiley & Sons, Inc.)

3. THE SOFTWARE REQUIREMENTS DOCUMENT 

Dokumen persyaratan perangkat lunak (kadang-kadang disebut persyaratan perangkat lunak spesifikasi atau SRS) adalah pernyataan resmi tentang apa yang harus dilakukan oleh pengembang sistem melaksanakan. Ini harus mencakup persyaratan pengguna untuk sistem dan detail spesifikasi kebutuhan sistem.

Terkadang, kebutuhan pengguna dan sistem diintegrasikan ke dalam satu deskripsi. Di dalam kasus lain, persyaratan pengguna didefinisikan dalam pengenalan sistem spesifikasi kebutuhan. Jika ada sejumlah besar persyaratan, detailnya persyaratan sistem dapat disajikan dalam dokumen terpisah.

Dokumen persyaratan sangat penting ketika kontraktor luar mengembangkan sistem perangkat lunak. Namun, pengembangan tangkas metode berpendapat bahwa persyaratan berubah begitu cepat sehingga dokumen persyaratan kedaluwarsa segera setelah ditulis, jadi upaya sebagian besar sia-sia. Alih-alih dokumen formal, pendekatan seperti Extreme Programming (Beck, 1999) mengumpulkan persyaratan pengguna secara bertahap dan tulis ini di kartu sebagai pengguna cerita. Pengguna kemudian memprioritaskan persyaratan untuk implementasi di peningkatan sistem berikutnya.

4. REQUIREMENT SPECIFICATION

Spesifikasi persyaratan adalah proses menuliskan pengguna dan persyaratan sistem dalam dokumen persyaratan. Idealnya, persyaratan pengguna dan sistem harus jelas, jelas, mudah dipahami, lengkap, dan konsisten. Di dalam praktiknya, hal ini sulit dicapai karena pemangku kepentingan menafsirkan persyaratan dengan cara yang berbeda dan sering ada yang melekat konflik dan inkonsistensi dalam persyaratan. 

Persyaratan pengguna untuk suatu sistem harus menggambarkan: kebutuhan fungsional dan non-fungsional sehingga dimengerti oleh pengguna sistem yang tidak memiliki detail pengetahuan teknis. Idealnya, mereka harus menentukan hanya perilaku eksternal sistem. Persyaratan dokumen tidak boleh menyertakan detail sistem arsitektur atau desain. Akibatnya, jika Anda menulis persyaratan pengguna, Anda tidak boleh menggunakan jargon perangkat lunak, notasi terstruktur, atau notasi formal. Anda harus menulis kebutuhan pengguna dalam bahasa alami, dengan tabel sederhana, bentuk, dan diagram intuitif.

Persyaratan pengguna hampir selalu ditulis secara alami bahasa yang dilengkapi dengan diagram dan tabel yang sesuai dalam dokumen persyaratan. Persyaratan sistem mungkin juga ditulis dalam bahasa alami tetapi notasi lain berdasarkan bentuk, model sistem grafis, atau matematika model sistem juga dapat digunakan.

4.1. NATURAL LANGUAGE SPECIFICATION

Bahasa alami telah digunakan untuk menulis persyaratan perangkat lunak sejak awal dari rekayasa perangkat lunak. Ini ekspresif, intuitif, dan universal. Ini juga berpotensi kabur, ambigu, dan artinya tergantung pada latar belakang pembaca. Untuk meminimalkan kesalahpahaman saat menulis bahasa alami persyaratan, saya sarankan untuk mengikuti beberapa panduan sederhana.

4.2 STRUCTURED SPECIFICATIONS 

Spesifikasi terstruktur dari suatu persyaratan untuk pompa insulin

Bahasa alami yang terstruktur adalah cara sistem penulisan persyaratan di mana kebebasan persyaratan penulis terbatas dan semua persyaratan ditulis dengan cara standar. Pendekatan ini mempertahankan sebagian besar ekspresi dan pemahaman bahasa alami tetapi memastikan bahwa beberapa keseragaman dikenakan pada spesifikasi. Tersusun notasi bahasa menggunakan template untuk menentukan sistem persyaratan. Spesifikasi dapat menggunakan pemrograman konstruksi bahasa untuk menunjukkan alternatif dan iterasi, dan dapat menyorot elemen kunci menggunakan bayangan atau font yang berbeda.

SPESIFIKASI TABULAR KOMPUTASI UNTUK POMPA INSULIN

Menggunakan spesifikasi terstruktur menghilangkan beberapa masalah spesifikasi bahasa alami. Variabilitas dalam spesifikasi berkurang dan persyaratan diatur lebih banyak efektif. Namun, terkadang masih sulit untuk menulis persyaratan dalam cara yang jelas dan tidak ambigu, terutama ketika perhitungan yang rumit (misalnya, bagaimana menghitung dosis insulin) harus ditentukan.

Untuk mengatasi masalah ini, Anda dapat menambahkan informasi tambahan ke persyaratan bahasa alami, misalnya, dengan menggunakan tabel atau model grafis dari sistem. Ini dapat menunjukkan bagaimana komputasi berlangsung, bagaimana status sistem berubah, bagaimana pengguna berinteraksi dengan sistem, dan bagaimana urutan tindakan dilakukan.

5. REQUIREMENTS ENGINEERING PROCESSES

Ini fokus pada penilaian apakah sistem berguna bagi bisnis (kelayakan studi), menemukan persyaratan (elisitasi dan analisis), mengubah persyaratan ini ke dalam beberapa bentuk standar (spesifikasi), dan pemeriksaan bahwa persyaratan benar-benar menentukan sistem yang diinginkan pelanggan (validasi). Namun, dalam praktiknya, rekayasa persyaratan adalah proses berulang di mana kegiatan tersebut disisipkan.

6. REQUIREMENTS ELICITATION AND ANALYSIS 

Setelah studi kelayakan awal, tahap selanjutnya dari persyaratan proses rekayasa adalah kebutuhan elisitasi dan analisis. Di dalam aktivitas, insinyur perangkat lunak bekerja dengan pelanggan dan pengguna akhir sistem untuk mengetahui tentang domain aplikasi, apa layanan sistem harus menyediakan, kinerja yang diperlukan dari sistem, perangkat keras, kendala, dan sebagainya.

Pengumpulan dan analisis persyaratan mungkin melibatkan berbagai berbagai jenis orang dalam suatu organisasi. Pemangku kepentingan sistem adalah siapa saja yang seharusnya memiliki pengaruh tidak langsung pada persyaratan sistem. Pemangku kepentingan termasuk pengguna akhir yang akan berinteraksi dengan sistem dan siapa pun di organisasi yang akan terkena dampaknya.

Pemangku kepentingan sistem lainnya mungkin insinyur yang mengembangkan atau memelihara sistem terkait lainnya, manajer bisnis, pakar domain, dan serikat pekerja perwakilan.

Kegiatan proses tersebut adalah:

1. Penemuan persyaratan. Ini adalah proses berinteraksi dengan pemangku kepentingan sistem untuk menemukan kebutuhan mereka. Persyaratan domain dari pemangku kepentingan dan dokumentasi juga ditemukan selama kegiatan ini..
2. Klasifikasi dan organisasi persyaratan. Kegiatan ini mengambil kumpulan persyaratan yang tidak terstruktur, persyaratan terkait kelompok, dan mengatur mereka ke dalam kelompok yang koheren. Cara pengelompokan yang paling umum persyaratan adalah dengan menggunakan model arsitektur sistem untuk mengidentifikasi sub-sistem dan untuk mengasosiasikan kebutuhan dengan setiap sub-sistem. Dalam prakteknya, persyaratan teknik dan desain arsitektur tidak dapat sepenuhnya dipisahkan.
3. Prioritas dan negosiasi persyaratan. Tak pelak, ketika banyak pemangku kepentingan yang terlibat, persyaratan akan konflik. Kegiatan ini adalah berkaitan dengan memprioritaskan persyaratan dan menemukan dan menyelesaikan konflik kebutuhan melalui negosiasi. Biasanya, pemangku kepentingan harus bertemu untuk menyelesaikan perbedaan dan menyepakati persyaratan kompromi.
4. Spesifikasi persyaratan. Persyaratan didokumentasikan dan dimasukkan ke putaran spiral berikutnya.

Pemangku kepentingan berkisar dari pengguna akhir sistem melalui manajer hingga pemangku kepentingan eksternal seperti regulator, yang mengesahkan akseptabilitas dari sistem.

Misalnya, pemangku kepentingan sistem untuk pasien perawatan kesehatan mental sistem informasi antara lain:

1. Pasien yang informasinya tercatat dalam sistem.
2. Dokter yang bertanggung jawab untuk menilai dan merawat pasien.
3. Perawat yang mengoordinasikan konsultasi dengan dokter dan mengelola beberapa perawatan.
4. Resepsionis medis yang mengelola janji temu pasien.
5. Staf TI yang bertanggung jawab untuk menginstal dan memelihara sistem.
6. Seorang manajer etika medis yang harus memastikan bahwa sistem memenuhi saat ini pedoman etik untuk perawatan pasien.
7. Manajer layanan kesehatan yang memperoleh informasi manajemen dari sistem.
8. Staf rekam medis yang bertanggung jawab untuk memastikan sistem tersebut informasi dapat dipelihara dan dilestarikan, dan pencatatan itu prosedur telah dilaksanakan dengan baik.

6.1. REQUIREMENTS DISCOVERY

Penemuan persyaratan (kadang-kadang disebut persyaratan elisitasi) adalah proses mengumpulkan informasi tentang sistem yang dibutuhkan dan sistem yang ada, dan menyaring pengguna dan persyaratan sistem dari informasi ini. Sumber dari informasi selama fase penemuan persyaratan meliputi dokumentasi, pemangku kepentingan sistem, dan spesifikasi sistem serupa. Anda berinteraksi dengan pemangku kepentingan melalui wawancara dan observasi dan Anda dapat menggunakan skenario dan prototipe untuk membantu pemangku kepentingan memahami apa yang sistem akan seperti.

Selain pemangku kepentingan sistem, kami telah melihat bahwa persyaratan juga dapat berasal dari domain aplikasi dan dari sistem lain yang berinteraksi dengan sistem sedang ditentukan. Semua ini harus dipertimbangkan selama elisitasi persyaratan proses. Sumber kebutuhan yang berbeda ini (pemangku kepentingan, domain, sistem) semuanya dapat direpresentasikan sebagai sudut pandang sistem dengan setiap sudut pandang menunjukkan subset dari persyaratan untuk sistem. Sudut pandang yang berbeda pada suatu masalah melihat masalah dalam cara yang berbeda. Namun, perspektif mereka tidak sepenuhnya independen tetapi biasanya tumpang tindih sehingga memiliki persyaratan yang sama. Anda dapat menggunakan sudut pandang ini untuk menyusun penemuan dan dokumentasi persyaratan sistem.

6.2. WAWANCARA

Wawancara formal atau informal dengan pemangku kepentingan sistem adalah bagian dari sebagian besar proses rekayasa kebutuhan. Dalam wawancara ini, tim rekayasa persyaratan mengajukan pertanyaan kepada pemangku kepentingan tentang sistem yang mereka gunakan saat ini dan sistem yang akan dikembangkan. Persyaratan berasal dari jawaban atas pertanyaan-pertanyaan ini. Wawancara mungkin dari dua jenis:

1. Wawancara tertutup, di mana pemangku kepentingan menjawab serangkaian pertanyaan yang telah ditentukan sebelumnya pertanyaan.
2. Wawancara terbuka, di mana tidak ada agenda yang ditentukan sebelumnya. Itu tim rekayasa persyaratan mengeksplorasi berbagai masalah dengan sistem pemangku kepentingan dan karenanya mengembangkan pemahaman yang lebih baik tentang kebutuhan mereka.

Dalam praktiknya, wawancara dengan pemangku kepentingan biasanya merupakan campuran dari keduanya. Anda mungkin harus mendapatkan jawaban untuk pertanyaan tertentu tetapi ini biasanya mengarah ke isu-isu lain yang dibahas dengan cara yang kurang terstruktur. Diskusi yang benar-benar terbuka jarang berhasil dengan baik. Anda biasanya harus bertanya beberapa pertanyaan untuk memulai dan agar wawancara tetap terfokus pada sistem yang akan maju. 

Wawancara baik untuk mendapatkan pemahaman menyeluruh tentang apa yang dilakukan pemangku kepentingan, bagaimana mereka dapat berinteraksi dengan sistem baru, dan kesulitan yang mereka hadapi dengan sistem saat ini. Orang-orang suka membicarakan pekerjaan mereka, jadi biasanya senang terlibat dalam wawancara. Namun, wawancara tidak begitu membantu dalam memahami persyaratan dari domain aplikasi. Mungkin sulit untuk memperoleh pengetahuan domain melalui wawancara

karena dua alasan:

1. Semua spesialis aplikasi menggunakan terminologi dan jargon yang spesifik ke sebuah domain. Tidak mungkin bagi mereka untuk mendiskusikan persyaratan domain tanpa menggunakan terminologi ini. Mereka biasanya menggunakan terminologi secara tepat dan cara halus yang mudah disalahpahami oleh para insinyur persyaratan.
2. Beberapa pengetahuan domain sangat familiar bagi para pemangku kepentingan sehingga mereka juga merasa sulit untuk dijelaskan atau mereka pikir itu sangat mendasar sehingga tidak layak disebut. Misalnya, untuk seorang pustakawan, tidak perlu dikatakan lagi semua akuisisi dikatalogkan sebelum ditambahkan ke perpustakaan. Namun, ini mungkin tidak jelas bagi pewawancara, sehingga tidak diambil diperhitungkan dalam persyaratan.

Wawancara juga bukan teknik yang efektif untuk memperoleh pengetahuan tentang persyaratan dan kendala organisasi karena ada kekuatan halus hubungan antara orang-orang yang berbeda dalam organisasi. Organisasi yang diterbitkan struktur jarang cocok dengan realitas pengambilan keputusan dalam suatu organisasi tetapi orang yang diwawancarai mungkin tidak ingin mengungkapkan yang sebenarnya daripada struktur teoretis untuk orang asing.

Secara umum, kebanyakan orang umumnya enggan membahas politik dan organisasi masalah yang dapat mempengaruhi persyaratan.

PEWAWANCARA EFEKTIF MEMILIKI DUA KARAKTERISTIK:

1. Mereka berpikiran terbuka, menghindari gagasan yang terbentuk sebelumnya tentang persyaratan, dan bersedia mendengarkan pemangku kepentingan. Jika pemangku kepentingan muncul dengan persyaratan yang mengejutkan, maka mereka bersedia berubah pikiran tentang sistem.
2. Mereka meminta orang yang diwawancarai untuk memulai diskusi menggunakan sebuah pertanyaan batu loncatan, proposal persyaratan, atau dengan bekerja sama dalam sistem prototipe. Mengatakan kepada orang-orang 'beri tahu saya apa yang Anda inginkan' tidak mungkin menghasilkan informasi berguna. Mereka merasa jauh lebih mudah untuk berbicara dalam konteks yang ditentukan daripada daripada secara umum

6.3. SCENARIOS

Orang biasanya merasa lebih mudah untuk berhubungan dengan contoh kehidupan nyata daripada abstrak deskripsi. Mereka dapat memahami dan mengkritik skenario tentang bagaimana mereka mungkin berinteraksi dengan sistem perangkat lunak. Persyaratan insinyur dapat menggunakan informasi yang diperoleh dari diskusi ini untuk merumuskan sistem yang sebenarnya persyaratan. Skenario dapat sangat berguna untuk menambahkan detail ke garis besar deskripsi persyaratan. Cerita yang digunakan dalam pemrograman ekstrim, adalah jenis skenario persyaratan. Skenario dimulai dengan garis besar interaksi. 

Selama elisitasi proses, detail ditambahkan ke ini untuk membuat deskripsi lengkap dari interaksi itu. Secara umum, skenario dapat mencakup:

1. Deskripsi tentang apa yang diharapkan sistem dan pengguna ketika skenario dimulai.
2. Deskripsi aliran normal peristiwa dalam skenario.
3. Penjelasan tentang apa yang bisa salah dan bagaimana ini ditangani.
4. Informasi tentang kegiatan lain yang mungkin terjadi pada saat yang sama waktu.
5. Deskripsi status sistem saat skenario selesai.

6.4. USE CASES

Use case adalah teknik penemuan kebutuhan yang pertama kali diperkenalkan di Metode keberatan (Jacobson et al., 1993). Mereka sekarang telah menjadi fundamental fitur dari bahasa pemodelan terpadu. Dalam bentuknya yang paling sederhana, sebuah use case mengidentifikasi aktor yang terlibat dalam interaksi dan menyebutkan jenis interaksi. Ini kemudian dilengkapi dengan informasi tambahan yang menjelaskan interaksi dengan sistem. Informasi tambahan dapat berupa deskripsi tekstual atau satu atau lebih banyak model grafis seperti urutan UML atau bagan status.

Use case didokumentasikan menggunakan diagram use case tingkat tinggi. Himpunan kasus penggunaan mewakili semua kemungkinan interaksi yang akan terjadi dijelaskan dalam persyaratan sistem. Aktor dalam proses, yang mungkin manusia atau sistem lain, direpresentasikan sebagai figur tongkat. Setiap kelas interaksi adalah direpresentasikan sebagai elips bernama. Garis menghubungkan aktor dengan interaksi. Secara opsional, panah dapat ditambahkan ke garis untuk menunjukkan bagaimana interaksinya dimulai. Ini diilustrasikan pada beberapa kasus penggunaan untuk sistem informasi pasien. 

Use case mengidentifikasi interaksi individu antara sistem dan penggunanya atau sistem lainnya. Setiap kasus penggunaan harus didokumentasikan dengan tekstual keterangan. Ini kemudian dapat dihubungkan ke model lain di UML yang akan mengembangkan skenario secara lebih rinci.

Konsultasi pengaturan memungkinkan dua atau lebih dokter, bekerja di tempat yang berbeda kantor, untuk melihat catatan yang sama pada waktu yang sama. Satu dokter memulai konsultasi dengan memilih orang-orang yang terlibat dari menu drop-down dokter yang sedang online. Catatan pasien adalah kemudian ditampilkan di layar mereka tetapi hanya dokter yang memulai yang dapat mengedit rekaman. Selain itu, jendela obrolan teks dibuat untuk membantu mengkoordinasikan tindakan. Diasumsikan bahwa konferensi telepon untuk suara komunikasi akan diatur secara terpisah.

Skenario dan kasus penggunaan adalah teknik yang efektif untuk memperoleh persyaratan dari pemangku kepentingan yang berinteraksi langsung dengan sistem. Setiap jenis interaksi dapat direpresentasikan sebagai kasus penggunaan. Namun, karena mereka fokus pada interaksi dengan sistem, mereka tidak efektif untuk menimbulkan kendala atau bisnis tingkat tinggi dan persyaratan nonfungsional atau untuk menemukan persyaratan domain. UML adalah de standar facto untuk pemodelan berorientasi objek, jadi gunakan kasus dan gunakan kasus berbasis elisitasi sekarang banyak digunakan untuk elisitasi persyaratan

6.5. ETHNOGRAPHY

Suchman (1987) memelopori penggunaan etnografi untuk mempelajari pekerjaan kantor. Dia menemukan bahwa praktik kerja yang sebenarnya jauh lebih kaya, lebih kompleks, dan lebih dinamis daripada model sederhana yang diasumsikan oleh kantor sistem otomatisasi. Perbedaan antara asumsi dan pekerjaan yang sebenarnya adalah alasan paling penting mengapa sistem kantor ini tidak berpengaruh signifikan terhadap produktivitas. Crabtree (2003) membahas berbagai studi sejak itu dan menjelaskan, secara umum, penggunaan etnografi dalam desain sistem. Dalam penelitian saya sendiri, saya punya menyelidiki metode mengintegrasikan etnografi ke dalam perangkat lunak proses rekayasa dengan menghubungkannya dengan rekayasa persyaratan metode (Viller dan Sommerville, 1999; Viller dan Sommerville, 2000) dan mendokumentasikan pola interaksi dalam sistem kooperatif (Martin dkk., 2001; Martin dkk., 2002; Martin dan Sommerville, 2004). Etnografi sangat efektif untuk menemukan dua jenis persyaratan:

ETHNOGRAPHY AND PROTOTYPING FOR REQUIREMENTS ANALYSIS

1. Persyaratan yang diturunkan dari cara orang benar-benar bekerja, bukan daripada cara di mana definisi proses mengatakan bahwa mereka seharusnya bekerja. Misalnya udara pengendali lalu lintas dapat mematikan sistem peringatan konflik yang mendeteksi pesawat dengan berpotongan jalur penerbangan, meskipun prosedur kontrol normal menentukan bahwa seharusnya digunakan. Mereka sengaja menempatkan pesawat di jalur yang saling bertentangan untuk sementara waktu waktu untuk membantu mengelola wilayah udara. Strategi pengendalian mereka dirancang untuk memastikan bahwa pesawat-pesawat ini dipindahkan terpisah sebelum masalah terjadi dan mereka menemukan bahwa alarm peringatan konflik mengalihkan perhatian mereka dari pekerjaan mereka.
2. Persyaratan yang berasal dari kerjasama dan kesadaran orang lain kegiatan orang. Misalnya, pengontrol lalu lintas udara dapat menggunakan kesadaran akan pekerjaan pengontrol lain untuk memprediksi jumlah pesawat yang akan memasuki sektor kontrol mereka. Mereka kemudian memodifikasi kendali mereka strategi tergantung pada beban kerja yang diprediksi. Oleh karena itu, sebuah sistem ATC otomatis harus memungkinkan pengontrol di suatu sektor untuk memiliki beberapa visibilitas pekerjaan di sektor yang berdekatan.

Etnografi menginformasikan pengembangan prototipe sehingga lebih sedikit penyempurnaan prototipe

siklus diperlukan. Selanjutnya, prototyping memfokuskan etnografi dengan mengidentifikasi masalah dan pertanyaan yang kemudian dapat didiskusikan dengan ahli etnografi. Dia kemudian harus mencari jawaban atas pertanyaan-pertanyaan ini selama fase berikutnya dari studi sistem (Sommerville et al., 1993).

7. REQUIREMENTS VALIDATION

Validasi persyaratan adalah proses pengecekan bahwa persyaratan benar-benar mendefinisikan sistem yang benar-benar pelanggan ingin. Ini tumpang tindih dengan analisis karena berkaitan dengan penemuan masalah dengan persyaratan. 

Validasi persyaratan adalah penting karena kesalahan dalam dokumen persyaratan dapat menyebabkan

biaya pengerjaan ulang yang ekstensif ketika masalah ini ditemukan selama pengembangan atau setelah sistem dalam pelayanan. Biaya untuk memperbaiki masalah persyaratan dengan membuat perubahan sistem biasanya banyak lebih besar daripada memperbaiki kesalahan desain atau pengkodean. Alasan untuk ini adalah bahwa perubahan persyaratan biasanya berarti bahwa sistem desain dan implementasi juga harus diubah. Selanjutnya sistem kemudian harus diuji ulang. Selama validasi persyaratan proses, berbagai jenis pemeriksaan harus dilakukan pada persyaratan dalam dokumen persyaratan. Pemeriksaan ini meliputi:

1. Pemeriksaan validitas. Seorang pengguna mungkin berpikir bahwa suatu sistem diperlukan untuk melakukan fungsi-fungsi tertentu. Namun, pemikiran dan analisis lebih lanjut dapat mengidentifikasi fungsi tambahan atau berbeda yang diperlukan. Sistem memiliki beragam pemangku kepentingan dengan kebutuhan yang berbeda dan serangkaian persyaratan adalah tak terhindarkan kompromi di seluruh komunitas pemangku kepentingan.
2. Pemeriksaan konsistensi. Persyaratan dalam dokumen tidak boleh bertentangan. Artinya, tidak boleh ada kendala yang kontradiktif atau berbeda deskripsi fungsi sistem yang sama.
3. Pemeriksaan kelengkapan. Dokumen persyaratan harus mencakup: persyaratan yang mendefinisikan semua fungsi dan batasan yang dimaksudkan oleh pengguna sistem.
4. Pemeriksaan realisme. Menggunakan pengetahuan tentang teknologi yang ada, persyaratan harus diperiksa untuk memastikan bahwa mereka benar-benar dapat dilaksanakan. Pemeriksaan ini juga harus memperhitungkan anggaran dan jadwal pengembangan sistem.
5. Verifiability. Untuk mengurangi potensi perselisihan antara pelanggan dan kontraktor, persyaratan sistem harus selalu ditulis sedemikian rupa sehingga dapat diverifikasi. Ini berarti Anda harus dapat menulis serangkaian tes yang dapat menunjukkan bahwa sistem yang dikirimkan memenuhi setiap yang ditentukan persyaratan.

Ada sejumlah teknik validasi persyaratan yang: dapat digunakan secara individu atau bersama-sama:

1. Tinjauan persyaratan. Persyaratan dianalisis sistematis oleh tim peninjau yang memeriksa kesalahan dan inkonsistensi.
2. Pembuatan prototipe. Dalam pendekatan validasi ini, model yang dapat dieksekusi dari sistem yang bersangkutan ditunjukkan kepada pengguna akhir dan pelanggan. Mereka dapat bereksperimen dengan model ini untuk melihat apakah itu memenuhi kebutuhan nyata mereka.
3. Pembuatan kasus uji. Persyaratan harus dapat diuji. Jika tes untuk persyaratan dirancang sebagai bagian dari proses validasi, ini sering mengungkapkan masalah persyaratan. Jika sebuah tes sulit atau tidak mungkin dirancang, ini biasanya berarti bahwa: persyaratan akan sulit untuk diterapkan dan harus dipertimbangkan kembali. Mengembangkan tes dari persyaratan pengguna sebelum kode apa pun ditulis adalah bagian integral dari pemrograman ekstrim.

Anda tidak boleh meremehkan masalah yang terlibat dalam validasi persyaratan. Pada akhirnya, itu sulit untuk menunjukkan bahwa seperangkat persyaratan memang memenuhi kebutuhan pengguna. Pengguna perlu membayangkan sistem yang sedang beroperasi dan membayangkan bagaimana sistem itu akan cocok dengan mereka kerja. Sulit bahkan bagi profesional komputer yang terampil untuk melakukan jenis abstrak ini analisis dan lebih sulit lagi bagi pengguna sistem. Akibatnya, Anda jarang menemukan semua persyaratan masalah selama proses validasi persyaratan. Tidak dapat dihindari bahwa akan ada perubahan persyaratan lebih lanjut untuk mengoreksi kelalaian dan kesalahpahaman setelah dokumen persyaratan telah disepakati.

8. REQUIREMENTS MANAGEMENT

Persyaratan untuk sistem perangkat lunak besar selalu berubah. Salah satu alasannya adalah bahwa sistem ini biasanya dikembangkan untuk mengatasi masalah 'jahat'— masalah yang tidak dapat diselesaikan sepenuhnya didefinisikan. Karena masalahnya tidak dapat didefinisikan sepenuhnya, persyaratan perangkat lunak pasti tidak lengkap. Selama proses perangkat lunak, pemahaman pemangku kepentingan tentang masalah terus berubah. Persyaratan sistem harus kemudian juga berevolusi untuk mencerminkan pandangan masalah yang berubah ini.

Setelah sistem diinstal dan digunakan secara teratur, persyaratan baru pasti ada muncul. Sulit bagi pengguna dan pelanggan sistem untuk mengantisipasi efek apa yang sistem baru akan memiliki proses bisnis mereka dan cara pekerjaan itu dilakukan. Setelah pengguna akhir memiliki pengalaman sistem, mereka akan menemukan kebutuhan baru dan prioritas. Ada beberapa alasan mengapa perubahan tidak dapat dihindari:

1. Lingkungan bisnis dan teknis sistem selalu berubah setelah instalasi. Perangkat keras baru mungkin diperkenalkan, mungkin perlu untuk antarmuka sistem dengan sistem lain, prioritas bisnis dapat berubah (dengan konsekuensi perubahan dalam dukungan sistem yang diperlukan), dan undang-undang dan peraturan baru mungkin diperkenalkan bahwa sistem harus selalu dipatuhi.
2. Orang yang membayar sistem dan pengguna sistem itu jarang orang yang sama. Pelanggan sistem memaksakan persyaratan karena kendala organisasi dan anggaran. Ini mungkin bertentangan dengan pengguna akhir persyaratan dan, setelah pengiriman, fitur baru mungkin harus ditambahkan untuk dukungan pengguna jika sistem ingin memenuhi tujuannya.

Sistem besar biasanya memiliki komunitas pengguna yang beragam, dengan banyak pengguna memiliki

persyaratan dan prioritas yang berbeda yang mungkin bertentangan atau bertentangan. Itu persyaratan sistem akhir pasti merupakan kompromi di antara mereka dan, dengan pengalaman, sering ditemukan bahwa keseimbangan dukungan yang diberikan kepada yang berbeda pengguna harus diubah.

Manajemen persyaratan adalah proses memahami dan mengendalikan perubahan pada sistem persyaratan. Anda perlu melacak kebutuhan individu dan memelihara tautan antara persyaratan dependen sehingga Anda dapat menilai dampak persyaratan perubahan. Anda perlu menetapkan proses formal untuk membuat proposal perubahan dan menghubungkan ini untuk persyaratan sistem. Proses formal manajemen persyaratan harus mulai segera setelah versi draf dokumen persyaratan tersedia. Namun, kamu harus mulai merencanakan bagaimana mengelola perubahan persyaratan selama persyaratan proses elisitasi.

9.1. REQUIREMENTS MANAGEMENT PLANNING

Perencanaan adalah tahap pertama yang penting dalam manajemen persyaratan proses. Tahap perencanaan menetapkan tingkat persyaratan detail manajemen yang diperlukan. Selama manajemen persyaratan tahap, Anda harus memutuskan:

1. Identifikasi kebutuhan. Setiap persyaratan harus unik diidentifikasi sehingga dapat direferensikan silang dengan persyaratan lain dan digunakan dalam penilaian ketertelusuran.
2. Proses manajemen perubahan. Ini adalah rangkaian kegiatan yang menilai dampak dan biaya perubahan. Saya membahas proses ini di lebih detail pada bagian berikut.
3. Kebijakan ketertelusuran. Kebijakan ini menentukan hubungan antara setiap persyaratan dan antara persyaratan dan desain sistem yang harus direkam. Kebijakan ketertelusuran juga harus menentukan bagaimana catatan ini harus dipelihara.
4. Dukungan alat. Manajemen persyaratan melibatkan pemrosesan sejumlah besar informasi tentang persyaratan. Alat yang dapat digunakan berkisar dari spesialis sistem manajemen persyaratan ke spreadsheet dan sederhana sistem basis data.

Manajemen persyaratan membutuhkan dukungan otomatis dan perangkat lunak untuk ini harus dipilih selama fase perencanaan. Anda membutuhkan alat mendukung:

1. Penyimpanan persyaratan Persyaratan harus disimpan di tempat yang aman, penyimpanan data terkelola yang dapat diakses oleh semua orang yang terlibat dalam proses rekayasa kebutuhan.
2. Manajemen perubahan Proses manajemen perubahan  adalah disederhanakan jika dukungan alat aktif tersedia.
3. Manajemen ketertelusuran Seperti dibahas di atas, dukungan alat untuk ketertelusuran memungkinkan persyaratan terkait ditemukan. Beberapa alat tersedia yang menggunakan teknik pemrosesan bahasa alami untuk membantu menemukan kemungkinan hubungan antara persyaratan. Untuk sistem kecil, mungkin tidak perlu menggunakan khusus alat manajemen kebutuhan. Persyaratan proses manajemen dapat didukung menggunakan fasilitas tersedia dalam pengolah kata, spreadsheet, dan PC database. Namun, untuk sistem yang lebih besar, lebih terspesialisasi dukungan alat diperlukan. Saya telah menyertakan tautan ke informasi tentang alat manajemen persyaratan di web buku halaman.

Ada tiga tahap utama untuk proses manajemen perubahan:

1. Analisis masalah dan spesifikasi perubahan. Prosesnya dimulai dengan identifikasi masalah persyaratan atau, kadang-kadang, dengan proposal perubahan tertentu. Selama tahap ini, masalah atau proposal perubahan dianalisis untuk memastikan validitasnya. Analisis ini adalah umpan balik kepada pemohon perubahan yang mungkin merespons dengan perubahan persyaratan yang lebih spesifik proposal, atau memutuskan untuk menarik permintaan tersebut.
2. Analisis perubahan dan penetapan biaya. Efek dari perubahan yang diusulkan dinilai menggunakan informasi ketertelusuran dan pengetahuan umum tentang persyaratan sistem. Biaya dari membuat perubahan diperkirakan baik dari segi modifikasi persyaratan dokumen dan, jika sesuai, dengan desain dan implementasi sistem. Setelah analisis ini selesai, keputusan dibuat apakah akan melanjutkan perubahan persyaratan atau tidak.
3. Perubahan implementasi. Dokumen persyaratan dan, di mana diperlukan, desain dan implementasi sistem, dimodifikasi. Kamu harus mengatur dokumen persyaratan sehingga Anda dapat membuat perubahan untuk itu tanpa penulisan ulang atau reorganisasi ekstensif. Seperti halnya program, perubahan dalam dokumen dicapai dengan meminimalkan referensi eksternal dan membuat bagian dokumen sebagai modular mungkin. Dengan demikian, bagian individu dapat diubah dan diganti tanpa mempengaruhi bagian lain dari dokumen.

Jika persyaratan baru harus segera dilaksanakan, selalu ada sebuah godaan untuk mengubah sistem dan kemudian memodifikasi secara retrospektif dokumen persyaratan. Anda harus mencoba menghindari ini karena hampir pasti mengarah ke spesifikasi persyaratan dan implementasi sistem menjadi keluar dari langkah. Setelah perubahan sistem dibuat, mudah untuk melupakan termasuk perubahan ini dalam dokumen persyaratan atau untuk menambahkan informasi ke dokumen persyaratan yang tidak sesuai dengan pelaksanaan.

Proses pengembangan tangkas, seperti pemrograman ekstrem, telah dirancang untuk mengatasi persyaratan yang berubah selama pengembangan proses. Dalam proses ini, ketika pengguna mengusulkan perubahan persyaratan, perubahan ini tidak melalui proses manajemen perubahan formal.

Sebaliknya, pengguna harus memprioritaskan perubahan itu dan, jika itu adalah prioritas tinggi, putuskan fitur sistem apa yang direncanakan untuk iterasi berikutnya? menjatuhkan.

Referensi 

Dennis, Alan, Wixom, Barbara Haley, Roth, Roberta M, 2011, Systems Analysis and Design 5th Edition,USA, John Wiley & Sons, Inc. Sommerville, Ian, 2011, Software Engineering (9th Edition). USA, Pearson Education.