30 saniyelik özet
Requirements Traceability Matrix, kısaca RTM, gereksinimlerin kaynağını, çözüm öğelerini ve doğrulama kanıtlarını birbirine bağlayan izlenebilirlik matrisidir. Bir ihtiyacın nasıl uygulandığını ve hangi kanıtla karşılandığını görmeye yardımcı olur. Ters yönde ise bir özelliğin hangi onaylı ihtiyaca dayandığını açıklayabilir. Değeri, satır sayısında veya dolu hücrelerde değildir. Eksik uygulamayı, gerekçesi belirsiz işi ve değişiklikten etkilenen testleri görünür kılmalıdır. Bir testin gereksinime bağlanmış olması, o gereksinimin doğru veya tamamen karşılanmış olduğunu tek başına göstermez.
Neden önemli?
Bir kurumsal üründe işlem onayı özelliği geliştirildiğini düşünün. Kullanıcı rol oluşturabiliyor, işlem limiti belirleyebiliyor ve onay ekranını açabiliyor. Ekip ilgili testlerin geçtiğini söylüyor. Ancak başlangıç ihtiyacı, kullanıcının kendi işlemini onaylayamaması olabilir. Bu davranış ayrıca tanımlanıp sınanmadıysa çalışan ekranlar, iş hedefinin karşılandığını kanıtlamaz.
İzlenebilirlik, bu boşluğu araştırmak için bir yol sağlar. İş hedefinden gereksinime, gereksinimden uygulamaya ve doğrulamaya ilerlenir. Bağlantı eksikse ekip yalnızca “tamamlandı” durumunu görmek yerine hangi kanıtın bulunmadığını sorabilir. Kaynağı olmayan geliştirme işi de incelenebilir; bu durum otomatik olarak gereksiz iş anlamına gelmez, gerekçesinin açıklanmasını gerektirir.
Yönetici açısından RTM, teslimat kararının dayanağını görünür kılar. Neyi yaptığımız kadar neyi doğrulamadığımızı da gösterir. Özellikle değişikliklerde önemlidir: Bir limit kuralı değiştiğinde yalnızca ekran değil, arka plandaki kontroller, veri tanımları ve test beklentileri de etkilenebilir. Güncel bağlantılar, bu incelemenin nereden başlayacağını gösterir; bütün etkileri kendiliğinden keşfetmez.
Terim nedir?
Gereksinim izlenebilirliği, bir gereksinimin yaşamı boyunca ilişkili kayıtlarla bağlantısının korunmasıdır. İleri yönde izleme, ihtiyaçtan çözüm ve doğrulama öğelerine gider. Geri yönde izleme, bir uygulama veya test öğesinin dayandığı gereksinimi ve onun kaynağını araştırır. Bu iki yön birlikte kullanıldığında teslimatın gerekçesi ile kanıtı arasında ilişki kurulabilir.
Matris çoğunlukla gereksinim kimliği, kaynak, üst hedef, tasarım veya geliştirme kaydı, doğrulama yöntemi ve sonuç gibi alanlar içerir. Kimlik, kayıtları tutarlı biçimde referanslamak için verilen benzersiz etikettir. Gereksinim metni değiştiğinde kimliği korumak yararlı olabilir; ancak hangi sürümün değerlendirildiği ayrıca izlenmelidir.
İlişkiler her zaman bire bir değildir. Bir gereksinim farklı bileşenler tarafından karşılanabilir. Tek bir test de birden fazla gereksinimin belirli yönlerini sınayabilir. Bu nedenle bir hücreye rastgele bağlantılar doldurmak yerine ilişkinin neyi ifade ettiği belirtilmelidir. “Uygular”, “doğrular” ve “bağımlıdır” farklı bağlantılardır.
Doğrulama kanıtı da yalnızca test kimliğinden oluşmaz. Testin çalıştırılması, sonucu ve değerlendirilen ürün sürümü önemlidir. Performans gibi bazı gereksinimler için ölçüm koşulları gerekir; başka gereksinimler inceleme veya analizle değerlendirilebilir. Kullanılan yöntemin ilgili gereksinimi gerçekten değerlendirebildiği açıklanmalıdır.
RTM mutlaka ayrı bir elektronik tablo olmak zorunda değildir. Bağlantılar ekiplerin mevcut iş ve test kayıtlarında tutulabilir; matris bu ilişkilerin bir görünümü olabilir. Araç seçimini, bilgiyi güncelleme ve karar verirken kullanma ihtiyacı belirlemelidir. Elle hazırlanmış bir rapor güncel kaynaklardan koparsa düzenli görünmesine rağmen yanıltıcı olabilir.
Gerçek vaka: NASA’nın tarihli izlenebilirlik yaklaşımı
NASA’nın NPR 7123.1B Systems Engineering Processes and Requirements belgesi, gereksinim yönetiminde üst ve alt gereksinimler arasında çift yönlü izlenebilirlik kurulmasını tanımlıyor. Belgenin doğrulama raporu yaklaşımında kaynak referansları, doğrulama yöntemi, sonuçlar, sapmalar ve düzeltici işlemler birlikte ele alınıyor.
Ek C’de, bu bilgilerin doğrulama matrisi olarak tutulabileceği açıklanıyor. Ayrıca değerlendirilen ürünün ve kullanılan şartname kayıtlarının sürümlerinin belgelenmesi öneriliyor. Böylece bir sonuç, hangi gereksinim ve hangi ürün hali için elde edildiğiyle birlikte anlam kazanıyor.
Kaynağın üst kısmı, bu sürümün artık yürürlükte olmadığını açıkça belirtiyor. Burada güncel zorunluluk olarak değil, yayımlanmış tarihli bir kurumsal süreç örneği olarak kullanılıyor. Belge, belirli bir uzay görevinin başarı oranını veya RTM sayesinde kazanılan süreyi göstermiyor.
Bu örnekten çıkarılabilecek ders, kanıtın bağlamıyla birlikte tutulmasıdır. “Doğrulama tamamlandı” ifadesini değerlendirirken gereksinim, yöntem, sürüm ve varsa çözülmemiş sapma aynı zincirde görülebilmelidir.
Varsayımsal örnek: Kurumsal işlem onayı
Bir yazılım şirketinde iş gereksinimi BR-ONAY olarak kaydediliyor: Kurumsal müşteriler, işlem yapan kişiyle onaylayan kişiyi ayırabilecek. Alt gereksinim FR-AYRIM, bir kullanıcının kendi başlattığı işlemi onaylayamamasını tanımlıyor. Bu etiketler örneğe ait kayıt kimlikleridir; ölçülmüş sayılar değildir.
Analist, FR-AYRIM kaydını kullanıcı rolü tanımına, onay ekranına ve sunucu tarafındaki yetki kontrolüne bağlıyor. Yalnızca ekran düğmesini kapatmak yeterli sayılmıyor. Başka bir yazılım üzerinden gönderilen onay isteğinin de aynı kurala tabi olması gerekiyor. Bu davranış API sözleşmesiyle ilişkilendiriliyor; API, yazılımlar arasındaki iletişim arayüzüdür.
Test kayıtları farklı yolları kapsıyor: Yetkili başka kullanıcı onay verebiliyor, işlemi başlatan kullanıcı onay veremiyor ve arayüz dışında gönderilen istek aynı kuralı aşamıyor. Her kayıt için beklenen sonuç, çalıştırma durumu ve ilgili ürün sürümü tutuluyor. Test henüz çalıştırılmadıysa gereksinim doğrulanmış olarak gösterilmiyor.
Daha sonra müşteriye özel onay zinciri talep ediliyor. Mevcut bağlantılar, hangi gereksinim ve bileşenlerin incelenmesi gerektiğini gösteriyor. Ancak yeni davranışın mevcut gereksinimi değiştirip değiştirmediğine analist ve iş sahibi karar veriyor. Matris karar vermez; karar için ilgili kayıtları bir araya getirir.
İnceleme sonucunda eski testlerin bir bölümü geçerliliğini koruyabilir, bir bölümü güncellenebilir ve yeni testler gerekebilir. Önceki sürümde alınmış başarılı sonuçlar, yeni davranış için otomatik olarak geçerli kabul edilmez. Böylece izlenebilirlik yalnızca geçmişi belgelemek yerine değişikliğin değerlendirilmesinde kullanılır.
Yaygın üç hata
- Bağlantı bulunmasını yeterli kanıt saymak
Bir test kaydı oluşturulmuş ama çalıştırılmamış olabilir. Çalıştırılan test de gereksinimin yalnızca bir bölümünü değerlendirebilir. Bağlantının yanında kapsamı, sonucu ve sürümü inceleyin. “Testi var” ile “karşılandığı doğrulandı” durumlarını ayırın.
- Her kaydı her şeyle ilişkilendirmek
Çok sayıda bağlantı, ilişki kalitesini artırmaz. Gereksiz ilişkiler değişiklik incelemesini zorlaştırır. Bağlantı kurarken hangi davranışın uygulandığını veya doğrulandığını açıklayın. Gereksinim çok genişse, anlamlı ve değerlendirilebilir alt gereksinimlere ayırmayı düşünün.
- Matrisi teslimattan önce bir kez hazırlamak
Gereksinimler ve çözüm değişirken bağlantılar güncellenmezse matris geçmiş bir durumu gösterir. Güncelleme sorumluluğunu ekiplerin iş akışına yerleştirin. Kapatılan kayıtların, değişen kabul koşullarının ve yeni sürümlerin ilişkilere etkisini inceleyin.
Mini uygulama / şablon
Kritik bir gereksinim seçin ve aşağıdaki alanlarla tek bir izlenebilirlik kaydı oluşturun. Önce temel zinciri tamamlamak, bütün projeyi aynı anda belgelemeye çalışmaktan daha yönetilebilir olabilir.
- Gereksinim kimliği ve sürümü
- —
- Gereksinim açıklaması
- —
- Kaynak ve karar sahibi
- —
- Üst iş hedefi
- —
- İlgili alt gereksinimler
- —
- Tasarım veya geliştirme kayıtları
- —
- Bağlantının türü ve gerekçesi
- —
- Doğrulama yöntemi
- —
- Test, analiz veya inceleme kaydı
- —
- Değerlendirilen ürün sürümü
- —
- Sonuç ve kanıt bağlantısı
- —
- Açık sapmalar ve aksiyon sahibi
- —
- Son güncelleme ve güncelleyen kişi
- —
Ardından zinciri iki yönde okuyun. İhtiyaçtan başlayıp kanıta ulaşabiliyor musunuz? Bir geliştirme kaydından başlayıp onaylı gerekçeyi bulabiliyor musunuz? Eksik bağlantıları ve belirsiz sonuçları ayrı kaydedin. Bir kayıt eksikse önce gerçekten eksik çalışma mı, yoksa eksik ilişki mi bulunduğunu araştırın. RTM’nin yararı, bu farkı konuşulabilir hale getirmesidir.
İlgili terimler
Business Requirement, Functional Requirement, Non-Functional Requirement, Business Rule, Acceptance Criteria, Use Case, API Specification / API Contract, Change Request ve Impact Analysis, User Acceptance Testing, Scope ve Out of Scope