Yazılım Gereksinim Dokümanı Nasıl Hazırlanır?

Yazılım gereksinim dokümanı, özel yazılım projesinde iş ihtiyaçlarını geliştirilebilir ve test edilebilir maddelere dönüştürür. Bu rehber; roller, iş kuralları, istisnalar ve kabul kriterleriyle kapsamı netleştirmek için uygulanabilir bir çerçeve sunar.

Bir özel yazılım projesinde sözlü talepler, ekipler aynı ifadeyi farklı yorumladığında sorun çıkarabilir. Yazılım gereksinim dokümanı nasıl hazırlanır sorusunun pratik cevabı, ihtiyacı ekran listesinden önce süreç, karar ve test edilebilir davranış olarak tanımlamaktır.

İyi hazırlanmış bir doküman, iş biriminin beklentisini, geliştirme ekibinin uygulayacağı davranışı ve test aşamasında kontrol edilecek koşulları aynı yerde toplar. Böylece proje boyunca neyin kapsamda olduğu, hangi kuralın kim tarafından belirlendiği ve bir özelliğin ne zaman tamamlanmış sayılacağı daha görünür olur.

Gereksinim dokümanı web sitesi briefinden neden farklıdır?

Web sitesi briefi çoğunlukla hedef kitle, sayfa yapısı, içerik, tasarım yönü ve iletişim hedefi gibi konuları netleştirir. Yazılım gereksinim dokümanı ise bir kullanıcının işlem başlatmasından sonucun kaydedilmesine kadar işleyen operasyonu tarif eder. Bu nedenle bir web tasarım briefi, özel yazılım gereksinim dokümanının yerine geçmez; iki belge farklı kararları destekler.

Örneğin bir kurumsal sitedeki iletişim formu için alanlar ve yönlendirme yeterli olabilir. İç operasyon yazılımında ise aynı talebin hangi rol tarafından inceleneceği, hangi koşulda reddedileceği, kimlerin göreceği ve geçmiş kaydının nasıl tutulacağı da tanımlanmalıdır.

Dokümana başlamadan önce doğru bilgiyi toplayın

Dokümanı tek başına yazmaya çalışmak, mevcut işleyişteki istisnaları atlama riskini artırır. Süreci kullanan kişiler, karar veren yöneticiler ve teknik bağımlılıkları bilen ekiplerle görüşerek mevcut durumu görünür hale getirin.

• Çözülmek istenen iş sorununu ve beklenen operasyonel sonucu yazın.
• Sürecin nerede başladığını, hangi adımlardan geçtiğini ve nasıl bittiğini çıkarın.
• İşlemi yapan, onaylayan, takip eden ve yalnızca görüntüleyen rolleri belirleyin.
• Kullanılan Excel dosyalarını, mevcut uygulamaları ve dış sistemleri envantere ekleyin.
• İlk sürümde yapılmayacak ihtiyaçları ayrıca belirtin.
• Belirsiz kalan kararları, karar sahibiyle birlikte açık soru olarak kaydedin.

Kaynak sistemlerde bulunan veriler de gereksinimin parçasıdır. Örneğin müşteri, ürün veya işlem kayıtları farklı dosyalarda tutuluyorsa; aktarılacak alanlar, tekrar eden kayıtlar ve veri sorumluluğu tanımlanmalıdır. Bu aşamada Excel'den yazılıma veri aktarımı planı hazırlamak, geliştirme başlamadan önce veri kaynaklarını netleştirmeye yardımcı olur.

Bir talebin gereksinim mi, çözüm önerisi mi olduğunu da ayırın. Satış yöneticisinin yalnızca kendi bölgesindeki fırsatları görmesi bir gereksinimdir. Bunun hangi ekranla, hangi teknolojiyle veya hangi menü yapısıyla sunulacağı ise çözüm tasarımının konusudur.

Yazılım gereksinim dokümanı nasıl hazırlanır?

Dokümanı okunabilir tutmak için her bölümün tek bir soruya cevap vermesi gerekir: Neden yapılıyor, kim kullanıyor, sistem ne yapacak, hangi koşullarda farklı davranacak ve nasıl doğrulanacak? Aşağıdaki yapı, bu soruları birbirinden ayırmanıza yardımcı olur.

1. Amaç, kapsam ve terimler

Belgenin başında yazılımın çözmek istediği problemi kısa ve açık biçimde açıklayın. Ardından kapsama dahil modülleri, kapsam dışı ihtiyaçları ve ekip içinde farklı yorumlanabilecek terimleri ekleyin. Örneğin sipariş, teklif, onay, aktif müşteri veya iptal gibi ifadelerin işletmeniz için ne anlama geldiğini belirtin.

Bu bölümde hedefi özellik listesine dönüştürmek yerine iş sonucuna odaklanın. Satın alma taleplerini tek merkezden izlemek, saha ekiplerinin ziyaret kaydını standartlaştırmak veya bayi siparişlerindeki onay akışını görünür hale getirmek gibi ifadeler daha sağlıklı bir başlangıç sağlar.

2. Kullanıcı rolleri ve yetkiler

Her kullanıcı aynı işlemi yapmamalıdır. Bu nedenle roller için yalnızca unvan yazmak yerine, hangi veriyi görebildiklerini ve hangi eylemleri yapabildiklerini açıklayın. Yetki, sadece menü görünürlüğü değildir; kayıt oluşturma, düzenleme, silme, onaylama, dışa aktarma ve rapor görüntüleme gibi davranışları da kapsar.

• Talep sahibi: Kendi talebini oluşturur, durumunu izler ve gerekli bilgileri günceller.
• Onaycı: Kendisine yönlendirilen talepleri inceler, onaylar veya gerekçeyle reddeder.
• Yönetici: Ekibin kayıtlarını görüntüler ve belirlenen kapsamda rapor alır.
• Sistem yöneticisi: Rol, tanım listesi ve yetki ayarlarını yönetir.

3. İş akışları ve ana senaryolar

Her kritik süreç için normal akışı adım adım yazın. Ekran adlarını erken aşamada kesinleştirmek yerine kullanıcı eylemini ve sistem tepkisini anlatın. Böylece tasarım değişse bile iş kuralı korunur.

• Tetikleyici olay nedir?
• İşlemin başlayabilmesi için hangi ön koşullar gerekir?
• Kullanıcı hangi bilgileri girer veya seçer?
• Sistem hangi kontrolleri yapar ve hangi kaydı oluşturur?
• İşlem tamamlandığında kim bilgilendirilir veya hangi durum güncellenir?

Örneğin bir talep oluşturulduğunda sistemin talep numarası üretmesi, ilgili onaycıya yönlendirmesi ve kullanıcının durum bilgisini görmesi ayrı gereksinimler olarak yazılabilir.

4. Fonksiyonel ve fonksiyonel olmayan gereksinimler

Fonksiyonel gereksinimler, sistemin yapacağı işleri açıklar. Kayıt oluşturma, arama, filtreleme, onay, bildirim gönderme veya rapor alma bu gruba girer. Fonksiyonel olmayan gereksinimler ise bu işlerin hangi kalite, erişim ve işletim koşullarında çalışacağını açıklar.

Hızlı olmalı veya güvenli olmalı gibi belirsiz ifadeler yerine bağlam yazın. Hangi ekranda hangi kullanıcıların işlem yapacağı, hangi hareketlerin kayıt altına alınacağı, kimlerin hangi veriye erişeceği ve hata durumunda kullanıcıya ne gösterileceği açıklanmalıdır. Entegrasyon varsa veri yönü, aktarılacak alanlar, hata bildirimi ve sorumlu sistem de dokümana eklenmelidir.

İstisnaları ve kabul kriterlerini birlikte yazın

Normal akış çoğu zaman yeterli değildir. İş süreçleri, eksik veri, tekrarlanan kayıt, yetki yetersizliği, iptal talebi veya dış sistemden yanıt alınamaması gibi durumlarda farklı davranır. Bu istisnalar yazılmadığında ekipler kendi varsayımlarına göre ilerleyebilir.

Örneğin iç satın alma talebi senaryosunda bütçe limiti aşıldığında, onaycı tanımlı olmadığında veya aynı talep yeniden gönderildiğinde ne olacağı karara bağlanmalıdır. Bu kararların her biri, test edilebilir kabul kriterleriyle tamamlanmalıdır.

Bütçe limiti kuralı için kabul kriterleri şu biçimde yazılabilir:

• Talep tanımlanan limiti aştığında durum Beklemede olarak güncellenir.
• Atanmış onaycı kendi bekleyen taleplerini listeleyebilir.
• Talep sahibi verilen kararın durumunu ve karar notunu görüntüleyebilir.
• Onay yetkisi olmayan bir rol, onay işlemini gerçekleştiremez.

Kabul kriteri, bir özelliğin tamamlanıp tamamlanmadığını değerlendirmek için ortak kontrol noktasıdır. Tasarım tercihinden çok davranışı tarif ettiği için geliştirme, test ve iş birimi incelemesinde aynı şekilde kullanılabilir.

İnceleme, öncelik ve değişiklik kaydını ihmal etmeyin

Doküman hazırlandıktan sonra gerçek kullanıcılarla senaryo üzerinden gözden geçirin. Bir işlemi başlatın, normal adımları izleyin ve ardından istisna durumlarını sorun. Bu yaklaşım, yalnızca metni okumaktan daha fazla belirsizliği ortaya çıkarabilir.

Her gereksinim maddesinde aşağıdaki bilgilerin bulunması dokümanı yönetilebilir kılar:

• Gereksinim kimliği ve kısa adı
• İş gerekçesi ve ilgili kullanıcı rolü
• Öncelik durumu
• Bağımlı olduğu veri, süreç veya entegrasyon
• Kabul kriterleri ve karar sahibi
• Değişiklik notu ile güncel durum

Kapsam değişikliği her zaman hata anlamına gelmez; ancak yeni talebin mevcut süreç, veri yapısı ve kabul kriterleri üzerindeki etkisi kayda alınmalıdır. KepezWeb'in yazılım geliştirme hizmeti kapsamında bu kararların geliştirme öncesinde görünür olması, iş birimi ile teknik ekip arasındaki ortak anlayışı güçlendirmeye yardımcı olur.

Sıkça Sorulan Sorular

Yazılım gereksinim dokümanında neler olmalı?

Dokümanda amaç, kapsam, kapsam dışı maddeler, kullanıcı rolleri, iş akışları, iş kuralları, veri kaynakları, entegrasyonlar, istisna senaryoları ve kabul kriterleri yer almalıdır. Her proje için aynı başlıklar aynı ayrıntıda gerekli olmayabilir.

Gereksinim dokümanını kim hazırlar?

İş birimi ihtiyaç ve kuralları sağlar; yazılım ekibi bunları uygulanabilir ve test edilebilir hale getirmeye yardımcı olur. Süreçte karar veren yöneticilerin ve günlük kullanıcıların görüşü de önemlidir.

Her ekran için ayrı gereksinim yazmak gerekir mi?

Her ekran için uzun açıklama yazmak zorunlu değildir. Ancak kritik karar, veri girişi, yetki, hesaplama veya onay davranışı içeren alanların gereksinimi açıkça tanımlanmalıdır.

User story ile gereksinim dokümanı aynı şey midir?

User story, kullanıcının ihtiyacını kısa bir perspektifle anlatır. Gereksinim dokümanı ise iş kuralları, istisnalar, veri bağımlılıkları ve kabul kriterleri gibi daha geniş bağlamı bir araya getirebilir. İki yaklaşım aynı projede birlikte kullanılabilir.

Doküman tamamlandıktan sonra yeni istek eklenebilir mi?

Yeni istekler eklenebilir; önemli olan bunların değişiklik kaydıyla yönetilmesidir. Yeni ihtiyacın hangi süreci etkilediği, önceliği ve kabul koşulları değerlendirilerek güncel dokümana işlenmelidir.

İç süreçlerinizi yazılıma taşımadan önce kapsam, rol ve entegrasyon başlıklarını birlikte değerlendirmek isterseniz KepezWeb ile iletişime geçebilirsiniz. Teklif al formunda mevcut iş akışınızı ve önceliklerinizi paylaşarak ilk çerçeveyi oluşturabilirsiniz.