Gereksinim Mühendisliği 1

Gereksinim Mühendisliği 1

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:

Kullanıcı sisteme kullanıcı adı ve şifresi ile giriş yapacaktır. Hatalı kullanıcı adı veya şifresi giren kullanıcıya girilen değerlerin niteliğine uygun uyarı mesajı verilecektir. Müşteriye 2 çeşit ödeme seçeneği sunulacaktır. Ödemeler kredi kartı yada havale ile yapılabilecektir. Kredi kartı tahsilatı için kredi kartı numarası, müşteri adı soyadı ve güvenlik numarası alınacaktır. Müşteri kredi kartı ile ödeme yapması halinde 1 ila 8 arasında ve bankalara göre değişen vade oranlarında taksitli ödeme yapabilecektir. Her kredi kartı farklı vade oranlarına sahip olup bu vade oranları ve ödeme taksit planı ödeme sayfasında müşteriye bilgilendirme amaçlı olarak sunulacaktı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.

 

Ör:

Kullanıcı şifreleri veritabanında Triple DES algoritması ile şifrelenmiş olarak saklanacaktır. Uygulama web isteklerini en geç 7 saniye içinde cevaplayacaktır. Kullanıcı arayüzü W3C “Web Content Accessibility Guidelines 1.0” standartlarına uyumlu olacaktır.

 

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;

 

İsterlerin ortaya çıkarıltılması İsterlerin analizi ve müzakere edilmesi İsterlerin Gereksinim olarak belirtimi Gereksinimlerin onaylanması Gereksinimlerin yönetilmesi ve evrimi

 

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;

 

Kullanıcılar ne istediklerini anlatamaz yada anlamazlar Gereksinimler sabitlenmiş ve bütçelendirilmiş olsa da, müşteri gereksinimlerin değiştirilmesine eğilimlidir Proje paydaşları arasındaki iletişim zayıf ve yavaştır Son kullanıcı teknik açıdan yetersizdir Müşteri analiz toplantılarında detaylara inmeden yüzeysel çıkarımlarda bulunur, eksik ve yanlış anlaşılmaya müsait bilgiler verebilir Müşterinin anlattıkları ile sizin anladıklarınız arasında büyük uçurumlar olabilir Müşteri eksik gereksinim dökümanı üzerinde tam emin olmasa dahi onaylayabilir Müşteri isterleri bulanık ifade edebilir Müşteri ile yazılım geliştiriciler farklı literatürde anlaşırlar. Yazılım geliştirici ile müşteri arasında algı farklılıkları vardır Analiz çalışmaları programı yazan kişiler tarafından yürütülür ve genellikle bu tip insanlar insan ilişkileri ve iletişim açısından yeterli yeteneğe sahip değildir Yazılı hale getirilmeyen gereksinimler müşteri tarafından suistimal edilebilir

 

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:

 

Doğru: müşteri yada son kullanıcı tarafından sağlanmış olmalıdır. Olanaklı: teknik şartlar gereksinime izin vermelidir. İstenen şey yapılması imkansız yada maliyet açısından çok yüksek ve riskli ise bu ister olanaklı değildir. Gerekli: proje paydaşları arasında gereksinimin gerekliliği noktasında bir fikir birliğnin bulunması ve sistem açısından elzem olması gerekmektedir. Önceliklendirilmiş: gereksinimler müşteri açısından proje paydaşları ile birlikte önceliklendirilmelidir. Müşteri açısından büyük önem taşıyan isterler yüksek öncelik seviyesine sahip olmalıdır. Açık: ifade edilen ister yada gereksinimin yalnız 1 yorumu olmalı ve herkes tarafından aynı şekilde anlaşılması sağlanmalıdır. Hatalı ve farklı yorumlara izin vermemelidir. Kısa ve Öz: yalnızca bir sonraki geliştirme aşaması için yeter seviyede bilgiyi içermesi, kısa ve özlü ifadelerin kullanılması tercih edilmelidir. İzlenebilir: gereksinimlerin proje boyunca geçirdiği evrim ve değişimler izlenebilmeli, bununla beraber gereksinimler arasındaki bağımlılık ilişkilerinin izlenebilir olması gerekmektedir. Eğer A gereksinimi değiştiğinde B gereksinimi de değişiyorsa A->B bir bağımlılık ilişkisinin olduğu anlaşılır. A gereksiniminde yapılacak herhangi bir değişim B’i de etkilediğinden bunlar arasındaki çapraz bağların ve etkilerinin izlenmesi önemlidir. Doğrulanabilir: gereksinim otomatik yazılım testleri (Birim, fonksiyonel testler...) yada manuel kullanıcı testleri ile test edilebilir ve doğrulanabilir olmalıdır. Tam: müşteri isterlerinin tam olarak açıklanmış olduğundan emin olunmalıdır. Tutarlı: gereksinimler arasında tutarlılığı gözetmeli ve tutarsız gereksinimlere izin verilmemelidir. Değişebilir: gereksinim yada isterlerin değişebilir olduğunu kabullenmek :)

 

 

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.

Döküman Arama

Başlık :

Kapat