Website Gereksinim Dokümanı Nasıl Yazılır
Gereksinim dokümanı, sizin ve geliştiricinin aynı website’i tarif ettiğinizden emin olmak içindir. Uzun olmak zorunda değildir. İki tarafın da gerçekten okuduğu dört sayfalık bir brief, ikisinin de bitirmediği elli sayfalık bir şartnameden daha çok anlaşmazlığı önler.
Bu rehber içine ne gireceğini, neyi dışarıda bırakacağınızı ve en önemli bölümü — projenin ne OLMADIĞINI — nasıl yazacağınızı ele alıyor.
Gereksinim dokümanı ne işe yarar#
Üç işi vardır: birkaç geliştiricinin aynı şeyi fiyatlamasını sağlamak (böylece teklifler karşılaştırılabilir olur), kapsam tartışmasında bir başvuru noktası olmak ve kararları hâlâ ucuzken almanızı zorlamak.
Bir tasarım briefi değildir ve teknik bir şartname değildir. "Site hızlı yüklenmeli" bir gereksinimdir; "nesne önbelleği için Redis kullanın" bir çözümdür ve kimseyi işe almadan önce seçmek, parasını ödediğiniz uzmanlığı devre dışı bırakır.
- Uygulamayı değil sonucu ve kısıtları yazın.
- Kurumunuzun dışındaki biri telefona ihtiyaç duymadan anlayabilsin.
- Tek oturumda okunacak kadar kısa tutun — çoğu site için dört ile sekiz sayfa fazlasıyla yeter.
- Tarih ve sürüm koyun, çünkü değişecek.
İçermeye değer bölümler#
Bu yapı çoğu website geliştirme projesini kapsar. Geçerli olmayan bölümleri doldurmak yerine atlayın.
| Bölüm | İçine ne girer |
|---|---|
| Arka plan | Kurumun ne yaptığı ve sitenin neden yapıldığı ya da değiştirildiği |
| Hedefler | Birincil hedef, ikincil hedefler ve başarının nasıl ölçüleceği |
| Kitle | İki üç ziyaretçi grubu ve her birinin geldiği soru |
| Sayfa yapısı | Bölümlere ayrılmış, yayın-kritik ya da sonra diye işaretlenmiş her sayfa |
| İşlevsel gereksinimler | Formlar, arama, hesaplar, filtreleme, rezervasyon, ödeme — her birinin ne yapacağı |
| Entegrasyonlar | Her dış sistem, bir kişi adı ve API belgesi bağlantısıyla |
| İçerik | Her sayfayı kim yazacak, kim onaylayacak, ne zaman teslim |
| İşlevsel olmayan | Performans, erişilebilirlik, tarayıcı ve cihaz desteği, diller, güvenlik |
| Kapsam dışı | Açıkça hariç tutulan işler — en değerli bölüm |
| Kısıtlar | Bütçe aralığı, teslim tarihi ve sabit kararlar (mevcut hosting, zorunlu CMS) |
Sınanabilir gereksinimler yazın#
Bir gereksinim, iki tarafın da sonradan karşılanıp karşılanmadığında anlaşabildiğinde işe yarar. "Site hızlı olmalı" sınanamaz; "ürün liste sayfası 4G üzerinde orta seviye bir Android’de 2,5 saniyenin altında Largest Contentful Paint’e ulaşmalı" sınanabilir.
Aynısı işlevsellik için de geçerli. "Bir iletişim formu" önemli olan her soruyu dışarıda bırakır.
| Muğlak | Sınanabilir |
|---|---|
| Bir iletişim formu | Altı alan, spam koruması, veritabanına kayıt, iki adrese e-posta, KVKK onay satırı |
| Mobil uyumlu | 320px’te kullanılabilir, tüm dokunma hedefleri en az 44px, yatay kaydırma yok |
| Hızlı | Dört ana şablonda 4G’de LCP 2,5 sn altı ve CLS 0,1 altı |
| Erişilebilir | Şablonlarda WCAG 2.2 AA, klavye ve ekran okuyucu geçişleriyle doğrulanmış |
| SEO uyumlu | Düzenlenebilir başlık ve açıklama, temiz URL, site haritası, makalelerde yapısal veri |
| Çok dilli | Üç dil, çevrilmiş URL’ler, hreflang etiketleri, her sayfada dil değiştirici |
Kapsam dışı listesi#
İnsanların atladığı ve projeyi kurtaran bölüm budur. Aklı başında birinin dahil sanabileceği şeyleri yazın ve açıkça dahil olmadıklarını söyleyin — ya da olmaları gerekiyorsa içeri alın.
Bunu teklifler gelmeden yapmak teklifleri karşılaştırılabilir kılar. Sonra yapmak bir tartışma demektir.
- Metin yazımı ve düzelti — teklif aksini söylemedikçe sizde sayın.
- Fotoğraf, illüstrasyon ve stok lisansları.
- İçerik girişi: 200 ürünü CMS’e kim yazacak?
- E-posta kurulumu, DNS taşıma ve hosting hesabı devri.
- Yayında teknik SEO kurulumundan ayrı olarak süregiden SEO çalışması.
- Eğitim, dokümantasyon ve devir.
- Yayın sonrası destek: ne kapsamda, ne kadar süreyle ve neyi faturalıyorsunuz.
İyi bir geliştirici bu listeye siz sormadan ekleme yapar. Soru sormadan her şeye evet diyen biri genelde belgeyi okumamıştır ve anlaşmazlık sadece ertelenmiştir.
Sık sorulan sorular
Gereksinim dokümanı ne kadar uzun olmalı?
Çoğu işletme sitesi için dört ile sekiz sayfa yeter. Mağaza ve uygulamalarda işlevsel bölüm büyüdüğü için daha uzun olur, ama yirmi sayfayı aşıyorsa bir konuşmanın çözemeyeceği neyin anlatıldığını sorun. Ölçüt kapsamlı olması değil, iki tarafın da okumuş olmasıdır.
Teknolojiyi belirtmeli miyim?
Yalnız gerçek bir kısıtınız varsa: ekibinizin bildiği mevcut bir CMS, kalmak zorunda olduğunuz bir hosting, entegre edilmesi gereken bir sistem. Aksi hâlde sonucu yazın ve uygulamayı işe aldığınız kişilere bırakın. Anlamadığınız bir teknolojiyi şart koşmak seçeneklerinizi daraltır ve size daha kötü bir cevap verir.
Tel çerçeve de gerekli mi?
En önemli üç dört şablon için düşük çözünürlüklü tel çerçeveler çok az emekle çok fazla belirsizliği kaldırır ve bir tasarımdan çok daha ucuza değişir. Yazılı gereksinimin yerine geçmezler — düzeni gösterirler, davranışı değil — ama ikisi birlikte her birinin tek başına yapabileceğinden çok daha doğru fiyatlanır.
Bazı cevapları bilmiyorsam?
"Karara bağlanacak" yazın ve kimin, ne zamana kadar karar vereceğini belirtin. Sahibi olan dürüst bir boşluk sorun değil; uydurulmuş bir cevap sorundur, çünkü teklif onun üzerine kurulur. Geliştiriciler belirsizliği zaten fiyatlıyor, o yüzden belirsizliği görünür kılmak genelde saklamaktan daha iyi bir rakam getirir.
website gereksinim dokümanıwebsite briefiweb sitesi şartnamesiproje kapsamısite yaptırma briefweb geliştirme gereksinimleri
