30 saniyelik özet
Business Requirement, yani iş gereksinimi, işletmenin neden değişime ihtiyaç duyduğunu ve değişiklikle hangi üst düzey sonuca ulaşmak istediğini açıklar. Belirli bir ekranı veya teknik yöntemi tarif etmekle sınırlı değildir. İyi bir iş gereksinimi; problemi, etkilenen alanı, beklenen faydayı ve başarı değerlendirmesini ilişkilendirir. Ayrıntılı çözüm gereksinimleri bu ihtiyaca dayanır. Böylece ekip yalnızca ne geliştireceğini değil, geliştirdiği davranışın işletme açısından neden gerekli olduğunu da anlayabilir.
Neden önemli?
Satış ekibi “müşteriye özel fiyat alanı ekleyelim” dediğinde geliştirme ekibi bu alanı yapabilir. Ancak sözleşmeli fiyatın teklif, sipariş ve fatura boyunca korunması gerekiyorsa tek bir alan yeterli olmayabilir. Talep yerine getirilmiş görünürken fiyat uyuşmazlıkları ve manuel düzeltmeler devam edebilir.
İş gereksinimi bu durumda tartışmayı genişletir: İşletmenin ihtiyacı, bir değeri ekrana yazmak mı, yoksa üzerinde anlaşılmış fiyatın ilgili işlemlerde doğru uygulanması mı? İkinci ifade farklı çözüm seçeneklerini değerlendirmeye imkân verir. Mevcut bir fiyat listesini kullanmak veya başka bir sistemden bilgi almak da seçenek olabilir.
Junior bir iş analisti için bu ayrım, paydaş önerisini bağlamıyla değerlendirme becerisidir. Öneriyi reddetmek gerekmez; önce karşılaması beklenen ihtiyaç araştırılır. Yönetici açısından ise iş gereksinimi, yatırımın gerekçesini kapsam kararına bağlar. Geliştirilen her özellik aynı işletme değerini üretmez.
Endüstri mühendisliği açısından burada sistemin toplam sonucu önemlidir. Teklif hazırlama hızlanırken yanlış fiyatların düzeltilmesi için finansın işi artıyorsa yerel iyileşme toplam faydayı sınırlayabilir. İş gereksinimi, faydanın hangi süreçte ve kimin işinde oluşacağını açıkça değerlendirmeyi sağlar.
Terim nedir?
İş gereksinimleri, değişimin iş açısından gerekçesini ve beklenen sonuçlarını üst düzeyde tanımlar. Kuruluşun hedefleri, yaşadığı problemler veya değerlendirmek istediği fırsatlarla bağlantılıdır. Çözümün hangi teknolojiyle kurulacağına karar vermeden de ifade edilebilir. Bununla birlikte gereksinimin kapsamı ve anlamı yeterince belirli olmalıdır.
Problem tanımı, mevcut durumda neyin aksadığını anlatır. İş hedefi, ulaşılmak istenen durumu belirler. İş gereksinimi, değişimin bu amaç için karşılaması gereken üst düzey ihtiyacı açıklar. Bu ifadeler birbirine yakın olabilir; her kuruluşun belge düzeni aynı değildir. Önemli olan aralarındaki bağın korunmasıdır.
Paydaş gereksinimi, belirli bir kişi veya grubun değişimden doğan ihtiyacını anlatır. Çözüm gereksinimi ise çözümün sağlayacağı davranış veya özellikleri daha ayrıntılı tanımlar. Örneğin işletmenin sözleşmeli fiyatları tutarlı uygulama ihtiyacı, satış temsilcisinin geçerli fiyatı görebilmesi ve sistemin doğru fiyatı siparişe taşıması gibi gereksinimlere ayrılabilir.
Bir iş gereksiniminin iyi yazılması, tek cümlede bütün ayrıntıların verilmesi anlamına gelmez. Gereksinim ifadesinin yanında kaynak, gerekçe, sorumlu, varsayım ve değerlendirme ölçüsü bulunabilir. Böylece kısa bir ifade, incelenebilir bir bağlama dayanır. Sadece belgeyi kısaltmak için önemli koşulları çıkarmak belirsizliği artırabilir.
Ölçüm de uygun seviyede seçilmelidir. Fiyat doğruluğu ihtiyacında uyuşmazlıklar ve manuel düzeltmeler değerlendirilebilir. Ancak işletmenin genel gelirindeki değişimi yalnızca bu çalışmaya bağlamak için yeterli kanıt bulunmayabilir. Gereksinimin katkısını değerlendirmek ile bütün ticari sonucun nedenini açıklamak ayrı çalışmalardır.
İzlenebilirlik, bir gereksinimin kaynağıyla ve onu karşılayan çözüm parçalarıyla ilişkisinin takip edilmesidir. Bu ilişki, çözüm değiştiğinde amacın korunmasına yardımcı olur. Bir ekran kaldırılabilir veya yöntem değişebilir; ancak iş ihtiyacının nasıl karşılanacağı yeniden açıklanmalıdır. Geliştirme kapsamı değişirken gerekçenin kaybolmaması önemlidir.
Gerçek vaka: Atlassian’ın gereksinimleri ortak bağlamda tutması
Atlassian’ın Sherif Mansour imzalı yazısı, şirketin kendi uygulamalarından ve çevik ekiplerden hareketle hazırladığı gereksinim sayfası yaklaşımını anlatıyor. Önerilen yapı; genel hedefleri, işin neden yapıldığını, stratejiyle ilişkisini ve varsayımları aynı çalışma alanında ele alıyor. Kullanıcı hikâyeleri, tasarımlar ve açık sorular da bu bağlama bağlanıyor.
Kullanıcı hikâyesi, bir ihtiyacı kullanıcı açısından kısa biçimde anlatan çalışma öğesidir. Yazıda, hikâyelerin müşteri görüşmeleri gibi kaynaklarla desteklenmesi ve başarı ölçülerinin belirtilmesi öneriliyor. İlgili fakat yapılmayacak işlerin kaydedilmesi de ortak beklenti oluşturmanın parçası olarak açıklanıyor.
Bu örnek, iş ihtiyacının geliştirme ayrıntılarından kopmaması için kullanılan gerçek bir dokümantasyon pratiğidir. Belirli bir projenin finansal başarısını ölçen vaka değildir. Kaynağın ayrıca belgelerin güncelliğini kaybetmesi riskini belirtmesi önemlidir: Ortak referansın faydası, kararlar ve uygulama değiştikçe güncellenmesine bağlıdır.
Kaynak: Sherif Mansour, “A Guide To Agile Requirements Documentation”, Atlassian, 10 Temmuz 2013.
Varsayımsal örnek: Kurumsal müşterilerin sözleşmeli fiyatları
İşletmelere e-ticaret yazılımı sunan bir şirkette satış ekibinin müşteriye özel fiyat alanı istediğini düşünelim. Bazı siparişlerde temsilci fiyatı elle düzeltiyor, finans ise fiyat farkının nedenini sonradan araştırıyor olsun. Analist önce gerçek işlem kayıtlarını ve ilgili sözleşme koşullarını inceler.
İş gereksinimi adayı şöyle yazılabilir: “Kurumsal müşteriler için geçerli sözleşmeli fiyatların tekliften siparişe tutarlı uygulanmasını ve fiyat uyuşmazlıklarından doğan manuel müdahalelerin azaltılmasını sağlamak.” Bu ifade, belirli bir ekranı çözüm olarak seçmeden iş ihtiyacını anlatır. Hangi müşteri ve işlem çeşitlerini kapsadığı ayrıca belirtilir.
İlk incelemede sözleşmelerin farklı başlangıç ve bitiş koşulları bulunduğu ortaya çıkabilir. Aynı müşteri için eski ve yeni fiyat kayıtlarının birlikte bulunması mümkündür. Hangi kaydın geçerli sayılacağı bir iş kuralıdır ve yetkili rollerle doğrulanmalıdır. İş gereksinimi bu ayrıntıyı tek başına çözmez, fakat araştırılmasını gerektirir.
Satışın ihtiyacı teklif hazırlarken geçerli fiyatı görmektir. Operasyon, siparişe hangi fiyatın uygulandığını bilmek ister. Finans ise sonradan yapılan değişikliğin gerekçesini takip etmek isteyebilir. Bu paydaş ihtiyaçları, çözümde fiyat seçimi, aktarımı ve işlem kaydı gibi davranışlara dönüştürülür.
Çözüm seçenekleri mevcut fiyat listesi, sözleşme kayıtlarının merkezi yönetimi veya başka bir sistemle bağlantı olabilir. Her seçenek veri güncelliği, operasyon yükü ve hata davranışı açısından değerlendirilir. Seçilen çözüm, ilk önerilen alanla aynı olmak zorunda değildir. Ancak karşılaması gereken iş ihtiyacı değişmemişse bu ilişki korunur.
Doğrulamada geçerli sözleşme, süresi dolmuş fiyat ve çelişen kayıt gibi senaryolar incelenir. Uygulama sonrası fiyat uyuşmazlıkları ve manuel düzeltmeler izlenebilir. Başlangıç değerleri ölçülmeden iyileşme oranı yazılmaz. Sonuç beklendiği gibi değilse gereksinimin yanlış anlaşılması, veri sorunu veya kullanım davranışı ayrı ayrı araştırılır.
Yaygın üç hata
- Çözüm önerisini iş gereksinimi diye yazmak. “Yeni bir fiyat ekranı yapılmalı” belirli bir çözüm tercihini anlatır. Önce hangi iş sonucunun gerekli olduğunu açıklayın. Çözüm tercihi haklı olabilir, fakat gerekçesi görünür olmadan alternatifler karşılaştırılamaz.
- Çok geniş ifadelerle yetinmek. “Verimlilik artmalı” hangi işi ve hangi sorunu ele aldığını göstermez. Etkilenen süreç, müşteri grubu ve beklenen değişim belirlenmelidir. Ayrıntılar ayrı alanlarda tutulabilir; ancak ifadenin kapsamı okuyucunun tahminine bırakılmamalıdır.
- Gereksinimi yazıp çözümle bağını kurmamak. İş ihtiyacı bir belgede, geliştirme görevleri başka yerde kalabilir. Değişiklikler olduğunda hangi davranışın hangi ihtiyaca hizmet ettiği izlenmelidir. Tamamlanan görev sayısı, iş gereksiniminin karşılandığını tek başına göstermez.
Mini uygulama: İş gereksinimi kartı
Bir özellik talebini seçin ve aşağıdaki alanlarla iş gereksinimi adayına dönüştürün. Bilinmeyen bilgiyi varsayımla tamamlamak yerine araştırılacak soru olarak kaydedin.
- Kaynak
- İhtiyaç kimden, hangi kanıtla geldi?
- İş problemi veya fırsat
- Neden değişiklik gerekli?
- İş hedefi
- Hangi sonuca katkı bekleniyor?
- Gereksinim ifadesi
- Değişim hangi üst düzey ihtiyacı karşılamalı?
- Etkilenen alan
- Hangi süreç, müşteri veya rol kapsamında?
- Varsayımlar
- Beklenti hangi koşullara dayanıyor?
- Başarı değerlendirmesi
- Karşılandığını hangi bulgu gösterecek?
- Sorumlu
- İhtiyacı ve sonucu kim değerlendirecek?
- Alt gereksinimler
- Hangi paydaş ve çözüm ihtiyaçlarına ayrılıyor?
- Açık sorular
- Hangi bilgi henüz doğrulanmadı?
Kartı ilgili paydaşlarla inceleyin. Sonra ilk önerilen çözümü geçici olarak kaldırıp ihtiyacın hâlâ anlaşılır olup olmadığına bakın. Anlaşılmıyorsa ifade çözüm tercihine fazla bağımlı olabilir. İş gereksiniminin değeri, uygulama yöntemleri değişse de neden çalışıldığını ve hangi sonucun korunacağını açıklamasıdır.
İlgili terimler
Business Objective, Problem Statement, Requirements Elicitation, Stakeholder Analysis, Business Rule, Functional Requirement, Non-Functional Requirement, User Story, Acceptance Criteria, Requirements Traceability Matrix, Scope ve Out of Scope, Business Case