Reacibility Requirement Matrix

1. Apa itu Requirements traceability Matrix (RTM) ?

       Requirements traceability Matrix (RTM) adalah dokumen yang menunjukkan hubungan antara persyaratan dan artefak lainnya. Ini digunakan untuk membuktikan bahwa persyaratan telah dipenuhi. Dan biasanya mendokumentasikan persyaratan, pengujian, hasil pengujian, dan masalah.
 

2. Apa itu Traceability?  

    Requirements traceability adalah kemampuan untuk  menghubungkan persyaratan ke artefak lain seperti berbagai jenis pengujian perangkat lunak atau bug. Ini digunakan untuk melacak persyaratan dan membuktikan bahwa persyaratan telah dipenuhi.
 

3. Mengapa Requirement Traceability Penting
 

•       Memenuhi Tujuan

     memastikan bahwa persyaratan Anda memenuhi tujuan awal Anda. Misalnya, ini memberi anda bukti bahwa Anda memenuhi persyaratan kepatuhan.
 

•       Menjalankan Tes yang Tepat

     membantu tim jaminan kualitas (QA) Anda memahami apa yang perlu diuji. Ini meningkatkan cakupan pengujian dengan memetakan kasus uji kembali ke setiap persyaratan.
 

•       Membuat keputusan

         Dapat digunakan untuk pengambilan keputusan selama pengembangan  produk

•       Mengelola Proyek

         Anda akan tahu persis seberapa jauh Anda telah berkembang. Dan Anda akan dapat mengelola cakupan kebutuhan Anda.

4. Cara Membuat RTM

      Anda dapat membuat RTM di Microsoft Excel. Atau Anda dapat menggunakan alat khusus untuk mempercepat proses.

Ada tiga langkah dasar — ??apa pun alat yang Anda gunakan:

• Tentukan tujuan Anda.
• Tetapkan artefak Anda (dan hubungannya)..
• Isi matriks ketertelusuran.

5. Manfaat Menggunakan Traceability Matrix

Ada enam manfaat utama menggunakan matriks ketertelusuran.

• Dapatkan visibilitas di seluruh pengembangan.
• Membuat keputusan yang lebih baik (misalnya, pada perubahan persyaratan).
• Mempercepat siklus rilis.
• Tenang saja mengetahui kebutuhan Anda terpenuhi.
• Buktikan kepatuhan lebih cepat.
• Lulus audit tanpa rasa takut.

6. Jenis Traceability Matriks

• Traceability ke depan

Dalam Persyaratan ‘Teruskan Ketertelusuran’ ke Kasus uji. Ini memastikan bahwa proyek berkembang sesuai arah yang diinginkan dan bahwa setiap persyaratan diuji secara menyeluruh.

• Traceability ke belakang

            Kasus Uji dipetakan dengan Persyaratan dalam ‘Kemamputelusuran Mundur’. Tujuan utamanya adalah untuk memastikan bahwa produk yang sedang dikembangkan saat ini berada di jalur yang benar. Ini juga membantu untuk menentukan bahwa tidak ada fungsionalitas tambahan yang tidak ditentukan yang ditambahkan dan dengan demikian ruang lingkup proyek terpengaruh.

• Traceability Dua Arah

            (Maju + Mundur): Matriks Ketertelusuran yang Baik memiliki referensi dari kasus uji ke persyaratan dan sebaliknya (persyaratan ke kasus uji). Ini disebut sebagai Ketertelusuran ‘Dua Arah’. Ini memastikan bahwa semua kasus Uji dapat dilacak ke persyaratan dan setiap persyaratan yang ditentukan memiliki kasus Uji yang akurat dan valid untuk mereka.

7 . Jenis Requirement specification

• Persyaratan bisnis

           Persyaratan pelanggan yang sebenarnya tercantum dalam dokumen yang dikenal sebagai Dokumen Persyaratan Bisnis (BRS) . BRS ini adalah daftar persyaratan tingkat tinggi yang diturunkan secara cermat, setelah interaksi singkat dengan klien.

           Biasanya disiapkan oleh ‘Analis Bisnis’ atau ‘Arsitek’ proyek (tergantung pada organisasi atau struktur proyek). Dokumen ‘Spesifikasi Persyaratan Perangkat Lunak’ (SRS) berasal dari BRS.

• Dokumen Spesifikasi Persyaratan Perangkat Lunak 

           Ini adalah dokumen terperinci yang berisi semua detail teliti dari semua persyaratan fungsional dan non-fungsional. SRS ini adalah dasar untuk merancang dan mengembangkan aplikasi perangkat lunak.

• Dokumen Persyaratan Proyek

           PRD adalah Dokumen Referensi untuk semua anggota tim dalam sebuah proyek untuk memberi tahu mereka apa yang harus dilakukan suatu produk. Ini dapat dibagi menjadi beberapa bagian seperti Tujuan produk, Fitur Produk, Kriteria Rilis dan Penganggaran & Jadwal proyek.

• Gunakan Dokumen Kasus

           Ini adalah dokumen yang membantu dalam merancang dan mengimplementasikan perangkat lunak sesuai kebutuhan bisnis. Ini memetakan interaksi antara aktor dan peristiwa dengan peran yang perlu dilakukan untuk mencapai tujuan. Ini adalah deskripsi langkah-demi-langkah rinci tentang bagaimana tugas perlu dilakukan.

Misalnya,

Aktor: Pelanggan

Peran: Unduh Game

Unduhan game berhasil.

Kasus Penggunaan juga dapat menjadi bagian yang disertakan dalam dokumen SRS sesuai dengan proses kerja organisasi.

• Dokumen Verifikasi Cacat

           Ini didokumentasikan berisi semua detail yang terkait dengan cacat. Tim dapat memelihara dokumen ‘Verifikasi Cacat’ untuk memperbaiki dan menguji ulang cacat. Penguji dapat merujuk dokumen ‘Verifikasi Cacat’, ketika mereka ingin memverifikasi apakah cacat telah diperbaiki atau tidak, menguji ulang cacat pada OS yang berbeda, perangkat, konfigurasi sistem yang berbeda, dll.

           Dokumen ‘Verifikasi Cacat’ berguna dan penting ketika ada fase perbaikan dan verifikasi cacat khusus.

• Cerita Pengguna

           Kisah pengguna terutama digunakan dalam pengembangan ‘Agile’ untuk menggambarkan fitur perangkat lunak dari perspektif pengguna akhir. Cerita pengguna menentukan tipe pengguna dan dengan cara apa dan mengapa mereka menginginkan fitur tertentu. Persyaratan disederhanakan dengan membuat cerita pengguna.

Saat ini, semua industri perangkat lunak bergerak menuju penggunaan Cerita Pengguna dan Pengembangan Agile dan perangkat lunak yang sesuai untuk merekam persyaratan.