Web Yazılım Projesi Nasıl Planlanır? Gereksinimden Yayına Adımlar

Web yazılım projesi planlamak ne demektir?

Web yazılım projesi planlamak, kod yazılmadan önce üç soruya yazılı cevap vermektir: ne çözülecek, kim kullanacak ve ilk sürümün sınırı nerede bitecek. Bu üç cevap belli olmadan yapılan işte her taraf farklı bir ürün hayal eder; fark da çoğu zaman yayına yakın bir tarihte, düzeltmesi zahmetli olduğu bir anda ortaya çıkar.

Planlama, kalın bir doküman yazmak anlamına gelmez. Küçük bir proje için bir iki sayfalık gereksinim özeti, bir akış şeması ve bir kapsam listesi çoğu zaman yeterlidir. Önemli olan belgenin uzunluğu değil, iki tarafın aynı belgeye bakarak “evet, kastettiğimiz bu” diyebilmesidir.

Kurumsal tanıtım sitesi ile özel yazılım arasındaki fark da burada belirginleşir. Tanıtım sitesinde ağırlık sayfa yapısı ve içeriktedir. Özel yazılımda ise kullanıcı rolleri, veri, iş kuralları ve dış sistemlerle bağlantı gibi daha fazla karar vardır; bu kararların bir kısmı yazılmazsa geliştirici tahminle ilerlemek zorunda kalır.

Gereksinimler nasıl toplanır?

Gereksinimler, “sistem şunu yapabilmeli” biçiminde yazılmış ve sınanabilir cümlelerle toplanır. “Hızlı olsun” gibi ölçülemeyen bir istek yerine “kayıt formu gönderildikten sonra kullanıcıya onay ekranı gösterilir” gibi bir cümle yazmak, hem geliştirici hem müşteri için aynı sonucu işaret eder.

Toplama işi tek bir toplantıyla bitmez; ama her turda aynı başlıklar üzerinden gitmek konuşmayı dağılmaktan korur.

1. Amacı tek cümleyle yaz: bu yazılım hangi iş sorununu çözüyor ve başarı nasıl anlaşılacak?
2. Kullanıcı rollerini listele: ziyaretçi, üye, yönetici gibi. Her rolün neyi görebileceğini ve neyi yapabileceğini ayrı ayrı belirt.
3. Bugünkü işleyişi anlat: işlem şu an e-tabloyla, telefonla ya da e-postayla mı yürüyor? Hangi adım zaman alıyor ya da hata üretiyor?
4. İstekleri “olmazsa olmaz”, “olsa iyi olur” ve “şimdilik kapsam dışı” olarak üç gruba ayır.
5. Kısıtları not et: kullanılacak alan adı, mevcut hosting, tercih edilen teknoloji, uyulması gereken mevzuat ve süreyi etkileyen takvim baskıları.
6. Varsayımları açıkça yaz. Örneğin “içerikler müşteri tarafından hazırlanacak” veya “ödeme alma bu sürümde yok” gibi cümleler sonradan çıkacak tartışmaları baştan kapatır.
7. Özeti her iki tarafa da gönder ve yazılı onay al. Onaylanan sürüm, sonraki değişiklik taleplerinin kıyaslanacağı referans olur.

İlk sürüm (MVP) kapsamı nasıl belirlenir?

İlk sürüm kapsamı, ürünün asıl amacını çalıştıran en küçük özellik kümesidir; geri kalan her şey ikinci sürüme bırakılır. MVP (minimum uygulanabilir ürün) denen yaklaşım bu fikre dayanır: tüm özellikleri aynı anda bitirmeye çalışmak yerine, gerçek kullanıcıyla karşılaşacak çekirdeği önce yayına almak.

Önceliklendirme yaparken her istek için iki soru sorulabilir: bu olmadan yazılım amacını yerine getirir mi, ve bu özelliğin yokluğunun geçici bir çözümü var mı? İkisine de “evet” cevabı veren istek ilk sürümden çıkarılabilir.

Aşağıdaki tablo, istekleri sınıflandırırken kullanılabilecek basit bir karar çerçevesidir. Rakam veya hazır puan içermez; amaç, tartışmayı ortak bir dile taşımaktır.

Kullanıcı akışları, veri modeli ve entegrasyonlar nasıl çıkarılır?

Kullanıcı akışı, bir kişinin hedefine ulaşmak için sırayla geçtiği ekranların ve kararların haritasıdır. Her akışın başlangıcını, başarılı bitişini ve hata durumunu çizmek yeterlidir; örneğin “üye girişi” akışında yanlış şifre ve unutulan şifre dalları da gösterilmelidir, çünkü gerçek kullanıcılar da yanlış şifre girer ya da şifresini unutur.

Veri modeli, sistemin hangi bilgileri sakladığının ve bunların birbiriyle ilişkisinin tarifidir. Örneğin bir randevu sistemi için “kullanıcı”, “hizmet” ve “randevu” varlıkları ile bunlar arasındaki bağ yazılır. Hangi alanın zorunlu, hangisinin benzersiz olduğu ve bir kaydın silinince ilişkili kayıtlara ne olacağı bu aşamada kararlaştırılır; sonradan değiştirmek, canlı veri bulunduğu için daha zahmetlidir.

Entegrasyon, yazılımın dış bir sistemle veri alışverişi yapmasıdır: e-posta servisi, ödeme sağlayıcısı, harita, muhasebe programı ya da kurumun mevcut API'si gibi. Her entegrasyon için şu bilgiler çıkarılmalıdır: karşı sistemin dokümantasyonu var mı, erişim anahtarını kim sağlayacak, karşı taraf yanıt vermezse yazılım ne yapacak ve bu bağlantı için kullanım şartları veya ek maliyet var mı.

Kişisel veri işleyen bir yazılımda veri modeli aynı zamanda hukuki bir karardır. Hangi kişisel verinin neden toplandığı, ne kadar süre saklanacağı ve kimlerin erişebileceği tasarım aşamasında yazılırsa, canlıya çıktıktan sonra veri yapısını ve erişim kurallarını yeniden düzenleme ihtiyacı azalır.

Gereksinim özeti şablonu: kopyalayıp doldurulabilecek taslak

Gereksinim özeti, projenin tek sayfalık sözleşme öncesi tarifidir ve aşağıdaki şablon doğrudan kopyalanıp doldurulabilir. Teklif isteyen kişi bu başlıkları doldurarak göndermişse, hem teklif veren hem de isteyen aynı varsayımlarla konuşmaya başlamış olur.

Şablon bir standart değildir; yazılımın türüne göre başlık eklenebilir ya da çıkarılabilir. Boş bırakılan başlık, “henüz karar verilmedi” anlamına gelir ve bunun kendisi de değerli bir bilgidir.

Gereksinim özeti şablonu

PROJE ADI:
HAZIRLAYAN / TARİH:

1) AMAÇ (tek cümle)
   Bu yazılım ............ sorununu çözecek.
   Başarı şu şekilde anlaşılır: ............

2) KULLANICI ROLLERİ
   Rol 1: ............  Yapabilecekleri: ............
   Rol 2: ............  Yapabilecekleri: ............

3) İLK SÜRÜM KAPSAMI
   Olmazsa olmaz: ............
   Önemli ama ertelenebilir: ............
   Kapsam dışı (açıkça yaz): ............

4) ANA KULLANICI AKIŞLARI
   Akış 1: ............ -> ............ -> ............ (hata durumu: ............)
   Akış 2: ............

5) VERİ
   Saklanacak başlıca veriler: ............
   Kişisel veri var mı? Evet / Hayır. Varsa amaç ve saklama süresi: ............
   Mevcut veriler taşınacak mı? Kaynağı ve biçimi: ............

6) ENTEGRASYONLAR
   Sistem adı / amaç / erişimi kim sağlayacak / karşı sistem yanıt vermezse ne olacak: ............

7) ALAN ADI, SUNUCU VE YAYIN
   Alan adı kimde: ............   Mevcut hosting var mı: ............
   Yayın ortamı ve yedekleme beklentisi: ............

8) İÇERİK VE GÖRSELLER
   Kim hazırlayacak, hangi tarihe kadar, kim onaylayacak: ............

9) KABUL ÖLÇÜTLERİ
   “Bitti” demek için şu senaryolar çalışmalı: ............

10) KISITLAR VE VARSAYIMLAR
    Takvim baskısı, mevzuat, tercih edilen teknoloji, bilinen riskler: ............

11) DEĞİŞİKLİK TALEPLERİ
    Yeni istekler yazılı iletilir; etkisi (kapsam/takvim/maliyet) yazılı yanıtlanır, onaydan sonra işe alınır.

12) İLETİŞİM VE ONAY
    Karar verici kişi: ............   Onay yöntemi: ............

Şablonun 3. ve 11. maddeleri en kritik olanlardır: ilki neyin yapılmayacağını, ikincisi yeni isteklerin nasıl ele alınacağını yazılı hale getirir. Bu özet teklif aşamasında paylaşılırsa kapsam, teklifte yazılı olarak netleştirilebilir.

Test, güvenlik ve kişisel veri temelleri planlamaya nasıl girer?

Test ve güvenlik, proje sonunda eklenen bir adım değil, gereksinim aşamasında yazılan kabul ölçütleridir. Her ana akış için “şu senaryo çalışmalı” cümlesi yazmak, test planının ilk halidir; hata durumlarını, yanlış girdiyi ve yetkisiz erişim denemesini de bu senaryolara eklemek gerekir.

Güvenlik için başvurulabilecek iki OWASP kaynağı vardır. OWASP Top 10, web uygulamalarındaki en kritik güvenlik risklerini listeleyen bir farkındalık belgesidir; 2025 sürümünde yetkilendirme hataları (Broken Access Control), güvenlik yapılandırma hataları, enjeksiyon, kimlik doğrulama hataları ve güvensiz tasarım gibi başlıklar yer alır. OWASP ASVS (Application Security Verification Standard) ise güvenlik gereksinimlerini sınanabilir maddeler halinde veren bir doğrulama standardıdır; sayfasında 5.0.0 sürümü kararlı sürüm olarak görünür. Birincisi “neye dikkat etmeliyim” listesidir, ikincisi “şartnameye hangi maddeleri koyabilirim” listesidir.

MDN'nin web güvenliği sayfası da pratik bir başlangıç noktasıdır. Sayfada tüm sayfaların ve alt kaynakların HTTPS ile sunulması, bir Content Security Policy (CSP) başlığı tanımlanması, çerezlerde SameSite, Secure ve HttpOnly niteliklerinin kullanılması, kullanıcı girdisinin doğrulanıp çıktının uygun biçimde kodlanması ve kullanıcı girişinde parolanın tek başına kullanılmaması, mümkünse passkey tercih edilmesi öneriliyor.

Kişisel veri işleyen yazılımlarda KVKK'nın yayımladığı Kişisel Veri Güvenliği Rehberi (Ocak 2018) de başvuru kaynağıdır. Rehber, veri sorumlularına yönelik yazılmıştır ve yeni sistemler geliştirilirken ihtiyaçlar belirlenirken güvenlik gereksinimlerinin göz önüne alınmasını, uygulamalarda girdi doğruluğuna dair kontroller bulunmasını, log kayıtlarının tutulmasını ve yedeklerin korunmasını ele alır. Hukuki yükümlülükler için yazılımı kullanacak kurumun veri sorumlusu olarak kendi danışmanından destek alması gerekir; bu yazı hukuki görüş değildir.

Arama motorlarından görünürlük isteniyorsa, sayfaları tarayıcıda JavaScript ile oluşturan uygulamalarda ayrıca Google'ın JavaScript SEO rehberi okunmalıdır. Rehberde Google'ın tarama, işleme (render) ve dizine ekleme aşamalarından geçtiği, sayfaların benzersiz başlıklara sahip olması gerektiği, tek sayfalık uygulamalarda URL parçaları yerine History API kullanılmasının önerildiği ve olmayan sayfalarda anlamlı HTTP durum kodlarının döndürülmesi gerektiği belirtiliyor.

Yayın ve bakım nasıl planlanır, teslimde neler istenmelidir?

Yayın planı, yazılımın test ortamından canlı ortama hangi sırayla, kimin onayıyla ve geri dönüş seçeneğiyle taşınacağının yazılı halidir. Bakım planı ise yayın sonrası güncellemelerin, yedeklerin ve hata düzeltmelerinin kimin sorumluluğunda olacağını belirler; bu ikisi planlanmadığında ilk önemli hata, kimin ne yapacağı tartışmasına dönüşür.

Yayın ve bakımla ilgili konuşulacak başlıklar şunlardır: alan adı ve sunucu kimin adına kayıtlı, yedekler nerede ve ne sıklıkla alınıyor, yedekten geri dönüş denendi mi, güvenlik güncellemeleri kim tarafından uygulanıyor, hata bildirimi hangi kanaldan yapılıyor ve değişiklik talepleri nasıl ele alınıyor. Bu başlıklara verilecek cevaplar teklifte ve sözleşmede yazılı olmalıdır.

Teslim aşamasında müşterinin aşağıdaki on maddeyi istemesi, sonraki dönemde yaşanabilecek bağımlılık ve belirsizlik riskini azaltır. Liste genel bir kontrol çerçevesidir; her projede hepsi geçerli olmayabilir, ama her madde için “gerekmiyor” demek de bilinçli bir karar olmalıdır.

1. Kaynak kod deposuna erişim ya da kodun tam kopyası ve hangi sürümün yayında olduğunu gösteren bir kayıt.
2. Kurulum ve yayın yönergesi: yazılımın sıfırdan başka bir sunucuya nasıl kurulacağını adım adım anlatan belge.
3. Yönetici hesapları, alan adı ve sunucu erişimlerinin müşteri adına kayıtlı olduğunun teyidi; gizli anahtarların güvenli bir yolla devri.
4. Kullanılan üçüncü taraf kütüphane, servis ve entegrasyonların listesi; lisans ve abonelik bilgileri.
5. Veri modelinin ve veritabanı yapısının belgesi; mümkünse örnek veriyle birlikte.
6. Kabul senaryolarının sonuçları: hangi senaryo, kim tarafından, hangi tarihte denendi ve sonucu neydi.
7. Yedekleme düzeninin tarifi ve yedekten geri dönüşün en az bir kez denendiğine dair kayıt.
8. Güvenlik kontrol notları: yapılan kontroller, bilinen açık noktalar ve ertelenen maddeler.
9. Bakım ve destek kapsamının yazılı tanımı: neyin kapsam içinde, neyin ayrı iş olduğu ve hata bildirim kanalı.
10. Kapsam dışı bırakılan ve ikinci sürüme ertelenen maddelerin güncel listesi.

Müşteri ve geliştirici sorumlulukları nasıl paylaşılır?

Sorumluluk paylaşımı, projede hangi kararı kimin vereceğini ve hangi girdiyi kimin sağlayacağını yazmaktır. Gecikmeler yalnızca teknik sorunlardan değil, bekleyen bir içerikten, verilmeyen bir erişim bilgisinden ya da kimsenin onaylamadığı bir karardan da kaynaklanabilir; bu yüzden müşterinin payına düşen işler de planın içinde görünür olmalıdır.

Aşağıdaki tablo tipik bir dağılımı gösterir. Her projede aynı olmak zorunda değildir; önemli olan tablonun baştan doldurulmuş olmasıdır.

Kapsam kayması nedir ve nasıl yönetilir?

Kapsam kayması (scope creep), proje başladıktan sonra yazılı kapsama kontrolsüzce yeni isteklerin eklenmesidir; yönetilmediğinde takvim ve maliyet, tarafların fark etmediği şekilde değişir. Genellikle kötü niyetten değil, ürün görünür hale geldikçe yeni fikirler doğmasından kaynaklanır; bu yüzden yasaklamak yerine bir karşılama düzeni kurmak daha sağlıklıdır.

Yönetim yöntemi basittir: her yeni isteği tek bir yere yaz, etkisini (kapsam, takvim, maliyet) yazılı olarak yanıtla, onaylanırsa işi ekle, onaylanmazsa ikinci sürüm listesine al. İki tarafın da ilk kez duyduğu şeyi aynı toplantıda karara bağlamamak ve her kararı yazılı kayda geçirmek yeterlidir.

Kapsam kaymasının erken sinyalleri şunlardır: “bunu da yapabiliriz” cümlesinin sıkça duyulması, kabul ölçütlerinin değişmesi, aynı ekranın tekrar tekrar baştan tasarlanması ve onaylanmış belgelerin güncellenmeden iş yapılması.

• Her değişiklik talebi yazılı gelir; sözlü istek not alınıp yazılı teyide çevrilir.
• Her talebin etkisi aynı yazıda bildirilir: ne eklenecek, neyin yerine geçecek, takvimi nasıl etkiler.
• Onaylanan talepler gereksinim özetinin güncel sürümüne işlenir; eski sürüm saklanır.
• Onaylanmayan ya da ertelenen talepler “ikinci sürüm listesi”nde toplanır, kaybolmaz.
• Her aşamanın sonunda kabul toplantısı yapılır; kabul edilen kısım için yeni istek yeni iş sayılır.

Sık sorulan sorular

Kaynaklar

1. OWASP Top 10:2025
2. OWASP Application Security Verification Standard (ASVS)
3. MDN Web Docs: Web security
4. KVKK: Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler), Ocak 2018
5. Google Search Central: JavaScript SEO temelleri (son güncelleme 4 Mart 2026)