Requirements Traceability Matrix (RTM): Definisi, Templat, dan Contoh

Matriks kebolehjejakan keperluan, atau RTM, ialah satu-satunya dokumen yang membuktikan setiap keperluan pihak berkepentingan berjaya melalui reka bentuk, pembangunan, dan pengujian tanpa hilang, bertindih, atau senyap-senyap ditinggalkan. Jika projek anda pernah menghantar ciri yang tidak diminta oleh sesiapa, atau terlepas satu yang diharapkan oleh semua orang, RTM yang diselenggara dengan baik adalah penyelesaiannya.

Apakah matriks kebolehjejakan keperluan?

Matriks kebolehjejakan keperluan (RTM) ialah dokumen berstruktur, biasanya berbentuk jadual, yang memetakan setiap keperluan perniagaan atau sistem kepada spesifikasi reka bentuk, modul kod, dan kes ujian yang berkaitan. Perkataan "jejak" adalah kuncinya: anda boleh mengikuti mana-mana keperluan ke hadapan sehingga hasil ujiannya, atau menjejaki mana-mana kes ujian ke belakang sehingga keperluan perniagaan asal, dan mengesahkan hubungan itu masih utuh.

Anggap ia sebagai lejar induk untuk penyata skop projek anda. Penyata skop menentukan apa yang termasuk dan tidak termasuk dalam sempadan. RTM menjejaki sama ada setiap item dalam skop benar-benar dibina dan disahkan.

Istilah utama yang perlu diketahui:

• ID Keperluan: Pengenal unik yang ditetapkan kepada setiap keperluan (cth. REQ-001).
• Sumber: Pihak berkepentingan, dokumen, atau peraturan yang menjana keperluan itu.
• Kebolehjejakan: Keupayaan untuk mengikuti kitaran hayat sesuatu keperluan dalam kedua-dua arah sepanjang kitar hayat projek.
• Liputan: Peratusan keperluan yang mempunyai sekurang-kurangnya satu kes ujian yang dipautkan.

Fakta penting

• Laporan Standish Group CHAOS secara konsisten mendapati keperluan yang tidak jelas atau tidak lengkap antara tiga punca utama kegagalan projek IT, menyumbang kepada lebihan kos pada lebih 50% projek yang bermasalah (Standish Group, 2023).
• PMI's Pulse of the Profession mendapati pengurusan keperluan yang lemah menyumbang kepada kegagalan projek bagi 37% organisasi yang tidak menggunakan amalan matang (PMI, 2022).
• Panduan IIBA BABOK (v3) mentakrifkan kebolehjejakan sebagai tugas analisis perniagaan teras, mencatatkan bahawa ia menyokong analisis impak, perancangan ujian, dan kawalan perubahan sepanjang kitar hayat projek (IIBA, 2015).

Jenis kebolehjejakan keperluan

Terdapat tiga pendekatan kebolehjejakan yang biasa digunakan. Kebanyakan projek mendapat manfaat apabila ketiga-tiganya berjalan serentak.

Kebanyakan pasukan agile bermula dengan kebolehjejakan hadapan dan menambah liputan belakang apabila suit ujian berkembang. Industri yang diatur secara ketat (peranti perubatan, penerbangan, perisian kewangan) biasanya mewajibkan kebolehjejakan dwiarah sejak hari pertama.

Apa yang terkandung dalam RTM

Lajur dalam RTM anda bergantung kepada jenis projek anda, tetapi set ini merangkumi kebanyakan projek penyampaian perisian atau sistem.

Anda boleh mengurangkan lajur untuk projek kecil atau mengembangkannya untuk program yang kompleks. Matlamatnya ialah supaya sesiapa yang mengambil RTM boleh menjawab dua persoalan tanpa bertanya sesiapa: "Adakah keperluan ini telah diuji?" dan "Ujian mana yang meliputinya?"

Mengapa RTM penting

Ia mencegah perluasan skop

Apabila setiap ciri dikaitkan dengan keperluan yang didokumenkan, jauh lebih sukar untuk kerja baharu menyelinap masuk tanpa disedari. Perbincangan perluasan skop berubah daripada "patutkah kita bina ini?" kepada "keperluan mana yang ini dipetakan kepadanya?" Persoalan itu sahaja sudah cukup menghentikan sejumlah besar permintaan separuh masak.

Ia memudahkan kawalan perubahan

Apabila pihak berkepentingan meminta perubahan, RTM menunjukkan dengan tepat kes ujian, spesifikasi reka bentuk, dan modul kod mana yang terjejas. Analisis impak yang dahulunya mengambil sehari penuh mesyuarat kini boleh diselesaikan dalam 20 minit dengan matriks yang diselenggara dengan baik.

Ia menyokong ujian dan pengesahan

Pasukan yang beralih daripada pembangunan kepada ujian penerimaan pengguna sering mendapati jurang: keperluan yang ditulis tetapi tidak pernah diuji. RTM mendedahkan jurang ini sebelum UAT bermula, bukan semasa ia berjalan.

Ia menyediakan jejak audit

Dalam industri yang diatur secara ketat, juruaudit mahu melihat bahawa setiap keperluan dalam spesifikasi yang diluluskan mempunyai hasil ujian yang sepadan. RTM ialah bukti itu. Tanpanya, anda perlu membina semula jejak itu daripada ingatan, yang jarang berjalan lancar.

Cara mencipta matriks kebolehjejakan keperluan

Langkah 1: Kumpul semua keperluan

Ambil keperluan daripada setiap sumber: penyata skop projek, temu bual pihak berkepentingan, dokumen peraturan, dan kisah pengguna yang telah diluluskan. Tetapkan ID unik kepada setiap satu sebelum anda melakukan apa-apa lagi. Jika anda melangkau ID, matriks itu akan menjadi mustahil untuk diselenggara.

Langkah 2: Tentukan struktur lajur anda

Pilih lajur yang benar-benar akan diisi oleh pasukan anda. Mulakan secara ringkas. RTM enam lajur yang diselenggara oleh semua orang lebih berguna berbanding versi lima belas lajur yang tidak dikemas kini oleh sesiapa. ID Keperluan, Penerangan, Sumber, ID Kes Ujian, dan Status Ujian merangkumi asas untuk kebanyakan projek.

Langkah 3: Pautkan keperluan kepada artifak reka bentuk

Bagi setiap keperluan, rekodkan bahagian dokumen reka bentuk, rujukan rajah seni bina, atau spesifikasi teknikal yang menanganinya. Jika belum ada artifak reka bentuk, tandakan baris itu sebagai "reka bentuk belum selesai." Penanda itu sendiri berguna: ia memberitahu pengurus projek bahawa sesuatu belum bersedia untuk pembangunan.

Langkah 4: Pautkan kepada item kerja pembangunan

Hubungkan setiap keperluan kepada tiket, kisah pengguna, atau item backlog sprint di mana ia sedang dibina. Alat seperti Jira, Azure DevOps, atau malah hamparan yang dikongsi boleh membawa pautan ini. Struktur pecahan kerja adalah sumber semula jadi untuk pemetaan ini.

Langkah 5: Pautkan kepada kes ujian

Bagi setiap keperluan, rekodkan ID kes ujian yang akan mengesahkannya. Semak kriteria penerimaan di sini: kes ujian sepatutnya secara langsung menguji sama ada kriteria penerimaan dipenuhi. Jika sesuatu keperluan tiada kes ujian, ia sama ada tiada liputan atau telah terlepas pandang sepenuhnya.

Langkah 6: Jejaki status pelaksanaan ujian

Semasa ujian berjalan, kemas kini lajur Status Ujian bagi setiap baris. Ramai pasukan menjalankan laporan liputan pada penghujung setiap kitaran ujian: apakah peratusan keperluan dalam status Lulus? Apakah yang masih gagal atau belum bermula? Ini menjadi input teruskan/hentikan untuk keputusan pelepasan.

Langkah 7: Pastikan sentiasa terkini sepanjang projek

RTM yang ditulis pada permulaan dan tidak pernah disentuh lagi hanyalah hiasan. Tetapkan pemilik yang jelas (biasanya penganalisis perniagaan atau pengurus projek) dan kemas kini setiap kali sesuatu keperluan berubah, kes ujian ditambah, atau keputusan reka bentuk menjejaskan skop. Layan ia seperti daftar hidup, bukan hasil kerja sekali sahaja.

Contoh RTM

Berikut contoh kecil untuk ciri log masuk pelanggan.

REQ-003 yang gagal bermakna pelepasan tidak patut diteruskan sehingga isu penghantaran e-mel diselesaikan atau keperluan itu secara rasmi dikeluarkan daripada skop. RTM menjadikan keputusan itu kelihatan dan didokumenkan.

Amalan terbaik dan kesilapan biasa

Amalan terbaik:

• Tetapkan ID keperluan sebelum menulis RTM. Penomboran selepas fakta membawa kepada jurang dan pertindihan.
• Gunakan alat yang dikongsi berbanding hamparan tempatan. Apabila RTM berada pada desktop seorang individu sahaja, ia "mati" apabila individu itu bercuti.
• Semak RTM pada setiap semakan sprint atau pintu peringkat projek. Semakan 15 minit mengesan pesongan sebelum ia bertimbun.
• Sertakan keperluan bukan fungsian (prestasi, keselamatan, kebolehcapaian). Ini adalah yang paling kerap dilupakan sehingga ia menyebabkan insiden pengeluaran.
• Pautkan kepada dokumen kriteria penerimaan bagi setiap keperluan supaya penguji tahu dengan tepat rupa "lulus" itu.

Kesilapan biasa:

• Menulis keperluan yang terlalu samar untuk diuji. "Sistem patut pantas" tidak boleh dijejaki kepada kes ujian. "Sistem mesti memulangkan hasil carian dalam masa kurang 2 saat bagi 95% permintaan" boleh.
• Melayan RTM sebagai dokumen serah tugas sekali sahaja. Ia patut dikemas kini secara berterusan, bukan disiapkan sekali dan disimpan begitu sahaja.
• Melangkau kebolehjejakan belakang. Pasukan sering menjejaki keperluan ke hadapan sehingga ujian tetapi tidak pernah menyemak sama ada mana-mana ujian wujud tanpa keperluan yang menyokongnya. Semakan itu menghapuskan kes ujian bagi ciri yang telah dikeluarkan daripada skop, menjimatkan masa pada setiap kitaran ujian.
• Membiarkan status ujian ketinggalan berbanding ujian sebenar. Baris yang menyatakan "Belum bermula" sedangkan ujian sudah dijalankan dan gagal memberikan gambaran palsu tentang kesihatan projek.

Soalan lazim

Apakah perbezaan antara RTM dan daftar keperluan?

Daftar keperluan menyenaraikan dan mengkategorikan keperluan berserta atributnya (ID, penerangan, pemilik, keutamaan). RTM melakukan semua itu DAN menjejaki setiap keperluan melalui reka bentuk, pembangunan, dan ujian. RTM ialah daftar itu ditambah lapisan kebolehjejakan.

Adakah projek agile memerlukan RTM?

Projek agile turut mendapat manfaat daripada kebolehjejakan, walaupun formatnya sering berbeza. Berbanding hamparan formal, ramai pasukan agile menggunakan alat pengurusan projek mereka (Jira, Azure DevOps) untuk memautkan kisah pengguna kepada kes ujian dan kriteria penerimaan. Konsep RTM adalah sama; artifaknya mungkin kelihatan berbeza.

Siapa memiliki RTM?

Biasanya penganalisis perniagaan atau pengurus projek memiliki RTM, dengan sumbangan daripada pembangun dan penguji. Pemilikan bermaksud bertanggungjawab untuk mengekalkannya sentiasa terkini, bukan melakukan semua kemas kini seorang diri. Dalam persekitaran yang diatur secara ketat, biasanya terdapat pengesah yang dinamakan untuk RTM secara keseluruhan.

Bila anda patut mula membina RTM?

Mulakan sebaik keperluan digariskan dasar, bukan selepas pembangunan bermula. Membina RTM lewat bermakna membina semula pautan daripada ingatan, yang perlahan dan terdedah kepada ralat. Idealnya, anda menetapkan ID Keperluan semasa penggalian keperluan dan mula mengisi matriks sebelum sebarang kerja reka bentuk bermula.

Bolehkah RTM digunakan untuk projek bukan perisian?

Ya. Projek pembinaan, pembuatan, dan pembangunan produk semuanya menggunakan matriks kebolehjejakan untuk memautkan spesifikasi kepada hasil ujian atau pemeriksaan. Lajur berubah (nombor lukisan reka bentuk berbanding modul kod, rekod pemeriksaan berbanding kes ujian automatik), tetapi logiknya adalah sama.

Matriks kebolehjejakan keperluan yang diselenggara dengan baik ialah salah satu daripada segelintir dokumen projek yang menjimatkan masa semasa penyampaian dan selepas pelancaran. Ia memberikan setiap ahli pasukan satu sumber kebenaran tunggal tentang sama ada sesuatu keperluan telah dibina dan disahkan, dan ia memberikan kepimpinan projek bukti yang mereka perlukan untuk membuat keputusan pelepasan yang termaklum. Mulakan dengan mudah, pastikan sentiasa terkini, dan ia akan berbaloi dengan usaha itu berkali-kali ganda.