Gereksinim Mühendisliği - I
Yazılım endüstrisi yaşadığı bunca kötü tecrübe ve başarısızlıktan sonra geç de olsa gereksinim mühendisliğinin önemini anlamak ve benimsemek zorunda kaldı. Yazılımların çıkış noktası ve kaynağı olan gereksinimlerinin sistematik ve disipliner bir yaklaşımla ele alınması kaçınılmaz bir sonuçtu.
Birçok yazılım uzmanı için müşteri isterleri ele avuca sığmayan, civa misali kara bir beladır. Projenin ilk aşamalarında istenenler ile son aşamasında ortaya çıkan sonuçlar arasında proje paydaşları (müşteriler, programcılar, kullanıcılar) açısından büyük uçurumların ve başarısız sonuçların alındığı yadsınamaz bir gerçektir.
Çok genel manada yazılım gereksinimi; müşterinin ihtiyacına yönelik isteklerine (müşteri isterleri) karşı geliştirilen sistem özelliği yada yeteneği olarak tanımlanabilir. Müşteri isterleri ile yazılım gereksinimleri her zaman aynı hizada olmayabilir. Müşteri isteri ile yazılımın gereksinimleri arasındaki kesişim proje analistleri tarafından ele alınması gereken önemli bir nüanstır. Her müşteri isteri gereksinim olmazken her gereksinim bir müşteri isterine karşılık gelebilmektedir. Bu nüans projelerde çok karıştırılan ve çeşitli problemlere yol açan bir konudur.
Yazılım gereksinimleri işlevsel (functional) ve işlevsel olmayan (non-functional) gereksinimler olarak ikiye ayrılmaktadır:
İşlevsel Gereksinimler: Sistemin kullanımına ilişkin özellikleri, sistem davranışlarını kapsayan ve müşteri açısından büyük önem taşıyan gereksinim tipidir.
Ör:
İşlevsel Olmayan Gereksinimler: Çoğunlukla sisteme ait kalite gereksinimleri olarak anılan gereksinim tipidir. Özellikle sistemin verimli ve etkin kullanımına ilişkin kalite standartlarını içeren; performans, güvenlik, erişebilirlik, güvenirlik, kullanılabilirlik ve esneklik gibi sistem parametrelerini inceler.
Yukarıda kısaca örnekleri ile açıklamaya çalıştığımız yazılım gereksinimleri proje açısından yönetimi en zor alandır. Proje yöneticileri ve analistleri müşteri isterlerini ortaya çıkarmak için bir hayli mesai harcamakta ve yoğun toplantı trafiği yaşamaktadırlar. Yanlış olan bir yöntem, yazılım gereksinimlerini projenin bağlangıç aşamasında belirlenmesi ve sonrasında unutulması yönünde olmaktadır. Dolayısıyla başta belirlenen gereksinimler ile sistemin güncel istekleri örtüşmemekte ve baştaki gereksinimler güncelliğini yitirmektedir. Proje boyunca yaşanan bu trajediyi ele alan aşağıdaki çizgi ilginizi çekecektir umarım. Durum gerçekten içler acısı :)
Gereksinim mühendisliği ise gereksinimleri proje boyunca ele alan, gereksinimleri yaşayan bir organizma gibi değerlendiren, yazılım mühendisliğinin bir alt koludur. Gereksinim mühendisliği temel olarak şu adımlardan oluşur;
Neden Gereksinim Mühendisliği?
Projeye başladınız ve müşterinizle günler süren analiz tolantıları trafiğiniz bir yandan sürüyor. Yavaş yavaş müşteri gereksinimleri ortaya çıkıyor ve kapsam analiz dökümanınız son şeklini almaya başlıyor. Toplantılarınız bitti ve ortaya gereksinim dökümanı yada adına siz ne derseniz deyin analiz dökümanınız fırından taze taze çıktı. Herkes çok mutlu, artık ne yapacağımız belli haydi kodlamaya.
Kodlama devam ediyor ve seçilen yazılım metodolojisine göre belli aralıklarda müşterinizle ortaya çıkan sonuçları değerlendiren müşteri kabul testleri yapıyorsunuz ve ilk büyük şoku yaşamaya başlıyorsunuz. Müşteri sizin daha öncesinde mutabık olduğunuz ve belki de müzakere ettiğiniz gereksinimlerin sonuçlarını beğenmiyor ve biz bunu istememiştik, biz bu şekilde bir ekran beklemiyorduk yada programı bu şekliyle kullanmamız imkansız bunun şu şekilde değiştirilmesi gerekiyor gibisinden yorumlar ile size geri dönüyor. İster istemez geliştirme ekibi bir gerilim yaşıyor, neden müşterinin fikir değiştirdiğini ve başlangıçta bu istenenlerin belirtilmediğini sorguluyor ve müşterinize için için kızıyorsunuz. Elbette problem izlenen yöntem ve iletişimde yatıyor. Gereksinim analizinde yaşanan zorluklara ilişkin olarak şu problemlerden bahsedilebilir;
Bu ve benzeri bir çok problem aslında sizin müşteri isterlerini iyi yönetemediğinizin bir sonucudur. Gereksinim mühendisliği bir dizi teknik ve sistematik çalışmanın yanında diğer sosyal disiplinleri de içine alan kapsamlı bir çalışma tekniğinir. Bu sosyal bilimlere örnek olarak aşağıdaki 4 sosyal bilim verilebilir:
İdrak psikolojisi (Cognitive Psychology): insan idrakini anlamaya yönelik bir bilim dalıdır. İnsanların dış etkenleri zihinlerinde nasıl algıladığı ve yaşayabilecekleri zorlukları ele alır. İnsanların idrak seviyelerinde iletişim kurmak için faydalıdır. Unutmayın siz ne anlatırsanız anlatın karşınızdaki kendi algı seviyesinde anlayacaktır.
İnsanbilimi (Antropoloji): insan aktiviteleri ve davranışlarını sistematik bir şekilde gözlemleyen bilim dalıdır. İnsanbilimi yazılım sistemlerinin insanlara en verimli şekilde cevap verebilmesini olanaklı kılar. Microsoft Office gibi büyük araçları geliştirirken bir düzine kültürel antropoloji uzmanını çalıştırmaktadır. Kalkıp size antropoloji uzmanı çalıştırın demek istemiyorum bu elbette sizin bütçeniz ve ürünün kapsamı ile direk bağlantılıdır fakat konunun önemini vurgulamak istiyorum.
Sosyoloji: sosyolojik yaklaşım biçimi, geliştirilmesi planlanan yeni sistem ile kurumsal ve bireysel anlamda değişmesi muhtemel iş yapış şekli ve kültürünün doğuracağı sonuçları tahminlemek ve bu geçiş aşamasının sosyojik açıdan doğru temellere oturtulmasını mümkün kılmaktadır. Sosyoloji daha çok bireyler yada birimler arasındaki politik değişimlerin doğuracağı problemleri anlamak ve buna uygun çözümleri geliştirmek için kullanılır. Yeri geldiğinde çatışma yönetimi gibi iletişim tekniklerini kullanmaya hazırlıklı olun.
Dilbilim: gereksinim mühendisliği doğası gereği iletişim üzerine inşa edilmiş bir tekniktir. Analiz aşamasında kullanılacak dilin açıklığı ve oluşturulması gereken sistem metaforu etkin bir dil stratejisinden geçer. Bu meyanda NLP (Sinir Dili Programlaması) gibi tekniklerden de yardım alınabilir.
Görüldüğü üzere yaptığımız iş ne kadar teknik olursa olsun bir şekilde sosyal bilimler ve iletişim bu binanın sağlam olmasını sağlayan çimento gibi her alanda karşımıza çıkıyor. Bunca teorik bilgiden sonra gereksinim mühendisliği sürecine geçmeye hazırız artık.
İsterleri Ortaya Çıkarma (Eliciting)
Bu aşama gereksinimlerin ortaya çıkmaya başladığı noktadır. Müşteri isterlerinin ortaya çıkartılması yada yakalanması hayli güç bir süreçtir. Bu aşamada ortaya çıkan olası isterler analiz, belirtim ve onaylama aşamalarından geçmeden gerçek gereksinim olamazlar. Dolayısıyla bu aşamada ortaya çıkartılan isterlere aday yazılım gereksinimleri denilebilir. Ortaya çıkarma sürecinde kullanılan teknikler şu şekildedir:
Görüşmeler ve Toplantılar: geleneksel hale gelmiş gereksinim yakalama yöntemidir. Proje başında yada yayım (release) başlarından yapılan analiz toplantıları ve görüşmeleri bu kategori içersine girer. Bu teknikteki asıl başarı kriteri toplantı yönetimi, toplantı tutanakları ve toplantı sonunda ortaya çıkan analiz dökümanlarıdır. Çoğu zaman toplantıların verimsiz geçtiği ve müşterinin asıl ihtiyaçlarına yönelmekte zorlandığı gözlemlenmiştir.
Senaryolar: nihai kullanıcının mevcut kullanımına yada planlanan kullanımına ilişkin iş senaryolarını hedef alan bir yöntembilim ile kullanıcıya “bu nasıl yapılır, bu durumda naparsınız, bir sonraki aşamada neler olur” cinsinden sorularla kullanıcı senaryosunun düzgün bir akış ile ortaya çıkartılması işlemidir. Bu sorular karar ağaçları (desicion trees) gibi yöntemler ile sorulabilir. Senaryo çalışmasında çoğunlukla kullanıcı hikayeleri (User Story) ve UML’de yer alan kullanım vakası (Use Case) gibi teknikler tercih edilir. Use Case’ ler özellikle çok güçlü bir müşteri ister yakalama tekniğidir. Bu alandaki çalışmalar giderek önem kazanmakta.
Prototip Çalışması: gereksinimlerin anlaşılması ve yakalanması noktasında belirsizliğin çok olduğu durumlarda başvurulan tekniktir. Prototip çalışmaları kullanıcı isteklerini karşılamaya yönelik taklit ekran ve form tasarımlarından oluşan bir çalışmalar bütünüdür. Erken aşamalarda prototip çalışmaları ile müşteri istekleri yakalanmaya ve proje riskleri minimize edilmeye çalışılır.
Gözlem: Kullanıcıların uygulama ile olan etkileşimi ve kullanım alışkanlıklarının gözlemlenmesi üzerine kurulmuş maliyetli fakat başarılı bir tekniktir.
İyi Gereksinim Kimdir?
Projelerde gözlemlediğim kötü bir alışkanlık da gereksinim dökümanlarının çok fazla laf kalabılığı içermesi ve hedefine uygun olmamasıdır. Çoğu tecrübesiz yazılımcı yazdığı gereksinim dökümanının kaç sayfa olduğundan dem vurmakta ve bunu bir başarı kriteri olarak sunmaya çalışmaktadır. Oysaki kaliteli döküman hedef kitlesine en kestirme yoldan cevap verebilen dökümandır. İyi bir gereksinimin aşağıdaki niteliklere sahip olması beklenmelidir:
Sonuç
Makalemizde incelemeye çalıştığımız gereksinim mühendisliği, projelerin başarı oranını doğrudan etkileyen ve kesinlikle ciddiye alınması gereken bir çalışmalar bütünüdür. Kurum bazında uygulayacağınız standart bir gereksinim süreç yönetimi projelerinizin başarı kriterlerine ulaşması için ön şart niteliğindedir.
Bu yazı dizisinin sonraki bölümlerinde İsterlerin analizi ve modellenmesi, belirtimi ve yazılım gereksinimleri döküman şablonu, gereksinimlerin onaylanması ve yönetimi gibi konular ele alınacaktır.