Panduan Terlengkap untuk Manajemen Persyaratan dan Ketertelusuran

Status Persyaratan & Permintaan Perubahan

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?

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!

Saat Anda mengumpulkan dan menganalisis data, bandingkan upaya pengembangan proyek dengan ukuran ukuran produk. Persyaratan Anda yang terdokumentasi 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. Dengan mengumpulkan data terkait ukuran untuk produk Anda dan mencatat upaya implementasi terkait, Anda dapat merumuskan perkiraan 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!

Jangan lupa untuk membagikan postingan ini!