Kapsamli Bir Analiz Yontemi: Volere

Hafta sonu ODTÜ'nün kütüphanesinden Suzanne ve James Robertson'ın "Mastering The Requirements Process" adlı kitabını almıştım. Çok güzel bir kitap. Özellikle yazılım sektöründen çıkılarak yazılmış olmakla birlikte, yeni bir sistem veya ürün geliştirme işiyle uğraşan herkese öneririm.

Yöntem anlatan kitapların ne yazık ki az bir kısmı faydalı bir bilgi veriyor. Pek çok kitap ya çok detaya gömülmüş, ya da işe yarar bilgiler içermeyen çok genel ve muğlak bir anlatıma sahip. Robertson'ların kitabı bu yönlerden çok iyi. Hem kapsayıcı bir teoriyle, analiz işinin bütününün resmini gösteriyor. Hem de çok fazla örneklerle anlatımı zenginleştirerek, ne demek istendiğini çok net bir şekilde somutlaştıyor.

Kitap Volere adını verdikleri bir analiz yöntemini anlatıyor. Bu yöntem, bir sistemin gereksinim analizini yaparken, hem izlemeniz gereken süreci adım adım anlatıyor, hem de nihai olarak üretilecek gereksinim spesifikasyon (requirements specification) dokümanının içeriğine yönelik bir şablon sunuyor. Anlatılan süreç, bu dokümanın içeriğine ait bilgilerin hangi aşamalarda nasıl toplanacağını gösteriyor.

Buraya önerdikleri gereksinim spesifikasyon dokümanının şablonunu Türkçe olarak aktarıyorum. (Umarım yazarlar bundan dolayı şikayetçi olmazlar :))

Sistem Kısıtlamaları - tüm sistemi belirleyen kısıtlamalar
1 Sistemin amacı - sistemi geliştirme amacı ve sağlayacağı iş faydası
2 Müşteri ve diğer paydaşlar - sistemle ilgisi olan kişiler
3 Sistemin kullanıcıları - son kullanıcılar
4 Gereksinim kısıtlamaları - çözüme ait kısıtlamalar
5 İsimlendirme uzlaşıları ve tanımlar - terimlerin net anlamları
6 İlgili veriler - sistem üzerinde etkisi olan, dış dünyaya ait veriler
7 Varsayımlar - proje ekibinin yaptığı varsayımlar
Fonksiyonel Gereksinimler - sistemin davranışına ait gereksinimler
8 Sistemin kapsamı - sistemin ele aldığı iş olaylarının sınırı ve yan sistemler/aktörler
9 Fonksiyonel ve veri gereksinimleri - sistemin yapması gereken işlevler ve tutması gereken kayıtlar
Fonksiyonel Olmayan Gereksinimler - sistemin davranış dışı özellikleri
10 Görünüm gereksinimleri - amaçlanan görünüm
11 Kullanışlılık gereksinimleri - son kullanıcıların sistemi kullanabilmesi için gereken özellikler
12 Performans gereksinimleri - ne kadar hızlı ve ne kapasitede
13 Operasyonel gereksinimler - sistemin kullanılacağı fiziksel ortamın gerektirdiği özellikler
14 Bakım ve taşınabilirlik gereksinimleri - sistemin ne kadar değişime uygun olduğu
15 Güvenlik gereksinimleri - sistemin güvenliği, gizliliği ve ürettiği verilerin doğruluğu
16 Kültürel ve politik gereksinimler
17 Yasal gereksinimler - kanunlara uygunluk
Diğer Proje Konuları
18 Açık noktalar
19 3. parti çözümler
20 Yeni sorunlar - sistemin işler hale gelmesiyle ortaya çıkacak sorunlar
21 Productiona geçiş için gerekli işler
22 Geçiş süreci - mevcut sistemden geçiş için yapılması gereken işler
23 Riskler - projenin karşılaşması muhtemel riskler
24 Maliyetler - projeyi geliştirme maliyetine dair ilk tahminler
25 Kullanıcı dokümantasyon planı - kullanıcılara yönelik kılavuzları geliştirme planı
26 Bekleyen gereksinimler - gelecek sürümlere eklenebilecek gereksinimler

Yazarlar, bu gereksinimlerin nasıl toplanacağına yönelik çok detaylı bir süreç tarif ediyorlar. Her bir gereksinimin toplanmasında dikkat edilecek noktalara ve yardımcı olacak araçlara değiniyorlar.

Kitapta bahsedilen gereksinim toplamada kullanılan araçlardan biri, yazarların Requirement Shell olarak adlandırdıkları, benim Gereksinim Kartı diye çevirdiğim bir araç. Her gereksinim, ilk akla geldiğinde bu karta yazılıyor. Kartta şu alanlar bulunuyor:

Gereksinim Kartı
Başlık:
Gereksinim No:
Gereksinim Tipi:
Olay/Use Case No:
Açıklama:
Gerekçe:
İlk Bildiren:
Kabul Kriteri:
Müşteri Memnuniyeti:
Müşteri Memnuniyetsizliği:
Bağımlılıklar:
Çatışmalar:
Kaynaklar:
Tarihçe:

Bütün bu alanların gereksinimin ilk kaydedildiği anda doldurulması gerekmiyor. Sadece gereksinimi unutmamak önemli olan. Gereksinimin bağlı olduğu olay ve use case numaralarıyla ilişkileri burada kaydedilerek, bütün gereksinim analizi, iş olaylarının ve use caselerinin etrafında yapılandırılıyor.

Kullanılacak analiz sürecini yazarlar çok kapsamlı olarak tarif ediyorlar. Ben biraz bunu oldukça basitleştirerek kendime göre bir süreç çıkardım. O da şu şekilde:

Analiz Süreci

• Proje Tanımlama
• Bilgi Toplama (Her bir use case için tekrarla)
• Use case yazımı
• Normal akış
• Extension points
• Alternatiflerin yürütülmesi
• Fonksiyonel olmayan gereksinimler
• Kabul kriterleri
• Prototip
• Gereksinimlerin yazılması
• Kalite denetimi

Sanırım burada yazdığım başlıklar belki ilk bakışta pek anlamlı görünmeyecektir. Ancak resmin bütününü tek bir blog yazısında göstermek istediğimden detaylara giremiyorum. Umarım ilerideki yazılarımda fırsat buldukça bunların detaylarına girebilirim. Ancak bu arada siz eğer bulabiliyorsanız kitabı okuyabilir veya http://www.volere.co.uk/ adresinden daha detaylı bilgi alabilirsiniz.