Cevap.

Sorunun Arka Planı:

IT projelerinin karmaşıklığı ve katılan uzman sayısının artmasıyla birlikte bir sorun ortaya çıktı: iş paydaşları anlaşılır bir tanım talep ederken, teknik ekip detaylı ve teknik olarak doğrulanmış bir tanım istiyor. Evrensel bir standart yok ve tarihsel olarak sistem analisti iki dünya arasında bir "çevirmen" haline geldi, gereksinimlerin formalizasyon düzeyini hedef kitleye uyacak şekilde uyarladı.

Sorun:

İş analistleri diyagramları ve spesifikasyonları okuyamıyor, UML/BPMN terimlerine aşina değiller. Geliştiriciler ise kullanıcı hikayeleri ve genel vizyon ile yetinmiyor — net kriterlere, şemalara, API şemalarına, veri formatlarına ihtiyaçları var. Analist yanlış bir gereksinim formatı seçerse, yanlış anlama, fonksiyonel uyumsuzluklar ve süreler kayması riskleri ortaya çıkar.

Çözüm:

Anahtar rolleri/tarafları belirlemek ve onların deneyimlerini, beklentilerini ve ihtiyaçlarını araştırmak için bir dizi mülakat veya anket düzenlemek.
İş talepçileri için — senaryolar (kullanıcı hikayeleri), BPMN diyagramları, terim sözlükleri, interaktif prototipler ve wireframe'ler kullanmak. Aşırı detaylandırmadan kaçınmak.
Geliştirme için — yapılandırılmış teknik spesifikasyonlar (SRS, sınıf diyagramları, ER diyagramları, API tanımları, Kabul Kriterleri) hazırlamak, net bir yorum sağlamaya dikkat etmek.
Uygulayıcılar ve test uzmanları için — ayrı kontrol listeleri, kabul kriterleri, test vakaları ve etkileşim şemaları hazırlamak.

Anahtar: Aynı gereksinim setini her hedef kitle için uygun bir formatta düzenlemek, herhangi bir yanlış anlamaya yol açmadan.

Anahtar Özellikler:

Gereksinim formatını kitlelerin yetkinliklerine ve beklentilerine uyarlama
Aynı gereksinimler için birden fazla karşılıklı anlaşılmış temsil kullanma
Tamlık ile aşırı detaylandırma arasında bir "altın ortayı" seçme

Kandırmaca Soruları.

SRS (Yazılım Gereksinimleri Spesifikasyonu) şablonunu alıp proje katılımcılarına değişiklik yapmadan iletmek mümkün mü?

Hayır. Aynı belge farklı roller için etkisizdir - iş talepçisinin SRS'i pek anlamayacak, uygulama ekibinin ise ihtiyaç duyduğu detaylardan yoksun kalma riski var. Gereksinimler her hedef kitle için uyarlanmalıdır.

Sıklıkla duyuluyor: "BPMN ve UML diyagramları, gereksinimlerin yazılı tanımını tamamen ikame ediyor — bu doğru mu?"

Hayır. Diyagramlar güçlü bir görsel ekleme olarak önemlidir, ancak her zaman açıklamalarla desteklenmelidir çünkü birçok paydaş (özellikle iş tarafı) notasyonları bilmez. Açıklayıcı bir blok olmadan birçok anlaşılmayan ayrıntı kalır.

İş ve teknik gereksinimleri bir bölümde karıştırmak mümkün mü?

Töre önerilmez. Bu, farklı roller için bilgilerin arama ve anlama konusunda zorluk çıkarır ve uygulama aşamasında hatalara yol açar. Belgelendirmeyi, iş gereksinimleri, teknik spesifikasyonlar, fonksiyonel olmayan beklentiler ve kabul kriterlerini net bir şekilde yapılandırarak yapılandırmak gerekir.

Tipik Hatalar ve Anti-Desenler

Tüm roller için yalnızca bir gereksinim formatı kullanma
Gereksiz yere detaylandırma (iş için "tonlarca şema")
Profesyonel jargonun kötüye kullanılması
Terim sözlüğünün olmaması, yanlış anlamalara yol açar.

Hayattan Bir Örnek

Olumsuz Durum

Analist, içinde karmaşık UML şemalarının yer aldığı büyük bir SRS belgesi hazırladı. İş paydaşları bunu hiç açmadı, uygulama ekibi ise göz kararıyla yorumlarda bulundu, entegrasyonlarda hatalar oluştu.

Artılar:

Formal olarak belgeler mevcut idi.

Eksiler:

İş, işlevleri anlamadı.
Birçok geri dönüş ve düzeltme oldu.
Geliştiriciler, bazı gereksinimleri göz ardı etti.

Olumlu Durum

İş için, interaktif prototipler ve temel iş terimleri içeren bir sunum hazırlandı, teknik ekip için ayrı bir teknik spesifikasyon ve API akış şeması oluşturuldu. Belgelendirme, Confluence'te tartışma statüleri ile güncellenerek desteklendi.