Microsoft Word'de Teknik Görev Tanımını Doğru Şekilde Oluşturma ve Biçimlendirme

Word'deki teknik görev tanımı (TZ), otomatik içerik tablosu oluşturmak için başlık stilleri sistemi, gereksinimler için numaralı listeler ve özellikler için tablolar kullanılarak biçimlendirilir. Belgenin temel bölümleri şunlardır: genel bilgiler, işlevsel ve işlevsel olmayan gereksinimler, çalışma aşamaları ve kabul kriterleri. Net yapı ve somut ifadeler, müşteri ile yüklenici arasındaki farklı yorumları ortadan kaldırır.

Aşağıda, yalnızca Microsoft Word araçlarını kullanarak dağınık notları hukuki ve teknik açıdan doğru bir belgeye dönüştürmeye ilişkin ayrıntılı talimatlar yer almaktadır.

Belgenin Temel Yapısı

İyi bir TZ, «genelden özele» mantığını izler. Word'de bu, başlıkların hiyerarşisi (Başlık 1, Başlık 2, Başlık 3) aracılığıyla uygulanır.

1. Kapak Sayfası

İlk sayfa minimum bilgi içermeli, ancak en önemli bilgilerin tamamını barındırmalıdır:

• Proje adı.
• Belge türü («Teknik Görev Tanımı»).
• Belge sürümü (örneğin v1.0) ve onay tarihi.
• Müşteri ve yüklenicinin bilgileri (şirket adları, sorumlu kişilerin ad soyadları, iletişim bilgileri).

2. İçindekiler

Word'de bu otomatik olarak oluşturulur (Başvurular → İçindekiler). Bu, 10 sayfadan uzun belgelerde gezinme için kritik öneme sahiptir. İçindekileri manuel olarak oluşturmayın — metinde yapılan herhangi bir değişiklikte bağlantılar bozulur.

3. Terimler ve Tanımlar (Sözlük)

Projede özel terimler varsa (örneğin «Lead», «Oturum», «API anahtarı»), bunları burada açıklayın. Bu, geliştiricilerin ve test uzmanlarının zamanını tasarruf ettirir.

Bölümlerin Ayrıntılı İçeriği

Genel Bilgiler ve Hedefler

Ürünün neden oluşturulduğunu açıklayın.

• Geliştirme dayanağı: sözleşme, emir veya iş hipotezine atıf.
• Hedef: neye ulaşmak istiyoruz (örneğin, «Sepet dönüşüm oranını %15 artırmak» veya «Depo stok takibini otomatikleştirmek»).
• Hedef kitle: sistemi kimler kullanacak.

İşlevsel Gereksinimler

Bu, TZ'nin «kalbidir». Her işlevi ayrı ayrı açıklayın. Word'de, her madde için benzersiz bir kimlik içeren numaralı liste kullanmak uygundur (örneğin FR-01, FR-02).

İdeal gereksinim formülü:

[Kimlik] Eylem: Kullanıcı [eylem] yapabilir. Koşul: [koşul] yerine getirildiğinde. Sonuç: Sistem [tepki] vermelidir. Öncelik: Yüksek/Orta/Düşük.

Örnek:

FR-01 Kayıt: Kullanıcı e-posta ile kayıt olabilir. Koşul: E-posta veritabanında mevcut değil. Sonuç: Sistem onay bağlantısı içeren bir e-posta gönderir ve «Aktif Değil» durumuna sahip bir hesap oluşturur.

İşlevsel Olmayan Gereksinimler

Doğrudan işlevlerle ilgili olmayan, ancak kaliteyi etkileyen kısıtlamalar.

• Performans: sayfa yükleme süresi < 2 sn, 1000 eşzamanlı kullanıcı desteği.
• Güvenlik: parolaların karma şeklinde saklanması, HTTPS kullanımı.
• Uyumluluk: son iki sürüm Chrome, Safari, Firefox'ta çalışma; mobil cihazlara duyarlılık.

Arayüzler ve Tasarım

Tasarımı sözcüklerle açıklamayın («güzel yapın» gibi). Word'e mockup veya prototip ekran görüntülerini ekleyin.

• Şekillere alt yazı ekleyin (görüntüye sağ tık → Başlık Ekle).
• Duyarlı düzen için kırılma noktalarını (ekran genişliklerini) belirtin.

Çalışma Aşamaları ve Süreler

Projeyi kilometre taşlarına (Milestones) ayırın. Word'de bunun için tablo en uygun seçenektir.

Kabul Kriterleri

Tamamlanan işler tutanağını imzalayacağınız net bir kontrol listesi.

• Tüm kritik hatalar düzeltildi.
• Ek 1'deki tüm test senaryoları başarıyla geçti.
• Kod, müşterinin deposuna aktarıldı.

Word'de Biçimlendirmeye İlişkin Teknik İpuçları

Belgenin profesyonel görünmesi ve kolayca düzenlenebilmesi için:

1. Stilleri kullanın. Başlıklara «Başlık 1», «Başlık 2» düzeylerini atayın. Bu, gezinme modunda belgenin bölümlerini daraltıp/genişletmenizi ve içindekileri otomatik olarak güncellemenizi sağlar.
2. Bölüm numaralandırması. Çok düzeyli listeyi etkinleştirin (Giriş → Çok Düzeyli Liste). Bölümler 1, 1.1, 1.1.1 şeklinde numaralandırılır. Bu, yazışmalarda maddelere atıfta bulunmayı kolaylaştırır («3.2.1 maddesine bak»).
3. Gözden geçirme. Göndermeden önce, yüklenicinin değişikliklerini görmek istiyorsanız gözden geçirme modunu etkinleştirin (Gözden Geçir → Değişiklikleri İzle) veya onların bu modu kullanmasını isteyin.
4. Sürüm kontrolü. Dosyayı adında tarih ve sürüm ile kaydedin: TZ_Proje_v1.2_2026-05-13.docx. Belgenin içinde, içindekilerden hemen sonra «Değişiklik Geçmişi» tablosu ekleyin.

Tablo: Değişiklik Geçmişi

Kopyalamak İçin Hazır Yapı Şablonu

Bu yapıyı boş bir Word belgesine kopyalayıp doldurabilirsiniz.

1. GENEL BİLGİLER
   1.1. Proje Adı
   1.2. Geliştirme Dayanağı
   1.3. Hedefler ve Görevler
   1.4. Terimler ve Tanımlar

2. PROJE GEREKSİNİMLERİ
   2.1. İşlevsel Gereksinimler
       2.1.1. Yetkilendirme Modülü
       2.1.2. Katalog Modülü
       2.1.3. ...
   2.2. İşlevsel Olmayan Gereksinimler
       2.2.1. Performans
       2.2.2. Güvenlik
       2.2.3. Barındırma Gereksinimleri

3. ARAYÜZLER VE TASARIM
   3.1. Site/Ekran Haritası
   3.2. Temel Ekranların Açıklaması (ekran görüntüleri ile)

4. TEKNOLOJİ YIĞINI VE ENTEGRASYONLAR
   4.1. Tercih Edilen Teknolojiler
   4.2. Üçüncü Taraf Hizmetlerle Entegrasyon (API)

5. ÇALIŞMA AŞAMALARI VE SÜRELER
   5.1. Takvim Planı
   5.2. Teslim ve Kabul Prosedürü

6. KABUL KRİTERLERİ
   6.1. Test Gereksinimleri
   6.2. Aktarılacak Malzemelerin Listesi

EKLER
   A. Prototipler
   B. Veri Örnekleri

TZ Hazırlarken Sık Yapılan Hatalar

1. Öz yerine «su». Dijital dönüşümün önemi hakkında uzun girişler geliştirici için gerekli değildir. Konuya doğrudan girin.
2. Önceliklerin olmaması. Her şey «çok önemliyse», hiçbir şey önemli değildir. İşlevleri Must Have (zorunlu), Should Have (tercih edilen), Could Have (mümkünse) olarak etiketleyin.
3. Bozuk kaynaklara atıflar. Figma veya Google Docs'taki mockup'lara atıf yapıyorsanız, erişim haklarını kontrol edin. Anahtar ekran görüntülerini doğrudan Word'e yedeklemek daha iyidir.
4. Mobil cihazların göz ardı edilmesi. Bu bir web hizmeti ise, akıllı telefonda nasıl davranması gerektiğini açıkça belirtin.

SSS

GOST 34 veya 19'a uyulması gerekiyor mu? Devlet sözleşmeleri için — zorunludur. Ticari projeler için makul yeterlilik yeterlidir. Yukarıdaki yapı, modern web geliştirme gerçeklerine uyarlanmıştır ve katı GOST'lardan daha kolay anlaşılır.

TZ yükleniciye hangi formatta gönderilmeli? Her zaman iki dosya gönderin: düzenlenebilir .docx (düzeltmeler ve yorumlar için) ve sabit .pdf (o ana kadar mutabık kalınan sürüm referansı olarak).

Gereksinimler süreç içinde değişirse ne yapılmalı? «Değişiklik Listesi» ekini kullanın veya ayrı bir «Change Log» belgesi tutun. Eski TZ'yi «sessizce» düzeltmeyin — yeni bir özellik veya mantık değişikliğine ilişkin her anlaşmayı kaydedin.

TZ Notion veya Google Docs'ta yazılabilir mi? Evet, ekip çalışması için kullanışlıdır. Ancak sıkı raporlama, belge imzalama veya büyük geleneksel şirketlerle çalışma gerekiyorsa, Word baskı kolaylığı, sayfa numaralandırması ve formatın hukuki geçerliliği nedeniyle fiili standart olarak kalmaya devam eder.