Cevap.

İş kuralları, bir şirket tarafından belirlenen formal veya informal normlardır ve iş yapma, karar alma, hesaplama, iletişim ve bilgi işleme yöntemlerini tanımlar.

Bir iş analisti, bu kuralları belirler, analiz eder ve belgeler; böylece gelecekteki sistemin veya sürecin şirketin gereksinimlerine ve yasalara uygun olmasını sağlar. Kurallar basit (örneğin, "indirim sadece düzenli müşterilere verilir") veya karmaşık olabilir (örneğin, "otomatik bonus dağıtımı yalnızca belirli şartlar yerine getirildiğinde gerçekleşir").

İş kurallarının doğru tanımlanması şunları garanti eder:

• Sistem iş mantığının gerçek süreçlerle örtüşmesi.
• Farklı sistemler ve departmanlar arasında gereksinimlerin tutarlılığı.
• Yazılımın güncellenmesi, test edilmesi ve desteklenmesinin kolaylaşması.

Anahtar özellikler:

• Tüm gereksinimler iş kuralları değildir. Bazıları uygulama veya entegrasyon kısıtlamalarıdır.
• İş kuralları sık sık değişir, bu nedenle bunları koddan ayırmak ve belgede tutmak önemlidir.
• Tanım dilinin hem iş dünyası hem de teknik uzmanlar için açık ve anlaşılır olması gerekir.

İkna edici sorular.

İş kuralları her zaman iş gereksinimleri ile aynı mıdır?

Hayır, iş gereksinimleri ulaşılan hedefi tanımlar, iş kuralları ise bu hedefe ulaşma yollarını veya kısıtlamalarını belirtir. Örneğin, bir gereksinim "satışları %10 artırmak" olabilirken, bir iş kuralı "yeni müşterilere %5'ten fazla indirim verilmemesi" şeklindedir.

İş mantığını iş kurallarının analizi ve formalleştirilmesi olmadan gerçekleştirmek mümkün müdür?

Hayır, çünkü formalize edilmemiş kurallar belirsizliklere, süreçlerin otomasyonunda hatalara ve şirketin düzeninin ihlaline yol açar.

İş kurallarının tanımı nerede saklanmalıdır: sadece şartnamede mi yoksa sistemin kodunda da mı?

İş kurallarının tanımı, hem proje belgelerinde (örneğin, gereksinimlerde veya ayrı bir kural kayıt defterinde) yer almalı, hem de sistemin iş mantığında yansımalıdır, ancak ana kaynak belge olmalıdır, kod değil.

Yaygın hatalar ve anti-patentler

• İş kurallarının çok genel veya belirsiz terimlerle formüle edilmesi.
• Farklı belge bölümlerinde iş kurallarının tekrarı.
• Bir kuralın istenmeyerek farklı durumları kapsayacak şekilde yetersiz detaylandırılması.
• İş kurallarının "varsayılan" olarak açık bir tanım olmadan bırakılması (sessiz bilgi).

Hayattan örnekler

Olumsuz durum:

• Kredi başvurusu otomasyon projesinde, yöneticiler yalnızca sözlü olarak iş kurallarını tekrar etti ve bunları spesifikasyona yansıtmadı, farklı geliştiricilere sözlü olarak açıkladılar — sonucunda bir senaryonun 3 farklı uygulama versiyonu ortaya çıktı. Artıları: MVP'yi hızlı bir şekilde başlattılar; onay süresinin minimize edilmesi. Eksileri: Farklı senaryolarda mantık uyuşmazlığı, otomasyonda sorunlar, departmanlar arası çatışmalar.

Olumlu durum:

• Kredi onaylama görevi için iş analisti tüm başvuru türleri için bir iş kuralı kaydı oluşturdu, bunu bir avukat ve IT ile onayladı. Uygulama biraz daha fazla zaman aldı, ancak kurallar herkes için anlaşılırdı. Artıları: İş mantığının açık olması, otomasyondaki hataların minimize edilmesi. Eksileri: İlk belgelendirme için daha fazla zaman harcandı.