Requirement Nedir ve Neden Yanlış Anlaşılır? Türler, İyi Requirement'ın Özellikleri ve Problem ile Çözümü Ayırmak

Sürüm notu: Bu yazı kavramsaldır; requirement tanımı ve iyi requirement'ın nitelikleri için ISO (International Organization for Standardization), IEC (elektroteknik standartları yayımlayan uluslararası kuruluş) ve IEEE'nin (Institute of Electrical and Electronics Engineers) ortak standardı ISO/IEC/IEEE 29148:2018, requirement seviyeleri için IIBA'nın (International Institute of Business Analysis) BABOK (Business Analysis Body of Knowledge) Guide v3'ü esas alınmıştır.

Önce Tahmin Et

Haziran sonu. Bookstore'un kurumsal satış müdürü Hakan, Product Owner Selin'e kısa bir e-posta atıyor: "Okullar ve kütüphaneler için Excel'den sipariş yükleme ekranı istiyoruz. Eylül başına yetişmesi lazım, okullar o zaman sipariş veriyor." Selin e-postayı ekibe iletiyor. Backend tarafındaki Emre işi okuyup tahminini söylüyor: "Dosya upload, satırları parse et, sepete ekle. Üç gün."

Üç gün sonra ekran hazır. Hakan ilk denemede bir okulun gönderdiği dosyayı yüklüyor ve ekran hata veriyor: dosyada ISBN yok, yalnızca kitap adları ve sınıf şubeleri var. İkinci dosyada ISBN'ler tireli, üçüncüsünde aynı kitap dört farklı satırda, her şube için ayrı. Hakan "bunlar bizim her eylül aldığımız dosyalar" diyor.

Okumaya devam etmeden düşün: Hakan'ın e-postasında bir requirement var mı? Varsa hangi cümle? Emre koda başlamadan önce hangi üç soruyu sorsaydı bu üç gün boşa gitmezdi?

Requirement Nedir?

ISO/IEC/IEEE 29148:2018 requirement'ı "statement which translates or expresses a need and its associated constraints and conditions" diye tanımlar: bir ihtiyacı, ona bağlı kısıtları ve koşulları dile getiren bir ifade. Bu tanımda üç şey dikkat çekiyor. Birincisi, requirement bir ifadedir; ekran, tablo ya da endpoint değildir. İkincisi, merkezinde bir ihtiyaç vardır; ihtiyacı söylemeyen bir cümle requirement değil, bir talimattır. Üçüncüsü, ihtiyaç tek başına yetmez; hangi kısıtlar altında ve hangi koşullarda geçerli olduğu da requirement'ın parçasıdır.

Bu gözle Hakan'ın e-postasına bakınca tek bir ihtiyaç cümlesi bulamıyorsun. "Excel'den yükleme ekranı" bir çözüm. "Eylül başına yetişmeli" bir kısıt. "Okullar o zaman sipariş veriyor" ise bir bağlam bilgisi. İhtiyacın kendisi, yani okulların ve kütüphanelerin sipariş verirken neyi başaramadığı, hiçbir yerde yazmıyor.

Standart iki kelimeyi de birbirinden ayırır ve bu ayrım geliştirici için çok işe yarar. Requirement verification, requirement'ların iyi yazılıp yazılmadığını, yani tek anlamlı, ölçülebilir ve tutarlı olup olmadığını inceleyerek doğrulamaktır. Requirement validation ise bu requirement'ların stakeholder'ların gerçekten istediği sistemi tarif edip etmediğini doğrulamaktır. Emre'nin ekranı iyi yazılmış bir talimatı doğru uyguladı ama yanlış sistemi inşa etti: verification'dan geçen, validation'dan kalan bir iş.

Requirement Seviyeleri: Business'tan Constraint'e

"Requirement" kelimesi farklı ayrıntı seviyelerindeki cümleler için kullanılır ve konuşmaların çoğu, iki kişinin farklı seviyeden konuşmasıyla karışır. Hakan business seviyesinde düşünür, Emre functional seviyede. Seri boyunca izleyeceğimiz özellik, okul ve kütüphanelerin toplu (kurumsal) sipariş vermesi; her seviyenin bu özellikteki karşılığı şöyle:

Seviyeler bir merdiven gibi birbirine bağlanır. Functional requirement'ı neden yazdığını sorduğunda stakeholder requirement'a, onu neden yazdığını sorduğunda business requirement'a çıkarsın. Bir functional requirement hiçbir üst seviyeye bağlanamıyorsa iki ihtimal vardır: ya bir stakeholder ihtiyacını yazmayı unuttun ya da o requirement'a gerek yok. Standart bu yukarı ve aşağı bağlantıyı traceability (izlenebilirlik) diye adlandırır ve requirement yönetiminin parçası sayar.

Constraint ile non-functional requirement sık karıştırılır. Non-functional requirement bir kaliteyi tarif eder ve genellikle bir aralıkta pazarlık edilebilir: 5 saniye yerine 8 saniye kabul edilebilir mi, konuşulur. Constraint ise tasarım alanını daraltan, ekibin seçmediği bir sınırdır: ERP'ye aktarım şartı bir teknik tercih değil, muhasebenin kararıdır. Standart constraint'i yalnız sisteme değil, geliştirme sürecine konan sınırları da kapsayacak şekilde tanımlar; "1 Eylül'den önce" bu yüzden bir constraint'tir.

BABOK bu listeye bir sınıf daha ekler: transition requirement. Bunlar yalnızca eski durumdan yenisine geçerken gereken, geçiş bitince ortadan kalkan ihtiyaçlardır. Bizim örneğimizde geçen yıl Excel'de tutulan kurumsal müşteri listesinin yeni sisteme aktarılması ve müşteri hizmetleri ekibinin yeni ekranlara alıştırılması böyle iki requirement.

Non-functional requirement'ları nasıl ölçülebilir hâle getireceğimizi 06. yazıda, ISO/IEC 25010:2023 quality model'iyle birlikte ayrıntılı göreceğiz. Bu yazıda yalnızca onları ayrı bir seviye olarak tanımak yeterli.

Requirement Neden Yanlış Anlaşılır?

Hakan'ın e-postası özensiz yazılmış değil. Yanlış anlaşılma birkaç yerden birden sızar.

Birincisi, kelimeler iki tarafta farklı şeyler ifade eder. "Toplu sipariş" Hakan için bir kurumun verdiği sipariştir; depo için aynı kitaptan çok sayıda adet demektir; Emre içinse bir sepete çok satır eklemek. Okul tarafında "sipariş" kelimesi bile farklıdır: okul muhasebesi için sipariş, kendi kestiği satın alma emri numaralı bir belgedir, bizim Order kaydımız değil.

İkincisi, insanlar bildikleri şeyi söylemez, çünkü onlar için apaçıktır. Hakan dosyaların şube şube geldiğini yıllardır biliyor; bunu ayrıca yazmak aklına gelmiyor. Bu tür söylenmeyen bilgiyi (tacit knowledge) ortaya çıkarmak bir sonraki yazının konusu.

Üçüncüsü, insanlar ihtiyaçlarını çözüm diliyle anlatır. "Excel'den yükleme ekranı" Hakan'ın problemi kendi bildiği bir araçla tarif etme şekli. Ekip bu cümleyi requirement diye okursa tasarım kararı daha ilk gün verilmiş olur.

Dördüncüsü, bilgi aracılar üzerinden gelir. Okulun satın alma sorumlusu ihtiyacını Hakan'a anlatır, Hakan Selin'e yazar, Selin ekibe iletir. Her aktarımda biraz bağlam düşer, biraz yorum eklenir. Emre'nin okuduğu cümle, ihtiyacın sahibinin söylediği cümle değil.

İyi Requirement'ın Nitelikleri

ISO/IEC/IEEE 29148:2018 tek bir requirement'ın taşıması gereken dokuz nitelik ve bir requirement kümesinin bütün olarak taşıması gereken beş nitelik sayar. Standardın metnini aktarmak yerine, en çok işe yarayanları geliştiricinin kendine soracağı sorulara çevirelim:

Kalan üç nitelik daha çok yazım disiplinine ilişkin: requirement bulunduğu seviyeye uygun ayrıntıda olmalı (business requirement'ta veritabanı tablosu geçmemeli), anlaşılmak için gereken her bilgiyi içermeli ve ekibin kabul ettiği yazım kalıbına uymalı.

Küme seviyesindeki nitelikler başka bir şeyi yakalar: tek tek kusursuz requirement'lar bir araya geldiğinde çelişebilir ya da bir boşluk bırakabilir. Depo "her sipariş tek sevkiyatta çıkar" der, kütüphane "her şubeye ayrı teslimat" ister; iki cümle de tek başına tek anlamlı ve doğrulanabilir, ama birlikte tutarsız. Bir requirement setinin tutarlı, eksiksiz, bütün olarak uygulanabilir, anlaşılır ve stakeholder'larla doğrulanabilir olması beklenir. Bu yüzden requirement'ları tek tek değil, ilgili olanları yan yana okuyarak review edersin.

Belirsiz Kelime Avı

Tek anlamlılığı sağlamanın en pratik yolu, belirsizlik taşıyan kelimeleri metinde aramaktır. Bir requirement metnini review ederken şu kelimelerin her birinin altını çiz ve her birine "ne kadar, kim karar verir, hangi durumda?" diye sor: "hızlı", "kolay", "kullanıcı dostu", "esnek", "gerekirse", "mümkün olduğunca", "uygun", "vb.", "destekler", "yeterli", "büyük", "ve/veya".

Bookstore'un ilk taslağından üç cümleyi bu gözle yeniden yazalım.

"Sistem büyük listeleri hızlı işlemeli." Burada iki belirsiz kelime var. Elicitation'da en büyük okul listesinin 900 satır civarında olduğunu öğrendiğini varsay; cümle "1.000 satıra kadar bir listenin doğrulama sonucu, normal yük altında 5 saniye içinde gösterilir" olur. "Normal yük"ün ne demek olduğunu da 06. yazıda ölçülebilir hâle getireceğiz.

"Gerekirse muhasebe onayı alınır." Kim karar veriyor, gerekli olup olmadığına? Okul muhasebesiyle konuşunca kuralın bir tutar sınırına bağlı olduğu ortaya çıkıyor: "Sipariş tutarı kurumun tanımladığı onay limitini aşıyorsa sipariş 'Onay Bekliyor' durumunda bekler ve kurumun muhasebe yetkilisi onaylayana kadar hazırlanmaz."

"Kurumsal siparişlerde minimum 20 adet şartı vardır." Bu cümle masum görünür ama en az üç okuması var: siparişin toplamı mı 20 adet olmalı, her kitaptan mı 20 adet, yoksa her şube için mi? 20 adet tam sınırda geçerli mi? Bu sorunun cevabını burada uydurmuyoruz; açık soru listesine yazıyoruz. Bu tür kural sorularını örneklerle netleştirmek 05. yazının, Example Mapping'in işi.

Bir uyarı: yerine konan sayı da bir yerden gelmeli. "5 saniye" ekibin uydurduğu bir sayıysa cümle tek anlamlı olur ama doğru olmaz.

Problemi Çözümden Ayırmak: "Excel'den Yükleme Ekranı"

Selin, Emre'nin ekranı başarısız olduktan sonra Hakan'la ve müşteri hizmetlerinden Gül'le yarım saatlik bir görüşme ayarlıyor. Soruların hiçbiri ekranla ilgili değil:

"Geçen eylül bir okulun siparişi size nasıl ulaştı, baştan anlatır mısın?" Gül anlatıyor: okul, öğretmenlerin hazırladığı listeleri birleştirip e-postayla gönderiyor; dosyaların biçimi okuldan okula değişiyor; Gül her satırı katalogda arayıp sepete ekliyor. Ortalama 240 satırlık bir liste yarım gününü alıyor. Geçen eylül 46 kurumsal sipariş gelmiş; 11'inde yanlış ISBN yüzünden en az bir yanlış kitap gönderilmiş.

"Bu iş bugün yapılmasa ne olur?" Hakan cevaplıyor: eylülün ilk iki haftasında kurumsal siparişler birikiyor, bazı okullar beklemeyip başka bir tedarikçiye gidiyor.

Artık problem cümlesi yazılabilir: "Kurumların kitap listeleri bize farklı biçimlerde ulaşıyor ve müşteri hizmetleri bunları elle sisteme giriyor. Bu iş liste başına yarım gün sürüyor, eylül yoğunluğunda siparişler birikiyor ve geçen dönem her dört siparişten birinde yanlış kitap gönderildi." Bu cümlede Excel geçmiyor. Excel'den yükleme hâlâ olası çözümlerden biri, ama artık yanında başkaları da var: satın alma sorumlusunun ISBN ve adet sütunlarını bir metin kutusuna yapıştırması, kurumun geçen yılki siparişini kopyalayıp üzerinde değişiklik yapması, müşteri hizmetlerine hızlı bir ISBN doğrulama aracı vermek.

Problem tanımı ve hipotez formatını Product Management'a Giriş serisinin "Output Değil Outcome" yazısında konuşmuştuk; burada aynı fikrin requirement tarafına bakıyoruz. Çözüm cümlesini atma, yukarı doğru takip et: "Bu ekran olsaydı ne değişirdi? O değişiklik kimin işine yarardı?" İkinci ya da üçüncü "neden"de genellikle asıl ihtiyaca varırsın. Hangi çözümün seçileceği ise ürün kararıdır; requirement'ın görevi, o kararı problemin dilinde verilebilir kılmaktır.

Developer'ın Requirement Sürecindeki Rolü

Requirement işini business analyst'e ya da Product Owner'a bırakmak cazip. Ama requirement'taki boşlukların çoğunu en erken fark eden kişi, onu koda dökmeye çalışan kişidir. UML (yazılım modellemede kullanılan standart diyagram dili) ve Modeling serisinin "Requirement'tan Diyagrama" yazısında, "gün" kelimesinin takvim günü mü iş günü mü olduğu sorusunun bir class'a attribute adı verirken ortaya çıktığını görmüştük. Kod belirsizliğe tahammül etmez.

Developer bu süreçte dört şey getirir: edge case soruları ("Aynı ISBN iki satırda geçerse? Stokta 30 varken 50 istenirse?"), maliyet ve uygulanabilirlik bilgisi ("ERP'ye anlık yazmak altı hafta, gece aktarımı iki gün"), daha ucuz alternatifler (dosya upload yerine bir yapıştırma kutusu) ve kayıt disiplini: verilen cevabı, cevabı vereni ve tarihi requirement'ın yanına yazmak.

Son madde traceability'nin hafif ama yeterli bir hâlidir. Her requirement'a kısa bir kimlik ver (REQ-BULK-03 gibi) ve bu kimliği ilgili story'de, test adında ve commit mesajında kullan. Ağır bir traceability matrix'i her proje için gerekmez; ama altı ay sonra "bu kontrol neden var?" sorusuna bir arama ile cevap verebilmek gerekir.

Üretimde Dikkat

Requirement'lar değişir; değişmesi bir başarısızlık değil, öğrenmenin işaretidir. Sorun, değişikliğin iz bırakmamasıdır. Hakan bir toplantıda "aslında okullar şube bazında ayrı fatura istiyor" dediyse, bu cümle bir sohbet kanalında kalmamalı; requirement'ın yeni sürümü olarak, kim söyledi ve ne zaman söyledi bilgisiyle kaydedilmeli.

Her requirement'ın bir sahibi olmalı: soruya kim cevap verir? Toplu siparişte indirim kuralının sahibi kurumsal satış, onay limitinin sahibi kurumun kendisi, ERP aktarımının sahibi Bookstore muhasebesi. Sahibi belli olmayan requirement'ta geliştirici boşluğu kendi tahminiyle doldurur ve bu tahmin production'da bir kural hâline gelir.

Sık Düşülen Tuzaklar

İlk tuzak requirement'ı ekran listesi sanmak. "Kurumsal sipariş ekranı, onay ekranı, fatura ekranı" bir requirement seti değil, bir tasarım taslağıdır. Ekran listesinde kurallar, kısıtlar, kalite beklentileri ve ekranı olmayan davranışlar (gece ERP aktarımı, onay limiti aşılınca bekleme) görünmez.

İkinci tuzak geç bulunan yanlış anlaşılmanın maliyetini kesin rakamlarla anlatmak. "Requirement aşamasında bulunan hata 1 birim, production'da 100 birim tutar" grafiği sunumlarda çok dolaşır ve genellikle IBM Systems Sciences Institute'a atfedilir. Laurent Bossavit'in "The Leprechauns of Software Engineering" kitabında ve sonraki yazılarında izini sürdüğü üzere bu rakamın arkasında yayımlanmış bir çalışma bulunamadı; kaynak olarak gösterilen kurum bir iç eğitim programıydı ve rakam büyük ölçüde Roger Pressman'ın 1987 tarihli ders kitabındaki ders notu atfı üzerinden yayıldı. Geç bulunan hatanın daha pahalı olabileceği fikri makul, ama çarpanı kesin bilgi gibi vermek yanlış. Argümanını kendi projenin verisiyle kur: Bookstore'da geçen eylül 11 siparişte yanlış kitap gitmesi, bir grafikteki "100 kat"tan daha ikna edicidir.

Üçüncü tuzak çözümü requirement diye kabul etmek. "Excel'den yükleme" cümlesini olduğu gibi backlog'a yazarsan, ekip doğru dosya parser'ını yazmak için harika bir iş çıkarır ve problem yerinde kalır.

Dördüncüsü "müşteri ne istediğini biliyor" varsayımı. Müşteri problemini iyi bilir; kendi işinin istisnalarını ise ancak sorulunca hatırlar. Requirement bir kerede teslim alınan bir paket değil, konuşarak inşa edilen bir anlaşmadır.

Küçük Bir Deneme

★☆☆ Ekibinin backlog'undan son eklenen beş item'ı al ve her birini bu yazıdaki seviyelerden birine etiketle: business, stakeholder, functional, non-functional, constraint ya da transition. Hangi seviyenin hiç temsil edilmediğine bak.

★★☆ Bir requirement metninde (bir PRD (ürün gereksinimleri dokümanı), bir Jira açıklaması, bir e-posta) belirsiz kelime avı yap. En az beş kelimeyi işaretle ve her biri için "ne kadar, kim karar verir, hangi durumda?" sorusunu yaz. Cevabını bilmediklerini bir açık soru listesine koy ve yanına kime soracağını ekle.

★★★ Sana bir çözüm cümlesiyle gelmiş son talebi düşün ("şu ekranı ekleyin", "şu raporu verin"). Talep sahibiyle konuşmadan önce, aklındaki problemi bu yazıdaki biçimde bir problem cümlesi olarak yaz; sonra talep sahibine "geçen sefer bu iş nasıl oldu?" diye sorup kendi cümleni onun anlattığıyla karşılaştır. İki cümle arasındaki fark, senin varsayımların listesidir.

Requirement'ı tanımladık, seviyelerini ayırdık ve iyi bir requirement'ın neye benzediğini gördük. Ama Hakan'ın e-postasındaki boşlukları doldurmak için Selin'in yarım saatlik görüşmesi yetmeyecek. Bir sonraki yazıda elicitation'a geçiyoruz: stakeholder haritası, görüşme, gözlem, workshop ve prototip ile toplu siparişin gerçek ihtiyacını nasıl ortaya çıkaracağımızı göreceğiz.