Portal yazılımı teklifi almadan önce projenin amacı, kullanıcıları, iş akışları, modülleri, entegrasyonları ve kalite beklentileri yazılı hâle getirilmelidir. Teknik şartname, yalnızca özelliklerin sıralandığı bir belge değil; yazılım firmalarının aynı kapsamı, teslimatları ve sorumlulukları fiyatlandırmasını sağlayan ortak değerlendirme temelidir. Kullanıcı rolleri, veri aktarımı, UX/UI, güvenlik, test, hosting, lisans ve bakım koşulları belirsiz bırakıldığında teklifler sağlıklı karşılaştırılamaz. Bu rehber, ihtiyaç belgesinin hazırlanmasından sahiplik hakları, kabul, garanti ve devir teslim maddelerine kadar teklif sürecinin temel adımlarını açıklamaktadır.
Portal Yazılımı Teklifi Öncesinde Neler Hazırlanmalıdır?
Portal yazılımı teklifi öncesinde işletmenin hedefleri, çözülecek süreç sorunları, kullanıcı grupları, mevcut sistemler ve beklenen sonuçlar tanımlanmalıdır. Firma henüz seçilmeden hazırlanan bu başlangıç çerçevesi, adayların aynı ihtiyacı anlamasını ve farklı çözüm yaklaşımlarını ortak bir zemin üzerinde açıklamasını sağlar.
Başlangıç belgesinin amacı nedir?
İhtiyaç belgesi her teknik kararı önceden vermek zorunda değildir; ancak mevcut durum, öncelikler, kısıtlar, bağımlılıklar ve karar bekleyen konular görünür olmalıdır. Kurumsal yazılım çözümlerinin planlanması yaklaşımında olduğu gibi kapsam, iş hedeflerinden teknik teslimatlara doğru ilerlemelidir.
- Portalın çözmesi gereken iş sorunlarını tanımlayın.
- Hedef kullanıcıları ve kurum içi paydaşları belirleyin.
- Mevcut süreçleri ve kullanılan sistemleri listeleyin.
- Öncelikli sonuçları ve başarı ölçütlerini açıklayın.
- Bilinen kısıtları ve teknik bağımlılıkları belirtin.
- Karar verilmesi gereken belirsizlikleri kaydedin.
Planlar değersizdir; fakat planlama her şeydir. - Dwight D. Eisenhower
Portal Teknik Şartnamesinin Kapsamı Nasıl Kurulur?
Portal teknik şartnamesi; iş hedeflerini, kullanıcı ihtiyaçlarını, işlevsel gereksinimleri, teknik kaliteyi, teslimatları ve ticari sorumlulukları aynı yapıda birleştirmelidir. Belge yalnızca yazılım firmasından fiyat istemek için değil, proje boyunca kapsamı doğrulamak ve teslimat kabulünü yönetmek için de kullanılmalıdır.
Şartname hangi ana bölümlerden oluşmalıdır?
Her gereksinime benzersiz bir tanım veya referans verilmesi, firmaların cevaplarını karşılaştırmayı kolaylaştırır. Adaylardan her madde için kapsamda, alternatif çözüm, varsayıma bağlı veya kapsam dışı gibi açık yanıtlar istenebilir. Böylece belirsiz ifadeler ve teklif içinde görünmeyen farklı yorumlar azaltılır.
- Proje amacı, kapsamı ve başarı ölçütleri
- Kullanıcı grupları, roller ve iş akışları
- Modüller, formlar ve raporlama gereksinimleri
- Tasarım, yazılım ve entegrasyon teslimatları
- Güvenlik, performans ve test kriterleri
- Sahiplik, garanti, bakım ve devir koşulları
Portal Kullanıcıları ve Rolleri Nasıl Tanımlanmalıdır?
Portal kullanıcıları ve rolleri, yalnızca müşteri, bayi, çalışan veya yönetici adlarıyla değil; erişebilecekleri veriler ve gerçekleştirebilecekleri işlemler üzerinden tanımlanmalıdır. Kullanıcının bağlı olduğu şirket, departman, bölge veya bayi grubu ile işlem limiti ve onay düzeyi de yetkilendirme kapsamına eklenmelidir.
Rol ve yetki matrisi neleri göstermelidir?
Rol matrisi, arayüzde gösterilecek menülerden daha geniş bir güvenlik tanımıdır. Sunucu tarafındaki veri sorguları, kayıt oluşturma, güncelleme, silme, onaylama ve dışa aktarma yetkileri ayrı ayrı belirtilmelidir. Kayıt, davet, hesap etkinleştirme, şifre yenileme ve erişim iptali gibi kullanıcı yaşam döngüsü de açıklanmalıdır.
- Kullanıcı grubu ve bağlı olduğu organizasyon
- Görüntüleyebileceği veri ve kayıt kapsamı
- Oluşturabileceği veya değiştirebileceği işlemler
- Onay yetkisi, işlem limiti ve vekâlet kuralları
- Giriş ve çok faktörlü doğrulama gereksinimleri
- Hesap kapatma ve yetki iptali süreçleri
Portal Modülleri ve İş Akışları Nasıl Yazılmalıdır?
Portal modülleri, yalnızca profil, belge, sipariş veya destek gibi başlıklarla değil; kullanan rol, işlenen veri, işlem adımları, iş kuralları, onaylar ve sonuçlar üzerinden yazılmalıdır. Aynı modül adı basit bir görüntüleme ekranından çok aşamalı ve entegre bir sürece kadar farklı kapsamlar taşıyabilir.
Fonksiyon tanımı hangi ayrıntıları içermelidir?
Her kullanım senaryosunda işlemi başlatan olay, beklenen sonuç, hata durumu, iptal yöntemi, bildirim ve yetki kontrolü belirtilmelidir. Öncelikli fonksiyonlarla sonraki aşamaya bırakılabilecek özelliklerin ayrılması, firmaların tekliflerini aynı faz yapısında vermesini ve kapsam değişikliklerinin daha kontrollü yönetilmesini sağlar.
- Modülü kullanan roller ve kullanım amacı
- Girdi verileri ve oluşturulan kayıtlar
- İşlem adımları ve iş kuralları
- Onay, ret, iptal ve istisna durumları
- Bildirimler ve bağlantılı sistem işlemleri
- Kabul kriterleri ve öncelik seviyesi
Portal Formları ve Raporları Nasıl Kapsamlandırılır?
Portal formları ve raporları, genel modül adlarının altında belirsiz bırakılmamalıdır. Formlarda veri alanları, doğrulamalar, dosya yüklemeleri ve onaylar; raporlarda ise göstergeler, filtreler, veri kaynakları, güncelleme sıklığı, kullanıcı yetkileri ve dışa aktarma seçenekleri tanımlanmalıdır.
Belirsiz teslimatlar nasıl önlenir?
“Gelişmiş form” veya “kapsamlı raporlama” gibi ifadeler firmalar tarafından farklı yorumlanabilir. Formların örnek alan setleri ve raporların örnek çıktı yapıları şartnameye eklenebilir. Dinamik filtre, grafik, tablo, dosya çıktısı veya zamanlanmış gönderim gibi ihtiyaçlar ayrı gereksinimler olarak belirtilmelidir.
- Zorunlu, isteğe bağlı ve koşullu form alanları
- Veri tipi, biçim ve doğrulama kuralları
- Dosya yükleme ve belge kontrol koşulları
- Rapor göstergeleri, filtreleri ve tarih aralıkları
- Rol bazlı rapor ve veri erişimi
- Dışa aktarma ve zamanlanmış gönderim seçenekleri
Portal Tasarım ve Yazılım Teslimatları Nasıl Ayrılır?
Portal tasarım ve yazılım teslimatları; kullanıcı araştırması, bilgi mimarisi, wireframe, UX/UI, responsive arayüz, frontend, backend, API, veritabanı ve yönetim paneli olarak ayrı gösterilmelidir. Bu ayrım, hazır tema uyarlaması ile özgün tasarımın ve standart modül yapılandırması ile özel geliştirmenin karıştırılmasını önler.
Responsive ve erişilebilir tasarım nasıl tanımlanır?
Responsive tasarım yalnızca portalın mobil cihazda açılması anlamına gelmez. Formlar, tablolar, dashboard bileşenleri, menüler ve kritik iş akışları farklı ekranlarda kullanılabilir olmalıdır. Klavye erişimi, renk kontrastı, odak sırası ve anlaşılır hata mesajları gibi erişilebilirlik gereksinimleri de kabul kriterlerine eklenmelidir.
- Kullanıcı akışları, wireframe ve prototipler
- Arayüz bileşenleri ve tasarım sistemi
- Masaüstü, tablet ve mobil uygulama davranışları
- Frontend ve backend geliştirme kapsamı
- API, veritabanı ve yönetim paneli
- Erişilebilirlik ve kullanılabilirlik kontrolleri
Portal Entegrasyonları Şartnamede Nasıl Tanımlanır?
Portal entegrasyonları, yalnızca ERP, CRM, ödeme veya kargo sistemi adlarıyla tanımlanmamalıdır. Aktarılacak veri, ana veri kaynağı, senkronizasyon yönü, güncelleme sıklığı, kimlik doğrulama, hata davranışı ve teknik sorumluluk her bağlantı için ayrı biçimde açıklanmalıdır.
Entegrasyon teklifleri nasıl karşılaştırılabilir?
Adayların aynı entegrasyon kapsamını fiyatlandırabilmesi için kullanılabilir API, test ortamı, erişim yetkileri ve sağlayıcı bağımlılıkları belirtilmelidir. ERP ve CRM ile kurumsal yazılım entegrasyonu planlanırken veri eşleştirme, yeniden deneme, kayıt tutma ve mutabakat işlemleri de teslimatlara eklenmelidir.
- Bağlanacak sistem ve teknik iletişim sorumlusu
- Aktarılacak veri kümeleri ve ana kaynak
- Tek veya çift yönlü senkronizasyon
- Gerçek zamanlı veya zamanlanmış aktarım
- Hata kaydı, yeniden deneme ve bildirim
- Güvenlik, test ve veri mutabakatı
Portal Veri Aktarımı Hangi Adımlarla Tarif Edilir?
Portal veri aktarımı, mevcut kayıtların yeni sisteme tek seferde yüklenmesi şeklinde tarif edilmemelidir. Kaynak verilerin incelenmesi, temizlenmesi, alanlarla eşleştirilmesi, dönüştürülmesi, deneme ortamına aktarılması ve sonuçların iş birimleriyle doğrulanması ayrı çalışmalar olarak tanımlanmalıdır.
Veri kabul kriterleri nasıl hazırlanır?
Hangi kayıtların taşınacağı, tarihsel verinin ne kadarının korunacağı, hatalı veya eksik kayıtların nasıl ele alınacağı ve dosya eklerinin nasıl aktarılacağı açıklanmalıdır. Aktarım sonrasında kayıt sayıları, finansal toplamlar, durum bilgileri veya örnek veri kümeleri üzerinden mutabakat yapılmalı; geri dönüş yöntemi yayına geçmeden belirlenmelidir.
- Kaynak sistemler ve taşınacak veri kapsamı
- Veri temizleme ve alan eşleştirme kuralları
- Dönüştürme ve eksik kayıt politikaları
- Deneme aktarımı ve örnek veri kontrolleri
- Mutabakat ve kullanıcı onayı ölçütleri
- Canlı aktarım ve geri dönüş planı
Portal Kalite ve Test Kriterleri Nasıl Belirlenir?
Portal kalite ve test kriterleri, “hızlı”, “güvenli”, “mobil uyumlu” veya “SEO uyumlu” gibi genel sıfatlar yerine doğrulanabilir koşullarla belirlenmelidir. Gereksinimin hangi ortamda, hangi veriyle, kim tarafından ve hangi başarı ölçütüyle test edileceği teknik şartnamede açıklanmalıdır.
Test ve kullanıcı kabulü nasıl ayrılır?
Yazılım ekibinin gerçekleştirdiği birim, entegrasyon, işlevsel, yetki, güvenlik ve performans testleri kalite güvence kapsamındadır. Kullanıcı kabul testi ise işletmenin gerçek senaryolarla teslimatın ihtiyacı karşılayıp karşılamadığını doğrulamasıdır. Hata seviyeleri, düzeltme yöntemi, yeniden test ve kabul yetkisi başlangıçta belirlenmelidir.
- İşlevsel ve uçtan uca süreç testleri
- Rol, yetki ve veri erişimi kontrolleri
- Entegrasyon ve hata senaryosu testleri
- Tarayıcı, cihaz ve erişilebilirlik kontrolleri
- Performans ve güvenlik değerlendirmeleri
- Kullanıcı kabulü ve hata öncelikleri
Portal Teklifinde Lisans ve Sahiplik Nasıl Gösterilir?
Portal teklifinde hosting, sunucu, alan adı, SSL, lisanslar, eklentiler ve üçüncü taraf servisler ayrı kalemlerle gösterilmelidir. Her giderin ilk yatırıma mı, dönemsel kullanıma mı yoksa işlem hacmine mi bağlı olduğu; kimin adına açılacağı ve proje sonrasında kim tarafından yönetileceği açıklanmalıdır.
Kaynak kodu sahipliği nasıl güvence altına alınır?
Kaynak kodu sahipliği; kod deposu, sürüm geçmişi, kullanım hakları, bağımlılıklar, yapılandırmalar ve dağıtım bilgilerini kapsamalıdır. Veri tabanı, tasarım dosyaları, dokümantasyon, alan adı, sunucu ve üçüncü taraf hesapları ayrıca değerlendirilmelidir. Bu koşulların yazılım projesi sözleşmesinde bulunması gereken maddelerle uyumlu olması gerekir.
- Hosting, lisans ve servis giderleri
- Kod deposu ve kaynak kodu erişimi
- Veri tabanı ve yedeklerin sahipliği
- Tasarım dosyaları ve teknik dokümantasyon
- Alan adı, sunucu ve kurumsal hesaplar
- Lisans kullanım ve devir hakları
Portal Yazılım Firması Teklifleri Nasıl Karşılaştırılır?
Portal yazılım firması teklifleri, aynı şartnameye verilen yanıtlar; teslimatlar, varsayımlar, kapsam dışı işler, sahiplik hakları ve destek koşulları üzerinden karşılaştırılmalıdır. Toplam bedel tek başına yeterli değildir; bir teklifte bulunan analiz, test, veri aktarımı, lisans, garanti veya dokümantasyon diğerinde bulunmayabilir.
Garanti, bakım ve devir maddeleri nasıl yazılır?
Garanti, mevcut kapsam içindeki yazılım hatalarının giderilmesini; bakım ve teknik destek ise ayrıca tanımlanmış işletim hizmetlerini kapsamalıdır. Yeni özellikler ayrı değişiklik süreciyle yönetilmelidir. Yazılım firmasından teklif alırken sorulması gereken konular dikkate alınarak adaylardan aşağıdaki alanlarda aynı yanıt yapısı istenmelidir.
- Kapsam, teslimatlar ve proje aşamaları
- Kabul kriterleri ve garanti koşulları
- Bakım, destek ve olay müdahalesi
- Yedekleme, izleme ve güncelleme sorumlulukları
- Kaynak kodu, veri ve hesap sahipliği
- Dokümantasyon ve devir teslim kapsamı
- Kapsam değişikliği ve ek iş yöntemi
- Tekrarlayan giderler ve kapsam dışı kalemler
Portal Projenizi Teknik Olarak Kapsamlandırın
Portalınızın teknik ihtiyaçlarını birlikte kapsamlandırın; teslimatları, sahiplik haklarını ve destek koşullarını açıkça gösteren karşılaştırılabilir bir proje teklifi alın.
Teklif Alın