Gereksinim belirleme: türler, teknikler, kalite

Gereksinim (requirement), sistemin yapması gereken ya da sahip olması gereken bir özelliktir. Projeler en çok burada kaybedilir: yanlış ya da eksik gereksinimle kurulan bir sistem, ne kadar iyi kodlanırsa kodlansın yanlış sistemdir. Analiz evresinin bu ilk adımı üç işten oluşur: gereksinimleri keşfet (elicitation), sınıflandır ve analiz et, yaz (requirements definition). Sınavda gereksinim cümlesi verip türünü sorarlar, bir senaryo verip “hangi toplama tekniği” diye sorarlar.

Altın kurallar:

1. Functional = ne yapar. Nonfunctional = ne kadar iyi, hangi koşulda yapar.
2. Nonfunctional dört türdür: operational, performance, security, cultural and political.
3. Ölçülemeyen gereksinim test edilemez. “Hızlı” yerine “2 saniyede”.
4. Teknik seçimi soruya bağlı: derin bilgi mi, geniş bilgi mi, ortak karar mı, gerçek davranış mı?

Gereksinim türleri

Functional requirements

Sistemin gerçekleştirmesi gereken bir işlemi ya da sunması gereken bir bilgiyi tanımlar.

• Process-oriented: “Sistem, üye kapıdan geçtiğinde üyeliğin geçerli olup olmadığını kontrol etmelidir.”
• Information-oriented: “Sistem her üyenin son 12 aylık ziyaret geçmişini tutmalıdır.”

Nonfunctional requirements

Sistemin işlevi değil, davranış özellikleri ve kısıtlarıdır.

TUZAK · iş kuralı functional’dır. “Siparişler en az 100 TL olmalı” bir kısıt gibi görünür ama sistemin işleyişini tanımlar: functional. “Sayfa 2 saniyede açılmalı” ise nonfunctional’dır. Sorulacak soru: “Bu, sistemin yaptığı bir iş mi, yoksa işi yapma kalitesi mi?”

Requirements definition

Gereksinimler numaralı bir listede toplanır, functional ve nonfunctional ayrı başlıklarda, önceliğiyle birlikte:

1. Functional
 1.1 Sistem musteri siparis verebilmeli.
 1.2 Musteri siparis durumunu gorebilmeli.
2. Nonfunctional
 2.1 Operational
   2.1.1 Android 10+ ve iOS 15+.
 2.2 Performance
   2.2.1 Menu 2 sn icinde yuklenmeli.

Bu numaralar izlenebilirlik (traceability) içindir: her gereksinim daha sonra bir use case’e, bir sınıfa ve bir test case’e bağlanır.

İyi bir gereksinimin özellikleri

Analiz stratejileri

Gereksinimleri toplarken analist mevcut süreci ne kadar değiştireceğine karar verir:

Kısa tanımlar: duration analysis sürecin toplam süresini adımların süre toplamıyla karşılaştırır (fark büyükse bekleme var). Activity-based costing her adımın maliyetini hesaplar. Informal benchmarking başka kurumların aynı işi nasıl yaptığına bakar. Outcome analysis müşterinin asıl istediği sonucu sorar. Activity elimination her adım için “bunu tamamen kaldırsak ne olur?” diye düşünür.

Gereksinim toplama teknikleri

Görüşme (interview)

En yaygın tekniktir. Beş adım: kimle görüşüleceğini seç, soruları hazırla, görüşmeye hazırlan, görüşmeyi yap, sonrasında rapor yaz (genelde 48 saat içinde).

Yapı: Structured (sorular önceden yazılı, sırayla) ya da unstructured (genel çerçeve, sohbet akışı). Sıra: Top-down (genelden özele) ya da bottom-up (özelden genele).

JAD (joint application development)

Kullanıcılar, yöneticiler ve analistler bir araya gelip gereksinimleri birlikte çıkarır. 10-20 kişi, bir facilitator, bir scribe. Oturumlar yapılandırılmıştır, karar oturumda alınır. Avantajı: farklı görüşler aynı anda çatışır ve uzlaşılır, süre kısalır. Zorluğu: pahalı (herkesi aynı anda toplamak), grup içinde baskın kişiler ya da sessiz kalanlar. e-JAD bu sorunu anonim elektronik katılımla azaltır.

Anket (questionnaire)

Çok sayıda kişiye aynı sorular. Ucuz ve geniş, ama derinlik yok ve dönüş oranı düşük olabilir. İpuçları: önce küçük bir grupla dene (pilot), soruları kısa ve tarafsız tut, en önemli soruları başa koy, katılımcıya sonucun nasıl kullanılacağını söyle.

Gözlem (observation)

Analist süreci yerinde izler. İnsanların söylediğiyle yaptığı farklı olabilir; gözlem gerçeği gösterir. Zayıf yanı Hawthorne etkisi: izlendiğini bilen kişi farklı davranır. Ayrıca sadece o an olanı görürsün, ay sonu kapanışı gibi seyrek olaylar kaçar.

Belge analizi (document analysis)

Formlar, raporlar, kılavuzlar, eski sistemin ekranları incelenir. Resmi sistemi (formal system) gösterir. Asıl ipucu, belgenin gerçek kullanımıdır: boş bırakılan alanlar, elle eklenen sütunlar, kenara yazılan notlar informal system’i ortaya çıkarır.

Teknik seçimi

Gerçek projede teknikler birleştirilir: önce belge analizi ile resmi süreci öğren, sonra kilit kişilerle görüş, geniş kitleyi ankete al, şüpheli noktaları gözlemle doğrula, son kararları JAD’de ver.

Çözümlü örnek: kampüs kütüphanesi

Durum: Kütüphane yeni bir rezervasyon sistemi istiyor. 25,000 öğrenci, 12 personel, 3 şube.

Adım 1: Strateji. Müdür “aynı süreç, sadece online” diyor ama öğrenciler bekleme süresinden şikâyetçi. Duration analysis: ödünç işleminin adımları toplam 4 dakika, ama öğrenci ortalama 18 dakika bekliyor. Fark kuyrukta. Bu BPI’ya işaret eder: süreci online ön rezervasyonla iyileştir.

Adım 2: Teknikler.

Adım 3: Gereksinim yaz.

• F1. Öğrenci müsait bir kitabı en fazla 48 saat için rezerve edebilmeli. (functional)
• F2. Rezervasyon süresi dolunca kitap otomatik olarak serbest kalmalı. (functional)
• N1. Rezervasyon onayı 3 saniye içinde gösterilmeli. (performance)
• N2. Sadece personel ceza kaydını silebilmeli. (security)
• N3. Sistem üniversitenin tek oturum açma (SSO) sistemine bağlanmalı. (operational)

Sık yapılan hatalar