Cevap.

Gereksinim toplama yaklaşımları tarihsel olarak lineer olarak düşünülmüştür: analist, çeşitli paydaşlarla iletişim kurar, isteklerin listelerini oluşturur ve bunları bir spesifikasyona dönüştürür. Gerçekte, proje ne kadar büyükse, farklı paydaş grupları arasında gereksinimler arasındaki üst üste gelmeleri, tekrarları ve tam zıt görevleri belirlemek o kadar zorlaşır.

Problem

Büyük sistemlerde sıkça karşılaşılır:

farklı departmanlar arasındaki çelişkiler (örneğin, güvenlik vs kullanım kolaylığı);
üst üste gelmeler ve tekrarlar (farklı ekipler aynı şeyi farklı açılardan istemektedir);
gizli bağımlılıklar (bir değişiklik diğerlerini tetikler).

Analiz aşamasındaki bir hata, uygulamalarda çatışmalara, sürelerin uzamasına, çalışmayan mekanizmalara veya modüllerin entegrasyonunun imkansız hale gelmesine yol açabilir.

Çözüm

Bir profesyonel sistem analisti, aşağıdaki teknikleri kullanmak zorundadır:

bağımlılık matrisleri oluşturma (örneğin, ".requirement-traceability-matrix") ve modeller (UML diyagramları, ER diyagramları);
zıt paydaş grupları arasında çalışma toplantıları ve değerlendirmeler yapma;
"gereksinim çelişkilerini çözme" tekniğini kullanma (örneğin, kolaylaştırma oturumları);
her aşamada gereksinimler arasındaki ilişkileri görmeyi sağlayan izleme (traceability) araçları entegre etme (örneğin, API gereksinimleri ve bu işlemler için güvenlik gereksinimleri);
gereksinimlerin düzenli olarak güncellenmesi ve önceliklendirilmesi.

Anahtar özellikler:

Matrisler ve diyagramlar karmaşık projeler için zorunludur.
Çelişki çözümü analistin sorumluluğudur.
Gizli bağımlılıklar modelleme ve iletişim yoluyla ortaya çıkar.

Hileli Sorular.

Gereksinimlerin önceliklendirilmesi çelişkilerin çözüm yolu mudur?

Hayır, önceliklendirme, uygulama sırasının belirlenmesidir. Çelişkiler, bunları bir geri bildirim listesine koymadan önce, uzlaşma veya gereksinimlerin gözden geçirilmesi yoluyla çözülmelidir.

Tüm ilişkileri yalnızca otomatik araçlarla belirlemek mümkün mü?

Hayır, otomasyon (örneğin, izleme araçları) yardımcı olur, ancak iç içe geçmiş iş mantıkları, süreçlerin nüansları ve gizli çatışmalar yalnızca gerçek paydaşlarla tartışmalar yoluyla kaydedilir.

Gereksinimlerin kesişmesi, birinin muhakkak gereksiz olduğu anlamına mı gelir?

Hayır, gereksinimler ifadelerinde örtüşebilir, ancak farklı nihai hedeflere sahip olabilir. Anlamı kontrol etmek ve bunları birleştirme veya açığa çıkarma fırsatlarını aramak gerekmektedir.

Tipik Hatalar ve Anti-Desenler

Çelişkili gereksinimlerin aceleyle birleştirilmesi (birini kaldırınca işletme senaryoları bozulur).
İlişkilerin belgelenmemesi — revizyonlarda eski gereksinimler "kaybolur" ve ihlal edilir.
Canlı iletişimler olmadan yalnızca belgelere güvenme.

Hayattan bir Örnek

Olumsuz vaka: Bir bankanın CRM sisteminde, iki departman bağımsız olarak "müşteri hızlı arama" entegrasyonu talep etti. Gereksinimler ayrı ayrı uygulandı, tekrarlar belirlenmedi — iki farklı arama, karışık senaryolar ortaya çıktı.

Artılar:

Her departmanın ayrı ayrı memnuniyeti

Eksiler:

Arayüz tutarsızlığı
Destek yükünün artması
Projenin maliyetinin yükselmesi

Olumlu vaka: Analist, ana gereksinim parçalarıyla atölye çalışmaları düzenledi, bağımlılık matrisini oluşturdu, senaryoları müşterilerle ve uygulayıcılarla iterasyonlar halinde onayladı.