You Are Reading

0

Perangkat Lunak Rekayasa Kebutuhan: Apa, Mengapa, Siapa, Kapan, dan Bagaimana

Syahaffath Assegaf Rabu, 19 Desember 2012

Oleh Linda Westfall

Kata kunci: rekayasa persyaratan, persyaratan elisitasi, analisis persyaratan, spesifikasi persyaratan, persyaratan manajemen, pemangku kepentingan

ABSTRAK

. Jika persyaratan perangkat lunak yang tidak benar, perusahaan tidak akan berakhir dengan perangkat lunak yang mereka butuhkan Artikel ini akan membahas:

• Apa: The berbagai tingkat dan jenis kebutuhan yang perlu didefinisikan

• Mengapa: Manfaat memiliki persyaratan perangkat lunak yang tepat

• Siapa: Para pemangku kepentingan dari persyaratan perangkat lunak dan membuat mereka terlibat dalam proses

• Ketika: kegiatan Persyaratan seluruh siklus hidup pengembangan perangkat lunak

• Bagaimana: Teknik untuk memunculkan, menganalisis, menentukan, dan memvalidasi persyaratan perangkat lunak


APA

. Persyaratan harus ditentukan dan disepakati oleh para pelanggan, pengguna, dan pemasok produk perangkat lunak sebelum perangkat lunak dapat dibangun Persyaratan mendefinisikan "apa" dari produk perangkat lunak:

• Perangkat lunak apa yang harus dilakukan untuk menambah nilai bagi para pemangku kepentingan. Persyaratan fungsional menentukan kemampuan dari produk software.

• Apa perangkat lunak harus untuk menambah nilai bagi para stakeholder ini persyaratan nonfunctional mendefinisikan karakteristik, sifat, atau kualitas bahwa produk perangkat lunak harus memiliki.. Mereka mendefinisikan seberapa baik produk melakukan fungsinya.

• Apa keterbatasan terdapat pada pilihan bagi para pengembang ketika menerapkan perangkat lunak. Definisi antarmuka eksternal dan kendala lainnya mendefinisikan keterbatasan ini.

Praktisi Kebanyakan perangkat lunak hanya berbicara tentang Namun "persyaratan.", Dengan mengakui bahwa ada berbagai tingkat dan jenis kebutuhan, seperti digambarkan pada Gambar 1 diadaptasi dari Karl Wiegers (2004), praktisi mendapatkan pemahaman yang lebih baik tentang informasi apa yang mereka butuhkan untuk mendapatkan , menganalisis, menentukan, dan memvalidasi ketika mereka menentukan persyaratan perangkat lunak mereka.

Kebutuhan bisnis mendefinisikan masalah bisnis yang akan dipecahkan atau peluang bisnis yang akan ditangani oleh produk software. Secara umum, kebutuhan bisnis menentukan mengapa produk software sedang dikembangkan. Persyaratan Bisnis

biasanya dinyatakan dalam hal tujuan dari pelanggan atau organisasi yang mengajukan permohonan pengembangan perangkat lunak.

Kebutuhan pengguna melihat fungsi dari produk perangkat lunak dari perspektif pengguna Mereka menentukan software apa yang harus dilakukan agar pengguna untuk mencapai tujuan mereka.. Beberapa user-level persyaratan mungkin diperlukan untuk memenuhi
tunggal bisnis persyaratan.


Gambar 1 Tingkat dan jenis kebutuhan

Sebagai contoh, kebutuhan bisnis untuk memungkinkan pelanggan untuk membayar gas di SPBU mungkin diterjemahkan ke dalam persyaratan beberapa pengguna, termasuk persyaratan bagi pengguna untuk:

• Geser kredit atau kartu debit

• Masukkan nomor PIN keamanan

• Meminta tanda terima di SPBU

Persyaratan fungsional produk yang mendefinisikan fungsi perangkat lunak harus dibangun ke dalam produk untuk memungkinkan pengguna untuk menyelesaikan tugas-tugas mereka, sehingga memenuhi kebutuhan bisnis Beberapa persyaratan tingkat fungsional mungkin diperlukan untuk memenuhi kebutuhan pengguna.. Misalnya, persyaratan bahwa pengguna bisa menggesek kartu kredit mereka mungkin diterjemahkan ke dalam persyaratan fungsional multiple termasuk persyaratan untuk perangkat lunak untuk:

• Prompt pelanggan untuk menempatkan kartu nya ke pembaca

• Mendeteksi bahwa kartu telah digesek

• Menentukan apakah kartu itu salah membaca dan meminta pelanggan untuk menggesek kartu lagi

• Parse informasi dari strip magnetik pada kartu

Berbeda dengan kebutuhan bisnis, aturan bisnis adalah kebijakan khusus, standar, praktek, peraturan, dan pedoman yang menentukan bagaimana pengguna melakukan bisnis
(Dan karena itu dianggap user-level persyaratan). Produk perangkat lunak harus mematuhi aturan-aturan ini agar dapat berfungsi secara tepat dalam domain pengguna.

User-level atribut kualitas adalah karakteristik nonfunctional yang menentukan kualitas produk perangkat lunak Kadang-kadang disebut. "Ilities," termasuk atribut kualitas keandalan, ketersediaan, keamanan, keselamatan, pemeliharaan, portabilitas, kegunaan, dan properti lainnya. Sebuah atribut kualitas dapat diterjemahkan ke dalam produk tingkat fungsional persyaratan untuk perangkat lunak yang menentukan apa fungsi harus ada untuk memenuhi atribut nonfunctional. Untuk

Sebagai contoh, suatu kemudahan belajar persyaratan mungkin diterjemahkan ke dalam persyaratan fungsional memiliki sistem tampilan pop-up membantu ketika pengguna melayang kursor di atas ikon.

Sebuah atribut kualitas juga dapat menerjemahkan ke dalam produk-tingkat persyaratan nonfunctional yang menentukan karakteristik perangkat lunak harus memiliki dalam rangka memenuhi atribut tersebut. Sebagai contoh, persyaratan kemudahan penggunaan mungkin diterjemahkan ke dalam persyaratan nonfunctional untuk waktu respon terhadap perintah pengguna atau laporan permintaan.

Persyaratan antarmuka eksternal menentukan persyaratan untuk aliran informasi di seluruh antarmuka bersama untuk hardware, pengguna, dan aplikasi perangkat lunak lain di luar batas-batas dari produk perangkat lunak yang dikembangkan.

Kendala mendefinisikan pembatasan dikenakan pada pilihan bahwa pemasok dapat membuat ketika merancang dan mengembangkan perangkat lunak. Misalnya, mungkin ada persyaratan bahwa perangkat lunak selesai menggunakan tidak lebih dari 50 persen dari memori sistem yang tersedia atau ruang disk untuk memastikan kemampuan untuk perbaikan di masa datang.

Persyaratan data yang menentukan item data tertentu atau struktur data yang harus dimasukkan sebagai bagian dari produk software. Sebagai contoh, sistem penggajian akan memiliki persyaratan untuk saat ini dan tahun-to-date data penggajian.

Perangkat lunak ini dapat menjadi bagian dari sistem yang jauh lebih besar yang mencakup komponen lainnya Dalam hal ini, kebutuhan bisnis dan user-level makan ke dalam persyaratan produk pada tingkat sistem.. Arsitektur sistem kemudian mengalokasikan persyaratan dari set persyaratan sistem ke bawah ke perangkat lunak, perangkat keras, dan manual operasi komponen.

MENGAPA

Kutipan berikut dari Fredrick Brooks menggambarkan mengapa persyaratan begitu penting: "Bagian tersulit dari membangun sistem perangkat lunak adalah memutuskan dengan tepat apa yang harus membangun Tidak ada bagian lain dari pekerjaan konseptual sesulit membangun persyaratan teknis rinci, termasuk semua. interface untuk orang, untuk mesin, dan sistem perangkat lunak lain. Tidak ada bagian lain dari pekerjaan sehingga melumpuhkan sistem yang dihasilkan jika dilakukan salah. Tidak ada bagian lain yang lebih sulit untuk memperbaiki nanti "(Brooks 1995). Memunculkan, menganalisis, dan menulis yang baik persyaratan adalah bagian paling sulit dari rekayasa perangkat lunak Namun, mengutip Karl Wiegers (2004), "Jika Anda tidak mendapatkan persyaratan yang benar, tidak peduli seberapa baik Anda melakukan hal lain.". Satu bisa berakhir melakukan sempurna pekerjaan membangun
salah produk.

Ada banyak isu yang dapat memiliki dampak negatif pada proyek pengembangan perangkat lunak dan produk jika praktisi tidak melakukan pekerjaan yang baik untuk mendefinisikan perangkat lunak mereka persyaratan Isu-isu termasuk.:

• lengkap persyaratan

• Kurangnya keterlibatan pengguna

• Persyaratan churn

• Wasted sumber

• Emas plating

• tidak akurat perkiraan

Jika persyaratan tidak lengkap, praktisi software akhirnya membangun sebuah produk perangkat lunak yang tidak memenuhi semua pelanggan dan kebutuhan pengguna. Seperti diilustrasikan dalam Gambar 2, Noritaki Kano mengembangkan model hubungan antara kepuasan pelanggan dan persyaratan mutu (Pyzdek 2000) Garis kualitas yang diharapkan mewakili. mereka


Gambar 2 Kano model untuk persyaratan mutu

Persyaratan
Tidak Bertemu

Menyenangkan Kualitas

Diharapkan Kualitas

Dasar Kualitas

Persyaratan
Bertemu

persyaratan kualitas yang pelanggan secara eksplisit menyatakan. Misalnya, mereka akan menyatakan preferensi mereka untuk membuat, model, pilihan, dan gas mileage saat berbelanja untuk sebuah mobil. Pelanggan akan puas (dan pergi membeli mobil di tempat lain) jika persyaratan eksplisit mereka tidak terpenuhi Kepuasan pelanggan meningkat sebagai lebih dari mereka. persyaratan eksplisit terpenuhi Ketika cukup persyaratan eksplisit mereka terpenuhi, pelanggan bergeser dari ketidakpuasan dengan produk untuk menjadi pelanggan yang puas.. Ada tingkat dasar persyaratan mutu bahwa pelanggan mengharapkan produk untuk memiliki. Ini adalah persyaratan yang diasumsikan oleh pelanggan dan biasanya tidak secara eksplisit dinyatakan. Misalnya, mereka mengharapkan mobil untuk memiliki empat ban, mesin bekerja, dan roda kemudi.
Tingkat persyaratan tidak memuaskan pelanggan Perhatikan bahwa garis dasar seluruh di wilayah ketidakpuasan.. Ketiadaan tingkat persyaratan mutu akan meningkatkan ketidakpuasan pelanggan. Kualitas Menyenangkan adalah tingkat persyaratan inovatif dan merupakan barang-barang yang tak terduga. Ini adalah item bahwa pelanggan bahkan tidak tahu yang mereka inginkan, tetapi mereka mencintai mereka ketika mereka melihat mereka Misalnya, ingat ketika cangkir pemegang dalam mobil pertama kali diperkenalkan?. Perhatikan bahwa kualitas keseluruhan bersemangat berada di kawasan puas. Harus diingat, namun , inovasi yang hari ini adalah harapan besok Persyaratan kualitas yang diharapkan adalah orang-orang praktisi dapat menimbulkan cukup mudah jika mereka berbicara dengan para pemangku kepentingan produk.. Namun, mudah untuk kehilangan kedua persyaratan kualitas dasar dan menarik jika mereka tidak melakukan pekerjaan yang menyeluruh dari rinci persyaratan elisitasi dan analisis. Selain itu, jika praktisi melewatkan kelompok stakeholder atau jika mereka tidak mendapatkan pengguna yang terlibat dalam proses persyaratan, mereka dapat berakhir dengan kesenjangan bahkan dalam persyaratan mereka diharapkan.

Persyaratan churn mengacu perubahan dalam persyaratan setelah mereka awalnya setuju dan baselined Beberapa perubahan ini merupakan bagian dari pemurnian pemahaman pengembang 'ketika mereka mengembangkan perangkat lunak.. Perubahan juga terjadi karena perubahan lingkungan atau kebutuhan pengguna dari waktu ke waktu yang terjadi sebagai bagian alami dari sebuah proyek dari setiap durasi yang signifikan. Jika persyaratan yang buruk didefinisikan, bagaimanapun, persyaratan churn terjadi karena hilang persyaratan yang seharusnya sudah termasuk dalam spesifikasi asli atau karena persyaratan yang ditulis dengan buruk atau ambigu. Ini adalah jenis
persyaratan churn bahwa praktek-praktek yang baik persyaratan rekayasa akan membantu menghindari.

Persyaratan kesalahan account untuk 70 persen menjadi 85 persen dari biaya pengerjaan ulang pada sebuah proyek software (Wiegers 2003). Jika seseorang menemukan cacat persyaratan selama fase persyaratan dan biaya satu unit untuk memperbaiki (misalnya, tiga jam rekayasa,

$ 500), biaya untuk memperbaiki yang cacat yang sama biasanya akan meningkat seperti yang ditemukan kemudian dan kemudian dalam siklus hidup. Bahkan, studi menunjukkan bahwa hal itu dapat biaya lebih dari 100 kali lebih untuk memperbaiki cacat persyaratan jika tidak ditemukan sampai setelah perangkat lunak dilepaskan ke lapangan.

Lain pemborosan sumber daya terjadi ketika plating emas ditambahkan ke perangkat lunak. Plating emas dapat terjadi ketika seorang pengembang menambahkan fungsionalitas untuk perangkat lunak yang tidak dalam spesifikasi persyaratan, namun mereka percaya bahwa "pengguna hanya akan mencintai" tanpa menempatkan fungsi bahwa melalui rekayasa persyaratan proses. Pengguna mungkin atau mungkin tidak ingin fungsi baru Jika tidak, biaya pengembangan itu adalah pemborosan. Cycling ini "ide yang baik" melalui proses rekayasa persyaratan membantu memastikan bahwa mereka benar-benar adalah sesuatu yang dibutuhkan. dalam produk sehingga penyepuhan emas tidak terjadi. Sebuah jenis kedua penyepuhan emas berasal dari pengguna Misalnya,. jika praktisi meminta pengguna "apa yang mereka inginkan", bukan "apa yang mereka butuhkan untuk dapat dilakukan dengan sistem, "mereka mungkin berakhir dengan daftar keinginan baik untuk kaya atau hal-hal yang mereka mungkin ingin suatu saat nanti, tapi tidak benar-benar membutuhkan sekarang. Ini adalah alasan yang baik untuk
memprioritaskan persyaratan dan memfokuskan sumber daya pada persyaratan yang paling penting pertama plating emas dapat mengakibatkan pemborosan sumber daya pada pelaksanaan fungsi yang bukan dari nilai nyata atau yang tidak pernah benar-benar digunakan.. Hal ini juga menciptakan risiko yang cacat di bagian fungsi tersebut akan menyebabkan masalah reliabilitas untuk sisa perangkat lunak.

Persyaratan mendefinisikan ruang lingkup produk yang sedang dikembangkan. Tanpa gambaran yang jelas tentang ruang lingkup itu, perkiraan jadwal proyek, biaya, dan kualitas akan menjadi kurang akurat.

SIAPA

Stakeholder adalah individu yang mempengaruhi atau dipengaruhi oleh produk software dan karena itu memiliki beberapa tingkat pengaruh terhadap persyaratan untuk produk software. Proses rekayasa persyaratan memberikan kesempatan terbaik untuk mempertimbangkan semua kepentingan berbagai stakeholder dalam konteks dengan satu sama lain. Ada tiga utama
kategori stakeholder: para acquirers dari produk software, pemasok dari produk software, dan pemangku kepentingan lainnya.

Stakeholder pengakuisisi jenis dapat dibagi menjadi dua kelompok besar. Pertama ada pelanggan yang meminta, pembelian, dan / atau membayar untuk produk software dalam rangka memenuhi tujuan bisnis mereka Kelompok kedua adalah pengguna,. Juga disebut end-user , yang benar-benar menggunakan produk secara langsung atau menggunakan produk secara tidak langsung oleh laporan penerimaan, output, atau informasi lain yang dihasilkan oleh produk.

Para pemasok produk perangkat lunak termasuk individu dan tim yang merupakan bagian dari organisasi yang mengembangkan produk perangkat lunak atau merupakan bagian dari organisasi yang mendistribusikan produk perangkat lunak atau terlibat dalam metode pengiriman produk lainnya (misalnya, outsourcing). Analis persyaratan , juga disebut analis bisnis atau analis sistem, bertanggung jawab untuk memunculkan kebutuhan dari pelanggan, pengguna, dan stakeholder lainnya, menganalisis persyaratan, menulis spesifikasi persyaratan, dan mengkomunikasikan persyaratan untuk pembangunan dan pemangku kepentingan lainnya. Para desainer bertanggung jawab untuk menerjemahkan persyaratan ke dalam desain arsitektur perangkat lunak dan rinci yang menentukan bagaimana perangkat lunak akan

diimplementasikan. Para pengembang bertanggung jawab untuk melaksanakan desain dengan menciptakan produk perangkat lunak Jika perangkat lunak merupakan bagian dari sistem yang lebih besar, hardware desainer dan pengembang juga mungkin tertarik dalam persyaratan perangkat lunak.. Para penguji menggunakan persyaratan sebagai dasar untuk menciptakan tes kasus yang mereka gunakan untuk menjalankan perangkat lunak di bawah spesifik, kondisi yang dikenal untuk mendeteksi cacat dan memberikan keyakinan bahwa perangkat lunak melakukan sebagaimana ditentukan. Para penulis dokumentasi bertanggung jawab untuk menggunakan persyaratan sebagai masukan ke dalam penciptaan dokumentasi pengguna, termasuk pengguna / operasi manual, file bantuan, petunjuk instalasi, dan materi pelatihan yang diperlukan Manajer proyek bertanggung jawab untuk perencanaan, monitoring, dan pengendalian proyek dan membimbing tim pengembangan perangkat lunak untuk keberhasilan pengiriman perangkat lunak.. dukungan teknis, operasi juga disebut atau help desk , bertanggung jawab untuk berinteraksi dengan komunitas pengguna untuk mendukung perangkat lunak setelah telah dikerahkan ke lapangan Produk perubahan manajemen, yang dapat mengambil bentuk panel kontrol perubahan (CCB), bertanggung jawab untuk meninjau perubahan yang diajukan atas.
persyaratan, menganalisis dampaknya, menyetujui / tidak menyetujui perubahan, dan memastikan bahwa perubahan disetujui diimplementasikan dan divalidasi.

. Mungkin juga ada pihak lain yang tertarik pada Contoh persyaratan stakeholder persyaratan lainnya meliputi:

• Hukum atau kontrak manajemen

• Manufaktur atau produk rilis manajemen

• Penjualan dan pemasaran

• atas manajemen

• Pemerintah atau instansi regulator

• Masyarakat luas

Mengidentifikasi dan mempertimbangkan kebutuhan semua pemangku kepentingan yang berbeda dapat membantu mencegah persyaratan produk perangkat lunak dari yang diabaikan. Sebagai contoh, jika sebuah perusahaan adalah menciptakan sistem penggajian dan tidak mempertimbangkan amal sebagai salah satu pemangku kepentingan, mungkin tidak mencakup persyaratan untuk perangkat lunak untuk:

• Biarkan penerima pembayaran untuk menentukan dari satu sampai tiga pemotongan amal

• Tunda pemotongan amal dari penerima pembayaran yang memeriksa setiap periode pembayaran

• Laporan saat ini dan tahun-to-date amal pemotongan pada slip gaji penerima pembayaran

• Mencetak cek untuk amal masing-masing untuk jumlah akumulasi dikurangi dari penerima pembayaran

Para analis persyaratan tidak akan pernah tahu banyak tentang pekerjaan stakeholder sebagai stakeholder itu. Dengan mengidentifikasi dan melibatkan stakeholder kunci, analis keuntungan akses ke basis pengalaman dan pengetahuan domain. Pekerjaan analis kemudian untuk menganalisis, memperluas, mensintesis, menyelesaikan konflik dalam, dan menggabungkan masukan dari semua stakeholder menjadi set yang diselenggarakan persyaratan pada tingkat yang sesuai abstraksi untuk audiens target.

Mengidentifikasi stakeholder dan membuat mereka terlibat dalam proses rekayasa persyaratan membawa perspektif yang berbeda ke meja yang dapat membantu dalam satu set yang lebih lengkap dari persyaratan di awal siklus hidup pengembangan perangkat lunak. Seperti Wiegers katakan, mendapatkan pemangku kepentingan yang terlibat menghilangkan kebutuhan untuk dua teknik elisitasi yang paling efektif persyaratan: clairvoyance dan telepati (Wiegers 2003).

Ingat, orang membenci perubahan dan produk software baru berarti mengubah cara para stakeholder akan melakukan sebagian atau seluruh pekerjaan mereka Mendapatkan masukan dari stakeholder dan partisipasi membuat mereka terlibat dalam solusi untuk kebutuhan mereka. Stakeholder Terlibat lebih mungkin untuk membeli ke dalam. menyelesaikan produk perangkat lunak, yang dapat menciptakan juara-juara untuk produk software dalam komunitas pemangku kepentingan. ini dapat bermanfaat dalam transisi produk perangkat lunak ke dalam lingkungan operasional.

Langkah pertama dalam mengidentifikasi stakeholder adalah untuk memastikan bahwa seseorang mempertimbangkan semua stakeholder potensial Daftar periksa berikut dapat membantu dalam mengidentifikasi stakeholder potensial.:

• Apa jenis orang akan menggunakan produk software?

• Apa kegiatan usaha yang didukung oleh produk perangkat lunak dan yang melakukan, yang terlibat dalam, atau mengelola kegiatan tersebut?

• siapa pekerjaan akan dipengaruhi oleh pengenalan produk software baru?

• Siapa yang akan menerima laporan, output, atau informasi lainnya dari produk software?

• Siapa yang akan membayar untuk produk software?

• Siapa yang akan memilih produk perangkat lunak atau pemasoknya?

• Jika produk software gagal, yang bisa berdampak?

• Siapa yang akan terlibat dalam pengembangan, mendukung, dan memelihara produk perangkat lunak?

• Siapa yang tahu tentang hardware, software lain, atau database yang antarmuka dengan produk software?

• Siapa yang mendirikan hukum, peraturan, atau standar yang mengatur kegiatan usaha yang didukung oleh produk software?

• Siapa yang harus dijaga dari menggunakan produk perangkat lunak atau dari menggunakan fungsi-fungsi tertentu / data dalam perangkat lunak?

• Siapa yang produk ini software untuk memecahkan masalah?

• Siapa yang produk ini menciptakan masalah bagi software?

• Siapa yang tidak ingin produk perangkat lunak untuk menjadi sukses?

Hal ini hampir tidak mungkin untuk pengembangan produk perangkat lunak untuk mempertimbangkan kebutuhan semua stakeholder Potensi kebutuhan stakeholder juga mungkin bertentangan satu sama lain.. Misalnya, perlu menjaga hacker tidak ramah dari

membobol konflik penggajian perangkat lunak dengan kebutuhan akuntan untuk akses cepat dan mudah ke perangkat lunak.

Langkah kedua dalam mengidentifikasi stakeholder adalah untuk praktisi untuk memutuskan bagaimana mereka akan berurusan dengan konflik Mereka melakukannya dengan menentukan stakeholder memiliki prioritas lebih tinggi berdasarkan kontribusi mereka terhadap keberhasilan produk perangkat lunak.. Ini memungkinkan praktisi untuk membuat sesuai trade-off ketika konflik terjadi. Gause dan Weinberg (1989) mendiskusikan apa yang mereka sebut strategi user-inklusi, yang penulis telah diperluas dengan strategi pemangku kepentingan-inklusi. Dalam strategi ini, praktisi software dapat melihat daftar stakeholder potensial dan menentukan apakah:

• Mereka ingin bersikap ramah kepada stakeholder ini dan mempertimbangkan bagaimana untuk mengakomodasi kebutuhan mereka dalam produk perangkat lunak (misalnya, membuat akses cepat dan mudah ke perangkat lunak untuk akuntan)

• Mereka mampu untuk mengabaikan kebutuhan mereka karena mereka tidak kunci keberhasilan produk perangkat lunak (misalnya, memutuskan bahwa kebutuhan khusus dari sebuah badan amal yang dikenal sedikit tidak cukup penting untuk dipertimbangkan ketika mendefinisikan persyaratan)

• Mereka ingin menjadi ramah dan mempertimbangkan bagaimana untuk mengatasi kebutuhan mereka dalam produk perangkat lunak (misalnya, mencegah hacker menyusup ke dalam perangkat lunak)

Langkah ketiga adalah untuk memutuskan siapa yang akan mewakili masing-masing kelompok stakeholder bahwa seseorang telah ditunjuk sebagai ramah atau tidak ramah Ada tiga pilihan utama.:

• Perwakilan. Pilih juara pemangku kepentingan untuk mewakili kelompok pemangku kepentingan Misalnya, jika ada beberapa penguji yang akan menguji produk, tester memimpin mungkin dipilih untuk mewakili kelompok pemangku kepentingan.. Tester memimpin kemudian akan berpartisipasi dalam persyaratan kegiatan rekayasa dan bertanggung jawab untuk mengumpulkan masukan dari penguji lain dan mengelola komunikasi dengan mereka.

• Contoh. Untuk kelompok stakeholder besar atau untuk kelompok mana akses langsung terbatas untuk beberapa alasan, sampling mungkin cocok. Dalam hal ini, itu akan diperlukan untuk menyusun rencana sampling untuk mendapatkan masukan dari serangkaian perwakilan dari para pemangku kepentingan dalam kelompok tertentu Sebagai contoh,. jika perusahaan memiliki beberapa ribu karyawan, mungkin memutuskan untuk mengambil set sampel karyawan untuk mewawancarai tentang kebutuhan mereka untuk sistem akuntansi baru.

• Exhaustive. Jika kelompok stakeholder kecil atau jika itu cukup penting untuk keberhasilan sistem, mungkin perlu untuk memperoleh masukan dari setiap anggota kelompok pemangku kepentingan. Misalnya, jika produk perangkat lunak hanya memiliki satu pelanggan atau sekelompok kecil pelanggan itu mungkin penting untuk memperoleh masukan dari masing-masing pelanggan.

Software praktisi harus menentukan kapan kelompok stakeholder perlu untuk berpartisipasi dalam kegiatan rekayasa persyaratan. Apakah mereka akan berpartisipasi seluruh proses atau hanya pada waktu tertentu? Sebagai contoh, praktisi mungkin ingin juara pemangku kepentingan untuk akuntan untuk menjadi anggota persyaratan tim dan

untuk berpartisipasi selama proses rekayasa persyaratan Mereka mungkin tidak membutuhkan pemangku kepentingan perwakilan sumber daya manusia untuk berpartisipasi di tim persyaratan,. tapi mungkin perlu mereka secara, terus menerus on-call dalam kasus ada pertanyaan. Namun, praktisi mungkin hanya perlu sampel karyawan selama kegiatan elisitasi persyaratan.

. Praktisi Software juga harus menentukan bagaimana mereka akan memiliki masing-masing kelompok stakeholder berpartisipasi Apakah mereka akan mengirim mereka kuesioner, melakukan satu-satu wawancara, mereka telah berpartisipasi dalam kelompok fokus atau dalam sebuah lokakarya yang difasilitasi persyaratan elisitasi, atau menunjukkan kepada mereka prototipe, mock-up, atau simulasi, dan mengumpulkan masukan mereka?

Keputusan akhir untuk menetapkan prioritas dari anggota tim stakeholder yang didasarkan pada kepentingan relatif mereka untuk keberhasilan produk perangkat lunak. Prioritas didirikan membantu seseorang menentukan yang suaranya untuk mendengarkan ketika konflik muncul antara kebutuhan berbagai pemangku kepentingan atau kelompok pemangku kepentingan.

KAPAN

Kebutuhan pengembangan meliputi semua kegiatan yang terlibat dalam mengidentifikasi, menangkap, dan menyepakati persyaratan ini meliputi definisi dan integrasi dari kebutuhan bisnis, kebutuhan pengguna, dan produk perangkat lunak tingkat persyaratan.. Mayoritas kegiatan pembangunan persyaratan terjadi selama Konsep awal dan fase persyaratan siklus hidup. Lanjutan elaborasi persyaratan, bagaimanapun, bisa beranjak ke tahap akhir dari siklus hidup pengembangan perangkat lunak.

Persyaratan manajemen meliputi semua kegiatan yang terlibat dalam meminta perubahan pada persyaratan baselined, melakukan analisa dampak bagi perubahan yang diminta, memberikan persetujuan atau penolakan perubahan tersebut, dan menerapkan perubahan yang disetujui. Persyaratan manajemen juga mencakup kegiatan yang digunakan untuk memastikan bahwa semua produk kerja dan rencana proyek disimpan konsisten dan pelacakan status persyaratan sebagai salah satu berlangsung melalui proses pengembangan perangkat lunak. Persyaratan manajemen merupakan kegiatan yang sedang berlangsung di seluruh siklus hidup pengembangan perangkat lunak.

Produk perangkat lunak yang diimplementasikan adalah divalidasi terhadap persyaratan selama fase pengujian siklus hidup untuk mengidentifikasi dan memperbaiki cacat dan untuk memberikan keyakinan bahwa produk tersebut memenuhi kebutuhan tersebut.

Persyaratan teknik adalah proses berulang-ulang Praktisi harus terlebih dahulu mengembangkan kebutuhan bisnis dan dasar mereka.. Persyaratan bisnis masukan ke dalam pengembangan user-level persyaratan. Berdasarkan upaya tersebut, praktisi dapat menemukan kesenjangan dalam kebutuhan bisnis mereka yang mengakibatkan mereka perbaikan lebih lanjut. Mereka kemudian dapat menggunakan informasi yang mereka peroleh dari menyempurnakan kebutuhan bisnis untuk update lebih lanjut dari pengguna-persyaratan tingkat Bisnis dan user-level persyaratan makan ke dalam definisi produk-tingkat kebutuhan.. Hal ini dapat menyebabkan perbaikan lebih lanjut dari
bisnis dan user-level persyaratan. Persyaratan produk yang kemudian masukan ke dalam desain perangkat lunak dan proses pembangunan, yang dapat mengungkap persyaratan implisit atau kebutuhan untuk perbaikan lebih lanjut dari bisnis, pengguna, dan produk-tingkat kebutuhan.


BAGAIMANA

. Software persyaratan rekayasa adalah, disiplin proses yang berorientasi pendekatan definisi, dokumentasi, dan pemeliharaan persyaratan perangkat lunak di seluruh siklus hidup pengembangan perangkat lunak Seperti diilustrasikan dalam Gambar 3, software persyaratan rekayasa terdiri dari dua proses utama: pengembangan dan persyaratan Persyaratan manajemen pembangunan. meliputi semua kegiatan yang terlibat dalam memunculkan, menganalisis, menentukan, dan memvalidasi persyaratan.


Gambar 3 Persyaratan Rekayasa Proses (berdasarkan Wiegers 2003)

Rekayasa Kebutuhan

Persyaratan Pembangunan

Persyaratan
Pendatangan

Persyaratan
Analisa

Persyaratan
Spesifikasi

Persyaratan
Pengesahan

Persyaratan Manajemen

Membangun & memelihara perjanjian dengan pelanggan & pengguna pada persyaratan

Mengontrol persyaratan baselined

Proses yang diusulkan perubahan persyaratan

Jauhkan persyaratan yang konsisten dengan rencana & produk kerja

Negosiasikan komitmen baru berdasarkan dampak perubahan disetujui

Saat Persyaratan

Baselined Persyaratan

Revisi Persyaratan

Langkah elisitasi persyaratan meliputi semua kegiatan yang terlibat dalam mengidentifikasi stakeholder persyaratan itu, memilih perwakilan dari setiap kelas pemangku kepentingan, dan menentukan kebutuhan dari masing-masing kelas stakeholder Proses elisitasi adalah langkah pengumpulan informasi dalam proses pengembangan persyaratan.. Banyak yang berbeda . teknik dapat digunakan untuk memperoleh persyaratan, termasuk wawancara dengan stakeholder, kelompok fokus, memfasilitasi lokakarya persyaratan, pengamatan proses kerja saat ini, kuesioner dan survei, analisis produk pesaing, dan benchmarking industri Persyaratan elisitasi praktek juga dapat melibatkan studi dokumentasi:

• Standar industri, hukum, dan / atau peraturan

• Produk literatur (milik sendiri atau kompetisi)

• Proses dokumentasi dan instruksi kerja

• Perubahan permintaan, masalah, atau help-desk laporan

• Pelajaran dari proyek-proyek sebelumnya atau produk

• Laporan dan kiriman lainnya dari sistem yang ada

Selama langkah analisis kebutuhan kebutuhan stakeholder, asumsi, dan informasi lain yang diidentifikasi selama elisitasi persyaratan yang menyatu bersama-sama dan disempurnakan

ke tingkat lebih lanjut detail. Langkah ini termasuk mewakili persyaratan dalam berbagai bentuk, termasuk prototipe dan model, melakukan trade-off analisis, menetapkan prioritas, menganalisis kelayakan, dan mencari celah yang mengidentifikasi persyaratan yang hilang. Informasi yang diperoleh dalam langkah analisis mungkin memerlukan iterasi dengan langkah elisitasi sebagai klarifikasi diperlukan, konflik antara kebutuhan dieksplorasi, atau persyaratan yang hilang diidentifikasi.

Persyaratan secara formal didokumentasikan selama tahap spesifikasi sehingga mereka dapat dikomunikasikan kepada para pemangku kepentingan Produk spesifikasi persyaratan dapat mengambil salah satu dari banyak bentuk.. Sebagai contoh, pada proyek-proyek kecil informasi persyaratan dapat didokumentasikan dalam Spesifikasi Persyaratan Software tunggal (SRS) Dokumen .. Pada proyek yang lebih besar, persyaratan dapat ditentukan dalam beberapa dokumen Sebagai contoh:

• Bisnis persyaratan dapat didokumentasikan dalam dokumen kebutuhan bisnis (BRD), pemasaran dokumen persyaratan (MRD), atau visi proyek dan dokumen ruang lingkup.

• Persyaratan Pengguna dapat didokumentasikan dalam serangkaian kasus digunakan dalam alat atau spesifikasi kebutuhan pengguna (URS) dokumen.

• Jika perangkat lunak merupakan bagian dari sistem yang lebih besar, produk-tingkat persyaratan dapat didokumentasikan dalam spesifikasi sistem persyaratan dan spesifikasi arsitektur sistem dapat mendokumentasikan alokasi persyaratan untuk perangkat lunak, perangkat keras, dan manual operasi komponen sistem itu.

• Perangkat lunak persyaratan fungsional dan nonfunctional dan kendala dapat didokumentasikan dalam sebuah SRS.

• antarmuka eksternal dapat dimasukkan dalam SRS atau terpisah dokumen persyaratan antarmuka eksternal.

Salah satu praktik yang baik untuk spesifikasi persyaratan adalah memiliki template standar persyaratan spesifikasi Template ini memungkinkan analis persyaratan untuk fokus pada konten, bukan format dan dapat membantu memastikan bahwa item kunci tidak diabaikan sebagai persyaratan sedang didokumentasikan.. Sebagai contoh, jika asumsi yang tidak didokumentasikan, mereka dapat menyebabkan kesalahpahaman di masa mendatang atau masalah lain Lain praktek yang baik adalah dengan menggunakan alat persyaratan (atau database).. Sebuah alat persyaratan dapat menjadi aset utama di kedua persyaratan manajemen dan manajemen proyek.

Langkah terakhir dalam proses pembangunan persyaratan adalah untuk memvalidasi persyaratan untuk memastikan bahwa mereka ditulis dengan baik, lengkap, dan akan memenuhi kebutuhan pelanggan Validasi dapat menyebabkan seseorang untuk iterate langkah lain dalam proses pengembangan persyaratan karena diidentifikasi, kesenjangan cacat. , tambahan informasi atau analisis kebutuhan, klarifikasi diperlukan, atau masalah lainnya.

Salah satu alat utama untuk validasi persyaratan adalah melakukan peer review formal dari dokumen spesifikasi persyaratan sebelum mereka baselined Bukti empiris dari berbagai perusahaan menunjukkan bahwa rekan meninjau persyaratan dokumentasi memiliki keuntungan tertinggi pada investasi dari setiap kegiatan deteksi cacat.. The Proses peer review harus melihat pada spesifikasi kebutuhan secara keseluruhan untuk memastikan bahwa itu adalah:

• Lengkap. Dokumen persyaratan meliputi semua informasi persyaratan yang diperlukan. Misalnya, SRS mencakup semua fungsi dan persyaratan nonfunctional, kendala, persyaratan antarmuka eksternal, dan persyaratan data yang harus dipenuhi.

• Konsisten. Konflik internal tidak ada antara persyaratan dalam dokumen yang dihasilkan dalam persyaratan bertentangan satu sama lain. Persyaratan juga tidak bertentangan dengan tingkat yang lebih tinggi persyaratan termasuk bisnis, pengguna, atau sistem-tingkat kebutuhan. Terminologi juga harus digunakan secara konsisten dalam dokumen:

o Sebuah kata memiliki makna yang sama setiap kali digunakan.
o Dua kata yang berbeda tidak digunakan untuk arti yang sama.

• Dimodifikasi Dokumen persyaratan yang diatur dan ditulis dengan cara yang akan memudahkan membuat perubahan di masa depan.:

o nonredundan: Setiap persyaratan dinyatakan dalam satu tempat.

o diganti: Setiap persyaratan dapat diubah tanpa dampak berlebihan pada kebutuhan lainnya.

Proses peer review juga harus melihat setiap kebutuhan individu untuk memastikan bahwa itu adalah:

• Cukup jelas. Setiap pernyataan persyaratan harus memiliki hanya satu penafsiran, dan kebutuhan masing-masing harus ditentukan dalam, koheren mudah dipahami. Misalnya, penelusuran penulis untuk kata-kata yang berakhir dengan "ly" (misalnya, cepat, pengguna -anak, otomatis) karena kata keterangan oleh alam hampir
selalu ambigu.

• Ringkas persyaratan Setiap harus dinyatakan dalam bahasa singkat, spesifik, berorientasi pada tindakan..

• Hingga Persyaratan tidak harus dinyatakan secara terbuka.. Sebagai contoh, kata-kata seperti "semua," "setiap" dan "seluruh" harus dihindari dalam pernyataan persyaratan.

• Measurable. Spesifik, batas terukur atau nilai-nilai harus dinyatakan untuk kebutuhan masing-masing yang sesuai.

• Kelayakan Persyaratan dapat diimplementasikan dengan menggunakan teknologi yang tersedia, teknik, alat, sumber daya, dan personel dalam biaya tertentu dan kendala jadwal..

• Diuji Ada ada cara yang cukup efektif untuk menentukan bahwa perangkat lunak memenuhi persyaratan..

• ditelusuri. Persyaratan Setiap harus dilacak kembali ke sumbernya (misalnya, user-level persyaratan, sistem-tingkat persyaratan, standar, permintaan tambahan). Hal ini juga harus ditentukan dengan cara yang memungkinkan ketertelusuran maju ke pelaksanaan, desain, dan tes.

Alat lain yang utama untuk memvalidasi persyaratan adalah untuk mulai menulis kasus uji untuk pengujian fungsional (black box) dari perangkat lunak. Karena pengujian fungsional hanya membutuhkan pengetahuan tentang persyaratan dan bukan dari internal dari produk software, praktisi dapat mulai menulis kasus uji terhadap kebutuhan mereka segera setelah mereka mulai menulis mereka. Keuntungan utama untuk menulis kasus uji fungsional di awal siklus hidup adalah bahwa hal itu akan mengungkap cacat dalam persyaratan uji kasus Menulis awal mungkin.
menghasilkan ulang beberapa jika perubahan persyaratan, tetapi biaya pengerjaan ulang yang akan lebih dari diimbangi dengan penghematan yang dihasilkan dari menemukan dan memperbaiki cacat lebih persyaratan sebelumnya.

Persyaratan pembangunan merupakan proses berulang-ulang Satu seharusnya tidak mengharapkan untuk pergi melalui langkah-langkah dalam mode satu-shot, linear.. Sebagai contoh, analis persyaratan dapat berbicara dengan pengguna, kemudian menganalisis apa yang user katakan. Mereka mungkin kembali kepada pengguna untuk klarifikasi dan kemudian mendokumentasikan apa yang mereka pahami sebagai bagian dari persyaratan Mereka kemudian dapat pergi untuk berbicara dengan pengguna lain, atau mengadakan lokakarya persyaratan bersama dengan perwakilan beberapa user.. analisis mereka kemudian mungkin termasuk membangun prototipe yang mereka menunjukkan kepada kelompok fokus Berdasarkan informasi yang analis mendokumentasikan persyaratan tambahan dan memegang persyaratan berjalan-melalui untuk memvalidasi bahwa seperangkat persyaratan. Analis kemudian pindah ke eliciting persyaratan untuk fitur berikutnya dan seterusnya..

Setelah satu atau lebih iterasi melalui proses persyaratan pengembangan perangkat lunak, sebagian atau seluruh persyaratan yang dianggap "cukup baik" untuk awal dan menjadi dasar
Untuk desain dan pengembangan perangkat lunak yang baik Sebuah mengatakan untuk mengingat pada saat ini adalah, Persyaratan tidak akan pernah menjadi sempurna "Ketika lebih baik musuh cukup baik?" -.. Satu selalu dapat melakukan perbaikan lebih lanjut dan mengumpulkan masukan lebih baselining Persyaratan adalah keputusan bisnis yang harus didasarkan pada penilaian risiko.

Persyaratan manajemen dimulai dengan mendapatkan pemangku kepentingan buy-in dengan persyaratan baselined Persyaratan manajemen mencakup kegiatan yang terlibat dalam meminta perubahan pada persyaratan baselined, melakukan analisa dampak bagi perubahan yang diminta, memberikan persetujuan atau penolakan perubahan tersebut, dan menerapkan perubahan yang disetujui.. Persyaratan manajemen juga mencakup kegiatan yang digunakan untuk memastikan bahwa kerja produk dan rencana proyek yang tetap konsisten dan pelacakan status persyaratan sebagai salah satu kemajuan melalui proses pengembangan perangkat lunak.

KESIMPULAN

Praktisi harus memahami berbagai jenis dan tingkat kebutuhan untuk melakukan pekerjaan yang baik dari rekayasa persyaratan. Hal ini membutuhkan pemahaman tentang manfaat memiliki persyaratan yang baik sehingga sumber daya yang memadai dan waktu yang didedikasikan untuk proses rekayasa persyaratan di seluruh siklus hidup pengembangan perangkat lunak. Melakukan rekayasa persyaratan dengan benar memerlukan pendekatan interdisipliner yang mempertimbangkan kebutuhan kelompok stakeholder beberapa. Ini juga membutuhkan keahlian dalam berbagai keterampilan teknik elisitasi persyaratan, termasuk persyaratan, analisis persyaratan, spesifikasi kebutuhan, validasi persyaratan, dan persyaratan manajemen.

REFERENSI
Brooks, F. 1.995 Mythical man-bulan: ..... Esai tentang rekayasa perangkat lunak, ulang tahun ke 20 edisi Addison-Wesley Professional Gause, D., dan G. Weinberg 1.989 persyaratan Menjelajahi, kualitas sebelum desain New York:. Dorset Publishing House .

Pyzdek, T. 2000 Quality engineering handbook New York: Marcel Dekker ...
.. Wiegers, KE 2.003 persyaratan Software, 2nd Edition Redmond, Wash:. Microsoft
Tekan.

Wiegers, KE 2004 Dalam mencari persyaratan yang sangat baik.. Proses Dampak situs Web. Lihat
URL: http://www.processimpact.com.

BIOGRAFI

Linda Westfall adalah Presiden dari Tim Westfall, yang menyediakan pelatihan dan jasa konsultasi dalam Rekayasa Perangkat Lunak, Kualitas Perangkat Lunak dan Manajemen Proyek Perangkat Lunak. Sebelum memulai bisnis sendiri, Linda adalah Manager Senior dari Metrik Kualitas dan Analisis di DSC Komunikasi di mana dia Tim merancang dan menerapkan program luas perusahaan metrik. Linda memiliki lebih dari dua puluh lima tahun
pengalaman dalam perangkat lunak waktu rekayasa kualitas nyata, dan metrik. Dia telah bekerja sebagai Software Engineer, Analis Sistem, Software Engineer Proses dan Manajer Produksi Software.

Sangat aktif profesional, Linda adalah kursi masa lalu dari American Society for Quality (ASQ) Divisi Software Dia juga menjabat sebagai Ketua Program Divisi Software dan Ketua Sertifikasi dan di Dewan Nasional ASQ Sertifikasi.. Linda adalah kursi masa lalu-dari Asosiasi untuk Excellence Rekayasa Perangkat Lunak (ASEE). Linda adalah Insinyur Profesional dalam Rekayasa Perangkat Lunak dari negara bagian Texas dan merupakan Software Engineer Kualitas ASQ Bersertifikat (CSQE) dan Auditor Mutu Bersertifikat (CQA).

Anda dapat menghubungi Linda dengan mengirim email ke lwestfall@westfallteam.com atau kunjungi situs web nya di www.westfallteam.com.

Translated by: Google Translate

Maaf ini di-translate tanpa di-edit, hehe
Untuk versi aslinya (pdf) dapat di-download di sini
Sedangkan versi translate (pdf & docx) dapat di-download di sini (pdf) dan di sini (docx)

0 komentar:

Poskan Komentar

 
Copyright 2011 [aerosurudoi]