İş analistlerinin en çok sıkıntı çektiği konulardan bir tanesi de iş birimlerinden gereksinimleri toplamaya başladıkları andan itibaren nasıl bir yöntem kullanarak hangi formatta gereksinimleri dokümante etmeleri gerektiği konusudur.
Çoğu zaman dokümanlar kullanılan standart şablonlardaki gereksiz formalite alanlarla daha da kompleks hale getirilmekte, iş analistlerine her proje için aynı formatta dokümanlar hazırlamaları dikte edilmekte ve hatta performans kriteri olarak konulmaktadır. Tüm paydaşlara tek tip bir doküman gönderilmekte, uzun uzadıya detaya boğularak yazılan bu dokümanları ne iş birimleri ne de yazılımcı arkadaşlarımız okumamaktadır.
Eğer sizlerde projelerinizde bu gibi sıkıntılar yaşıyorsanız sizler için işinize yarayabilecek birkaç önerimiz var;
1. Çok farklı dokümantasyon tipleri var, hangisini ne zaman kullanmalıyım?
Meslek hayatına yeni başlayan çiçeği burnunda İş analisti arkadaşlarımızın ; uzun süredir İş analisti olarak çalıştığı halde sektörde kullanılan herhangi bir doküman şablonunu henüz kullanmayan; veya metodolojileri ve sektörü yakından takip eden şirketlerde çalışmasına rağmen neyi neden kullandığını tam olarak kestiremeyen İş Analisti arkadaşlarımızın en çok sordukları sorulardan bir tanesi de sanırım budur.
Biraz araştırma yaptıysanız yada yaparsanız gereksinimlerin dokümantasyonu ile ilgili çok farklı tipte şablonlar olduğunu görecekseniz. 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österecektir.
IIBA® (International Institute of Business Analysis) tarafından da kabul görmüş bazı doküman tipleri şunlardır;
BRD (Business Requirement Document) :
İş gereksinimleri ile ulaşılması hedeflenen 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ümandır . Dokümanın sorumlusu İş analisti olsa da oluşturulması ekip işidir ve farklı birimler dahil olmalıdır (İş birimleri, development ekipleri, SMEs vb.) Mevcut sistemin işleyişi ve yaşanan sıkıntılar, yeni sistem ile çözümlenmesi hedeflenen problem 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.
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 yada 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.
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 yada 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ı yada 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 yada kullanıcı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 yada 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. Gereksinimleri analiz ediyorum, peki hangi format benim için 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. Hazır şablonlar kullandığımız dokümanlarda çok fazla gereksiz alanlar var, bunları dokümanda tutmalı mıyız?
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 yada zorunluluk yoksa bu bölümleri çıkarabilirsiniz. Doküman şablonunda bu alanlar olduğu için dokümanda tutmak zorunda değilsiniz.
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 onaylayalı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 ve domain bilgi seviyesinden emin değilseniz yada 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. Agile ile yazılım geliştirirken gerçekten dokümana ihtiyaç olmuyor mu?
Agile 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ğil dir. 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 referans 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 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.
Kaynak: https://ba-works.com/blog/gereksinimlerin-dokumantasyonu-hakkinda-merak-edilenler/
