Gereksinim izlenebilirlik matrisi hazırlamak: kaynaktan teste izleme

İzlenebilirlik matrisi neden gerekir?

Gereksinim sayısı arttıkça "bu gereksinim neden var, nerede uygulandı, test edildi mi" soruları hafızayla yanıtlanamaz. İzlenebilirlik matrisi bu soruları tek tabloda cevaplar.

Faydaları şu yerlerde görülür. Birincisi kapsam kontrolüdür: kaynağı belli olmayan bir gereksinim ya hatalıdır ya da kapsamın sessizce büyüdüğünü gösterir. İkincisi test kapsamıdır: bir gereksinime bağlı test yoksa doğrulanmadan teslim edilecek demektir. Üçüncüsü etki analizidir: bir gereksinim değiştiğinde hangi tasarım ve testlerin etkileneceği matristen okunur.

Matris özellikle sözleşmeye bağlı, denetime tabi ya da çok paydaşlı projelerde önemlidir. Küçük ve hızlı çevik ekiplerde ise aynı amaç, ürün backlog'u ile test senaryoları arasındaki bağlantılarla karşılanabilir. Araç değişse de ilke aynıdır: her iş bir ihtiyaca, her ihtiyaç bir teste bağlanır.

Bu konu yazılım ve iş analizi bağlamındaki gereksinim izlenebilirliğidir; üretimde ürün veya parti izlenebilirliği farklı bir konudur.

Matrisin yapısı: ileri ve geri izleme

Geri izlenebilirlik, gereksinimi bir üst düzeydeki ihtiyaca ve iş hedefine bağlar. Böylece her gereksinimin bir gerekçesi olduğu görülür. İleri izlenebilirlik ise gereksinimi tasarım öğesine, geliştirilen bileşene ve teste bağlar. Böylece her gereksinimin karşılandığı ve doğrulandığı görülür.

İki yön birlikte kurulduğunda zincir tamamlanır: iş hedefi, paydaş ihtiyacı, çözüm gereksinimi, tasarım öğesi, test senaryosu. Zincirdeki bir halka eksikse matris bunu gösterir.

Matrise hangi sütunlar girer?

Çekirdek sütunlar şunlardır:

• Gereksinim kimliği: benzersiz ve değişmeyen numara ya da kod
• Gereksinim açıklaması: kısa ve açık ifade
• Kaynak: gereksinimi doğuran ihtiyaç, paydaş, belge ya da hedef
• Öncelik: zorunlu, önemli, istenen gibi sınıf
• Durum: önerildi, onaylandı, geliştirmede, doğrulandı, ertelendi
• Tasarım referansı: ilgili tasarım belgesi ya da bileşen
• Test referansı: ilgili test senaryosu kimliği
• Sahip: gereksinimden sorumlu kişi

Projeye göre sürüm, risk, kabul kriteri ya da değişiklik talebi referansı eklenebilir. Her ek sütun bakım yükü demektir; yalnız gerçekten kullanılan alanlar tutulmalıdır.

Tabloyu bir elektronik tabloda başlatmak çoğu proje için yeterlidir. Gereksinim sayısı çok arttığında ya da çok sayıda ekip aynı kayıtla çalıştığında, gereksinim yönetim araçları bağlantıları otomatik tutabilir.

Kimliğe anlamlı bir yapı verin. Türü ve alanı gösteren kısa bir ön ek ve sıra numarası, matrisi okuyan kişinin satırın ne hakkında olduğunu kimliğe bakarak anlamasını sağlar. Bir gereksinim silindiğinde kimliği başka bir gereksinime verilmez; aksi halde eski bağlantılar yanlış satıra işaret eder.

Adım adım hazırlama

Önce gereksinim listesi kimlikli hale getirilir. Her gereksinim tek ve açık yazılır; kimlik biçimi baştan belirlenir. Sonra her gereksinim için kaynak bulunur: hangi görüşme, belge ya da hedeften geldiği yazılır. Kaynağı bulunamayan gereksinim paydaşa sorulur.

Üçüncü adımda gereksinimler tasarım öğelerine bağlanır. Tasarım netleştikçe bu sütun doldurulur. Dördüncü adımda test senaryoları yazılır ve gereksinimlerle eşleştirilir. Bir gereksinime birden çok test, bir teste birden çok gereksinim bağlanabilir.

Beşinci adımda matris gözden geçirilir. Kaynağı olmayan, testi olmayan ya da hiçbir tasarıma bağlanmayan satırlar işaretlenir. Bunlar eksiklik, fazlalık ya da kapsam sorunudur.

Son olarak bakım rutini kurulur: değişiklik talebi onaylandığında etkilenen satırlar güncellenir, durum alanı sürüm ilerledikçe değişir.

Matrisi canlı tutmak

Matrisin değeri güncelliğinden gelir. Değişiklik talebi süreci matrisle bağlanmalıdır: talep onaylandığında ilgili gereksinim, tasarım ve test satırları aynı gün güncellenir. Güncellenmeyen matris, gerçeği değil geçmişi gösterir.

Durum alanı da düzenli izlenir. Sprint ya da sürüm sonunda matris, hangi gereksinimlerin teslim edildiğini ve doğrulandığını anlatır. Kabul toplantısında bu tablo, tartışmayı kanıta taşır.

Sahiplik netleşmelidir. Matrisin bakımını genellikle iş analisti üstlenir; test bağlantılarını test ekibi, tasarım bağlantılarını teknik ekip ekler. Herkesin hangi sütundan sorumlu olduğu yazılır.

Her sürümden önce kısa bir denetim yapın:

• Kaynağı boş satır var mı?
• Testi boş satır var mı?
• Hiçbir gereksinime bağlanmayan test ya da tasarım öğesi var mı?
• Durumu eski kalmış satır var mı?
• Onaylanan değişiklik talepleri matrise işlendi mi?

İlk iki soru kapsam ve doğrulama açığını, üçüncüsü gereksiz işi gösterir.

Örnek: bir satırın yolculuğu

Bir finans ekibi için fatura onay uygulaması geliştiriliyor. Paydaş görüşmesinde "onay bekleyen faturalar tek ekranda görünsün" ihtiyacı çıkıyor. Bu ihtiyaç kimlik alıyor ve çözüm gereksinimine dönüşüyor: onay bekleyen faturalar, onaylayıcıya göre süzülebilen bir listede gösterilir. Matriste kaynak sütununa görüşme notu ve iş hedefi yazılır, öncelik zorunlu olur.

Tasarım aşamasında satır, liste ekranının tasarımına ve süzme bileşenine bağlanır. Test ekibi iki senaryo yazar: yetkili kullanıcı kendi bekleyenlerini görür, yetkisiz kullanıcı başkasınınkini göremez. İki test kimliği de aynı satıra eklenir. Sürüm sonunda testler geçince durum doğrulandı olur.

Bir süre sonra paydaş listeye departman süzmesi ister. Değişiklik talebi açılır; matriste bu satıra bakan ekip hangi tasarımın ve hangi testlerin etkileneceğini hemen görür. Matris olmasaydı aynı bilgi birkaç kişinin hafızasında aranacaktı.

Sık yapılan hatalar

İlk hata matrisi bir defa hazırlayıp bırakmaktır. Güncellenmeyen matris yanlış güvence verir.

İkinci hata, gereksinimleri kimliksiz ya da kimlikleri değişen biçimde tutmaktır. Kimlik değişirse bağlantılar kopar.

Üçüncü hata, aşırı ayrıntıya girmektir. Her kod satırını gereksinime bağlamaya çalışmak sürdürülemez; izlenebilirlik karar ve doğrulama için gereken düzeyde tutulur.

Dördüncü hata, yalnız ileri yönü kurmaktır. Geri izlenebilirlik olmayınca, kimsenin istemediği ama geliştirilmiş özellikler fark edilmez.

Beşinci hata, bağlantıyı yalnız test varlığıyla ölçmektir. Bir gereksinime test bağlı olması, testin gereksinimi gerçekten doğruladığı anlamına gelmez; bağlanan senaryo gözden geçirilmelidir. Altıncı hata, ertelenen ya da iptal edilen gereksinimleri tablodan silmektir. Satırı silmek yerine durumunu değiştirin; böylece kararın geçmişi kalır.

Bu beceriyi Mindset programlarında nerede çalışırsınız

İş analizi uzmanlığı programında gereksinim yaşam çemberi yönetimi başlığı gereksinimlerin takibini ve değişiklik yönetimini işler. İş analistliği BABOK çerçevesi eğitiminde ise gereksinim türleri, yazımı ve izlenebilirlik ayrı bir başlıktır. Matris hazırlamak ya da denetlemek zorunda kalan iş analistleri ve test sorumluları için uygun bir zemindir.