İyi Bir Gereksinim Analizi Nasıl Olmalı-Olmamalı?

Merhabalar, bu yazımda iş analistleri için en önemli konulardan biri olan gereksinim analizi yazarken nelere dikkat etmemiz gerektiğine değineceğim. Keyifli okumalar 😊

İyi Bir Gereksinim Analizi Nasıl Olmalı?

Gereksinimleri elde etmenin yanı sıra kaliteli gereksinim yazabilmek de oldukça zordur. Tam, eksiksiz ve tüm paydaların anlayabileceği gereksinimler yazılımın kalitesini de doğrudan etkilemektedir. Mükemmel gereksinim yazmak imkansız ve gerekli de değildir. Önemli olan yazılan gereksinimlerin, iyi gereksinimin taşıması gereken özelliklerin büyük çoğunluğunu taşımasıdır.

Uygulanabilir

Gereksinimler, bütçe, kaynaklar, süre, iş kuralları, kısıtlamalar ve yasal zorunluluklara uygun olarak tanımlanmalıdır. Sistemsel olarak kolayca uygulanamayacak, ekstra donanım ihtiyacı ve maliyet gerektirecek gereksinimler yerine uygulanabilir çözümler üretilmeli ve gereksinim tanımlaması yapılmalıdır. ‘Kullanıcı siparişini aynı gün kargo opsiyonu ile verebilmeli’ şeklinde tanımlayacağımız bir gereksinim, eğer siparişi aynı gün tedarik edebilecek yeterli alt yapımız yok ise her ne kadar kolayca sürece dahil edilebilecek bir seçim gibi görünse de uygulanabilir bir gereksinim olmayacaktır.

Önceliklendirilmiş

Gereksinimler tanımlanırken mutlaka önceliklendirme yapılmalı, hangi gereksinimin daha öncelikli olduğu tanımlanmalıdır. Ayrıca gereksinimler arası ilişkiler de belirlenmeli, gerçekleşmesi birbirine bağlı gereksinimler varsa açıkça belirtilmelidir.

Anlaşılır

Analiz dokümanlarında çoğu zaman kısaltmalar ya da teknik terimler ile gereksinimler tanımlanır. Analiz dokümanlarını farklı bilgi seviyesindeki paydaşlar da okuyacağı için herkesin anlayacağı şekilde gereksinimler tanımlanmalı, çok fazla kısaltma kullanılıyorsa dokümanda bu kısaltmalar ayrı bir bölümde açıklanmalıdır.

Atomik

Gereksinimler daha küçük parçaya bölünemeyecek kadar atomik seviyede tanımlanmalıdır. Tanımlanan bir gereksinim kendi içerisinde farklı gereksinimleri içeriyorsa anlamlı olabilecek şekilde parçalara ayrılmalı ve ayrı şekilde tanımlanmalıdır.

Örneğin; “Kullanıcı ürün listesinden incelemek istediği bir ürünü seçerek ürün detaylarını görüntüleyebilmeli ve sipariş verebilmeli” şeklinde tanımlanan bir gereksinim kendi içerisinde farklı gereksinimleri de içerdiği için doğru bir tanımlama değildir. User-centered bir gereksinim analizinde incelemek istenen ürünün seçilerek detayının görüntülenmesi ve sipariş verme 2 ayrı gereksinim olarak tanımlanmalıdır.

Açık, Kesin

Gereksinimler tüm paydaşlar tarafından anlaşılacak derecede açık bir şekilde tanımlanmalı, okuyucunun tartışmasına açık olmamalı ve muğlak ifadeler içermemelidir. Gereksinimleri tanımlarken ‘ya da’, ‘veya’ gibi ifadeler kullanılmamalıdır.

Bütün, Tam

Gereksinimler tüm paydaşlar için yeterli seviyede detay içerecek şekilde tanımlanmalıdır. ‘Kullanıcı sipariş verebilmeli’ şeklinde tanımlanan bir gereksinim eksik bir gereksinimdir. Sipariş verme sürecinin tamamının nasıl gerçekleşeceği, ürünün sepet üzerinden mi sipariş verileceği, sipariş verirken teslimat adresi oluşturma ve ödeme aşamalarının da tanımlanması gerekir. Hatta atomik seviyede tanımlayabilmek için gerekirse sipariş verme süreci de parçalanarak sepet oluşturma, adres oluşturma, ödeme süreci, sipariş onayı gibi kısımlar da ayrı birer gereksinim olarak tanımlanabilir.

Tutarlı

Gereksinimler birbirleri ile tutarlı ve iş ihtiyacını karşılıyor olmalıdır. Farklı paydaşlar ile yapılan görüşmeler sonucunda ortaya çıkan, birbirleri ile çelişen gereksinimlerin netleştirilmesi gerekir.

Kısa, Öz

Gereksinimler tanımlanırken fazladan olabilecek gereksiz bilgiler verilmemeli, kısa ve basit bir şekilde tanımlanmalıdır. Uzun cümleler ve bağlaçlar kullanılması analiz dokümanlarının okunmasını ve kolay anlaşılmasını olumsuz yönde etkilemektedir.

Doğrulanabilir

Tanımlanan gereksinimler doğrulanabilecek şekilde kabul kriterleri içermelidir. “Kullanıcı kolay bir şekilde siparişini verebilmeli” ya da “Sipariş hızlı bir şekilde gerçekleştirilebilmeli” şeklinde tanımlanacak gereksinimler doğrulanabilir değildir. “Kime göre kolay olacak?”, “Kolay olup olmadığına nasıl karar vereceğim?” ya da “Ne kadar hızlı olmalı?” gibi sorulara yanıt verecek şekilde ölçülebilir kabul kriterleri ile gereksinimler tanımlanmalıdır. Böylelikle test aşamasında test yapan kişinin inisiyatifine göre değil tanımlanan kriterlere göre testin başarılı ya da başarısız olduğu kararı verilir.

İyi Bir Gereksinim Analizi Nasıl Olmamalı?

Gereksinimleri iyi yazmanın yöntemi, gereksinimleri nasıl yazmamaktan geçer. Yapılan hatalar genelde aynı türden olduğu için neler yapılmaması gerektiğini ortaya çıkarmak daha kolaydır. Böylece önceden düşülmüş tuzaklara yeniden düşülmeyerek hatasız, anlaşılır, eksiksiz ve geri dönüşü olmayan gereksinimler yazılmış olur.

Belirsizlik ve birden fazla anlam taşıyan ifadeler yer almamalıdır

Bu durum en çok düşülen bir hata olmasına rağmen gereksinimleri açık ve anlaşılır biçimde yazmak oldukça zordur. Bir de anlaşılırlığı arttırmak için çok fazla kelime kullanmak da gereksinimlerin okunurluğunu azaltarak sıkıcı bir hal alacaktır. Özellikle “ya da”, “veya”, “bununla birlikte” gibi kelimeler içeren gereksinimler potansiyel muğlak gereksinimlerdir ve bu kelimeler gereksinimin belirsizliğini arttıracaktır. Örneğin, “Aynı sistem hata halinde görsel veya sesli uyarılar verecektir” gibi bir gereksinim yazılırsa, hata mesajlarının sesli mi görsel mi olacağı belirsizdir.

Gereksinimler bağlaçlar ile birbirine bağlanmamalıdır

Gereksinimlerde cümleleri bağlamak amacıyla “ve”, “veya” bağlaçları ile geçiyorsa bunları ayrı ayrı gereksinim olarak yazmak gerekir. Böylece hem gereksinimlerin okunurluğu arttırılmış olur hem de test edilirken her birine ayrı ayrı önem gösterilmiş olur.

Gereksinimleri genişleten, farklı yönlere çeken, dağıtan kelimelerden sakınmak gerekir

Bu durum daha çok gereksinimleri test ederken sorun oluşturur. Şöyle ki; test yapılırken yorumlama yapmak gerekir, koşulun tersi durumlarını, alternatif durumlarını da test etmek gerekecektir. Gereksinimleri yazarken “ise”, “-diği zaman”, “-in dışında”, “-madıkça”, “-masına rağmen” gibi ekleri içeren sözcüklerden kaçınılmalıdır.

Gereksiz yere uzun cümleler kurarak gereksinimler yazılmamalıdır

Gereksiz yere uzun cümleler kurarak gereksinimleri yazmamalı, konuyu dağıtmamak gerekir. Uzun gereksinimler birkaç adet gereksinime parçalanabilir. Gereksinim yazmak edebi eser yazmak değildir. Uzun cümleler hatta paragraflar yazmak işin teknik tarafı ile ilgilenen geliştiriciler ve kullanıcılar için sıkıcılık yaratır.

Gereksinimleri yazarken tasarım yapılmamalıdır

Gereksinimleri yazarken tasarım yapmak çok kolayca düşülen bir tuzaktır. Gereksinimleri detaylı yazmaya başladıkça bazen gereksinim diye yapacağımız tasarımı yazarız. Analiz ve tasarımı aynı grup yapacak ise çoğunlukla bu tehlikeyle karşılaşılır. Gereksinimlerde bileşenlerin, nesnelerin veya sınıfların ismi geçmemelidir. Fonksiyon veya yordamlar tanımlanmamalıdır.Veritabanına yönelik ifadeler, tablo isimleri, alan isimleri ve indekslerden bahsedilmemelidir.

Spekülasyon yapılmamalıdır

Gereksinimler, kullanıcılar ile geliştiriciler arasında yapılmış bir kontrattır. Burada net olmayan üzerinde spekülasyon yapılabilecek kelimelerden kaçınılmalıdır. Bu kelimeler “çoğunlukla”, “bazen”, “ara sıra”, “genellikle”, “sık sık” gibi kelimelerdir. Her şeyi net olarak ortaya koymak daha sonra spekülasyon yapılmasının önüne geçecektir.

İmkansızı istemekten kaçınılmalıdır

Hiçbir sistem mükemmel değildir. İmkansızı istemek ve bunu sorun haline getirmek gereksizdir. Bu kuruntuları yaratan veya yaratabilecek kelimeler şunlardır: “%100 güvenilir”, “asla bozulmayan”, “her duruma göre uyarlanabilecek kadar esnek”, “tüm platformlarda çalışan”, “her kullanıcı”, “her bir” vb. Örneğin “Program tüm hataları yöneterek işleyişine devam etmelidir” şeklinde bir gereksinimi sağlayacak bir sistem imkansızdır. Burada hata türleri belirtilmeli ve diğer hatalarda nelerin yapılması gerektiği, hangi durumlarda sistemin işleyişinin sonlandırılacağı net olarak belirtilmelidir.

İhtimal içeren ifadelerden kaçınılmalıdır

Gereksinimlerin içinde geçen “-ebilir, belki, olasılıkla” gibi kelimeler şüpheli durumlar oluşturur. Yazılım geliştiriciler, kullanıcıların mutlaka yapabilmesi gereken işlemlere odaklanırlar. Bu durumda böyle ihtimal içeren işlevler göz ardı edilir veya ertelenir. Bir şey ya yapılmalıdır ya da reddedilmelidir.