İçeriğe geç

Gereksinim Analizi 4. Hafta

Arkadaşlar merhaba,

Bu hafta gereksinim mühendisliği konseptinde öne çıkan bazı unsurlar üzerinde durulmuştur. Gereksinim analizi süreci ve öneminin kavranmasına odaklanılmıştır. Bu bağlamda aşağıdaki unsurlara odaklanılmıştır.

Farklı döküman tipleri arasından hangisi kullanılmalıdır?

Gereksinimleri analiz ediyorum benim için hangi format uygun?

Hazır şablonlar kullandığımız dökümanlarda birçok alan var bu alanları dökümanda tutmalı mıyız?

Dökümanlara onay almak zor mu ?

Agile ile yazılım geliştirilirken gerçekten dökümana ihtiyaç olmuyor mu ?

IIBA nedir? Hangi döküman tiplerini standart olarak kabul etmiştir?

BRD nedir? Hedefleri nelerdir?

SRS nedir? Hedefleri nelerdir?

BRD kadar detaylı bir çalışmaya ihtiyaç duyulmayan daha küçük işlerde/projelerde kullanılabilecek başka bir döküman tipi var mıdır? Açıklayınız.

 

GEREKSİNİM ANALİZİ SÜRECİ VE ÖNEMİ

Gereksinim analizi aşaması, mühendislik süreci ve özellikle de yazılım geliştirme sürecinin ilk aşamasıdır. Bazı kaynaklar ilk aşama olarak Planlama aşamasını ele alır. Bazı kaynaklar ise Planlamayı ayrı bir aşama olarak ele almayıp gereksinim analizi ile birlikte değerlendirir. Yapı olarak: yeni veya değiştirilmiş bir ürün için karşılanması gereken ihtiyaçları veya koşulları belirleyen ve bu süreçte yararlanıcılar veya kullanıcılar gibi muhtelif paydaşların muhtemel çelişkili gerekliliklerini göz önüne alan görevleri kapsamaktadır.

Gereksinim analizi, bir projenin başarısı için kritik derecede önem taşımaktadır. Çünkü sistem sonucunda elde edilecek ürünün temeli bu aşama üzerine atılmaktadır. Analiz aşamasında gereksinimler, tespit edilebilir iş ihtiyaçları veya fırsatlarıyla ilişkili olarak uygulanabilir, ölçülebilir, test edilebilir olmalıdır ve sistem tasarımı için yeterli seviyede tanımlanmalıdır.

Bu nedenden ötürü de iş analistlerinin en çok sıkıntı çektiği konulardan bir tanesi gereksinimleri çıkarmaya başladıkları zamandan itibaren nasıl bir metot kullanarak hangi formata uygun olarak gereksinim dokümanı hazırlamaları gerektiği konusudur.

Bu ihtiyaç ve önem derecesi noktasında hazırlanan dokümanlar çoğu zaman kullanılan standart şablon yapısındaki gereksiz formal kısımlar ile daha bir kompleks hale gelmekte; iş analistlerine her projeye aynı formatta doküman hazırlamaları konusunda baskı yapılmakta; farklı projelerin dökümanlarının birbirine eş olması da performans kriteri olarak ele alınmaktadır. Tüm paydaşlara aynı tip doküman gönderilmektedir ve bunun sonucunda müşteri veya gereksinim sonucunda ürünü ortaya koyacak yazılımcı bu dökümanları okumamaktadır. Bunun sonucunda da tam olarak kestirilemeyen gereksinim ölçütleri öğrenilmemekte ve sonuçta çıkan ürün veya yazılım ihtiyaçları karşılamamaktadır.

Kavramsal olarak, hazırlanacak gereksinim analizi, üç tür etkinlik içermektedir. Bunlar:

İhtiyaçları ortaya çıkarmak: Müşteriler ve kullanıcılar ile iletişim kurma görevinin sağlanması ile onların ihtiyaç, istek ve şartlarının belirlenmesi.
İhtiyaç analizi: Belirtilen gerekliliklerin belirsiz olup olmadığını belirleme yani müşterinin bahsettiği gereklilikler asıl ihtiyaç ile örtüşüyor mu?
Kayıt gereksinimleri: Gereksinimler, doğal dil belgeleri, kullanım kutuları, kullanıcı öyküleri veya işlem özellikleri gibi çeşitli biçimlerde belgelenebilir.

Bu işlemlerin gerçekleştirilmesi aşamasında bazen gereksinim analizi, birçok hassas psikolojik becerinin de işin içine katıldığı zaman alıcı ve zorlu bir süreç olabilmektedir. Ancak unutulmamalıdır ki bu aşamanın verimi, yazılımın veya ürünün hem geliştirme aşamasındaki hem de müşteride olduğu süredeki hataların azalmasını sağlayacaktır. Bunun için de yeni sistemler ile çevre ve insanlar arasındaki ilişkileri değişecektir ve tüm paydaşları tanımlamak, tüm ihtiyaçları belirlemek ve göz önünde bulundurmak, ele alınacak yeni sistemlerin olumlu ya da olumsuz etkilerini müşterilerin anlamalarını sağlamak önemlidir.

Gereksinim Türleri

Gereksinimler birçok yönden kategorize edilmiştir. Teknik yönetimle ilgili gereksinimlerin ortak sınıflandırmaları aşağıda sıralanmıştır:

Müşteri Gereksinimleri
Sistemin misyon hedefleri, ortamı, kısıtlamaları ve etkinlik ve uygunluk önlemleri açısından beklentilerini tanımlayan varsayımları içermektedir. Operasyonel gereklilikler temel ihtiyacı tanımlayacak nitelikte ve en azından aşağıdaki listede öngörülen soruları cevaplayacak seviyede olmalıdır:
• Sistem nerede kullanılacak?
• Görev profili veya senaryo: Sistem misyon hedefini nasıl başaracak?
• Performans ve ilgili parametreler: Görevi başarmak için kritik sistem parametreleri nelerdir?
• Kullanım ortamları: Çeşitli sistem bileşenleri nasıl kullanılır?
• Etkililik gereksinimleri: Sistem görevini yerine getirirken ne kadar etkili veya verimli olmalıdır?
• Çalışma ömrü döngüsü: Sistem kullanıcı tarafından ne kadar süreyle kullanılacak?
• Çevre: Sistemin etkili bir biçimde hangi ortamlarda çalışması beklenebilir?

İşlevsel Gereksinimler
İşlevsel gereklilikler, gerçekleştirilmesi gereken gerekli görev, eylem veya etkinliği belirleyerek neler yapılması gerektiğini açıklar. Fonksiyonel ihtiyaç analizi için üst düzey fonksiyonlar olarak kullanılacaktır.

İşlevsel Olmayan Gereksinimler
İşlevsel olmayan gereksinimler, belirli davranışlardan ziyade bir sistemin çalışmasını değerlendirmek için kullanılabilecek kriterleri belirtir.

Performans Gereklilikleri
Bir görev veya işlevin ne derece yürütüleceği; Genellikle miktar, kalite, kapsam, zamanlama veya hazır olma açısından ölçülür. Gereksinim analizi sırasında performans (ne kadar iyi yapılması gerektiği) gereksinimleri, sistem ömrü faktörlerine dayalı olarak tanımlanan tüm işlevler arasında interaktif olarak geliştirilecek; Tahminlerinde kesinlik derecesi, sistem başarısı için kritiklik derecesi ve diğer gereksinimlerle olan ilişkileri ile karakterize edilecektir.

Tasarım Gereksinimleri
Teknik veri paketleri ve teknik el kitaplarında ifade edilen işlemler için, ürünler için “yapım”, “kod ve satın alma gereksinimleri ve “nasıl yürütülür ” sorularının gerekliliklerini içermektedir.

Türetilen Gereksinimler
Üst düzey gereksinimlerin ima edildiği veya değiştirdiği şartlar. Örneğin, uzun mesafeli veya yüksek hız için bir gereklilik, düşük ağırlık için bir tasarım gereksinimi ile sonuçlanabilir.

Tahsis Edilen Gereksinimler
Üst düzey bir gereksinimi birden fazla alt düzey gereksinime bölen veya aksi halde tahsis etmek suretiyle kurulan bir gereklilik.

Gereksinim Analizi Aşamasında yaşanılan sıkıntıları azaltmak ve maksimum oranda verim sağlamak amacıyla birkaç öneri bulunmaktadır.

1. FARKLI DOKÜMAN TİPLERİ ARASINDAN HANGİSİ KULLANILMALIDIR?

İş hayatına yeni girmiş olan yazılım mühendisi veya İş analisti kişilerin ya da uzun süredir İş analisti olduğu halde tam verim elde edemeyen kişilerin ortak sorunu olarak bu madde ortaya çıkmaktadır. Literatüre veya internetteki ilgili sayfalara bakıldığı zaman çokça dökümantasyon ile karşılaşılabilir bu da ikilemde kalma riskini doğurmaktadır.

Birçok şirket bu şablonları kendilerine göre revize ederek farklı isimler vermiştir. Buna rağmen birçoğu standart tek tip bir şablon oluşturarak her projede ve her farklı yazılım geliştirme yönteminde aynı şablonu kullanmaya çalışmaktadır. Oysaki projenin hangi aşamasında olduğunuza, neyi hangi amaçla dokümante etmek istediğinize, dokümanı kim için hazırladığınıza, proje planında tanımlanan paydaşlarla iletişimin formalite seviyesine göre kullanmanız gereken doküman tipleri farklılık göstermektedir.

IIBA® (International Institute of Business Analysis) tarafından kabul görmüş bazı doküman tipleri vardır. Bunlar;

BRD (Business Requirement Document) :
İş gereksinimleri ile ulaşılması amaçlanan gerçek kullanıcı ihtiyacının (Business Need/Business Requirements), Why ve What sorularının kullanıcı odakları cevaplarının ve projenin objektifinin çok net bir şekilde yer alması gerektiği, projenin başında kurumsal analiz çalışmaları ile birlikte oluşturulmaya başlanan kapsamlı bir doküman olarak değerlendirilmektedir.

Dokümanın sorumlusu sistemin iş analisti olarak değerlendirilse de oluşturulması ekip işidir ve farklı birimler de dahil olmalıdır (İş birimleri, development ekipleri, SMEs vb.). Temelde mevcut sistemin işleyişi ve yaşanan sıkıntılar, yeni sistem ile çözümlenmesi hedeflenen problemler tanımlanır. Ayrıca paydaşların (Stakeholders) listesi, rol ve sorumlulukları, product scope, riskler ve etki analizi, varsayımlar, fonksiyonel ve fonksiyonel olmayan gereksinimler, Use case tanımları, iş kuralları dokümante edilir. Genellikle SRS dokümanı ile karıştırılır. Bu dokümanın mottosu nasıldan ziyade neyi elde etmeyi hedeflediğimizdir yani teknik çözümün burada yeri yoktur.

Bir iş gereksinimleri belgesi (BRD), müşterinin ihtiyaç ve beklentilerinin belgelendirilmesi de dahil olmak üzere bir proje için işletme çözümünün ayrıntılarını vermektedir. Bir girişim mevcut (veya yeni bir donanım / yazılım modeli eklemek istendiğinde) yeni bir BRD oluşturulmalıdır. BRD süreci, bir Altı Sigma DMAIC (Tanımlama, Ölçme, Analiz Etme, Geliştirme ve Kontrol) kültürü içerisinde birleştirilebilir.

BRD’nin en yaygın hedefleri şöyledir:
•Menfaat sahipleri ile anlaşma yapmak
•Bir teknoloji servis sağlayıcısına, müşterinin ve iş ihtiyaçlarını karşılamak için çözümün ne yapması gerektiği konusunda bir temel oluşturmak
•Bu proje için bir sonraki aşamaya girdi sağlamak
•Müşterinin / işletmenin ihtiyaçlarını nasıl çözeceğini tanımlamak için çözüm karşılanacaktır.

Bu açıdan bakıldığında BRD çok önemlidir çünkü her giriş ve çıkışın her işlem işlevi ile ilişkili olduğunu açıklayan sonraki tüm proje çıktılarının temelidir.

SRS (Software / System Requirement Specification) :
Sistem gözünden gereksinimlerin dokümante edildiği dokümandır. Örneğin bir E-ticaret sitesi için müşterinin bilgilerinin alınması bir fonksiyonel gereklilikse ve BRD dokümanında tanımlandıysa bunun yeni bir sayfa ya da bir pop-up sayfası ile mi alınacağı, database’e web servisler ile mi aktarılacağı bir sistem gereksinimidir ve SRS dokümanında tanımlanır. Bu dokümanda sistem özellikleri (features), ara yüzler (user/system/hardware interfaces), fonksiyonel olmayan sistem gereksinimleri (performance/security/reliability vb.) tanımlanır.

Genellikle bu doküman analiz periyodunda Sistem Analistleri tarafından hazırlanır, sistem Analisti yoksa da teknik ekibin desteği ile iş analistleri tarafından hazırlanabilir. Birçok şirkette Functional Specification (Fonksiyonel Gereksinim) dokümanı olarak da yanlış bir ifade ile tanımlanır ki fonksiyonel olmayan sistem gereksinimlerini de kapsamalıdır. Yazılım Gereksinimleri Spesifikasyonu (SRS) paydaşlar ve yazılım tasarımcıları arasında bir iletişim aracıdır.

SRS’nin spesifik hedefleri şunlardır:
•İncelemeleri kolaylaştırmak
•İşin kapsamını tanımlamak
•Yazılım tasarımcılarına (yani, navigasyon yardımcıları, belge yapısı) bir referans sağlamak
•Birincil ve ikincil kullanım durumlarını test etmek için bir çerçeve oluşturmak
•Müşteri ihtiyaçlarına yönelik özellikler de dahil olmak üzere sürekli iyileştirme için bir platform sağlama (eksik özellikleri veya soruları kullanarak)
•Güvenilirlik, Uygunluk, Güvenlik, Sürdürülebilirlik

Vision and Scope Document :
Bazı şirketlerde BRD yerine hazırlanır. Her proje için mutlaka proje ve ürünün kapsamı (product scope) gerek BRD ile gerekse Vision and Scope dokümanı ile mutlaka tanımlanmalıdır. Bu doküman tipi de genellikle BRD kadar detaylı bir çalışmaya ihtiyaç duyulmayan daha küçük işlerde/projelerde kullanılabilir. Projenin ya da yapılacak işin neden gerekli olduğu, çalışma kapsamında yapılması planlanan özellikler (user/stakeholder requirements), varsa özellikle kapsam dışı bırakılması konuşulmuş bir konu ve projedeki paydaşların kim olacağı mutlaka tanımlanmalıdır. Dokümanın sorumlusu İş Analistleridir. BRD yazılmadığı durumlarda analiz periyodunda her bir user requirement için tanımlanması gereken Fonksiyonel gereksinimler ayrı ayrı ya da gruplanarak Use Case dokümanları formatında tanımlanmalıdır. Fonksiyonel olmayan gereksinimler ise Use Case dokümanlarına ek doküman olarak tanımlanabilir (Supplementary Requirement Specification). Önemli olan fonksiyonel ve fonksiyonel olmayan gereksinimlerin ayrı tanımlanmasıdır.

Product roadmap and Product Backlog :
Agile projelerde kullanılan bir yöntemdir. Gereksinimlerin feature bazlı tanımlanmasıyla Product roadmap dokümanı oluşturulmaya başlanır ve müşterinin ya da kullanıcının ihtiyacı göz önüne alınarak feature’lar üzerinde önceliklendirme yapılır ve Roadmap belirlenir. Agile da kullanılan epic, user story gibi detaylar roadmap’de değil product backlog’da tanımlanır. Roadmap mümkün olduğunca sade ve minimum detayda olmalıdır. Bu doküman Product Owner tarafından gerekli durumlarda İş analistlerinin desteği ile hazırlanır.

RFI, RFQ, RFP :
Tedarikçilerle çalışacağınız projelerde, farklı çözüm önerilerini değerlendirirken satın almayı planladığınız hizmet ile ilgili daha fazla bilgiye ihtiyacınız varsa RFI (Request for Information) dokümanı hazırlayıp tedarikçilerinize doldurmaları için gönderebilirsiniz. Nasıl bir çözüm ile devam edeceğinize karar verdikten sonra farklı tedarikçilerden teklifleri almak amacıyla RFQ ( Request for Quote) dokümanı kullanılır. RFP (Request for Proposal) ise daha formal bir dokümandır ve teklif talep formu olarak adlandırılır. RFP dokümanı bir ürün ya da servisi satın alma süresinde atlanmamalıdır çünkü bu formda kapsamı, gereksinimleri, kısıtları, değerlendirme kriterlerinizi, ürün ile ilgili servis hizmetleri, yasal zorunlulukları, tedarikçi firmanın hizmet kalitesi, destek faaliyetleri, proje takvimi, maliyeti gibi birçok konuyu ele almanız gerektiği için hem sizin ne istediğinizi daha iyi ifade etmenizi sağlar hem de tedarikçilerinizin verecekleri hizmet ile ilgili yükümlülüğünü arttırır.

2. GEREKSİNİMLERİ ANALİZ EDİYORUM, PEKİ HANGİ FORMAT BENİM İÇİN UYGUN?

İş birimlerinden almış olduğunuz gereksinimleri analiz ederken çalışmalarınızı tek tip bir format kullanarak hazırlamak zorunda değilsiniz. Nasıl her zaman aynı gereksinim analiz tekniğini kullanmak zorunda olmadığınız gibi, ihtiyacınıza göre farklı formatlarda çıktılar hazırlayabilirsiniz.

Örneğin eğer analiz dokümantasyonunuzu çok farklı rol, pozisyon ve bilgi seviyesindeki paydaşlarınızın değerlendirip onaylamasını istiyorsanız içerisine Data ile ilgili gereksinimler için “Data Dictionary” ve domain ile ilgili spesifik terimlerin herkes tarafından aynı şekilde anlaşılmasını sağlamak için “Glossary” koyabilirsiniz. Eğer çok fazla iş kuralınız varsa onları daha okunur kılmak için “Decision Table (Karar Tablosu)” kullanabilirsiniz. İş birimlerinin daha iyi anlaması açısından ekranları tasarlarken wireframeler çizebilirsiniz. Yine farklı bir örnek olması açısından eğer yazılım ekiplerinizin daha iyi anlayacağını düşünüyorsanız farklı modelleme tekniklerinden yararlanarak iş akışlarınızı, veri modellerinizi çizebilirsiniz. Hazırladığınız bu çalışmaları ayrı analiz dokümanları olarak da paylaşabileceğiniz gibi BRD, SRS gibi formatlarda dokümanlar kullanıyorsanız uygun şekilde dahil edebilirsiniz.

3. HAZIR ŞABLONLAR KULLANDIĞIMIZ DOKÜMANLARDA ÇOK FAZLA GEREKSİZ ALANLAR VAR, BUNLARI DOKÜMANDA TUTMALI MIYIZ?

Her şirketin hatta her projenin ihtiyacı farklı olabileceği için bu konuda esnek olmanız önerilir. Şirketinizde kullandığınız dokümanlardaki gerek görmediğiniz alanları çıkarın ve dokümanlarınızı ihtiyacınıza göre revize edin. Eğer gereksinimleriniz içerisinde herhangi bir iş kuralı yoksa İş Kuralları bölümünü, eğer herhangi bir kısıt ya da zorunluluk yoksa bu bölümleri çıkarabilirsiniz. Doküman şablonunda bu alanlar olduğu için dokümanda tutmak zorunda değilsiniz. (ymh 114 için verilen şablon aynen korunup gereksiz veya doldurulamayan alanlar ve bu alanların gerektirdiği olgular için “bu kısmın gerektirdiği olgu (mesela veri tabanı viewler) tanımlanmamıştır” şeklinde kısa açıklamalar yazılabilir.)

4. DOKÜMANLARA ONAY ALMAK NEDEN BU KADAR ZOR?

Zor çünkü çok uzun dokümanlarınız var, kullanıcı gereksinimleri ve teknik gereksinimlerinizi ayırmıyorsunuz, iş birimleri dokümanlarınızı okumuyor, yazılımcılar dokümanlarınızı okumuyor ve onay almakta sıkıntı çekiyorsunuz. Hadi onay aldınız diyelim, sizce gerçekten onaylayan grup tamamıyla dokümanı anlayarak mı onaylıyor yoksa ben onaylayayım da bir an önce iş başlasın diye mi düşünüyor?

Bu problemleri aşmak için öncelikli olarak paydaşlarınızı çok iyi belirlemeniz ve onların anlayabileceği seviyede dokümanlar yazmanız gerekmektedir. Kullanıcı ve sistem gereksinimlerini ayırarak ilgili gruplardan ayrı ayrı inceleyip onay vermelerini isteyebilirsiniz. Eğer BRD gibi tek bir doküman hazırlıyorsanız, dokümanın en sonuna bir tablo yaparak hangi paydaşın hangi kısmı okuyup onaylaması gerektiğini belirtmeniz okuyuculara çok yardımcı olacaktır. Böylelikle tüm dokümanı detaylı okumalarına gerek kalmadan sadece ilgili kısımları dikkatlice okuyup onaylayabilirler.

Doküman dili sade ve anlaşılır olmalıdır. Gereksiz uzun cümleler yerine daha basit ve kısa cümlelerle anlatmak istediklerinize odaklanın. Okuyucularınızın teknik bilgi seviyesinden emin değilseniz ya da farklılık gösteriyorsa çok fazla teknik terim ve jargon kullanmayın.

Eğer bunlara rağmen hala zorlanıyorsanız, paydaşlarınız ile bir araya gelin ve dokümanı sözel olarak siz anlatın, sorularını yanıtlayın, açık noktaları minimize edin ve hemen akabinde yazılı onay vermelerini isteyin.

5. AGİLE İLE YAZILIM GELİŞTİRİRKEN GERÇEKTEN DOKÜMANA İHTİYAÇ OLMUYOR MU?
Agile (çevik) manifesto der ki “Working software over comprehensive documentation”. Maalesef bu cümle biraz yanlış anlaşılmakta ve uygulanmakta. ‘Agile yapıyoruz ama hala doküman yazmak zorunda kalıyoruz, nasıl Agile yaklaşım bu’ diye soruluyor çoğu zaman. Agile demek dokümantasyona ihtiyacımız olmayacak, hadi doküman yazmayı bırakalım demek değildir.

Agile dokümana yoğunlaşmaz, esas odak noktası çalışan bir yazılımın daha hızlı çıkmasıdır. Agile’ın temel prensiplerine göre ekiplerin yakın çalışması sonucu birbirleri ve müşteri ile sürekli iletişimde olmaları kolaylaşır, analist ve yazılımcı bir araya gelerek iş birliği içerisinde geliştirme yaparlar, sık sık çıkan release’ler ile iletişim, gereksinimler yerine yazılımın üzerinden yapılır ve böylelikle dokümantasyon ihtiyacı azalır. Dokümantasyonun azalması Agile çalışmanın bir gerekliliği değil etkisidir.

agile

Agile çalışma mantığında şekilde de görüleceği üzere çok önemli olarak etiketlenen kısımdaki olgular az önemli olarak belirtilen olgulara göre öncüllenen yapıtaşlarıdır. Net olarak söylenmelidir ki dökümana ihtiyaç yoktur denilemez.

Agile projelerde gereksinimler User Story olarak kısa cümleler halinde tanımlanır ve her bir User Story için Acceptance Criteria (Kabul kriterleri) yazılır. Bunlara ilave olarak ihtiyaç duyduğunuz durumlarda, analiz dokümanları oluşturabilirsiniz. Yalnız unutmayın amacınızın süper dokümanlar yaratmak yerine daha hızlı bir şekilde kullanıcının ihtiyacını doğru olarak karşılamak. Bu yüzden mümkün olduğunca daha amaca hizmet eden, kısa ve net çıktılar hazırlayın.

Her farklı proje ya da analiz çalışması öncesinde proje tipine, kullanacağınız yönteme, paydaşlarınıza ve zaman kısıtınıza göre nasıl bir formatta gereksinimlerinizi dokümante etmeniz ve hangi tip dokümanları kullanmanız gerektiğine siz karar verin, projenizin uzmanı sizsiniz!
Unutmayalım ki dokümantasyon sadece bir araçtır, önemli olan kullanıcın ihtiyacını doğru anlayıp doğru şeyi dokümante ederek hedeflenen sonuca ulaştırmaktır. Yalın olun ve gereksiz formalitelerden kurtulun, iletişimi her zaman ön plana çıkarın.

 

 

Tarih:Genel

İlk Yorumu Siz Yapın

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

− 9 = 1