Yazılımda Gereksinim Analizi Nedir?

Yazılım sistemleri kompleks sistemlerdir. Bu yüzden, yazılım geliştirme sürecinde en önemli uğraşlardan biri karmaşıklık ve değişim ile başa çıkabilmektir.

Ama öncelikle yazılım mühendisliğinin ve bir yazılım mühendisinin uğraşının ne olduğuna bakalım.

Yazılım mühendisliği bir modelleme, problem çözme ve bilgi edinme faaliyetidir.

Genellikle en başta elimizde uygulama alanı belli bir problem vardır. Geliştirme sürecinde yazılım mühendisleri sistemin ve uygulama alanının (application domain) bir çok modelini oluşturur. Modellemeyi, henüz geliştirilmemiş bir sistemin soyut bir projesi olarak düşünebiliriz. Uygulama ve çözüm alanının (solution domain) modelleri oluşturulurken, yazılım geliştiriciler veri toplar ve bilgiyi organize eder. Bu bilgi edinme ve daha sonrasında gelen, sistem hakkında karar verme sürecinde bu kararları bir gerekçeye dayandırmalıdır. Daha sonra oluşturulan modeller, problemimize uygun bir çözüm bulmak için kullanılır. Bulduğumuz bu çözüm karmaşıklık sorununu ortadan kaldırırken aynı zamanda sisteme getirilecek değişikliklere de direnmeyecek şekilde tasarlanmalıdır.

O zaman ilk önce karmaşıklık ile başa çıkmamızı sağlayacak nesne yönelimli analiz ve dizayn adımlarının neler olduğuna bakalım:

• Gereksinim analizi (veya gereksinim çözümleme)
• Analiz
• Sistem Dizaynı
• Nesne Dizaynı
• İmplementasyon
• Test

Bu yazıda ilk adım olan gereksinim analizini anlatmaya çalışacağım.

Gereksinim analizi, bir yazılım sistemi geliştirme sürecinde takip edilmesi gereken ilk adımdır. Temel amacı sistemin amacını ve gereksinimlerini belirlemektir.

Not: Bu yazıda nesne yönelimli analiz ve dizayn ele alınacak.

Burada yazılım mühendisinin, gereksinim analizi yaparken sistemin dahilinde olan uygulama alanı (application domain) ve son kullanıcıların (veya müşterilerin) istekleri ve gereksinimleri hakkında bilgi sahibi olması gerekir.

Genellikle sistemin hitap edeceği kullanıcılar veya müşteriler kendi alanlarında uzmandır ve sistemin ne yapması gerektiği hakkında bilgi sahibidirler. Fakat yazılım geliştirme hakkında bilgileri yoktur veya azdır. Diğer yandan, yazılım mühendisleri yazılım geliştirme süreçleri, metotları ve metodolojileri gibi teknik konulara hakimken uygulama alanı veya sistem gereksinimlerini tam olarak belirlemek noktasında eksik olabilirler.

İşte bu noktada gereksinim analizi, bir yazılım sistemi geliştirme sürecinde, geliştirici ve kullanıcı (veya müşteri) arasında ki bu boşluğu kapatmada önemli bir adımdır.

Gereksinim analizi yapılırken ilk önce sistemin olası kullanımlarını örneklendiren senaryolar ve bu senaryoların soyut bir gösterimi olan use case’ler oluşturulmalıdır. Bu adımlar müşteri ve geliştiricinin anlaşabilmesi adına tamamen doğal, günlük ve teknik olmayan bir dille yapılmalıdır.

Örneğin bu adımda; sistem fonksiyonları, kullanıcı ve sistem etkileşimi, sistemde karşılaşılabilecek hatalar ve bu hataların nasıl ele alınacağı gibi şeyler belirtilebilecekken sistem yapısı veya mimarisi, sistemi geliştirirken kullanılacak teknolojiler, geliştirme metot ve metodolojileri belirtilmez. Çünkü bu gereksinimler genellikle kullanıcının geliştiriciyle direkt olarak anlaşabileceği özellikler değildir.

Peki gereksinim analizi adımlarında neler yapılmalıdır?

• Aktörlerin belirlenmesi
• Senaryoların oluşturulması
• Use Case’lerin oluşturulması ve geliştirilmesi
• Aktörler ve Use Case’ler arasındaki ilişkilerin belirlenmesi
• Analiz Objelerinin belirlenmesi
• Fonksiyonel Olmayan gereksinimlerin belirlenmesi

Aktörlerin Belirlenmesi

Aktörler, geliştirilen sistem ile etkileşime geçebilecek varlıkları temsil eder. Bu varlık bir insan veya başka bir sistem olabilir. Her rolün işlevselliği (functionality) farklıdır.

İlk adım olarak aktörlerin belirlenmesi, sistem sınırlarının belirlenmesi için de önemli bir adımdır. Sistem sınırlarının belirlenmediği durumlarda ise, aktörler ve nesneler veya sistem bileşenleri ve alt sistemleri birbirinden ayırt etmek zorlaşabilir. Alt sistemler ve nesneler sistem sınırlarının içinde yer alırken, aktörler ve sistem bileşenleri sistem sınırlarının dışındadır. Örneğin, geliştirilen sistemi kullanacak olan başka bir yazılım bir aktördür.

Aktörleri belirlerken şu soruları sorabiliriz:

• Sistemimiz hangi kullanıcı gruplarını destekliyor?
• Ana fonksiyonları hangi kullanıcı grupları gerçekleştirir?
• Sistem bakımı ve yönetimi gibi ikincil fonksiyonları hangi kullanıcı grupları gerçekleştirir?
• Sistem hangi harici donanım veya yazılım sistemleriyle etkileşime girecek?

Örneğin bir bankacılık uygulaması için kullanıcı (şahıs), şirket, banka, veri tabanı sistemleri birer aktör olabilir.

Senaryoların Oluşturulması

Aktörler belirlendikten sonra bir sonraki adım senaryoların oluşturulmasıdır. Burada amaç her bir aktörün gerçekleştirebileceği fonksiyonların ortaya çıkarılmasıdır.

Bir senaryo sistemin tek bir özelliğini kullanıcı gözünden anlatır. Tüm olası durumları açıklamaz.

Gereksinim analizinde, geliştiriciler ve kullanıcılar, sistemin ne olması gerektiğine dair ortak bir karar elde etmek için bir çok senaryo yazar ve düzenler. İlk başta bu senaryolar çok soyut ve eksik olabilir. Bu süreç iteratif olarak ilerleyerek, tamamlanmış ve somut senaryolar elde edilir.

Peki bu senaryoları elde edebilmek için hangi soruları sormalıyız?

• Aktörlerin, sistemin gerçekleştirmesini istediği fonksiyonlar nelerdir?
• Aktör hangi verilere erişebiliyor? Bu verileri kim oluşturuyor? Bu veriler değiştirilebilir veya kaldırılabilir mi? Eğer evet ise, kim tarafından değiştirilebilir veya kaldırılabilir?
• Aktörün, sistemi hangi harici değişikliklerden haberdar etmesi gerekiyor?
• Sistemin aktörü hangi olaylar hakkında, ve hangi gecikme ile bilgilendirmesi gerekiyor?

Geliştirici, bu senaryoları her zaman uygulama alanı (application domain) dilini, terimlerini kullanarak yazmalıdır. Bu nedenler, geliştirici uygulama alanı hakkında daha ayrıntılı bilgi edindikçe senaryolar iyileşecek ve daha çok detay eklenecektir.

Aktörler ve senaryolar belirlendikten sonra, use case’lerin belirlenmesine geçilir.

Use Case’lerin Oluşturulması

Bir use case belli bir fonksiyon için tüm olası senaryoları belirtir. Bir senaryoyu bir use case’in örneği (instance) olarak düşünebiliriz. Use case’i bir aktör başlatabilir ve devamında farklı aktörler de etkileşime girebilir.

Yani kısaca bir use case, sistemin başlatılması ile tetiklenen bir dizi etkileşimi tanımlayarak sistemdeki olay akışını temsil eder.

Use case’lerin hangi bölümlerden oluştuğuna bakalım;

Use Case Adı: Use case ismi aktörün ne yapmaya çalştığını anlatan bir fiil yada fiil grubu olmalıdır.

Katılımcı Aktörler: Aktörler bir isim veya isimlerden oluşan sözcük grupları olmalıdır.

Olay Akışı: Olay akışında yazılan her bir adımda, bu adımı kimin gerçekleştirdiği açıkça belirtilmelidir. Adımlar arasındaki nedensellik açık olmalıdır.

Bir use case, bir kullanıcı aktivitesini (fonksiyonunu) eksiksiz bir şekilde açıklıyor olmalı. İstisna durumları ayrıca belirtilmelidir.

Use case’ler de kullanıcı arayüzleri açıklanmaz. En fazla iki-üç sayfayı geçmemelidir.

Sistemin fonksiyonalitesini açıklamak için senaryoların ve use case’lerin kullanılması aslında geliştirme sürecinin başlarında kullanıcı tarafından belirlenen gereksinimlerin oluşturulması içindir. Sistemin dizayn ve implementasyonu başladığında daha bir çok gereksinim ortaya çıkacak ve eklenecektir. Bu süreçte yazılan use case’ler yeniden yazılabilir, değiştirilebilir veya tamamen silinebilir. Bu süreç lineer değil iteratif ilerleye bir süreçtir.

Aktörler ve Use Case’ler Arasındaki İlişkilerin Belirlenmesi

Aktörler ve use case’ler arasındaki ilişkilerin belirlenmesi, modelin karmaşıklığının azaltılmasını ve anlaşılabilirliğinin artırılmasını sağlar.

• <<initiate>> ilişkisi, use case’in bir aktör tarafından başlatıldığını belirtir.
• <<participate>> ilişkisi, bir aktörün use case ile iletişim kurduğunu belirtir.

Bunların dışında use case’ler arasında, use case’lerin daha iyi anlaşılabilmesi için kullanılan diğer ilişkiler de vardır.

• <<extend>> ilişkisi istisnai veya ortak olan olay akışlarını ayırmak için kullanılır. İstisnai ve ortak olay akışlarını temel use case’den ayırmanın avantajı temel use case’in daha anlaşılır hale gelmesi ve geliştiriciye her fonksiyonaliteyi ayrı olarak ele almasına olanak sağlamasıdır. Hem extend eden, hem de extend edilen use case’ler kendi içlerinde ayrı olarak tanımlanmış, giriş ve çıkış durumları belirtilmiş use caseler olmalıdır.
• <<include>> ilişkisi use case’ler arasındaki fazlalığı azaltmak için kullanılır. Örneğin, iki use case’de de kullanılan ortak bir use case <<include>> ilişkisi ile belirtilebilir.

Analiz Objelerinin Belirlenmesi

Şu ana kadar ki amacımız, kullanıcı ve geliştirici arasındaki terminoloji farkından oluşan açıklığı kapatabilmekti. Fakat bu sorun sisteme yeni bir geliştirici dahil olduğun onun için hala geçerli olacak olan bir sorundur.

Bu yüzden projeye hali hazırda devam eden geliştiriciler bu sorunun önüne geçebilmek için, her bir use case için bir sözlük oluşturur.

Böylece ilk analiz nesne modeli oluşur. Analiz nesnelerinin tam olarak belirlenmesi Analiz adımında gerçekleşir. Bu yazıda sadece Gereksinim Analizi adımına odaklandığımız için Analiz adımı yer almıyor.

Fonksiyonel Olmayan Gereksinimlerin Belirlenmesi

Gereksinim analizinde son adım olarak sistemin fonksiyonel olmayan gereksinimlerini belirlememiz gerekiyor. Fonksiyonel olmayan gereksinimler, sistemin geliştirilmesi ve maaliyeti üzerinde çok fazla etkiye sahip olduğundan dolayı fonksiyonel gereksinimlerle aynı anda tanımlanır.

Fonksiyonel olmayan gereksinimler, kullanıcıların işlerini beklenmedik şekilde etkileyebilir. Bu gereksinimleri tam olarak belirlemek için, müşteri ve geliştirici hangi özelliklerin kullanıcılar için kritik olduğunu belirlemelidir.

Sistemin performansı, stabilitesi, güvenliği vb. şeyler fonksiyonel olmayan gereksinimlerdir.

Fonksiyonel olmayan gereksinimleri daha doğru bir şekilde belirlemek için aşağıdaki sorulara cevap aranabilir:

• Kullanıcının uzmanlık düzeyi nedir?
• Kullanıcının aşikar olduğu arayüz standartları nedir?
• Sistem ne kadar güvenilir olmalı?
• Bir arıza durumunda sistemin yeniden başlatılması gibi bir olasılık düşünülebilir mi?
• Sistem ne kadar veri kaybedebilir?
• Sistemin güvenlik gereksinimleri var mı?
• Herhangi bir kullanıcı görevinin zaman açısından kritik bir özelliği var mı?
• Sistem kaç eş zamanlı kullanıcıyı destekleyecek?
• En kötü gecikme süresi ne olmalı?
• Sistemi farklı bir yazılıma veya donanım ortamına taşıma planı var mı?
• Sistem bakımı kim tarafından yapılacak?
• Donanım ortamında kısıtlamalar var mı?
• Bakım veya test ekibi tarafından getirilen kısıtlamalar var mı?
• Sistem mevcut başka bir sistemle etkileşime girmeli mi?
• Veriler sisteme nasıl aktarılır/ veriler sistemden nasıl alınır?
• Sistemi kim kullanacak?
• Kaç tane kurulum öngörülüyor?
• Kurulum sırasında zaman sınırlamaları olacak mı?
• Sistem lisansı alınacak mı?

Gibi bir çok soru sorarak fonksiyonel olmayan gereksinimleri belirleyebiliriz.

Tüm bu işlemler bir yazılım sistemi geliştirilmesinde karmaşıklık ile başa çıkabilmek için ilk adım olan gereksinim analizi adımını oluşturur. Bu adımı Analiz, Sistem Tasarımı, Nesnelerin Tasarımı, İmplementasyon (kodlama) ve Test takip eder.

Bütün bu adımlar sonucunda ortaya çıkan bir yazılım sistemi, var olduğu süreç boyunca her zaman aynı kalmaz. Dış etmenler değişkendir, bu da geliştiricileri sistemde değişiklik yapmaya itebilir. Geliştiricilerin bu noktada da değişimi yönetebilmeleri gerekir. Bunları başka bir yazıda ele alabiliriz, umarım faydalı olmuştur..

Kaynak:

Bernd Bruegge, Allen H. Dutoit, Object-Oriented Software Engineering