Yanlış anlaşılmayan sistem gereksinimleri nasıl yazılır?

İşletme sahibi “Sipariş girişi için kolay bir ekran ve hızlı bir satış raporu istiyoruz” diye yazar; yazılım geliştirici aynı cümleyi okur ve başka bir şey anlar. İkisi de hatalı değildir; cümle birden fazla anlama gelebilir. Fark teslimattan sonra ortaya çıktığında onu düzeltmek, kodlamadan önce netleştirmekten çok daha pahalıya mal olur.

Net gereksinimler uzun bir doküman demek değildir; iki farklı kişinin okuyup aynı şeyi anladığı bir metindir. Bu makalede yanlış anlamaların genellikle nerede ortaya çıktığını, gereksinimlerin bunları azaltacak şekilde nasıl yazılacağını ve yazılım ekibine ulaşmadan önce nasıl gözden geçirileceğini ele alıyoruz.

Gereksinimler neden yanlış anlaşılır?

Bunun nedeni nadiren yetkinlik eksikliğidir. Sık karşılaşılan dört neden vardır ve bunlar, kodlama başlamadan önce herhangi bir gereksinim dokümanında fark edilebilir:

• Belirsiz kelimeler: “Hızlı”, “kolay”, “esnek” ve “gerektiğinde” test edilebilir bir davranışı tanımlamaz. Yönetici için hızlı olan, her gün yüzlerce sipariş giren bir çalışan için yavaş olabilir.
• Gizli iş kuralları: Çalışanlar, müşterinin kredi limiti kontrol edilmeden siparişin sevk edilmediğini bilir; ama “bilindiği” için kimse bunu yazıya dökmemiştir.
• Eksik istisnalar: Gereksinim yalnızca olağan durumu anlatır; hazırlandıktan sonra iptal edilen siparişe, kısmi iadeye ve ödemesini birkaç seferde yapan müşteriye hiç değinmez.
• Kabul kriterlerinin olmaması: İki taraf “bitti” kelimesinin ne anlama geldiği konusunda önceden anlaşmaz ve aradaki farkı teslimatta görür.

Diyelim ki gereksinimde “Müşteri araması hızlı olmalı” yazıyor. Yazılım geliştirici bunu tam ada göre arama olarak anlayabilir; satış çalışanı ise bir telefon görüşmesi sırasında müşteriyi cep telefonu numarasının bir kısmıyla bulmayı kastediyor. Aynı gereksinimden iki farklı sistem çıkmıştır.

Bu fark toplantılarda görünmez, çünkü her taraf kelimeyi duyar ve onu kendi bildikleriyle doldurur. Fark, çalışan ekranın başına ilk kez oturduğunda, yani düzeltilmesinin en pahalı olduğu anda ortaya çıkar.

Çözüm bu kelimeleri silmek değil, onları davranışa dönüştürmektir. “Kolay veri girişi” yerine şunu yazın: Çalışan siparişi tek bir ekrandan girer, müşteriyi adının ya da cep telefonu numarasının bir kısmına göre arayıp seçer ve fiyatlar onaylı fiyat listesinden otomatik olarak doldurulur.

Kullanıcı hikâyeleri: kim, ne ve neden

Kullanıcı hikâyesi, her gereksinimi bir kişiye ve bir amaca bağlayan kısa bir cümledir. Olağan kalıbı şöyledir: Belirli bir rolü üstlenen biri olarak bir şey yapmak istiyorum, böylece işimde bir sonuç elde edebilirim. Kalıbın değeri son kısmındadır: “Böylece” ile başlayan kısım gereksinimin nedenini açıklar; ekibin mümkün olduğunda daha basit bir çözüm önerebilmesini sağlayan da bu nedendir.

Varsayımsal bir örnek: “Depo sorumlusu olarak, sevkiyat için onaylanmış siparişleri teslim tarihine göre sıralanmış şekilde görmek istiyorum, böylece acil sevkiyatları önce hazırlayabilirim.” Bu cümle kullanıcıyı, ekranı, sıralamayı ve nedeni belirtir; hiçbir teknolojiden söz etmez.

Her amaç için tek bir hikâye yazın ve hikâyeyi tek başına geliştirilip test edilebilecek kadar küçük tutun. Açıklamak için bütün bir paragraf gerektiren bir hikâye, çoğu zaman birbirinden ayrılması gereken birkaç hikâyedir.

Hikâyeye ekranla ya da butonla başlamaktan kaçının. “Siparişleri dışa aktarmak için bir buton istiyorum” bir çözümü tarif eder; “Günün siparişlerini öğleden önce kargo şirketine göndermek istiyorum” ise dışa aktarmadan daha basit bir çözümü olabilecek bir ihtiyacı tarif eder.

İş kuralları ve istisnalar: “Herkesin bildiğini” yazın

İş kuralları, ekrandan bağımsız olarak sistemde olup biteni belirleyen koşullardır: kimin neyi onayladığı, bir siparişin ne zaman reddedildiği, indirimin nasıl hesaplandığı. Her kuralı sade bir dille tek bir cümlede yazın; hikâyelerde ve testlerde numarasıyla anılabilmesi için de kuralları numaralı bir listede toplayın.

Diyelim ki bir dağıtım şirketi kurallarını şöyle yazıyor:

1. Müşterinin borç bakiyesini kredi limitinin üzerine çıkaracak bir sipariş, satış müdürünün onayı olmadan sevk edilmez.
2. Satış temsilcisine tanınan sınırı aşan bir indirim, şube müdürünün onayını gerektirir.
3. Depodan çıkmış bir sipariş iptal edilmez; iade olarak işlenir.
4. Stok, sipariş girildiğinde değil, onaylandığında rezerve edilir.

Dikkat ederseniz her kuralda koşul, sonuç ve varsa istisna yetkisinin kimde olduğu belirtilir. İki çalışan bir kuralı farklı ifade ediyorsa, bu, işin kendisindeki bir farklılıktır ve kodlama sırasında değil, kodlamadan önce çözülmelidir.

Ardından her hikâye için istisnaları açıkça yazın: Miktar yalnızca kısmen mevcutsa, sipariş onaylanmadan şube kapanırsa ya da çalışan mükerrer bir müşteri kaydı girerse ne olur? Yazılmayan istisna ortadan kalkmaz; canlıya geçişten sonra ortaya çıkar ve aceleyle çözülür.

Kabul kriterleri ile girdi ve çıktı örnekleri

Kabul kriterleri hikâyeyi doğrulanabilir koşullara dönüştürür: Koşulların hepsi sağlanıyorsa hikâye tamamlanmıştır, biri eksikse tamamlanmamıştır. Kriterler her hikâye için ayrı ayrı yazılır ve kodlamanın nasıl yapılacağını değil, kullanıcının ne gördüğünü tanımlar. Yukarıdaki depo sorumlusu hikâyesi için kriterler şöyle olabilir:

• Listede yalnızca onaylanmış siparişler görünür; bekleyen ya da iptal edilen siparişler görünmez.
• Siparişler teslim tarihine göre sıralanır ve tarihi en yakın olan ilk sırada yer alır.
• Teslim tarihi geçmiş sipariş belirgin biçimde işaretlenir.
• Depo sorumlusu satış fiyatlarını ve kredi limiti bilgilerini görmez.

Hesaplama ya da koşul içeren yerlere girdi ve çıktı örnekleri ekleyin. Varsayımsal bir örnek: Kredi limiti elli bin, borç bakiyesi kırk bin olan bir müşteri on beş binlik mal sipariş ediyor.

Birinci kurala göre beklenen çıktı: Sipariş “Onay bekliyor” durumunda kaydedilir, satış müdürüne bir bildirim gider ve stok henüz rezerve edilmez. Bunun gibi tek bir örnek, günlerce sürebilecek bir tartışmayı sonuçlandırır ve hazır bir test senaryosuna dönüşür.

Ortak dil, gözden geçirme ve onay

Terim sözlüğü

Her kurum bazı kelimeleri kendine özgü anlamlarla kullanır. “Sipariş” satış ekibi için fiyat teklifi anlamına gelebilirken depo için sevk emri demektir. Gereksinimlerde tekrar eden her terimi tanımlayan kısa bir sözlük yazın ve bu terimleri hikâyelerde, kurallarda ve ekranlarda aynı anlamda kullanın.

Sözlükten varsayımsal bir örnek: “Aktif müşteri, son üç ay içinde onaylanmış bir siparişi olan müşteridir.” Bunun gibi kısa bir tanım, raporlarda ve satış temsilcilerinin listelerinde neyin görüneceğini belirler ve her departmanın bunu kendi yöntemiyle hesaplamasını önler.

İşi yapanlarla birlikte gözden geçirme

Yalnızca yöneticinin yaptığı bir gözden geçirme eksik kalır. Yönetici sürecin nasıl işlemesi gerektiğini bilir, çalışan ise gerçekte nasıl işlediğini. Hikâyeleri ve kuralları sistemi kullanacak kişilerle birlikte okuyun ve onlardan, geçen haftaki işlerinden gerçek bir vakanın üzerinden adım adım geçmelerini isteyin.

Her adımda şunu sorun: İşler yazıldığı gibi gitmezse ne yaparsınız? Bu sorunun yanıtı, istisnaları ve gizli iş kurallarını yönetimle yapılan herhangi bir toplantıdan daha çok ortaya çıkarır. Üzerinde anlaşılanları ayrı tutanaklara değil, dokümanın kendisine yazın.

Kim onaylar?

Her bölümü kimin onaylayacağını belirleyin: Karar verici kapsamı ve öncelikleri, her sürecin sahibi de o sürecin kurallarını ve istisnalarını onaylar. Onaylanmış bir gereksinim, toplantıda laf arasında yapılan bir yorumla değil, yazılı bir değişiklik talebiyle değişir. Karar verici henüz belli değilse, “Bir yazılım projesine başlamadan önce beş soru” başlıklı makalemiz onu belirlemenize yardımcı olabilir.

Her gereksinimin onay tarihini ve onu kimin onayladığını kayıt altına alın; böylece iki kişi anlaşamadığında hangi sürümün esas alınacağını herkes bilir.

Kodlama öncesi gereksinim kontrol listesi

• Gereksinimin rolü, eylemi ve nedeni belirten bir kullanıcı hikâyesi var.
• “Hızlı” ya da “kolay” gibi belirsiz kelimeler, test edilebilir bir tanım olmadan kullanılmamış.
• İlgili iş kuralları numaralı listede yazılı ve bu kurallara numaralarıyla atıf yapılıyor.
• Bilinen istisnalar, her birinde ne olması gerektiğiyle birlikte yazılı.
• Her hikâyenin tek tek doğrulanabilen kabul kriterleri var.
• Her hesaplama ya da koşul için girdi ve beklenen çıktı örneği var.
• Kullanılan terimler sözlükte aynı anlamla tanımlı.
• Gereksinimi, onu kullanacak kişiler gözden geçirdi ve karar verici onayladı.

Net bir gereksinim, iki farklı kişinin okuyup ondan aynı şeyi geliştireceği gereksinimdir.

Net gereksinimler özel araçlar değil, yazarken ve gözden geçirirken disiplin gerektirir. Bu çalışma iş analizinin özüdür: ekibinizin bildiklerini, yazılım geliştiricinin tahmin yürütmeden üzerine inşa edebileceği bir metne dönüştürmek. Durumunuzu ITS ekibiyle görüşebilirsiniz; mevcut gereksinimlerinizi kodlamadan önce gözden geçirmek için birlikte keşif toplantısıyla başlayabiliriz.