Cevap.

Soru geçmişi:

Başlangıçta, gereksinimlerin formalleştirilmesinde odak işlevsel yetenekler üzerineydi, ancak zamanla, ilk bakışta "görünmeyen" kriterlerin (performans, güvenlik, dayanıklılık vb.) ürünlerin başarılı bir şekilde uygulanması ve sürdürülebilirliği için kritik öneme sahip olduğu anlaşıldı. Bunların göz ardı edilmesi, yazılımın lansmanı sonrası arızalara ve öngörülemeyen davranışlara yol açıyordu.

Sorun:

İşlevsel olmayan gereksinimler genellikle bağlam incelenmeden standart bir şekilde belgelenir. Bunlar, "Otomanın kullanışlı olması gerekir" veya "Sistem hızlı olmalıdır" gibi sadece işaret koymak için belirtilir veya çok soyut bir şekilde oluşturulurlar. Bu, geliştiricilere, mimarlara ve test uzmanlarına net bir KPI sağlamaz.

Çözüm:

Sistem analisti, gerçek kısıtlamaları ortaya çıkarmak için iş, IT ve bakım uzmanları ile oturumlar düzenler, niceliksel metrikler (örneğin, SLA, TPS, gecikme değerleri) kaydeder, işlevsel olmayan gereksinimleri açık bir şekilde spesifikasyonlarda tanımlar ve daha sonra bunların test edilebilirliğini test senaryoları ve proje mimari belgeleriyle bağlayarak sağlar.

Anahtar özellikler:

Nicel (ölçülebilir!) özelliklerin kullanımı.
Anahtar IT uzmanları ile mutabakat yoluyla formalleştirme ve gerekçe aşamasının dahil edilmesi.
Gereksinimlerin test yöntemleri ile bağlanması.

İnce sorular.

"Sistem, 24/7 erişilebilir olmalıdır" gibi grup gereksinimleri bırakmak yeterli midir?

Hayır, erişim parametrelerini (örneğin, %99.95) ve kurtarma koşullarını kesinlikle belirtmek gerekir.

"Yanıt süresi hızlı olmalıdır" demek yeterli midir?

Hayır, bu tür ifadeler işe yaramaz. Örneğin: Yük altında %95 taleple 3 saniye < Yanıt süresi gibi belirtmek gereklidir.

Genel TDD'de sadece yazılmışlarsa işlevsel olmayan gereksinimler formalleştirilmiş midir?

Hayır, bunların ayrıştırılması ve mimari çözümler ve test planları ile bağlanması gerekir, aksi takdirde yerine getirilmesi imkansız veya doğrulanamaz kalacaktır.

Tipik hatalar ve anti-desinler

Test etmeyi sağlamayan belirsiz ifadeler bırakmak.
Diğer projelerden gereksinimlere kopyalama yapmak ve özel durumları analiz etmemek.
IT/SRE ve bakım danışmanlıklarını yok saymak.

Gerçek yaşam örneği

Olumsuz vaka: e-banking projesi, SLA detaylandırılmadan "24/7 erişilebilirlik, hızlı çalışma" talebiyle başlatıldı.

Artılar:

Gereksinimlerin hızlı hazırlanması

Eksiler:

Sık arızalar, dış kaynak sağlayıcı ile çözümsüz tartışmalar
Müşteri şikayetleri

Olumlu vaka: Analist, bakım bölümü ile çalışarak %99.9 uptime, maksimum yanıt süresi 2 saniye belirtti ve bozulma senaryolarını açıkladı.