Gereksinim Mühendisliği

Yazılım geliştirme süreçlerinin en önemlilerinden birisi, geliştirilecek olan sistem veya yazılım için müşterinin gereksinimlerini ortaya çıkarmak ve bunları analiz etmektir. Gereksinim mühendisliği; müşterinin bir yazılımdan beklentilerini, operasyonel ve geliştirme esnasındaki kısıtları da dikkate alarak ortaya koyma ve gereksinimleri belgeleme işlemlerini sistematik olarak yapabilme disiplinidir. Gereksinim mühendisliği için benzer bir diğer tanım ise, yazılımda neler yapılacağını, nasıl yapılacağını belirtmeksizin, doğru, eksiksiz, tutarlı ve muğlak olmayan ifadeler biçiminde belirtmek ve ortaya çıkartmak için tanımlanan süreçler bütünüdür. Yazılım geliştirme sürecinin tüm aşamalarında, kalite ile maliyet ve kaynak kullanımının azaltılmasının öneminin artması ile birlikte bu sürecin de önemi zamanla artmış ve sistem geliştirme süreçlerinin en önemli ve kritik aşaması olduğunun farkına varılmıştır.
 

Sistem gereksinimleri tam ve doğru olarak ortaya konulamaz ise, daha sonraki süreçlerde bu aşamadan dolayı ortaya çıkacak problemlerin maliyeti göreceli olarak artacak ve ortaya çıkan yazılım kaynaklar açısından verimli olmayacaktır. Bu sürecin mühendislik şeklinde ifade edilmesinin nedeni ise gereksinimleri elde etme esnasında ve analiz işlemlerinde sistematik yaklaşımların yer almasıdır. Bu önemine rağmen hala yazılım geliştiriciler bu sürece daha az zaman ve emek harcayarak doğrudan geliştirme sürecine geçmekte, müşteri gereksinimleri dokümanlarını yapısal ve düzenli biçimde hazırlamamaktadırlar.

Gereksinim nedir?
 

Gereksinim mühendisliğinin temelini oluşturan gereksinim için belli bir sınır koymak imkansızdır. Müşteri ile uzlaşışmış tüm istekler ve ortaya çıkabilecek tüm kısıtlar gereksinim olarak düşünülmelidir. Geniş bir aralıkta değerlendirilen gereksinimler, üst seviyedeki genel isteklerden yazılımın fonksiyonel detaydaki belirtimlerine kadar dağılım gösterir. Sonuçta hepsinin gereksinim olarak ele alınıp analizinin yapılması gerekir. Gereksinimler çok değişik şekilde sınıflandırılıp, farklı tiplere ayrılabilir.

Gereksinim tipleri ve dokümanlar:
 

- Kullanıcı gereksinimleri: Doğrudan kullanıcıya yönelik, görsel ve fonksiyonel ağırlıklı gereksinimlerdir. Doğal dille yazılabilen, diyagramlarla gösterilebilen ve müşterileriler için hazırlanan gereksinimlerdir. Kullanıcı senaryoları (use-case) için temel oluşturur. Kullanıcıdan alındıkları için teknik anlamda detaylar içermeyebilir.

- Sistem gereksinimleri: Sistemin servislerinin detaylı tanımlamaları ile donanımsal yapılara özgü gereksinimlerdir. Üst seviyede sistem iskeletini tanımlarlar. Yapısal bir doküman olup müşteri ile yapılan anlaşma ve sözleşmeye göre hazırlanır.

- Özel kısıtlara yönelik gereksinimler:Yazılımın performansı ve niteliklerini tanımlayan subjektif olmayan kesin sınırlar ve kısıtlardır. Yazılımın etki alanını belirleyen gereksinimlerdir. Yazılımın geliştirilmesine yönelik kısıtlar da bu tip gereksinimlerdir.

- Yazılım Belirtimleri: Yazılımın geliştirme ve tasarıma yönelik detaylı şekilde belirtimleridir. Geliştiricilere yönelik hazırlanan teknik bir dokümandır.

Ayrıca gereksinimleri etki alanları ve niteliklerine göre de 3 ayrı tipe ayırabiliriz.

- İşlevsel (fonksiyonel) gereksinimler: Sistemin sunacağı hizmetler ile sistemin işlevsel altyapısını tanımlarlar. Sistemin ne yapacağını yapısal ve işlevsel olarak ortaya koyarlar. Geliştirmeden bağımsız çoğunlukla giriş, çıkış arabirimleri, süreçler ile hata yönetimine yönelik gereksinimlerdir. Sistem girişindeki izin verme ve yetkilendirme gereksinimleri de bu tiptedir. Sistemin neler yapacağını soyut olarak değil de detaylandırılmış biçimde belirler.

- İşlevsel olmayan gereksinimler:Sistemin daha çok kısıtları ile fiziksel ortam, arayüzler, kullanıcı odaklı olma, güvenlik, güvenilirlik, kalite güvence gibi soyut niteliklerini belirleyen gereksinimlerdir. Yazılımlara işlevsellik katmamasına rağmen bu tip gereksinimler özellikle yazılım kalitesi açısından kritik rol oynarlar. Bu gereksinimler yazılımda karşılanmadığı sürece yazılımın kullanılabilirliği yetersiz kalacaktır.

- Çalışma (etki) alanına özel gereksinimler: Yazılımsal olmayan, yazılımın geliştirileceği alana özel gereksinimler ve teknik dokümanlardan ortaya çıkarılan sistem özellikleridir. Her yazılımın uygulama alanına özgü terimleri, dokümanları ve iş süreçleri bulunabilir. Bunları önceden kestirmek imkansızdır ve ancak ilgili alanda çalışılması durumunda elde edilebilirler. Bunlar işlevsel gereksinimleri de içerirler ve bu gereksinimler yazılım tarafından desteklenmedikçe yazılımın çalışması beklenemez.

İşlevsel ve işlevsel olmayan gereksinimleri karşılaştırmak istenildiğinde, ortak ve ortak olmayan bir çok noktalar bulunur. İşlevsel olmayan gereksinimler sadece işlevsel gereksinimlere yapılan eklenti veya süsleme değildir. Yazılımların, istenilen işlevsel hizmetlerini gerçekleştirmesi yanında kalite, güvenilirlik gibi subjektif gibi görünen niteliklerinin de desteklenmesi gerekir. Kaliteli bir yazılım için işlevsel ve işlevsel olmayan gereksinimler tamamen karşılanmak zorundadır. Yazılım gereksinimleri dokümanında her ikisinin de bulunması gereklidir. Örneğin güvenilirlik işlevsel olmayan gereksinimi için yazılıma birkaç işlev ile hata raporlama yapılarının kurulması gerekecektir. Ancak bu şekilde yazılımların güvenilirliği sağlanır.

Gereksinim Mühendisliğinin Zorlukları

Gereksinimleri elde etmenin çeşitli zorlukları mevcuttur. Bu zorluklar, bu sürecin iyi analiz edilerek sürecin sistematik tanımlamasının yapılmasını ve uygun araçlar ile yapıların hazırlanmasını zorunlu kılmıştır. Her yazılım geliştirme sürecinde yaşanabilen bu zorluklar şöyle belirlenebilir.

- Uygulama alanına yabancı olmak: Yazılım geliştiriciler çok çeşitli alanlara hizmet sunmaktadırlar ve her sektörün de kendine özgü kavramları ve iş süreçleri bulunmaktadır. Yazılım geliştirilecek alanda bilgi birikimi sahibi olunmaması durumunda, doğru ve eksiksiz gereksinim elde etmek zordur. Çünkü çalışılacak alanın iş süreçlerini anlayıp bunların arasındaki ilişkileri ortaya çıkarmak ve müşteri gereksinimlerini elde etmek için varolan sistemi anlamak, çözümlemesini yapmak gerekir. Bu zorluğun üstesinden gelmek için piyasa araştırması yapılmalı veya mümkün olduğunca bileşen tabanlı çözümler üreterek eldeki çözümler yeni sisteme uyarlanmalıdır.
 

- Uygulama alanının kompleks olması: Uygulama geliştirme alanı ne kadar kompleks ve büyük olursa, ortaya o kadar fazla gereksinim ve bu gereksinimler arasındaki ilişkiler çıkar. Kompleks sistemleri anlamanın yanı sıra bu sistemler arasında ilişkileri kurmak da oldukça zordur. Bu durumda önce sistemleri modüllere ayırmak sonra da bu modüller arasındaki arayüzleri çıkartmak, gereksinimleri elde etmeyi kolaylaştıracaktır.
 

- Tüm sistemi bir kişinin bilmesi: Organizasyon altyapısı oturmamış bir kuruluşa yazılım geliştirileceği zaman çoğunlukla sistemi bütünüyle bilen bir kişiyle karşılaşılır. Bu kişi genelde o kuruluşta yıllardır çalışan ve eski sistemin mimarlarından birisidir. Fakat çoğunlukla bu durumdaki kişilerin, gereksinimleri elde etmek için yeterli zamanları olmaz ve yerlerinde bulunamazlar. En doğru bilgi bu kişilerden alınabileceği için, bu kişilerden gereksinimleri elde etmek için planlı toplantılar yapmak ve zamanı verimli kullanmak gerekir.
 

- Müşterilerin bilgilerini ortaya koy(a)maması: Gereksinimleri elde ederken uç kullanıcılar genelde sistemden beklentilerini tam olarak ortaya koymazlar veya koymak istemezler. Kimi zaman yeni sisteme karşı bir tutum izlenerek bilgi sağlamayarak zorluklar çıkarılabilir. Bazen de dar bir bakış açısından sistemin bütününe bakmak durumunda olan kişiler, gerçek gereksinimleri göz ardı ederek detaylarda boğulurlar ve yeterince verimli olamazlar. Bu durumda sistemle ilgili tüm kişi ve grupları gereksinim sağlayıcı olarak seçmek ve her kişiye uygun sorular sormak gerekir. Farklı bakış noktaları, sistemin tüm paydaşlar tarafından nasıl algılandığı konusunda ipucu verir ve sistemin analizini kolaylaştırır.
 

- Müşteri ihtiyaçlarını tam yansıtamamak: Elde edilen gereksinimler bazen müşterinin ne istediğini tam olarak yansıtamazlar. Müşterinin yeterli ve eksiksiz bilgi vermemesinden kaynaklanan veya analistin dikkat ve özeni göstermemesinden kaynaklanan nedenlerden dolayı ortaya beklentilerin dışında bir sistem çıkar. Bu durumun üstesinden gelmek için müşteriden alınan gereksinimleri onaylatmak ve eksikleri önceden tamamlamak gerekir.
 

- Gereksinimlerin tutarsız ve eksik olması: Gereksinimlerin farklı bakış açılarından elde edilmesi durumunda benzer gereksinimler arasında uyuşmazlık ve tutarsızlık ortaya çıkabilmektedir. Bazen de gereksinimler tam elde edilemediğinden oluşan eksiklikler daha sonraki süreçlerde ek maliyetler ortaya çıkarabilmektedir. Bunu önlemek için gereksinimleri, kontrol listelerini kullanarak sınama ve doğrulama yapmak gerekir. Bu şekilde gereksinimler arası tutarsızlıklar ortaya çıkarılabilir.
 

- Gereksinim değişikliklerinin maliyetli olması: Gereksinimler için müşteriden kabul alınıp onaylandıktan sonra ortaya çıkacak değişiklikler maliyetli olmaktadır. Onaylama sürecinden sonra yazılım tasarımına geçileceği için ortaya çıkacak değişiklikler, doğrudan tasarımı etkileyecektir ve geri dönüşler, ek maliyetler ve fazladan zaman gerektirecektir. Ayrıca gereksinimlerde olabilecek değişikliklerin takibi ile değişikliğin diğer gereksinimleri nasıl etkileyeceğinin izlenmesi gerekecektir. Bunun için gereksinim dokümanlarında izlenebilirlik matrisinin oluşturulması ve değişiklik tarihçesinin hazırlanması gereklidir.
 

- Yazılım ekibi ile müşteri arasındaki yanlış anlamalar: Analistler her zaman yazılım geliştirme ekibi ile müşteri arasında köprü görevi kurarak, müşterinin gereksinimlerini tam ve anlaşılır biçimde yazılım geliştiricilere aktarmakla yükümlüdür. Yalnız kimi zaman gerek analist-müşteri ve gerekse analist-geliştirici arasında yanlış anlamalar olmakta ve ortaya beklenmeyen sonuçlar çıkabilmektedir. Bunu önlemek için sık sık müşteriye geri bildirimlerde bulunmak ve hatta yapılabiliyorsa müşteri temsilcisinin de yazılım ekibinin bir parçası olmasını sağlamak gereklidir. Müşteriden erken geri dönen uyarılar ve bildirimler, ileride oluşabilecek yüksek maliyetlerin önüne geçilmesini sağlayacaktır.

Gereksinim Mühendisliğinin Önemi

Gereksinim mühendisliğinin önemi belirtilen bu zorluklardan ve nedenlerden dolayı daha da artmıştır. Üniversitelerin yazılım mühendisliği bölümlerinde ayrı bir ders ve disiplin olarak ele alınıp, akademik çalışmalar ile gereksinim elde etme yöntemleri, gereksinim analizi ve gereksinimlerin geliştirilmesi, olgunlaştırılması konusunda yeni teknikler ortaya konulmaktadır. Gereksinim mühendisliğinin önemi birkaç madde ile şöyle özetlenebilir.

- Geliştirme aşamasında alınan yanlış kararların sonradan düzeltilmesi pahalı olmaktadır. Gereksinim mühendisliğindeki sistematik ve yapısal yaklaşımlar sayesinde geliştirme sürecine geçmeden problemlerin önemli bir kısmı ortaya çıkarılıp, gerekli çözümler erken ve daha az maliyetle sağlanmaktadır. Alınan yanlış kararlardan daha yazılım geliştirmenin başlangıcında geri dönülebilmektedir.

- Gereksinim mühendisliği faaliyetleri yazılım sistemleri için birçok temel tesis eder. Tek hedef doğru, tam ve tutarlı bir gereksinim dokümanı hazırlamaktır. Müşterinin gereksinimlerini doğru algılamayı tetikler ve problemin içeriğine yönelik gözden geçirmeyi ön plana çıkarır. Ayrıca müşterinin de katılımcı olmasını sağlayarak doğrulama ve onaylama yöntemleri ile müşteriyi bağımlı kılar. İyi analiz edilmiş gereksinimler, yazılım tasarımı için sağlam bir iskelet oluşturup, değişimler izlenebilir ve ilişkilendirilebilir.

- Gereksinim mühendisliği, gereksinimleri kayıt edip bunların arındırılıp yalın hale gelmesini sağlar. Doğrudan müşteriden alındığı halde gereksinimler yazılımlar için gerekli olmayan nitelikler içerir. Gereksinim mühendisliği metotları ile bu gereksinimler süzgeçten geçirilip, müşterinin asıl isteklerinin ortaya çıkması sağlanır. Yazılımın daha şeffaf olmasını sağlayıp müşteri ile geliştiriciler arasında iletişimin kurulmasında sistematik bir yapı sunar. Böylece müşteri ile geliştiricilerin ortak bir dili ve metotları bulunur.

- Gereksinim mühendisliği, yazılım için bir test planı oluşturulmasına imkan verip, doğrulama ve sınamaların bu plan doğrultusunda gereksinim tabanlı yapılmasını sağlar. Gereksinim dokümanı, tasarım ve geliştirme aşamalarında doğruluk ve bütünlük kontrollerinin yapılabilmesi için temel referanstır.

- Gereksinim mühendisliği, proje yönetimi için takip eden süreçlerdeki yönetim faaliyetleri, maliyet tahmini, zaman ve kaynak ihtiyacı ile kontroller açısından bir başlangıç noktası oluşturur. Gereksinim dokümanında, gelecekteki değişiklikler için kısıtlar belirtilip destek ve bakım süreçlerine baz oluşturulabilir. Ayrıca revizyonlar sonucunda değişen maliyetleri önceden tahmin edebilmek için bir veri kaynağıdır.

- Gereksinim mühendisliği faaliyetleri yetersiz kalırsa, kullanıcıların yazılım geliştirme ekibine olan güveni azalır ve beklentilerini karşılamayan bir yazılım çıkacağı inancıyla tam ve eksiksiz gereksinim bildirimlerinden kaçınabilirler. Bu güven kaybı ileride yapılacak diğer yazılım geliştirmelerini de etkileyecek ve müşterinin uzun dönemde yazılıma ve yazılım ekibine olan bakış açılarında güvensizlikler yaratacaktır. Sistemli gereksinim mühendisliği yaklaşımıyla müşterinin katılımı sağlanıp, gereken güven ortamı, yazılım geliştirmenin tüm süreçlerinde sağlanabilir.


Gereksinim Ayrıştırılması

Gereksinimleri tiplerine ayırabilmemize rağmen bunları gerçek anlamda yazılım gereksinimleri dokümanında tam olarak ayrıştırmak çok zordur. Yazılım gereksinimleri dokümanında işlevsel ve işlevsel olmayan gereksinimlerin ayrı ayrı ele alınıp analiz edilmesi ideal olandır ama tüm sistemi etkileyen gereksinimler için bu türden ayrıştırma yapmak zorlaşır. Sistem gereksinimleri, bazen özel işlevler ile kısıtlardan daha önemli olabilir. Bazı gereksinimlerin hangi tipe uygun olduğuna karar vermek de zordur. Kullanıcı dostu için olan gereksinimlerden çevrim içi (online) yardım gereksinimi bir işlevsel-olmayan gereksim olmasına rağmen yardım seçeneği için sisteme bazı işlevleri eklemek gerekir. Bu gereksinimin hangi tipe uygun olduğuna karar verirken etki alanına ve önceliklendirilmesine bakılır.
 

Gereksinimler, sistemdeki etkilerine ve kullanılırlığına göre kalıcı veya değişken olabilirler. Kalıcı gereksinimler daha çok organizasyonun ana faaliyet alanından türetilen ve tüm süreçlerde değişmez olan gereksinimlerdir. Örneğin bir hastanede her zaman doktor ve hemşire bulunması bu tip gereksinimdir. Değişken gereksinimler ise sistemin kullanımı veya geliştirilmesi sırasında değişime uğrayabilecek gereksinimlerdir. Örneğin sigorta şirketlerine özgü yasalar ve vergi düzenlemeleri bu tip gereksinimlerdir. Analistlerin, analiz ve tasarımında zorlandıkları bu tip gereksinimlerdir.


Gereksinim Mühendisliği Süreçleri

Gereksinim Mühendisliğinin 4 ana süreci ve bunları gerçekleştirmek için tüm süreçlere uygulanan faaliyetler vardır. Bu süreçler birbirinden tamamen bağımsız olmayıp birbirini bütünleyen ve eksiksiz bir yazılım gereksinim dokümanı hazırlamak için gereken çalışmalardır. Süreçlerinin tamamının yazılım geliştirme sürecinde uygulanması gerekmez. Organizasyon ve proje büyüklüğüne göre uygun olanlar seçilir. Bu süreçler:
 

- Olurluk (fizibilite) çalışması: Müşteri gereksinimlerinin maliyetinin, uygun bütçe ve teknoloji sınırları içinde olup olmadığının tespit edildiği süreçtir. Müşterilere, fazladan istenilen hizmetlerin bir ek maliyeti olduğu ve bunun hem zaman hem de maddi açıdan yeterli olması gerektiği belirtilmelidir. Bazen de eldeki teknolojinin de yetersiz kalması ortaya çıkabilir. Tüm gereksinimler için olurluk çalışmasının yapılması gereklidir. Bunun sonucunda fizibilite raporu hazırlanmalıdır. Değişik biçimlerde olurluk çalışması yapılabilir.
   - Teknik olurluk (kaynak, teknoloji vb)

   - Ekonomik olurluk
   - Yasal olurluk
   - Alternatifler
Olurluk çalışmasında ayrıca karlılık-maliyet analizinin de çıkarılması ve belli kriterlere göre karar verilmesi gereklidir. Her bir hizmet ve araç için maliyetlerin ortaya konulması ve beklenti, risk ve öncelik değerleri ışığında karar verilmesi gerekir.

- Gereksinim analizi: Müşterinin ve tüm paydaşların sistemden olan beklentilerini ortaya çıkarmak ve bunları uygun metodolojilerle ayrıştırıp arındırmaktır. Özelikle çatışma yönetiminin bu süreçte yapılması ve varsa tutarsızlıkların çözümlenmesi gereklidir. Gereksinimlerin önceliklendirilmesi de bu süreçte yapılır. Müşteri bakış açısına göre tüm gereksinimler aynı öncelik derecesine sahip görünebilir. Ortada bir proje planı ve bütçe olması nedeniyle bazı gereksinimlerin daha fazla önceliğe sahip olması gerekecektir.
 

- Gereksinim tanımlama: Gereksinimleri müşterinin anlayabileceği formlara dönüştürerek gerekli tanımlamaları yapmaktır. Bu süreçte diyagram veya formlar kullanılır ve görsel anlamda yapısal doküman hazırlanır. Müşteriye yönelik süreçtir ve gereksinim analizi süreciyle iç içe yürütülür.
 

- Ayrıntılı gereksinim belirtimi: Gereksinimleri detaya inerek tanımlama ve ortak olmayan ve olmayan noktaları ortaya koyma sürecidir. Yazılım tasarımına giriş yapılır. Bu süreç daha çok uygulama geliştiriciler ile müşteri ortamındaki teknik paydaşlar içindir. Gereksinim tanımlama sürecinden ortaya çıkan formların her biri için detaylı formlar ve diyagramlar oluşturulur. Yazılımın tasarımında tanımlanacak nesneler için soyut tanımlamalar yapılır ve üst düzeyde veri akışı diyagramı oluşturulur.

Gereksinim mühendisliğinin dört ana süreci ve bunları gerçekleştirmek için de tüm süreçlere uygulanabilecek aktiviteler vardır. Bunlar süreçlerin doğru tamamlanabilmesi için mutlaka uygulanması gereken aktivitelerdir. Her bir süreçte, bu aktivitelerden biri veya birden fazlası uygulanabilir. Çoğunlukla da süreçlerle aynı şekilde adlandırılmışlardır.
 

- Çalışma alanını anlamak: Çalışma yapılacak alan ile varsa daha önceki varolan sistemi ve süreçleri anlama aktivitesidir. Uygulama alanında, olurluk çalışması yapılmasında ve iyileştirme yapmak için başvurulur.
 

- Gereksinim elde etme/meydana çıkarma: Paydaşlarla birlikte gereksinimleri keşfetme, meydana çıkarma aktivitesidir. Bu aktivite kapsamında paydaşlarla mülakat ve müzakere yapılır, varolan dokümanlar gözden geçirilir, gözlemleme ve sosyal ortam analizi yapılır, gereksinim anketleri düzenlenir ve bunlar değerlendirilir. Sosyal içerikli bir çalışma olup tüm paydaşlar ile etkili bir iletişim ortamının kurulması gerekir. Tüm paydaşların farklı bakış açıları dikkate alınarak sistem gereksinimleri hakkında bilgiler elde edilir. Gereksinimleri önceliklendirmek planlama ve süreç yönetimi açısından çok önemlidir. Önceliklendirme ayrı bir uzmanlık ve yetenek gerektirmesine rağmen gereksinimler üzerindeki bazı kriterler gereksinimlere öncelik sağlar. İşlevsel gereksinimler ve çalışma alanına özgü temel ve kritik gereksinimler önceliklidir. Ayrıca analiz sonucu birbirini takip eden gereksinimlerde de kolay önceliklendirme yapılabilir.
 

- Analiz ve modelleme: Gereksinimleri tanımlayarak ayrıntılı belirtimlerini oluşturma faaliyetidir. Müşteri gereksinimleri modüler şekilde ayrıştırılmış ve arındırılmış olur. Tasarım öncesi yazılım modellemesi yapılır ve veri tipleri tanımlanır. Gereksinimler arasındaki arayüzler ve sistem etkileşimleri detaya inilmeden belirtilir. Bilgisayar destekli yazılım mühendisliği (CASE) araçlarıyla gereksinimler kullanıcı senaryoları ve diyagramları oluşturulur.
 

- Gereksinimleri geliştirme ve olgunlaştırma: Gereksinimler analiz edildikçe yeni gereksinimleri doğurur. Proje bütçesi ve kaynak sınırlamaları çerçevesinde yeni ortaya çıkan gereksinimlerin de müşteri onayı ile gerçekleştirilmesine gereksinimleri geliştirme faaliyeti denir. Bu tip gereksinimler daha çok proje kabul aşamasında ortaya çıkabilecek kabul kriterleridir. Gereksinimleri geliştirmenin bir diğer yöntemi ise prototip oluşturma ve bu prototipi müşteriye sunarak daha önceden alınan gereksinimlerin eksiklerini tamamlamak ve geliştirmektir.
 

- Onaylama ve doğrulama: Müşteri onayı olmayan gereksinimleri tasarıma girdi olarak almak, hatalara ve boşa emek harcanmasına neden olabilir. Büyük projelerde müşteri tarafından da teknik kişilerin proje ekibinde yer alması nedeniyle onaylama işlemi anlık yapılsa da hazırlanan tüm gereksinim dokümanlarının resmi olarak onaylatılması gereklidir. Bu onaylamadan sonra ortaya çıkabilecek gereksinim değişikliklerinin maliyeti ve proje planı revizyonları daha kolay olabilecektir. Gereksinimleri doğrulamak için kontrol listelerinin kullanılması gereklidir. Kontrol listesindeki tüm kriterlerin sağlandığından emin olunması ve eksikliklerin tamamlanması zorunludur.
 

- Gereksinim yönetimi: Gereksinim mühendisliği süreçlerini, proje planına uygun olarak zamanında ve eksiksiz tamamlayabilme aktivitesidir. Müşteri görüşmelerinin ve toplantılarının düzenlenmesi ve elde edilen gereksinimlerin doğru analiz edilerek dokümantasyon edilmesi bu faaliyet kapsamındadır. Proje yöneticisi ve müşteri sorumlusu tarafından yürütülür.

Son Olarak Gereksinim Mühendisliği

Yazılım projelerinde hataların sayısı ve maliyeti arttıkça proje planına uygun olarak tam zamanında tamamlanan proje sayısı da gittikçe düşmektedir. Sistematik yaklaşımların kullanılmaması nedeniyle bir çok proje zaman aşımına uğrayarak geç tamamlanabilmekte veya yarıda kalmaktadır. Gereksinimlerin yönetilmesi ve süreç olarak tanımlanması sonucu hata ve maliyet miktarları düşmekte, elde edilen somut veriler ışığında yazılım ön-kestirimlerindeki doğruluk yüzdeleri yükselmektedir. Gereksinim mühendisliği yazılım geliştirme sürecinin başında olması nedeniyle bundan sonraki tüm süreçleri de doğrudan etkilemektedir.
 

Yazılım mühendisliğindeki eğitiminin daha çok tasarım ve programlamaya yönelik olması sebebiyle, yazılım projelerinde çalışan analistlerin, gereksinimleri tam ve doğru elde edilmiş bir uygulamada hata yapma ihtimali oldukça düşük olmaktadır. Bu sebepten dolayı müşterinin gereksinimlerini doğru almak ve analiz etmek, projenin tamamlanmasında en önemli kriterdir. Proje yönetiminde gereksinim mühendisliği süreçlerine yeterli zaman ve kaynak ayrılması, başarının anahtarı olacaktır.


Kaynaklar
 

"Software Engineering", Ian Sommerville (6th edition).
"Software Requirements", Karl E. Wiegers (2nd Edition).
"Requirements Engineering", Journal Of Object Technology-September-2002, Donald G. Firesmith.
"Characteristics of Good Requirements", INCOSE- Requirements Working Group.
"Recommended Requirements Gathering Practices", Dr. Ralph R. Young.
 

Kasım Şen

Bu yazıyla ilgili görüş ve yorumlarınızı yorum@teknoTurk.org ve kasims@kocsistem.com.tr adreslerine yollayabilirsiniz.