Gereksinim çözümleme

Bilgisayar bilimlerinde, gereksinim analizi ya da gereksinim çözümleme; çeşitli sistemlerin gerekliliklerini ve olası çelişkili durumlarını göz önüne alarak, yazılımı analiz etmek, belgelemek, doğrulamak ve yönetmek için yeni veya değiştirilmiş bir ürün üzerinde projenin ihtiyaçlarını, sistem gereksinimlerini ve koşullarını belirleyen görevleri kapsamaktadır.^[1]

Gereksinim analizi; bir sistem veya yazılım projesinin başarısı veya başarısızlığı açısından kritik önem taşır. İhtiyaçların belgelenmesi, uygulanabilir olması, ölçülebilir olması, test edilebilir formda olması, izlenebilir olması ve belirlenen işletmenin ihtiyaçlarına uygun olması gerekir.

Genel bakış[değiştir | kaynağı değiştir]

Kavramsal olarak, gereksinim analizi üç tür etkinlik içermektedir:

1. İhtiyaçların ortaya çıkarılması: İş süreci dokümantasyonu ve grup görüşmeleri sağlanarak ihtiyaçları belirlemektir. Buna bazen ihtiyaç toplama veya gereksinim keşfi de denir.
2. İhtiyaç analizi: Belirtilen gerekliliklerin açık, eksiksiz, tutarlı, net olup olmadığını belirleme ve belirlenen çelişkileri çözme.
3. Kayıt gereksinimleri: Gereksinimler, genellikle bir özet listesi içeren çeşitli formlarda belgelenebilir.Doğal dil belgeleri, kullanım örnekleri, kullanıcı hikâyeleri, süreç özellikleri ve veri modelleri de dahil olmak üzere çeşitli modeller oluşturulabilir.

Gereksinim analizi, pek çok hassas psikolojik becerinin katıldığı uzun ve yorucu bir süreç olabilir. Büyük sistemler, yüzlerce veya binlerce sistem gereksinimi açığa çıkararak analistlerin iş yükünü artırabilir.^[2] Yeni sistemler, ortamları ve insanlar arasındaki ilişkileri değiştirir, bu nedenle geliştiricilerin tüm ortamları tanımlamalarını, tüm ihtiyaçları göz önünde bulundurmalarını ve yeni sistemlerin etkilerini anlamalarını sağlamak önemlidir.Analistler, müşterinin gereksinimlerini ortaya çıkarmak için çeşitli teknikler kullanabilirler. Bunlar, senaryoların geliştirilmesi, kullanım durumlarının belirlenmesi, işyeri gözlemi, etnografi kullanılması, röportajlar düzenlenmesi veya gözden geçirme oturumları yapmak gibi yöntemleri içermektedir.Ve böylelikle gereksinim listeleri oluşturulabilir.Prototip belirleme yöntemi, proje sunulacak şahıs ya da kuruma örnek olarak gösterilebilecek bir sistem maksadıyla kullanılabilir. Analist, gerekirse, şahıs ya da kurumların kesin gereksinimlerini belirlemek için bu yöntemlerin bir kombinasyonunu kullanır ve böylece işletme ihtiyaçlarını karşılayan bir sistem üretilir.Gereksinim kalitesi aşağıdaki bazı yöntemlerle iyileştirilebilir:

• Görselleştirme: Görselleştirme ve simülasyon gibi teknikler kullanılarak arzu edilen nihai ürünün daha iyi anlaşılmasını teşvik etmek.
• Şablonların tutarlı kullanımı: Gereksinimleri belgeleyen tutarlı bir dizi model ve şablon üretmek.
• Bağımlılıkları belgelemek: Gereksinimler arasındaki bağımlılıkları ve ilişkileri belgelemek.Ayrıca ek olarak bu bağımlılıklara ilişkin varsayımlar üretmek de sayılabilir.

Gereksinim çözümleme başlıkları[değiştir | kaynağı değiştir]

Gereksinim analizi konuları kabaca şöyle listelenebilir:

Kitlenin kimliği[değiştir | kaynağı değiştir]

Yazılım geliştirilecek kitlenin belirlenmesidir.Bununla beraber kitlenin niteliksel ya da niceliksel özelliklerinin belirlenmesi konusu da oldukça önemlidir.Bu kitle şunları kapsayabilir:

• Sistemi işletmecisi olan herkes.
• Sistemden yararlanan herkes.(işlevsellik açısından ya da politik, finansal ve sosyal yönlerden)
• Sistemi satın alan ya da satın almak üzere ilgilenen herkes.
• Sistemin özelliklerini düzenleyen kuruluşlar. (finansal, güvenlik vb. kurumları)
• Sisteme karşı görüşlü insanlar veya kuruluşlar. (olumsuz düşünen kitle)

Kitle ile görüşmeler[değiştir | kaynağı değiştir]

Hedef kitle ile görüşmeler, gereksinim analizinde kullanılan yaygın bir tekniktir.Kitlenin bakış açılarına ve belirlenen ihtiyaçlarına odaklanılır.Yazılım geliştirecek ekibin, kitlenin ait olduğu sistemi önceden etraflıca analiz etmesi gerekmektedir.Çünkü bu görüşmelerde, genellikle geliştiricinin ilgili çalışma sahasının yaşam döngüsü hakkındaki bilgi yetersizliğinden ve buna paralel olarak kitlenin de teknik bilgi yetersizliğinden kaynaklı sorunlar çıkmaktadır.Bunu önleyebilmek için etkili iletişim teknikleri kullanılmalıdır.

Müşterek gereksinim geliştirme oturumları[değiştir | kaynağı değiştir]

Bu oturumlarda yazılım geliştirme sürecinde iş analisti(business analyst) kullanılır.Böylelikle kolaylıkla kitlenin gereksinimleri ortaya çıkarılır, ayrıntıları analiz edilir ve işlevler arası etkileri ortaya çıkarmak için tartışmalara girilir.Bu analist tarafından kontrollü bir ortamda yürütülür.Böylelikle müşterek gereksinim geliştirme oturumları sağlanabilir.Tartışmayı belgelemek ve oturumun hedefini karşılayan uygun şartları sağlamak için tartışmayı yönetmek üzere iş analistinin düşüncelerinden bağımsız özel bir yazar bulunmalıdır.

Sözleşme tarzı gereksinim listeleri[değiştir | kaynağı değiştir]

İhtiyaçların belgelendirilmesinin geleneksel yolu, sözleşme tarzı gereksinim listeleridir. Karmaşık bir sistemde, bu tür gereksinim listeleri yüzlerce sayfaya kadar sürebilir.

İfade yerindeyse, bu liste adeta uzun bir alışveriş listesi gibidir.Modern analiz yöntemlerinde bu tür listeler çok fazla avantajlı değildir.Çünkü amaçlarına ulaşmada başarısız oldukları görülmüştür.Buna rağmen, bu teknik günümüze kadar gelebilmiştir

Prototipler[değiştir | kaynağı değiştir]

Bir prototip, başka bir bilgisayar programının özelliklerinin bir bölümünü sergileyen ve henüz oluşturulmamış bir uygulamayı görselleştiren bilgisayar programıdır. Popüler bir prototip biçimi, gelecekteki kullanıcıların ve diğer kitlenin sistemin nasıl görüneceği konusunda fikir sahibi olmalarına yardımcı olan bir taklit uygulamasıdır. Prototipler, tasarım kararlarını kolaylaştırır, çünkü uygulamanın geleceği, uygulama oluşturulmadan önce görülebilir ve paylaşılabilir. Kullanıcılar ve geliştiriciler arasındaki iletişimde büyük gelişmeler genellikle prototiplerin tanıtımından sonra görülmüştür.Geliştirilme aşamasından önce, uygulamalar hakkında belirtilen hedef kitle görüşleri sayesinde verimlilik artmıştır.Bu ise, daha az değişiklik ve dolayısıyla daha düşük maliyet anlamına gelmektedir.

Kullanım örnekleri[değiştir | kaynağı değiştir]

Bir kullanım örneği, ister özgün bir çalışma, ister sonradan değiştirilmiş olsun, genellikle yazılım içeren bir sistemin işlevsel gereksinimlerini belgeleyen bir yapıdır. Her kullanım örneği, belirli bir iş hedefine ulaşmak için sistemin bir insan kullanıcısı veya başka bir sistemle nasıl etkileşim kuracağını anlatan bir dizi senaryo sağlar. Kullanım örnekleri genellikle teknik ifade biçiminden uzaktır ve bunun yerine son kullanıcının veya hedef kitlenin anlayacağı dili tercih eder. Kullanım örnekleri, genellikle sistem analisti ve hedef kitle tarafından birlikte incelenir.

Kullanım örnekleri, yazılım veya sistemlerin davranışlarını açıklamak için suni ve basit araçlardır. Kullanım örneği, kullanıcıların yazılım veya sistemin nasıl çalışacağı ile ilgili metinsel bir açıklama içerir. Kullanım örnekleri, sistemin iç işleyişlerini ya da mekanizmalarını içermemelidir.Ve sistemin nasıl uygulanacağını açıklamamalıdır. Bunun yerine, sıralı varsayımlar olmaksızın bir görevi gerçekleştirmek için gerekli adımları açıkça belirtmelidir. (Örneğin bir muhasebe programında yeni bir ürünün nasıl ekleneceği bilgisi paylaşılabilir.)

Gereksinim çözümlemede bazı konular[değiştir | kaynağı değiştir]

Yazılım geliştirilecek kitlenin sorunları[değiştir | kaynağı değiştir]

Steve McConnell, Rapid Development adlı kitabında, kullanıcı gereksinimlerinin karşılanmasını engelleyen bir dizi sorunu ayrıntılarıyla anlatıyor:

• Kullanıcılar, ne istediklerini bilmiyor veya kullanıcıların gereksinimler hakkında net bir fikri yok.
• Kullanıcılar bir dizi yazılı gereksinimi önce belirleyip daha sonra iptal edebilmektedir.
• Kullanıcılar maliyet ve zamanlama belirlendikten sonra ilaveten gereksinim konusunda ısrarcı davranıyor.
• Kullanıcılarla iletişim yavaş ilerliyor.
• Kullanıcılar genellikle incelemelere katılmazlar veya bunu yapacak bilgileri yoktur.
• Kullanıcılar teknik açıdan karışık düşünmektedirler.
• Kullanıcılar geliştirme sürecini anlamıyorlar.
• Kullanıcılar mevcut teknoloji hakkında bilgi sahibi değiller.

Bu durum, sistem veya ürün geliştirmeye başladığında bile kullanıcı gereksinimlerinin değişmeye devam etmesine neden olabilir.

Mühendis ya da geliştirici sorunları[değiştir | kaynağı değiştir]

Gereksinim analizi sırasında mühendislerden ve geliştiricilerden kaynaklı sorunları şunlardır:

Kod yazmaya yönelik doğal bir eğilim vardır, bu durum gereksinim analizi tamamlanmadan önce yazılım geliştirmenin başlamasına yol açabilir ve bunun sonucu da muhtemelen, gerçek gereksinimleri bilinmeden geliştirilen ve öngörülemeyen ya da yeniden yapılandırılamayan yazılımlar doğurabilir.

Geliştiriciler ve hedef kitlenin anlaşmaları bozulabilir.Sonuç olarak, geliştiriciler projeyi teslim edebilmek için çalışırlar.Tamamlanan bir ürünün, geliştirilinceye kadar olan sürecini yönetirler ama buna karşın hedef kitlenin kanaatleri, başlangıçtaki anlaşmanın doğrultusunda olmayabilir yani anlaşmayı bozabilirler.

Mühendisler ve geliştiriciler, gereksinimleri, müşterinin ihtiyaçlarına özel bir sistem geliştirmek yerine mevcut bir sisteme veya modele uydurmaya çalışabilir.

Analiz, müşterinin ihtiyaçlarını doğru bir şekilde anlamak için farklı istihdam alanlarında bilgisi olan personel yerine, mühendisler veya programcılar tarafından sıklıkla uygulanabilir.Bu ise gerçeklik küresine uygun olmayan çözümler üretilmesine sebebiyet verebilir.

Bazı çözüm denemeleri[değiştir | kaynağı değiştir]

İletişim sorunlarına çözüm denemesinde iş veya sistem analizinde uzmanlar çalıştırılması vardı.

1990'larda prototiplendirme, birleşik modelleme dili(UML), şablon kullanma ve çevik yazılım geliştirme gibi teknikler, önceki yöntemlerde sık karşılaşılan sorunların çözümleri olarak düşünülmüş ve buna paralel olarak geliştirilmiştir.

Ayrıca, uygulama simülasyonunun yeni bir sınıfı veya uygulama tanımlama araçları piyasaya girdi. Bu araçlar, işletme kullanıcıları ile yazılım geliştirme organizasyonu arasındaki iletişim boşluğunu gidermek ve herhangi bir kod üretilmeden önce uygulamaların test yoluyla pazarlanmasını sağlamak için tasarlanmıştır. Bu araçların en nitelikli olanları şunlardır:

• Uygulama akışlarını ve test alternatiflerini çizebilmek için elektronik beyaz tahta.
• İş mantığını ve veri ihtiyaçlarını yakalama yeteneği.
• Son başvuruyu yakından taklit eden yüksek kalitede prototip üretme yeteneği.
• Etkileşim yeteneği.
• Bağlamsal gereksinimleri ve diğer yorumları ekleme yeteneği.
• Uzak ve dağıtık kullanıcıların simülasyon ile çalışıp etkileşime girme becerisi.

Kaynakça[değiştir | kaynağı değiştir]