Aşağıdaki proje için teknik spesifikasyon dokümanı hazırla:
PROJE:
- Adı: [PROJE ADI]
- Tip: [YAZILIM / DONANIM / SİSTEM]
- Amaç: [NE ÇÖZÜYOR]
- Hedef kullanıcı: [KİMLER KULLANACAK]
- Karmaşıklık: [BASIT / ORTA / KARMAŞIK]
DOKÜMAN TİPİ: [SRS (Software Requirements Specification) / SDD (Software Design Document) / HARDWARE SPEC]
STANDART: [IEEE 830 / ISO/IEC/IEEE 29148 / EARS]
UZUNLUK: [30-100 SAYFA TİPİK]
SRS YAPI (IEEE 830 bazlı):
1. GİRİŞ
1.1 AMAÇ
- Bu dokümanın amacı
- Hedef kitle (geliştirici, test ekibi, müşteri)
1.2 KAPSAM
- Ürün adı
- Ne yapar (kısa)
- Ne yapmaz (kapsam dışı)
- İş hedefleri
1.3 TANIMLAR, KISALTMALAR
- Glossary tablosu
- Tüm teknik terimler
- Domain-specific terimler
1.4 REFERANSLAR
- İlgili standartlar (ISO, IEEE, TSE)
- Önceki belgeler (proje teklifi, tasarım dökümanı)
- Yasal mevzuat (KVKK, GDPR)
1.5 GENEL BAKIŞ
- Dokümanın organizasyonu
- Bölüm bölüm ne okunmalı
2. GENEL TANIM
2.1 ÜRÜN PERSPEKTİFİ
- Bağımsız ürün mü, büyük sistemin parçası mı
- Bağlam diyagramı (context diagram)
- Dış sistemlerle arayüz
2.2 ÜRÜN İŞLEVLERİ
- 5-10 ana işlev özeti
- Alt işlevler (hiyerarşi)
2.3 KULLANICI SINIFLARI VE KARAKTERİSTİKLERİ
- Her kullanıcı sınıfı (admin, regular, guest)
- Beceri seviyesi
- Sıklık ve yoğunluk
- Özel ihtiyaçlar (engelli erişim)
2.4 İŞLETME ORTAMI
- Donanım platformu
- İşletim sistemi
- Tarayıcı destek matrisi
- Veritabanı
- Dış entegrasyonlar
2.5 KISITLAMALAR
- Programlama dili
- Kod standartları
- Lisans gereksinimleri
- Zaman bütçesi
- Bellek/performans limitleri
- Güvenlik / uyumluluk
2.6 VARSAYIMLAR VE BAĞIMLILIKLAR
- Proje başlangıcında varsayılan koşullar
- Dış bağımlılıklar
- Risk: varsayım yanlış çıkarsa
3. FONKSIYONEL GEREKSİNİMLER
3.1 FORMAT (EARS notation önerilir)
- Temel: "WHEN [olay] THE SYSTEM SHALL [aksiyon]"
- Koşullu: "WHILE [koşul] THE SYSTEM SHALL..."
- Tetiklenmiş: "IF [koşul] THEN THE SYSTEM SHALL..."
3.2 HER GEREKSINIM İÇİN:
- Benzersiz ID (REQ-001 formatı)
- Başlık
- Açıklama (EARS format)
- Priority (critical / high / medium / low)
- Source (kim istedi)
- Rationale (niçin)
- Acceptance criteria (ölçülebilir)
- Dependencies (hangi başka REQ'lara bağlı)
- Verification method (test / inspection / demo / analysis)
3.3 USE CASES
- UC-001, UC-002 formatı
- Her use case için:
- Aktör(ler)
- Ön koşullar
- Ana senaryo (step-by-step)
- Alternatif senaryolar
- Başarı son durumu
- Hata senaryoları
- İlgili use case'ler
3.4 KULLANICI HİKAYELERİ (Agile ise)
- "As a [kullanıcı], I want [özellik], so that [fayda]"
- Story point tahmini
- Acceptance criteria
4. DIŞI ARAYÜZ GEREKSINIMLERI
4.1 KULLANICI ARAYÜZLERİ
- Ekran tasarım prensipleri
- Wireframe / mockup referansları
- Erişilebilirlik (WCAG 2.1)
- Çoklu dil desteği
- Responsive design
4.2 YAZILIM ARAYÜZLERİ
- API endpoint'ler
- İstek/yanıt formatları (JSON, XML)
- HTTP status kodları
- Rate limiting
- Versiyon stratejisi
4.3 DONANIM ARAYÜZLERİ
- Sensörler
- Kontrolcüler
- İletişim protokolleri (RS485, CAN, Modbus)
- Pin assignments
4.4 İLETIŞIM ARAYÜZLERİ
- Network protokolleri (HTTP, MQTT, WebSocket)
- Güvenlik (TLS, VPN)
- Bandwidth gereksinimleri
5. DIĞER FONKSİYONEL OLMAYAN GEREKSINIMLER
5.1 PERFORMANS
- Response time (95th percentile < 200ms)
- Throughput (X transaction/sec)
- Concurrent users
- Data volume
5.2 GÜVENLİK
- Kimlik doğrulama
- Yetkilendirme
- Veri şifreleme (at rest, in transit)
- Audit log
- Penetrasyon testi gereksinimi
5.3 GÜVENİLİRLİK
- Availability (99.9% uptime)
- MTBF (Mean Time Between Failures)
- Recovery time
- Fault tolerance
5.4 KULLANILABİLİRLİK
- Öğrenme kolaylığı
- Hata mesajları kalitesi
- Online yardım
- Accessibility (WCAG AA)
5.5 SÜRDÜRÜLEBİLİRLİK
- Kod okunabilirliği
- Modülerlik
- Test coverage (>%80)
- Dokümantasyon standardı
5.6 PORTABILITY
- Platform bağımsızlığı
- Browser compatibility
- Mobile/desktop parity
6. DOĞRULAMA VE ONAYLAMA
6.1 TEST STRATEJİSİ
- Unit testing
- Integration testing
- System testing
- User acceptance testing (UAT)
- Performance testing
- Security testing
6.2 KABUL KRİTERLERİ
- Her gereksinim için ölçülebilir kabul kriteri
- Pass/fail threshold'lar
- Müşteri sign-off prosedürü
7. EKLER
7.1 GEREKSİNİM İZLENEBILIRLIK MATRISI (Requirements Traceability Matrix - RTM)
- REQ-ID × Test Case
- REQ-ID × Design Element
- Her gereksinimin test edildiğini garanti
7.2 VERİ MODELİ
- ER diyagramları
- Veri sözlüğü
- İş kuralları
7.3 EKRAN AKIŞLARI
- Ekran-ekran geçiş diyagramı
- User journey map
7.4 KULLANIM SENARYOLARI
- End-to-end örnek senaryolar
- Edge case'ler
SDD (System Design Document) EK BÖLÜMLER:
SDD = SRS + nasıl çözüleceği
- Algoritma detayları (pseudocode)
- Veri yapıları
- Sınıf hiyerarşisi
- Design patterns
- Error handling stratejisi
- State machines
- Sequence diagrams (detaylı)
KALITE KONTROL:
- [ ] Her gereksinim testable (ölçülebilir)
- [ ] Birbirine çelişen gereksinim yok
- [ ] Muğlak ifade yok ("kullanıcı dostu" yerine "3 tık içinde")
- [ ] Tüm aktörler kapsandı
- [ ] Tüm use case'ler için alternatif akış var
- [ ] Non-functional req. ölçülebilir
- [ ] Glossary tam
- [ ] Numaralama tutarlı
- [ ] Revizyon geçmişi güncel
REVIEW SÜRECİ:
1. PEER REVIEW (ekip içi)
2. CUSTOMER REVIEW (müşteri teknik ekibi)
3. FORMAL REVIEW (sign-off toplantısı)
4. BASELINE (onaylanan versiyon kilitlenir)
5. CHANGE CONTROL (değişiklik süreci)
Türkçe + İngilizce teknik terim (ilk geçişte her iki dilde).