📄 Şablonlar

Şablonlar

Bu şablonlar yeni başlayan və orta səviyyəli IT Biznes Analitiklər üçün hazırlanıb. Tələblərin sənədləşdirilməsi, user story və use case-lərin yazılması, stakeholder və proses analizi, texniki analiz və dəyişikliklərin strukturlaşdırılması üçün hazır forma kimi istifadə edilə bilər.

Şablon səviyyələri: Başlanğıc – yeni başlayanlar üçün sadə şablon; Orta – daha detallı analiz tələb edən şablon; Praktiki – real layihələrdə istifadə üçün genişləndirilmiş şablon.

Bu kateqoriyada şablon tapılmadı.

RD — Requirement Document (Tələblər sənədi)

Orta

Layihənin bütün tələblərini bir yerdə toplayan ümumi tələblər sənədi.

Nə vaxt: Layihənin əvvəlində tələbləri rəsmi şəkildə yazıb komandaya təqdim edəndə.

Şablona bax

Məqsəd

Biznes, funksional və qeyri-funksional tələbləri tək sənəddə toplayıb bütün tərəflərin eyni anlayışa gəlməsini təmin etmək.

Əsas bölmələr

  • Sənəd məlumatı və status
  • Məqsəd və əhatə dairəsi (scope)
  • Maraqlı tərəflər
  • Biznes / funksional / qeyri-funksional tələblər
  • Fərziyyələr, məhdudiyyətlər, açıq suallar

Hazır şablon

TƏLƏBLƏR SƏNƏDİ (RD)

1. Sənəd haqqında
   - Layihə adı:
   - Versiya:
   - Tarix:
   - Müəllif (IT BA):
   - Status: Qaralama / Təsdiq gözləyir / Təsdiqlənib

2. Məqsəd
   - Bu sənəd nə üçün hazırlanıb:
   - Həll olunan problem:

3. Əhatə dairəsi (Scope)
   - Daxildir:
   - Daxil deyil:

4. Maraqlı tərəflər (Stakeholders)
   - Ad / Rol / Məsuliyyət:

5. Biznes tələbləri
   - BT-01:
   - BT-02:

6. Funksional tələblər
   - FT-01:
   - FT-02:

7. Qeyri-funksional tələblər
   - QFT-01 (performans / təhlükəsizlik / əlçatanlıq):

8. Fərziyyələr və məhdudiyyətlər
   -

9. Asılılıqlar (digər sistem / komanda)
   -

10. Açıq suallar
   -

Nümunə

FT-01: Sistem istifadəçiyə şifrəni email vasitəsilə bərpa etmək imkanı verməlidir. QFT-01: Əsas səhifə 2 saniyədən az müddətdə açılmalıdır.

BRD — Business Requirements Document

Orta

Layihənin niyə görüldüyünü izah edən biznes tələbləri sənədi.

Nə vaxt: Layihə başlamazdan əvvəl biznes məqsədini və gözlənilən faydanı rəhbərliyə təsdiqlətmək üçün.

Şablona bax

Məqsəd

Biznesin nəyə nail olmaq istədiyini yüksək səviyyədə təsvir etmək. Texniki həlli yox, biznes ehtiyacını izah edir.

Əsas bölmələr

  • Biznes problemi və məqsəd
  • Uğur meyarları (KPI)
  • Əhatə dairəsi və biznes tələbləri
  • Risklər və fərziyyələr

Hazır şablon

BİZNES TƏLƏBLƏRİ SƏNƏDİ (BRD)

1. Xülasə (Executive Summary)
   - Layihənin bir cümlə ilə izahı:

2. Biznes problemi / imkanı
   - Hazırkı vəziyyət:
   - Problem:

3. Biznes məqsədləri
   - Məqsəd 1:
   - Məqsəd 2:

4. Uğur meyarları (KPI)
   - Məs: 6 ayda onlayn satışı 20% artırmaq

5. Əhatə dairəsi
   - Daxildir:
   - Daxil deyil:

6. Biznes tələbləri
   - BT-01:
   - BT-02:

7. Maraqlı tərəflər
   -

8. Fərziyyələr və risklər
   -

Nümunə

Biznes məqsədi: Müştərilərin filiala getmədən müqavilələrini onlayn görməsini təmin etmək. Uğur meyarı: Filiala zənglərin sayını 3 ayda 30% azaltmaq.

SRS — Software Requirements Specification

Praktiki

Sistemin necə işləməli olduğunu detallı təsvir edən texniki tələblər sənədi.

Nə vaxt: Komanda işə başlamazdan əvvəl, funksional və qeyri-funksional tələbləri dəqiq sənədləşdirəndə.

Şablona bax

Məqsəd

İnkişaf və test komandasının eyni anlayışla işləməsi üçün sistemin bütün funksional və qeyri-funksional tələblərini dəqiq müəyyən etmək.

Əsas bölmələr

  • Giriş, məqsəd, əhatə dairəsi
  • Ümumi təsvir (istifadəçilər, mühit)
  • Funksional tələblər
  • Qeyri-funksional tələblər
  • İnterfeys və inteqrasiya tələbləri

Hazır şablon

PROQRAM TƏLƏBLƏRİ SPESİFİKASİYASI (SRS)

1. Giriş
   1.1 Məqsəd:
   1.2 Əhatə dairəsi:
   1.3 Terminlər və qısaltmalar:

2. Ümumi təsvir
   2.1 Məhsulun ümumi mənzərəsi:
   2.2 İstifadəçi rolları:
   2.3 İş mühiti (brauzer / OS / cihaz):
   2.4 Fərziyyələr və asılılıqlar:

3. Funksional tələblər
   FT-01:
     - Təsvir:
     - Giriş:
     - İşlənmə:
     - Çıxış / nəticə:
   FT-02:

4. Qeyri-funksional tələblər
   - Performans:
   - Təhlükəsizlik:
   - Əlçatanlıq (availability):
   - İstifadə rahatlığı (usability):

5. İnterfeys tələbləri
   - İstifadəçi interfeysi:
   - API / inteqrasiya:

6. Açıq suallar / qeydlər
   -

Nümunə

FT-02 — Giriş: İstifadəçi email və şifrə daxil edir. İşlənmə: Sistem məlumatları yoxlayır. Çıxış: Düzgündürsə şəxsi kabinetə yönləndirir, yanlışdırsa xəta mesajı göstərir.

FRD — Functional Requirements Document

Orta

Sistemin etməli olduğunu funksiya-funksiya təsvir edən sənəd.

Nə vaxt: BRD-dəki biznes tələblərini konkret funksiyalara çevirəndə.

Şablona bax

Məqsəd

Hər biznes tələbinin sistemdə hansı konkret funksiya ilə qarşılanacağını aydın göstərmək.

Əsas bölmələr

  • Funksiya kodu və adı
  • Təsvir, aktyor, ilkin şərt
  • Addımlar və qaydalar
  • Əlaqəli biznes tələbi

Hazır şablon

FUNKSİONAL TƏLƏBLƏR SƏNƏDİ (FRD)

Funksiya: FT-01
- Funksiyanın adı:
- Təsvir (sistem nə edir):
- Aktyor (kim istifadə edir):
- İlkin şərt (precondition):
- Addımlar:
   1.
   2.
- Biznes qaydaları:
   -
- Gözlənilən nəticə:
- Əlaqəli biznes tələbi: BT-..

Funksiya: FT-02
- ...

Nümunə

FT-01 — Adı: Müqavilə siyahısı. Aktyor: Müştəri. İlkin şərt: Müştəri sistemə daxil olub. Nəticə: Sistem müştərinin aktiv müqavilələrini siyahı şəklində göstərir.

Non-Functional Requirements (Qeyri-funksional tələblər)

Orta

Sistemin necə işləməli olduğunu — sürət, təhlükəsizlik, etibarlılıq — təsvir edir.

Nə vaxt: Funksional tələblərlə yanaşı keyfiyyət gözləntilərini yazanda.

Şablona bax

Məqsəd

Sistemin keyfiyyət xüsusiyyətlərini ölçülə bilən şəkildə müəyyən etmək (yəni «sürətli olsun» yox, «2 saniyədən az açılsın»).

Əsas bölmələr

  • Performans, təhlükəsizlik, əlçatanlıq
  • İstifadə rahatlığı, uyğunluq, miqyaslana bilmə

Hazır şablon

QEYRİ-FUNKSİONAL TƏLƏBLƏR

QFT-01 Performans:
   - Səhifə açılma vaxtı:
   - Eyni anda istifadəçi sayı:

QFT-02 Təhlükəsizlik:
   - Autentifikasiya / giriş qaydaları:
   - Məlumatın şifrələnməsi:

QFT-03 Əlçatanlıq (Availability):
   - İş vaxtı (uptime), məs: 99.5%

QFT-04 İstifadə rahatlığı (Usability):
   - Dil / əlçatanlıq tələbləri:

QFT-05 Uyğunluq (Compatibility):
   - Dəstəklənən brauzer / cihaz:

QFT-06 Miqyaslana bilmə (Scalability):
   - Yüklənmənin artması ilə davranış:

Nümunə

QFT-01: Sistem eyni anda 500 istifadəçini yavaşlamadan dəstəkləməlidir. QFT-03: İllik iş vaxtı 99.5%-dən az olmamalıdır.

API Requirement Template

Praktiki

İki sistem arasında məlumat mübadiləsi (API) tələbini təsvir edir.

Nə vaxt: Sistemlərin inteqrasiyası və ya yeni endpoint tələb olunanda.

Şablona bax

Məqsəd

Developer və inteqrasiya komandasının lazımi API-ni dəqiq başa düşməsi üçün giriş/çıxış məlumatını və qaydaları aydın yazmaq.

Əsas bölmələr

  • Endpoint, metod, məqsəd
  • Giriş (request) və çıxış (response) məlumatı
  • Xəta halları və təhlükəsizlik

Hazır şablon

API TƏLƏBİ

1. Ümumi məlumat
   - API adı:
   - Məqsəd (nə üçün lazımdır):
   - Endpoint (URL):
   - Metod: GET / POST / PUT / DELETE

2. Giriş (Request)
   - Parametrlər (ad / tip / məcburidir?):
   - Nümunə giriş:

3. Çıxış (Response)
   - Sahələr (ad / tip / izah):
   - Uğurlu cavab nümunəsi:

4. Xəta halları
   - Kod / izah (məs: 400 - yanlış məlumat, 401 - giriş yoxdur):

5. Təhlükəsizlik
   - Autentifikasiya üsulu (token / açar):

6. Qeydlər
   -

Nümunə

Endpoint: /api/contracts — Metod: GET Məqsəd: Daxil olmuş müştərinin aktiv müqavilələrini qaytarmaq. Çıxış: id, contractNumber, status, startDate.

User Story Şablonu

Başlanğıc

İstifadəçi ehtiyacını qısa və aydın formada ifadə etmək üçün.

Nə vaxt: Backlog-a yeni tələb əlavə edəndə və ya sprint planlaşdırmasında.

Şablona bax

Məqsəd

Bu şablon istifadəçi ehtiyacını qısa və aydın formada ifadə etmək üçün istifadə olunur.

Əsas bölmələr

  • User story (rol – məqsəd – fayda)
  • Acceptance criteria
  • Biznes qaydaları və qeydlər

Hazır şablon

User Story:
Bir [rol] olaraq,
Mən [məqsəd / ehtiyac] istəyirəm,
Beləliklə [biznes dəyəri / nəticə] əldə edim.

Acceptance Criteria:
1. GIVEN ...
   WHEN ...
   THEN ...

2. GIVEN ...
   WHEN ...
   THEN ...

Business Rules:
- ...

Notes:
- ...

Nümunə

Bir müştəri olaraq, Mən şəxsi kabinetdə aktiv sığorta müqavilələrimi görmək istəyirəm, Beləliklə müqavilə məlumatlarımı filial ilə əlaqə saxlamadan yoxlaya bilim. Acceptance Criteria: GIVEN müştərinin aktiv müqaviləsi var WHEN müştəri şəxsi kabinetə daxil olur THEN sistem aktiv müqavilələri siyahıda göstərir.

Acceptance Criteria (Qəbul meyarları)

Başlanğıc

User story-nin «tamamlandı» sayılması üçün lazım olan konkret şərtlər.

Nə vaxt: Hər user story üçün — developer və tester eyni nəticəni gözləsin deyə.

Şablona bax

Məqsəd

Funksiyanın hansı şərtlərdə düzgün sayılacağını dəqiqləşdirmək. İki üsul var: Gherkin (Given/When/Then) və ya sadə siyahı.

Əsas bölmələr

  • Hər meyar üçün şərt, hərəkət və nəticə
  • Müsbət və mənfi (xəta) halları

Hazır şablon

ACCEPTANCE CRITERIA

User Story / Funksiya:

Üsul 1 — Gherkin (Given/When/Then):
AC-01:
  GIVEN [ilkin vəziyyət]
  WHEN  [istifadəçi hərəkəti]
  THEN  [gözlənilən nəticə]

AC-02 (mənfi hal):
  GIVEN ...
  WHEN  ...
  THEN  [xəta mesajı / blok]

Üsul 2 — Sadə siyahı (checklist):
- [ ] Şərt 1
- [ ] Şərt 2
- [ ] Xəta halı düzgün idarə olunur

Nümunə

AC-01: GIVEN istifadəçi düzgün email və şifrə daxil edib WHEN «Daxil ol» düyməsini basır THEN sistem onu şəxsi kabinetə yönləndirir. AC-02: GIVEN şifrə yanlışdır WHEN istifadəçi daxil olmağa çalışır THEN «Email və ya şifrə yanlışdır» mesajı görünür.

Use Case Şablonu

Orta

İstifadəçi ilə sistemin qarşılıqlı əlaqəsini strukturlu təsvir edir.

Nə vaxt: Bir funksiyanın bütün addımlarını və alternativ halları detallı göstərmək lazım olanda.

Şablona bax

Məqsəd

Bir məqsədə çatmaq üçün istifadəçi və sistem arasındakı addımları — əsas və alternativ axınları — aydın sənədləşdirmək.

Əsas bölmələr

  • Aktyor, məqsəd, ilkin/son şərt
  • Əsas axın (main flow)
  • Alternativ və xəta axınları

Hazır şablon

USE CASE

- Use Case ID:
- Ad:
- Aktyor (kim):
- Məqsəd:
- İlkin şərt (Precondition):
- Son şərt (Postcondition):

Əsas axın (Main Flow):
   1. Aktyor ...
   2. Sistem ...
   3. ...

Alternativ axın (Alternative Flow):
   A1. Əgər ... olarsa, sistem ...

Xəta axını (Exception Flow):
   E1. Əgər ... baş verərsə, sistem xəta göstərir.

Biznes qaydaları:
   -

Nümunə

Ad: Kartla ödəniş. Aktyor: Müştəri. Əsas axın: 1. Müştəri kart məlumatını daxil edir → 2. Sistem yoxlayır → 3. Ödəniş təsdiqlənir → 4. Çek göndərilir. Xəta axını: E1. Balans kifayət deyilsə, sistem «Ödəniş alınmadı» mesajı göstərir.

Use Case Scenario (Ssenari)

Orta

Use case-in konkret bir halını real məlumatla, hekayə kimi göstərir.

Nə vaxt: Komanda və ya müştəriyə funksiyanı real nümunə ilə izah edəndə.

Şablona bax

Məqsəd

Use case-i konkret bir vəziyyətdə, real istifadəçi və məlumatla addım-addım göstərmək. Bir use case-in bir neçə ssenarisi ola bilər (uğurlu, uğursuz).

Əsas bölmələr

  • Ssenari adı və tipi (uğurlu / uğursuz)
  • Vəziyyət və addımlar
  • Nəticə

Hazır şablon

USE CASE SCENARIO

- Əlaqəli Use Case:
- Ssenari adı:
- Tip: Uğurlu / Uğursuz
- Aktyor:
- Vəziyyət (kontekst):

Addımlar:
   1.
   2.
   3.

Nəticə:
   -

Nümunə

Ssenari: «Uğurlu ödəniş». Aktyor: Aysel. 1. Aysel 50 AZN-lik səbəti ilə ödənişə keçir. 2. Kart məlumatını daxil edir. 3. Sistem ödənişi təsdiqləyir. Nəticə: Sifariş yaradılır, Aysel email ilə çek alır.

Process Description (Proses təsviri)

Orta

Bir biznes prosesinin addımlarını, rollarını və qaydalarını yazılı təsvir edir.

Nə vaxt: As-is (cari) və ya to-be (hədəf) prosesi sənədləşdirəndə.

Şablona bax

Məqsəd

Prosesin necə işlədiyini hər kəsin başa düşməsi və təkmilləşdirmə imkanlarının görünməsi üçün addım-addım yazmaq.

Əsas bölmələr

  • Proses adı, məqsəd, sahib (owner)
  • Başlanğıc/bitmə hadisəsi (trigger)
  • Addımlar, rollar, qaydalar

Hazır şablon

PROSES TƏSVİRİ

- Proses adı:
- Tip: As-Is (cari) / To-Be (hədəf)
- Məqsəd:
- Proses sahibi (Owner):
- İştirakçı rollar:
- Başlanğıc hadisəsi (Trigger):
- Bitmə nəticəsi:

Addımlar:
   1. [Rol] — hərəkət
   2. [Rol] — hərəkət
   3. ...

Qərar nöqtələri (əgər / o zaman):
   -

Biznes qaydaları:
   -

İstifadə olunan sistemlər / sənədlər:
   -

Nümunə

Proses: Məzuniyyət ərizəsi (As-Is). 1. İşçi ərizəni doldurur. 2. Rəhbər təsdiqləyir/rədd edir. 3. HR sistemə daxil edir. Qərar: Rəhbər rədd edərsə, ərizə işçiyə geri qayıdır.

Change Request (Dəyişiklik tələbi)

Praktiki

Layihə gedişində yaranan dəyişiklik tələbini rəsmiləşdirir.

Nə vaxt: Razılaşdırılmış scope-a yeni tələb və ya dəyişiklik əlavə olunmalı olanda.

Şablona bax

Məqsəd

Dəyişikliyi, onun səbəbini və təsirini yazıb qərar verənlərin (CCB) təsdiqi üçün təqdim etmək.

Əsas bölmələr

  • Dəyişikliyin təsviri və səbəbi
  • Təsir (vaxt, büdcə, scope)
  • Qərar və təsdiq

Hazır şablon

DƏYİŞİKLİK TƏLƏBİ (CHANGE REQUEST)

- CR ID:
- Tələb edən / tarix:
- Başlıq:
- Təsvir (nə dəyişməlidir):
- Səbəb (niyə lazımdır):
- Prioritet: Yüksək / Orta / Aşağı

Təsir analizi:
   - Scope-a təsir:
   - Vaxt cədvəlinə təsir:
   - Büdcəyə təsir:
   - Risklər:

Alternativlər:
   -

Qərar: Təsdiqləndi / Rədd edildi / Gözləyir
Təsdiq edən / tarix:

Nümunə

Başlıq: Ödəniş səhifəsinə Apple Pay əlavə edilməsi. Səbəb: Müştəri tələbi. Təsir: +1 sprint, kart inteqrasiyası ilə risk yoxdur. Qərar: Təsdiqləndi.

Impact Analysis (Təsir analizi)

Praktiki

Bir dəyişikliyin hansı sistem, proses və komandaya təsir edəcəyini qiymətləndirir.

Nə vaxt: Dəyişiklikdən və ya yeni tələbdən əvvəl riski və əhatəni anlamaq üçün.

Şablona bax

Məqsəd

Bir dəyişikliyin nəyə toxunacağını əvvəlcədən görmək — beləliklə gözlənilməz problemlərin qarşısını almaq.

Əsas bölmələr

  • Dəyişikliyin təsviri
  • Təsir olunan sahələr (sistem, proses, data, komanda)
  • Risk və azaltma tədbirləri

Hazır şablon

TƏSİR ANALİZİ (IMPACT ANALYSIS)

- Dəyişiklik / tələb:
- Tarix / müəllif:

Təsir olunan sahələr:
   - Sistemlər / modullar:
   - Biznes prosesləri:
   - Məlumat (data):
   - İnteqrasiyalar / API:
   - İstifadəçilər / komandalar:

Təsir səviyyəsi: Yüksək / Orta / Aşağı

Risklər:
   - Risk:
   - Ehtimal / nəticə:
   - Azaltma tədbiri:

Lazım olan iş / resurs:
   -

Tövsiyə:
   -

Nümunə

Dəyişiklik: Login üsulunu OTP-yə keçirmək. Təsir: Login modulu, SMS inteqrasiyası, dəstək komandasının təlimi. Risk: SMS gecikməsi → azaltma: təkrar göndər düyməsi.

Traceability Matrix (İzlənmə matrisi)

Praktiki

Hər tələbin user story, dizayn və testlə əlaqəsini izləyən cədvəl.

Nə vaxt: Heç bir tələbin unudulmadığını və test edildiyini yoxlamaq üçün.

Şablona bax

Məqsəd

Hər tələbi mənbədən test nəticəsinə qədər izləyib heç bir tələbin boşda qalmadığını təmin etmək.

Əsas bölmələr

  • Tələb ID və təsviri
  • Əlaqəli user story / funksiya
  • Test case ID və status

Hazır şablon

İZLƏNMƏ MATRİSİ (TRACEABILITY MATRIX)

| Tələb ID | Tələbin təsviri | User Story / Funksiya | Test Case ID | Status |
|----------|-----------------|-----------------------|--------------|--------|
| BT-01    |                 | US-01                 | TC-01        | Keçdi  |
| BT-02    |                 | US-02                 | TC-02        | Açıq   |
| FT-01    |                 | US-03                 | TC-03, TC-04 |        |

Qeyd: Hər tələbin ən azı bir test case ilə örtülməsinə əmin ol.

Nümunə

BT-01 «Müştəri müqavilələrini görür» → US-01 → TC-01 (Keçdi). Belə cədvəl göstərir ki, hansı tələb test olunub, hansı hələ açıqdır.

Stakeholder Register Şablonu

Orta

Layihənin maraqlı tərəflərini bir cədvəldə sistemli şəkildə qeyd edir.

Nə vaxt: Layihənin başlanğıcında, elicitation mərhələsində və ya yeni stakeholder əlavə olunduqda.

Şablona bax

Məqsəd

Layihədə iştirak edən və ya layihədən təsirlənən maraqlı tərəfləri sistemli şəkildə qeyd etmək üçün istifadə olunur — kim, hansı təsir səviyyəsi, hansı gözlənti və hansı risklə.

Əsas bölmələr

  • Stakeholder adı, rolu, şöbəsi
  • Təsir səviyyəsi və qərarvermə səlahiyyəti
  • Əlaqə kanalı, gözləntilər və risklər

Hazır şablon

STAKEHOLDER REGISTER

| Stakeholder adı | Rol / Vəzifə | Şöbə / Komanda | Layihədə rolu | Təsir səviyyəsi | Qərarvermə səlahiyyəti | Əlaqə kanalı | Gözləntilər | Risk / Qeyd |
| --------------- | ------------ | -------------- | ------------- | --------------- | ---------------------- | ------------ | ----------- | ----------- |
|                 |              |                |               | Yüksək/Orta/Aşağı | Bəli / Xeyr          |              |             |             |

Nümunə

Aysel Məmmədova — Product Owner (Digital Channels) Layihədə rolu: biznes tələblərinin təsdiqi · Təsir səviyyəsi: Yüksək · Qərarvermə: Bəli Əlaqə kanalı: Email / Jira · Gözlənti: müştəri kabinetində müqavilələrin görünməsi Risk / Qeyd: tələblər gec təsdiqlənərsə UAT gecikə bilər

Texniki Analiz Sənədi Şablonu

Praktiki

AS-IS analizi, TO-BE həll dizaynı, tələblər, API-lər və field təsvirlərini bir sənəddə birləşdirən geniş şablon.

Nə vaxt: Yeni funksionallıq, mövcud prosesdə dəyişiklik, inteqrasiya, API dəyişiklikləri və ya sistemlərarası təsir analizi zamanı.

Şablona bax

Məqsəd

Bu sənəd mövcud vəziyyətin analizini, hədəf həll dizaynını, biznes və funksional tələbləri, API-ləri, field təsvirlərini və açıq sualları bir yerdə toplamaq üçün istifadə olunur.

Əsas bölmələr

  • 1. Requirements Elicitation — tələblərin mənbələri və açar suallar
  • 2. Stakeholder Register — maraqlı tərəflər
  • 3. AS-IS — mövcud vəziyyətin analizi (workflow, API-lər, açıq suallar)
  • 4. TO-BE — hədəf həll dizaynı, tələblər, field-lər və API-lər

Qeyd: Şablon real layihə üçün uzundur — lazım olmayan bölmələri silə, cədvəlləri öz sistemə uyğunlaşdıra bilərsən.

Hazır şablon

TEXNİKİ ANALİZ SƏNƏDİ

============================================================
1. REQUIREMENTS ELICITATION
============================================================

1.1 Purpose
Bu bölmədə tələblərin hansı mənbələrdən və hansı görüşlər
əsasında toplandığı qeyd olunur.

1.2 Elicitation Sources
| Mənbə           | Tip      | Link / Attachment | Qeyd |
| --------------- | -------- | ----------------- | ---- |
| Biznes görüşü   | Meeting  |                   |      |
| Email yazışması | Email    |                   |      |
| Mövcud sənəd    | Document |                   |      |

1.3 Key Questions
| Sual | Cavab | Cavablandıran şəxs | Status |
| ---- | ----- | ------------------ | ------ |
|      |       |                    | Open   |

============================================================
2. STAKEHOLDER REGISTER
============================================================
| Stakeholder adı | Rol / Vəzifə | Şöbə / Komanda | Layihədə rolu | Təsir səviyyəsi | Qərarvermə səlahiyyəti | Əlaqə kanalı | Gözləntilər | Qeyd |
| --------------- | ------------ | -------------- | ------------- | --------------- | ---------------------- | ------------ | ----------- | ---- |
|                 |              |                |               |                 |                        |              |             |      |

============================================================
3. AS-IS — CURRENT STATE ANALYSIS
============================================================

3.1 Document Header
| Field               | Description                                  |
| ------------------- | -------------------------------------------- |
| Issue Type          | Epic / Task                                  |
| Epic / Task         | Jira link və ya task ID                      |
| Initiator           | Sorğunu başladan şəxs / komanda              |
| Expectation         | Mövcud problemin və gözləntinin qısa təsviri |
| Translate Page Link | Uyğun Confluence / dokumentasiya linki       |

3.2 AS-IS Workflow
| Workflow item            | Link / Description                 |
| ------------------------ | ---------------------------------- |
| BPMN / UML / FigJam Link | Mövcud proses axınının linki       |
| Current UI / Screen      | Mövcud ekran görüntüsü və ya link  |
| Current system behavior  | Sistemin hal-hazırda necə işlədiyi |

3.3 Detailed Workflow — Scenarios
| Step Name | Step Description |
| --------- | ---------------- |
| Addım 1   |                  |
| Addım 2   |                  |

3.4 Existing APIs
| API Name             | Method   | Endpoint | Purpose                                    | Request Model | Response Model | Response Codes | Swagger Link | Related Screen |
| -------------------- | -------- | -------- | ------------------------------------------ | ------------- | -------------- | -------------- | ------------ | -------------- |
| Get Asan info by FIN | GET/POST |          | FIN üzrə ASAN məlumatlarının əldə edilməsi |               |                | 200, 400, 500  |              |                |

3.4.1 Table / DB Names
| Table / DB Name | Purpose | Related API | Notes |
| --------------- | ------- | ----------- | ----- |
| will be added   |         |             |       |

3.5 Stakeholders Involved
(Bax: 2. Stakeholder Register)

3.6 Sources Used
| Source | Type | Link / Attachment | Notes |
| ------ | ---- | ----------------- | ----- |
|        |      |                   |       |

3.7 Open Questions
| ID | Question | Owner | Status | Answer / Note |
| -- | -------- | ----- | ------ | ------------- |
| Q1 |          |       | Open   |               |

============================================================
4. TO-BE — SOLUTION DESIGN & REQUIREMENTS
============================================================

4.1 Document Header
| Field               | Description                            |
| ------------------- | -------------------------------------- |
| Issue Type          | Epic / Task                            |
| Epic / Task         | Jira link və ya task ID                |
| Initiator           | Sorğunu başladan şəxs / komanda        |
| Expectations        | Hədəf nəticə və biznes gözləntisi      |
| Translate Page Link | Uyğun Confluence / dokumentasiya linki |

4.2 TO-BE Workflow
| Workflow item             | Link / Description                                |
| ------------------------- | ------------------------------------------------- |
| BPMN / UML / FigJam Link  | Yeni proses axınının linki                        |
| UI Screen                 | Yeni ekran görüntüsü və ya dizayn linki           |
| UI Component Details      | Ekrandakı komponentlərin izahı                    |
| Button Actions            | Button klikləndikdə hansı əməliyyatın baş verdiyi |
| Related API               | Klik və ya əməliyyat zamanı müraciət edilən API   |
| Request / Response Models | API request və response modelləri                 |

Qeyd: Bu bölmədə UI ekran görüntüsü əlavə edilməli, ekrandakı
komponentlər izah olunmalı, button varsa klikləndikdə hansı
API-yə müraciət edildiyi və request/response modelləri
göstərilməlidir.

4.3 Detailed Workflow — Scenarios
| Step Name | Step Description |
| --------- | ---------------- |
| Addım 1   |                  |
| Addım 2   |                  |
| Addım 3   |                  |

4.4 Business Requirements
| ID     | Description | Priority            | Business Goal |
| ------ | ----------- | ------------------- | ------------- |
| BR-001 |             | High / Medium / Low |               |

4.5 Functional Requirements
| ID     | Title | Description | Requirements |
| ------ | ----- | ----------- | ------------ |
| FR-001 |       |             |              |

4.6 Field Descriptions
| Field / Attribute | Type   | Required | Validation         | Min-Max Value | Example | Related Screen             |
| ----------------- | ------ | -------- | ------------------ | ------------- | ------- | -------------------------- |
| fin               | String | Yes      | 7 simvol olmalıdır | 7             | ABC1234 | Müştəri məlumatları ekranı |

4.7 APIs
| API Name | Mapping | Enum | Response Codes     | Swagger Link | Related Screen |
| -------- | ------- | ---- | ------------------ | ------------ | -------------- |
|          |         |      | 200, 400, 404, 500 |              |                |

4.8 Stakeholders
(Bax: 2. Stakeholder Register)

4.9 Elicitation Sources
(Bax: 1. Requirements Elicitation)

4.10 Open Questions
| ID | Question | Owner | Status | Answer / Note |
| -- | -------- | ----- | ------ | ------------- |
| Q1 |          |       | Open   |               |

Nümunə

4.6 Field Descriptions — nümunə: Field: fin · Type: String · Required: Yes · Validation: 7 simvol olmalıdır · Example: ABC1234 · Ekran: Müştəri məlumatları 3.4 Existing APIs — nümunə: API: Get Asan info by FIN · Method: GET/POST · Endpoint: /asan/info · Purpose: FIN üzrə ASAN məlumatı · Codes: 200, 400, 500

Meeting Minutes (Görüş qeydləri)

Başlanğıc

Görüşdə danışılanları, qərarları və tapşırıqları qeyd edir.

Nə vaxt: Hər stakeholder görüşü və ya komanda toplantısından sonra.

Şablona bax

Məqsəd

Görüşdə nə razılaşdırıldığını yazılı saxlamaq — kimin nəyə cavabdeh olduğu və hansı qərarların verildiyi sonradan qarışmasın.

Əsas bölmələr

  • Görüş məlumatı və iştirakçılar
  • Müzakirə mövzuları və qərarlar
  • Tapşırıqlar (action items)

Hazır şablon

GÖRÜŞ QEYDLƏRİ (MEETING MINUTES)

- Görüşün mövzusu:
- Tarix / saat:
- Yer / platforma:
- İştirakçılar:
- İştirak etməyənlər:

Gündəlik (Agenda):
   1.
   2.

Müzakirə / əsas məqamlar:
   -

Qərarlar:
   -

Tapşırıqlar (Action Items):
   | Tapşırıq | Cavabdeh | Son tarix |
   |----------|----------|-----------|
   |          |          |           |

Növbəti görüş:

Nümunə

Qərar: Login üsulu OTP olacaq. Tapşırıq: «API tələbini hazırla — IT BA — 20.06».

Stakeholder Interview Questions

Başlanğıc

Maraqlı tərəflərdən tələbləri toplamaq üçün hazır sual dəsti.

Nə vaxt: Tələblərin toplanması (elicitation) mərhələsində müsahibə apararkən.

Şablona bax

Məqsəd

Stakeholderdən düzgün sualları soruşaraq real ehtiyacı, problemi və gözləntini üzə çıxarmaq.

Əsas bölmələr

  • Kontekst və rol sualları
  • Problem və ehtiyac sualları
  • Proses, gözlənti və prioritet sualları

Hazır şablon

STAKEHOLDER MÜSAHİBƏ SUALLARI

Rol və kontekst:
   - Bu prosesdə sizin rolunuz nədir?
   - Gündəlik işinizdə bu sistemdən necə istifadə edirsiniz?

Hazırkı vəziyyət (As-Is):
   - İndi bu iş necə görülür?
   - Hansı addımlar vaxt aparır və ya çətindir?

Problem və ehtiyac:
   - Ən böyük problem nədir?
   - Bu problem işə necə təsir edir?

Gözləntilər (To-Be):
   - İdeal həll necə görünərdi?
   - Hansı nəticə sizin üçün uğur sayılır?

Prioritet və məhdudiyyət:
   - Ən vacib funksiya hansıdır?
   - Hər hansı məhdudiyyət və ya qayda varmı?

Yekun:
   - Əlavə etmək istədiyiniz nə var?
   - Bu mövzuda daha kimlə danışmalıyam?

Nümunə

Sual: «İndi müştəri müqaviləsini necə öyrənir?» Cavab: «Filiala zəng edir.» → Buradan «onlayn müqavilə görünüşü» ehtiyacı üzə çıxır.