Teknik şartname, çözümü gereksiz ayrıntıyla kilitleyen bir ürün listesi değil; işletmenin ihtiyacını, beklenen davranışı ve teslimin nasıl doğrulanacağını ortaklaştıran çalışma belgesidir. İyi hazırlanmış bir şartname, teklifleri aynı ölçütlerle karşılaştırmayı ve kapsam değişikliklerini yönetmeyi kolaylaştırır.
Bu rehberde ne bulacaksınız?
İş hedefini fonksiyonel gereksinime çevirmeyi, performans ve erişilebilirlik gibi kalite ölçütlerini test edilebilir yazmayı, teslimat sahipliğini belirlemeyi ve kabul sürecini planlamayı öğreneceksiniz.
İş hedefini ve kapsam sınırını yazın
Şartnameye teknoloji adıyla değil, sitenin çözmesi gereken kullanıcı ve işletme problemiyle başlayın. İlk sürümde bulunacak sayfaları, dilleri, kullanıcı rollerini ve kapsam dışında kalacak işleri ayrı gösterin.
Fonksiyonel gereksinimleri senaryolaştırın
“İletişim formu olacak” yerine kimin, hangi alanlarla, hangi doğrulama ve başarı davranışıyla form göndereceğini açıklayın.
- Her işlev için kullanıcı, tetikleyici ve beklenen sonucu yazın.
- Hata, boş veri ve tekrar gönderim senaryolarını ekleyin.
- Yönetim panelinde değiştirilecek alanları belirtin.
Kapsam dışını görünür yapın
Belirsiz bırakılan içerik, entegrasyon ve lisans işleri daha sonra taraflarca farklı yorumlanabilir.
- Metin ve görsel üretim sorumluluğunu ayırın.
- Alan adı, hosting ve üçüncü taraf ücretlerini belirtin.
- Sonraki faza bırakılan fikirleri ayrı listeleyin.
Kalite gereksinimlerini ölçülebilir kurun
“Hızlı, güvenli ve mobil uyumlu” ifadeleri test yöntemi olmadan kabul ölçütü değildir. Ölçüm ortamı, örnek sayfalar ve başarısızlık eşiği tanımlanmalıdır.
Performans bütçesi belirleyin
Core Web Vitals saha hedeflerini izleyin; geliştirme kabulünde ayrıca kontrollü laboratuvar testleri ve varlık bütçeleri kullanın.
- Kritik şablonlar için ölçüm URL’leri seçin.
- Görsel, font ve üçüncü taraf script sınırlarını yazın.
- Test cihazı, bağlantı koşulu ve cache durumunu kaydedin.
Erişilebilirlik ölçütünü açıklayın
Hedeflenen WCAG sürümü ve uygunluk düzeyi belirtilmeli; klavye, odak, kontrast, form etiketi ve hata mesajı kontrolleri teslim testine eklenmelidir.
- Kritik kullanıcı akışlarını yalnız klavyeyle test edin.
- Metin ve arayüz kontrastını araçla doğrulayın.
- Form hatalarının ekran okuyucuya aktarımını kontrol edin.
Teknik sahiplik ve güvenlik sınırlarını tanımlayın
Şartname; hesap sahipliği, yetki modeli, veri akışı, yedek, güncelleme ve olay sorumluluğunu proje başlamadan netleştirmelidir.
Hesap ve veri sahipliğini koruyun
Alan adı, hosting, analitik ve yönetim hesapları işletme adına açılmalı; hizmet sağlayıcıya işi için gereken en düşük yetki verilmelidir.
- Teslim edilecek kullanıcı ve erişim listesini yazın.
- Şifre yerine ayrı kullanıcı ve güvenli paylaşım kullanın.
- Üçüncü taraf veri aktarımını envantere ekleyin.
Bakım sorumluluğunu teslimata bağlayın
Yayın sonrasında çekirdek, tema, eklenti, sertifika, yedek ve güvenlik uyarılarını kimin izleyeceği belirtilmelidir.
- Güncelleme ve test sıklığını tanımlayın.
- Yedek saklama ile geri yükleme sorumlusunu yazın.
- Kritik olay iletişim ve müdahale süresini belirleyin.
Kabul testini ve değişiklik yönetimini planlayın
Teslimin yalnız görsel onayla tamamlanması, işlev ve SEO hatalarının sonradan fark edilmesine yol açabilir. Her gereksinim için doğrulama kanıtı ve onay sahibi bulunmalıdır.
Kabul matrisi hazırlayın
Gereksinim, örnek URL, test adımı, beklenen sonuç, sorumlu ve durum bilgilerini tek tabloda izleyin.
- Mobil ve masaüstü akışlarını ayrı test edin.
- Form, yönlendirme, canonical ve sitemap çıktılarını doğrulayın.
- Başarısız test için düzeltme ve yeniden test kaydı açın.
Değişiklik talebini kontrollü yönetin
Yeni isteklerin süre, maliyet ve diğer gereksinimlere etkisi onaylanmadan uygulamaya alınmamalıdır.
- Talebin gerekçesini ve önceliğini kaydedin.
- Kapsam, süre ve bağımlılık etkisini değerlendirin.
- Onaylanan yeni kapsam temelini saklayın.
Resmi kaynaklar
Özellikler ve platform kuralları zamanla değişebilir. Uygulama öncesinde aşağıdaki birincil kaynakların güncel sürümünü kontrol edin.