Solusi Penglihatan


Bantuan
Daftar
Login
Mulai Uji Coba Gratis

Bagaimana Mengukur Persyaratan Kualitas

Persyaratan harus memiliki kualitas jika proyek ingin berhasil. Dengan menetapkan standar dan ketentuan, tim dapat mengevaluasi kemajuan mereka dalam mencapai tujuan tersebut. Metrik yang digunakan akan berbeda tergantung pada pekerjaan yang dilakukan; namun, beberapa indikator umum untuk persyaratan pelacakan meliputi:

  • Cakupan Pengujian – Berapa banyak dari setiap fungsi sistem yang telah diuji?
  • Akurasi Penilaian – Apakah ada tingkat kebenaran yang tinggi dalam spesifikasi?
  • Kelengkapan Fungsi – Apakah semua area fungsionalitas ditentukan dengan cukup detail?
  • Kejelasan Kriteria Penerimaan – Bisakah kriteria penerimaan pengguna dengan mudah diidentifikasi dari dokumentasi?
  • Perubahan permintaan - Berapa jumlah permintaan perubahan yang telah diajukan sejak spesifikasi ditulis?

Dengan mengukur faktor-faktor kualitatif ini secara teratur, Anda akan dapat mengidentifikasi di mana tim Anda perlu memfokuskan upaya mereka dan meningkatkan kualitas proyek Anda.

Bagaimana Mengukur Persyaratan Kualitas

Daftar Isi

Mengapa Penting untuk Menilai Kualitas Persyaratan?

  • Pertama-tama kita harus menentukan apakah kita memiliki masalah persyaratan dan seberapa besar masalah itu agar dapat secara akurat menghitung jumlah upaya yang diperlukan untuk mengubah sumber daya kita yang tidak mencukupi menjadi sumber daya yang memuaskan.
  • Sebagai supervisor, kami berusaha untuk memastikan bahwa tim kami bekerja secara produktif saat membuat spesifikasi kebutuhan atau melakukan analisis kebutuhan. Apakah mereka memenuhi tujuan mereka?
  • Mempertimbangkan berbagai skenario, kami menetapkan tolok ukur untuk spesifikasi persyaratan kami dalam hal nilai metrik kualitas kriteria. Kami menetapkan empat nilai untuk mencerminkan masing-masing situasi:
    • Membuat novel orisinal di lingkungan yang sulit bukanlah hal yang mudah.
    • Membuat narasi inovatif tanpa tekanan atau batasan apa pun.
    • Pembangunan duniawi
    • Akuisisi barang-barang non-perkembangan
  • Untuk memastikan kualitas tertinggi untuk proyek kami, kami menetapkan tolok ukur untuk entri Tinjauan Persyaratan Sistem dan Tinjauan Persyaratan Perangkat Lunak.

Dalam hal metrik teknik, metrik kualitas persyaratan adalah salah satu alat paling ampuh yang tersedia. Lagi pula, secara historis, mengembangkan sesuatu yang berbeda dari yang awalnya dimaksudkan telah menjadi masalah umum bagi para insinyur. Meskipun menggunakan standar yang objektif tidak akan menjamin hasil yang sempurna setiap saat, namun secara drastis dapat mengurangi potensi risiko dan kekurangan pada produk akhir.

Ukuran Produk

Memahami jumlah persyaratan dalam suatu proyek sangat penting. Ini dapat dicapai melalui kasus penggunaan, persyaratan fungsional, cerita pengguna, deskripsi fitur, tabel respons peristiwa, atau model analisis. Namun, pilihan tim Anda untuk mewakili persyaratan ini sama sekali tidak memengaruhi fungsi utama mereka – menerapkan perilaku sistem berdasarkan kondisi khusus dan kebutuhan fungsional.

Mulailah proses penilaian persyaratan Anda dengan menghitung persyaratan fungsional individual yang dialokasikan untuk rilis produk atau iterasi pengembangan. Jika individu yang berbeda tidak dapat memperoleh hasil yang sama saat menghitung, penting untuk mempertimbangkan jenis kesalahpahaman dan ambiguitas lain yang dapat muncul di masa mendatang. Anda perlu mengetahui sejumlah persyaratan yang membentuk rilis untuk melacak kemajuan tim Anda secara akurat. Tanpa pengetahuan ini, Anda tidak akan memiliki cara untuk mengukur kapan Anda selesai dengan proyek tersebut! Mengawasi berapa banyak pekerjaan yang tersisa di backlog Anda memastikan bahwa setiap orang memahami apa yang perlu dilakukan sebelum selesai.

Untuk memastikan bahwa persyaratan fungsional Anda adalah ukuran ukuran sistem yang akurat, penting bagi analis untuk membuatnya pada tingkat detail yang konsisten. Cara terbaik untuk melakukannya adalah dengan memecah persyaratan tingkat tinggi menjadi komponen turunan yang lebih kecil yang dapat diuji secara individual. Dengan kata lain, penguji harus merancang pengujian sederhana yang akan menentukan apakah setiap persyaratan telah diterapkan dengan benar atau tidak. Ini memastikan semua tugas memerlukan jumlah implementasi dan upaya pengujian yang sama terlepas dari kerumitannya. Untuk memastikan bahwa pengembang dan penguji dapat mengimplementasikan dan menguji setiap persyaratan dengan benar, penting untuk melacak berapa banyak persyaratan anak yang ada. Metode penentuan ukuran alternatif lainnya mencakup poin kasus penggunaan dan poin cerita, yang semuanya mengukur perkiraan upaya yang diperlukan untuk potongan fungsionalitas yang ditentukan secara khusus.

Meskipun persyaratan fungsional sangat penting, persyaratan nonfungsional juga tidak dapat diabaikan. Tuntutan khusus ini membutuhkan peningkatan jumlah upaya untuk merancang dan menerapkan secara efektif. Fungsionalitas tertentu bergantung pada kebutuhan nonfungsional yang tercantum seperti masalah keamanan, yang harus direpresentasikan dalam perkiraan ukuran untuk fitur fungsional. Namun, semua keinginan nonfungsional tidak akan muncul di sini—memastikan untuk mempertimbangkan pengaruhnya pada perkiraan Anda sangatlah penting! Pertimbangkan situasi berikut:

  • Menyediakan beberapa jalur untuk menggunakan fitur tertentu meningkatkan pengalaman pengguna; namun, upaya semacam itu membutuhkan lebih banyak waktu dan energi dari pengembang daripada jika hanya tersedia satu metode akses.
  • Bahkan jika Anda tidak mengimplementasikan fitur produk baru, batasan desain dan implementasi yang dipaksakan seperti antarmuka eksternal untuk mengakomodasi lingkungan operasi yang ada dapat secara signifikan meningkatkan jumlah pekerjaan antarmuka yang diperlukan.
  • Untuk memastikan performa maksimal, algoritma yang cermat dan pekerjaan desain database mungkin diperlukan untuk menjamin respons yang cepat.
  • Untuk memenuhi persyaratan ketersediaan dan keandalan yang ketat, perlu dibangun mekanisme failover dan pemulihan data yang dapat memakan waktu. Selain itu, arsitektur sistem yang Anda pilih juga dapat dipengaruhi oleh permintaan ini.

Dengan melacak peningkatan persyaratan dari waktu ke waktu, terlepas dari metrik ukuran yang digunakan, Anda akan mendapatkan wawasan yang bermanfaat. Klien saya memperhatikan bahwa proyek mereka biasanya meningkat sekitar dua puluh lima persen sebelum pengiriman. Selain itu, sebagian besar proyek mereka berjalan setidaknya dua puluh lima persen lebih lama dari yang diharapkan! Bukan kebetulan di sini — jelas ada hubungan antara kedua tren ini.

Persyaratan Kualitas

Luangkan waktu untuk mengukur kualitas kebutuhan Anda dengan melakukan inspeksi terhadapnya. Dokumentasikan cacat apa pun yang Anda temukan dan pisahkan ke dalam kategori yang berbeda, seperti persyaratan yang hilang, yang salah, yang tidak dibutuhkan, ketidakjelasan, dll. Setelah itu, analisis jenis cacat ini beserta akar penyebabnya sehingga permintaan di masa mendatang dapat dilakukan dengan benar dari awal hingga akhir. Gunakan data ini sebagai peluang perbaikan untuk meningkatkan efisiensi proses kebutuhan Anda! Misalnya, jika Anda menentukan bahwa persyaratan yang hilang biasanya merupakan masalah yang berulang, maka metode elisitasi Anda perlu diubah. Ada kemungkinan bahwa analis bisnis Anda tidak cukup bertanya atau pertanyaan yang benar, atau mungkin Anda harus melibatkan lebih banyak lagi perwakilan pengguna yang sesuai dalam proses mengembangkan kebutuhan.

Jika tim merasa terdesak waktu saat memeriksa semua dokumentasi persyaratan mereka, opsi yang lebih efisien adalah memeriksa beberapa halaman lalu menghitung kerapatan cacat rata-rata—jumlah cacat per halaman spesifikasi. Dengan asumsi bahwa sampel ini mencerminkan keseluruhan dokumen secara akurat (yang mungkin merupakan asumsi yang tepat), mengalikannya dengan halaman yang tidak diperiksa dapat memberi kami perkiraan berapa banyak bug tersembunyi yang tersisa dalam spesifikasi kami. Pemeriksa yang tidak berpengalaman mungkin tidak dapat mendeteksi semua cacat, jadi gunakan perkiraan jumlah cacat yang tidak terlihat sebagai perkiraan minimal. Dengan menggunakan sampel inspeksi, Anda dapat menilai kualitas dokumen dan memutuskan apakah layak secara finansial untuk memeriksa spesifikasi persyaratan lainnya – yang tidak diragukan lagi ya!

Selain itu, cacat persyaratan catatan ditemukan setelah baseline ditetapkan. Isu-isu ini akan luput dari perhatian selama kontrol kualitas saat mengembangkan persyaratan. Hitung tingkat keberhasilan tim Anda dalam menemukan kesalahan ini pada tahap awal ini – ini akan jauh lebih hemat biaya daripada mencoba memperbaikinya saat desain dan pengkodean telah selesai!

Data inspeksi dapat memberi Anda dua metrik yang sangat berharga: efisiensi dan efektivitas. Efisiensi menghitung jumlah rata-rata cacat yang terdeteksi per jam kerja, sementara Efektivitas menunjukkan proporsi dari semua cacat yang ada yang diidentifikasi melalui inspeksi – ukuran yang memberikan indikasi seberapa sukses inspeksi Anda (atau praktik jaminan kualitas lainnya). Efisiensi memungkinkan Anda memperkirakan biaya untuk menemukan cacat melalui inspeksi. Anda dapat menimbang biaya ini terhadap jumlah yang dikeluarkan untuk menangani cacat dalam persyaratan yang ditemukan kemudian dalam pengembangan atau setelah pengiriman, memungkinkan Anda untuk menentukan apakah peningkatan kualitas persyaratan bermanfaat secara finansial.

Manajemen Risiko Alat Kesehatan

Status Persyaratan

Untuk tetap di atas proyek, lacak setiap persyaratan sepanjang masa pakainya. Anda bahkan dapat menetapkan nilai atribut untuk menyimpan informasi tersebut untuk keamanan dan akurasi ekstra. Jenis pelacakan status ini akan membantu mengurangi dilema umum dengan proyek perangkat lunak – dengan salah mengklaim bahwa “sembilan puluh persen selesai”. Setiap persyaratan harus memiliki salah satu dari status ini selama jangka waktu tertentu:

  • Advokasi (seseorang dengan penuh semangat mendukungnya)
  • Proses persetujuan berhasil dan alokasi telah ditempatkan pada baseline.
  • Setelah menyusun, membuat skrip, dan menguji kode dengan hati-hati, kami menerapkannya.
  • Setelah persyaratan menjalani dan lulus tesnya, itu diverifikasi untuk integrasi yang berhasil ke dalam produk.
  • Persyaratan ini akan dipenuhi di kemudian hari.
  • Anda memutuskan untuk Menghapusnya dan tidak menerapkannya.
  • Dibubarkan (konsepnya tidak pernah diberi lampu hijau)

Selain opsi status yang disebutkan di atas, status lain dapat dipertimbangkan. Beberapa mungkin memilih status "Ditinjau" untuk memvalidasi persyaratan mereka sebelum menambahkannya ke konfigurasi dasar. Alternatifnya, organisasi dapat menggunakan "Dikirim ke Pelanggan" sebagai sarana untuk memverifikasi bahwa mereka telah merilis persyaratan dengan benar dan benar.

Jika Anda bertanya tentang kemajuan seorang pengembang, dia mungkin menjawab bahwa ada 87 persyaratan untuk proyek khusus ini. 61 telah dikonfirmasi dan 9 sudah ada tetapi masih menunggu verifikasi sementara 17 masih harus diselesaikan. Namun, penting untuk diperhatikan bahwa permintaan ini tidak semuanya cocok dalam hal ukuran atau pengaruhnya terhadap kepuasan pelanggan; mereka mungkin membutuhkan jumlah usaha yang berbeda juga. Sebagai manajer proyek, saya tidak ragu bahwa kami memiliki pemahaman yang akurat tentang ukuran subsistem dan seberapa dekat penyelesaiannya. Ini jauh lebih efektif daripada sekadar mengatakan "Saya sudah menyelesaikan sekitar sembilan puluh persen". Dengan gambaran kemajuan secara keseluruhan, saya dapat dengan percaya diri mengatakan "tampak hebat!"

Perubahan permintaan

Untuk mencapai manajemen persyaratan yang berhasil, organisasi Anda harus memperhatikan setiap penambahan, penghapusan, dan modifikasi persyaratan. Ini akan memungkinkan Anda untuk melacak status serta implikasi dari semua permintaan perubahan. Anda juga dapat menggunakan data ini untuk menjawab beberapa pertanyaan pertanyaan seperti:

  • Berapa banyak permintaan perubahan yang telah dibuat dalam jangka waktu yang ditentukan?
  • Berapa banyak permintaan yang telah dijawab dan berapa banyak yang belum terselesaikan?
  • Berapa tingkat persetujuan untuk permintaan, dan berapa persentase yang ditolak?
  • Sejauh mana tim mengeluarkan energi untuk melaksanakan setiap modifikasi resmi?
  • Berapa lama biasanya permintaan tetap terbuka?
  • Rata-rata, berapa banyak item (misalnya persyaratan atau artefak) yang dipengaruhi oleh setiap permintaan perubahan yang dikirimkan?

Sistem Manajemen Persyaratan

Pastikan Anda melacak setiap perubahan yang dilakukan selama proses pengembangan setelah menetapkan garis dasar untuk setiap rilis. Ingat, satu permintaan perubahan dapat berdampak pada banyak persyaratan dari berbagai jenis (berorientasi pengguna, fungsional, dan non-fungsional). Untuk menilai berapa banyak perubahan yang dialami dalam periode waktu tertentu, bagilah jumlah modifikasi dengan jumlah total persyaratan sebelum periode ini (seperti saat menentukan garis dasar Anda).

Kami tidak ingin sepenuhnya menghapus volatilitas persyaratan. Lagi pula, seringkali ada pembenaran yang sah untuk mengubahnya. Namun pada saat yang sama, kami harus memastikan bahwa proyek kami dapat menangani perubahan dan tetap memenuhi kewajibannya. Mendekati penyelesaian menimbulkan biaya tambahan ketika perubahan sering dilakukan; ini membuat sulit untuk menentukan kapan Anda akan merilis produk Anda ke dunia! Seiring kemajuan pembangunan, sebagian besar proyek harus menjadi lebih tahan terhadap perubahan; dengan kata lain, tingkat penerimaan perubahan harus menurun secara bertahap hingga mencapai nol saat rilis selesai. Pendekatan iteratif memberi tim banyak peluang untuk menggabungkan peningkatan dalam iterasi selanjutnya sambil tetap berada di jalur dengan garis waktu setiap siklus.

Jika tim Anda dibanjiri dengan permintaan perubahan, kemungkinan besar proses elisitasi tidak komprehensif atau ide terus muncul seiring kemajuan proyek. Oleh karena itu, penting untuk melacak dari mana perubahan ini berasal dari pemasaran, pengguna, tenaga penjualan, tim manajemen, dll. Mengawasi informasi ini akan membantu Anda dalam menentukan siapa dan apa yang memerlukan perhatian untuk meminimalkan persyaratan yang diabaikan dan mencegah miskomunikasi di masa mendatang.

Ketika permintaan perubahan tetap tidak terselesaikan dalam jangka waktu yang lama, ini merupakan indikasi yang jelas bahwa proses manajemen perubahan Anda memerlukan perhatian. Saya secara pribadi telah menyaksikan satu organisasi yang memiliki permintaan peningkatan yang telah berumur beberapa tahun dan masih tertunda. Untuk membuat manajer proyek memprioritaskan energi mereka pada item terpenting dalam backlog, tim ini harus menetapkan permintaan terbuka spesifik ke dalam rilis pemeliharaan terencana dan mengonversi perubahan tertunda jangka panjang lainnya sebagai yang ditolak. Dengan cara ini mereka dapat lebih mudah mengatasi apa yang penting dan mendesak terlebih dahulu sebelum menangani masalah yang kurang mendesak.

Waktu dan Usaha

Untuk memastikan kinerja yang optimal, kami sangat menyarankan agar Anda mencatat jumlah waktu yang dihabiskan tim Anda untuk tugas rekayasa persyaratan. Ini termasuk menyusun persyaratan kualitas dan mengelola perubahan, melacak kemajuan, membuat data ketertelusuran, dan aktivitas lain yang terkait dengan proses ini.

Orang sering bertanya kepada saya berapa banyak waktu dan energi yang harus dicurahkan untuk kebutuhan proyek. Jawaban ini sangat bergantung pada ukuran, tim, organisasi yang membangunnya, dan tujuannya. Melacak upaya Anda yang diinvestasikan dalam tugas-tugas penting untuk proyek seperti ini dapat membantu Anda merencanakan masa depan dengan estimasi yang akurat.

Jika tim Anda sebelumnya telah menyelesaikan proyek dan mengalokasikan 10% waktunya untuk persyaratan, setelah refleksi Anda mungkin telah memperhatikan bahwa kualitas persyaratan tersebut dapat jauh lebih baik. Jika dihadapkan dengan proyek serupa lainnya, akan bijaksana bagi Manajer Proyek untuk memastikan lebih banyak upaya diberikan untuk menciptakan spesifikasi menyeluruh – lebih dari sepuluh persen dari total sumber daya yang tersedia sudah cukup!

Waktu dan Usaha

Saat Anda mengumpulkan dan menganalisis data, bandingkan upaya pengembangan proyek dengan ukuran ukuran produk. Persyaratan terdokumentasi Anda akan memberikan gambaran tentang ukuran keseluruhannya. Untuk lebih tepatnya, Anda dapat menghubungkan upaya untuk menghitung spesifikasi individual yang dapat diuji, menggunakan poin kasus, atau poin fungsi – apa pun yang sebanding dengan pengukuran produk Anda. Mengacu pada Gambar 1 dalam konteks ini menghasilkan tolok ukur untuk mengevaluasi kemampuan tim pengembangan Anda yang selanjutnya membantu memperkirakan konten rilis serta cakupannya secara akurat! Dengan mengumpulkan data terkait ukuran untuk produk Anda dan mencatat upaya implementasi terkait, Anda dapat merumuskan estimasi yang akurat dalam persiapan untuk proyek serupa di masa mendatang.

Ketakutan mungkin melekat di benak banyak orang; takut bahwa mengembangkan program pengukuran perangkat lunak akan mencuri waktu yang berharga dari tugas-tugas penting. Sebaliknya, menerapkan sistem metrik yang efisien dan tepat sasaran tidak membutuhkan terlalu banyak tenaga atau tenaga. Yang perlu Anda lakukan hanyalah membangun infrastruktur dasar untuk mengumpulkan dan menganalisis data, serta mendorong anggota tim Anda untuk mencatat beberapa detail yang relevan tentang aktivitas kerja mereka. Saat Anda membuat budaya berdasarkan metrik di dalam perusahaan Anda, sungguh menakjubkan apa yang dapat dipelajari melalui metode ini!

Kesimpulan

Persyaratan elisitasi dan analisis merupakan komponen penting dari pengembangan perangkat lunak. Tanpa mereka, sebuah proyek dapat gagal karena spesifikasi yang hilang atau salah, menyebabkan pengerjaan ulang yang mahal dan hasil yang berpotensi tidak memuaskan. Oleh karena itu, penting untuk memastikan bahwa Anda memiliki proses yang efisien untuk mengumpulkan persyaratan dan memverifikasi keakuratan sepanjang garis waktu proyek. Dengan manajemen yang tepat, tim dapat mencapai kesuksesan dengan membuat persyaratan terperinci yang menjelaskan secara akurat semua fungsionalitas yang diinginkan, memastikan tidak ada yang terlewatkan. Dengan mengevaluasi proses dan metrik yang ada secara teratur di setiap usaha, tim akan dapat lebih memahami apa yang terbaik bagi mereka saat mencari umpan balik pengguna selama siklus pengembangan. Ini akan membantu menjaga proyek tetap pada jalurnya dan berkontribusi terhadap hasil berkualitas lebih tinggi.

Jangan lupa untuk membagikan postingan ini!

Atasan

Tingginya Biaya Manajemen Persyaratan yang Buruk

Juni 06th, 2024

11 pagi EST | 5 WIB | 8 PST

Louis Arduino

Pembicara Utama

Dampak & Solusi untuk Manajemen Persyaratan yang Tidak Efisien

Jelajahi dampak signifikan dari praktik manajemen persyaratan yang tidak efisien terhadap biaya dan jadwal proyek.