İş Analisti Olarak Gereksinimler Nasıl Düzenlenir?

⚡ Akıllı Özet

İş analisti olarak iş gereksinimlerini organize etmek, paydaşlardan gelen ham girdileri yapılandırılmış, önceliklendirilmiş ve tracGeliştiricilerin, test uzmanlarının ve yöneticilerin her birinin amacını kaybetmeden kendi tercih ettikleri formatta kullanabileceği, elektronik ortamda okunabilir bir belge.

📚 Tanım: İş gereksinimi, bir proje veya ürün için paydaşların ihtiyaçlarını, tartışılabilmesi, analiz edilebilmesi ve doğrulanabilmesi için yeterli ayrıntıda yakalayan resmi bir belgedir.
???? On Adımlı Yöntem: Kategorize etme, düzenleme, listeleme, tanımlama, sunma, içindekiler tablosu, araç, gereksiz bilgileri kaldırma, sürece eşleme ve tablolar ve madde işaretleriyle biçimlendirme.
📈 Kullanabileceğiniz Formatlar: Tablolar, elektronik tablolar, iş akışı diyagramları, grafikler, ER modelleri, prototipler ve yapılandırılmış cümle şablonları geçerli sunumlar olarak kabul edilir.
️ İş Analistlerinin Tercih Ettiği Araçlar: Jira, Confluence, Jama Connect, DOORS ile birlikte, Modern Requirements için Azure DevOps, Miro, LucidchartBalsamiq ve Figma.
🎯 Önce İzleyici: Aynı gereksinimi yöneticilere, geliştiricilere ve son kullanıcılara farklı şekillerde sunarak her paydaşın hızlı bir şekilde harekete geçmesini sağlayın.
⚠️ Tuzaklardan Kaçının: Ne ile nasıl'ı karıştırmak, belirsiz ifadeler, eksiklikler tracyetenek, önceliklendirme yok ve atlamaping Onay süreci, BRD'nin yeniden işlenmesinin çoğuna neden olur.

Devamını Oku

İş gereksinimi, bir proje veya ürün için paydaşların ihtiyaçlarını özetleyen resmi bir belgedir. İş gereksinimlerini sunmak için tek bir standart format yoktur, ancak her sürüm, tartışılması, analiz edilmesi, belgelenmesi ve doğrulanması için yeterli ayrıntıda ürünü veya projeyi kapsamalıdır.

Bir iş gereksinimi aşağıdaki yollardan herhangi biriyle sunulabilir:

Bir tablo veya e-tablo
Bir diyagram (iş akışı)
Grafik
Bir model (varlık-ilişki diyagramı)
Bir prototip veya simülasyon
Yapılandırılmış bir cümle veya metin şablonu

Bir İş Gereksinimi Nasıl Düzenlenir ve Sunulur

Aşağıda, gereksinimleri yazma ve düzenleme adımları yer almaktadır. İş Analisti.

) 1 Adım Gereksinimleri kategorilere ayırın.

Her gereksinimi ait olduğu kategoriye yerleştirin.
Teknik paydaşlar teknik gereksinim kategorisini, teknik olmayan paydaşlar ise iş veya genel gereksinim kategorisini görmelidir.
Her kuruluş, kendi standartlarına uygun kategorileri belirlemelidir.
Sınıflandırma, gereksinim türüne (işlevsel veya ticari) göre de yapılabilir, ancak bu ayrım her projeye uygun olmayabilir.

) 2 Adım Gereksinimleri düzenleyin.
Paydaşların belgede kolayca gezinmelerini ve eksik maddeleri tespit etmelerini sağlamak için gereksinimleri mantıklı bir sıraya göre toplayın ve düzenleyin.

) 3 Adım Bir liste hazırlayın.
Onaylaması gereken paydaşlara göre gruplandırılmış gereksinimlerin bir inceleme listesini hazırlayın.

Örneğin, teknik altyapıya sahip bir paydaş yalnızca ürünün teknik yönüyle ilgilenecektir.

) 4 Adım Benzersiz tanımlayıcılar kullanın.
If tracBirbirlerine gereksinimleri iletmek zor olduğundan, benzersiz tanımlayıcılar kullanın. tracDaha kolay hale getirmek.

) 5 Adım Gereksinimleri paydaşın tercih ettiği yöntemle sunun.
Aynı gereksinimi farklı paydaşlar için farklı formatlarda sunmanız gerekebilir; biri grafiksel bir görünümü tercih ederken, diğeri yapılandırılmış cümleleri tercih edebilir.

) 6 Adım Bir içerik tablosu hazırlayın.
Tüm gereksinimler için bir içindekiler tablosu oluşturun. Bu, paydaşlara yardımcı olur. track ve onları hızlıca bulun.

) 7 Adım İş Analizi araçlarını kullanın.
Kullanım İş Analizi araçları Bu, gereksinimlerin sürümler arasında tutarlı bir şekilde sunulmasına ve sınıflandırılmasına yardımcı olur.

) 8 Adım Gereksinim belgelerini süreç akışına göre düzenleyin.
Belgeden gereksiz gereksinimleri kaldırın ve kalanları destekledikleri süreç akışına göre düzenleyin.

) 9 Adım Gereksinimleri haritalandırın.
Topladığınız her gereksinimi, süreç akışındaki belirli bir adıma eşleştirin; böylece inceleyenler gereksinimi desteklediği iş akışıyla ilişkilendirebilirler.

) 10 Adım Tablo ve madde işaretlerini kullanın.
Karmaşık gereksinimleri sunmak için tablolar, her birinin kilit noktalarını vurgulamak için ise madde işaretleri kullanın.

İş Gereksinimleri Belgesi Yazma ve Sunma İçin Faydalı İpuçları

Daha iyi sunum için ve tracİş gereksinimlerinin kralı olan bu alanda, aşağıdaki ipuçları her İş Analisti (BA) için faydalıdır.

Gereksinimleri kategorize etmek zaman alıcıdır, bu nedenle her seferinde yeni kategoriler oluşturmak yerine, iş analistlerinin, paydaşların, konu uzmanlarının ve teknik ekiplerin projeler arasında yeniden kullanabileceği standart bir kategori kümesi tanımlayın.
Her gereksinimi hedef kitlesi bağlamında hazırlayın. Başlıca oyuncuları, etkileyicileri ve karar vericileri (paydaşlar, teknik personel, geliştiriciler vb.) anlayın.
Bir seferde bir gereksinim tanımlayın. Her gereksinim atomik olmalıdır.
Belirsizlikten kaçının — gereksinim ifadelerinde "vb." veya "yaklaşık." gibi muğlak niteleyiciler kullanmayın.
Henüz tanımlanmamış bir gereksinime atıfta bulunmayın.
Belgedeki yinelenen ve çelişkili ifadeleri kaldırın.
Karmaşık gereksinimleri daha küçük, yönetilebilir ve gözden geçirilebilir noktalara ayırın.
Tanımlamak ne Sistem yeterli olacaktır, gerek yok. Nasıl Bunu yapacaktır; uygulama tasarım aşamasında yer almalıdır.

İş Gereksinimlerini Görselleştirmek İçin Popüler Teknikler

Uzun ve karmaşık metinler, paydaşları kaybetmenin en hızlı yoludur. İş analistleri, her metin tabanlı gereksinimi görsel bir unsurla eşleştirerek amacın bir bakışta anlaşılmasını sağlarlar. Aşağıdaki teknikler BABOK Kılavuzu'nda ve çoğu kurumsal iş analisti uygulamasında yer almaktadır.

İş Süreci Modelleme ve Gösterimi (BPMN): BPMN, havuzlar, şeritler, geçitler ve olaylar kullanarak uçtan uca iş süreçlerini şematik olarak gösterir. Kimin neyi ne zaman yaptığını göstermek için idealdir.
Kullanım Durumu Diyagramları ve Descriptiyonu Aktör-sistem etkileşimlerini ve her aktörün beklediği sonuçları yakalayın. Özellik odaklı ürün geliştirme listeleri için idealdir.
Kabul Kriterleri İçeren Kullanıcı Hikayeleri: Kısa "Bir ... olarak şunu istiyorum, böylece..." ifadeleri, Verilen-Ne Zaman-O Zaman kriterleriyle birlikte kullanılır. Çevik ekiplerde varsayılan format budur.
Tel çerçeveler ve maketler: Düşük veya orta çözünürlüklü ekranlar, şu alanlarda üretilmiştir: FigmaBalsamiq veya Axure Bu, kullanıcı arayüzü gereksinimlerini teknik olmayan paydaşlar için somut hale getirir.
Varlık İlişki Diyagramları (ERD): Çözümün saklaması gereken veri varlıklarını ve aralarındaki ilişkileri gösterin; bu, raporlama ve entegrasyon gereksinimleri için kritik öneme sahiptir.
Veri Akış Diyagramları (DFD): TracVerilerin süreçler, depolar ve harici aktörler aracılığıyla nasıl hareket ettiğini, özellikle analitik veya entegrasyon projelerinde nasıl işlediğini açıklayın.

Tekniği hedef kitleye uygun hale getirin: yöneticiler süreç haritalarına ve yolculuk diyagramlarına, geliştiriciler ERD'lere ve kullanıcı hikayelerine, son kullanıcılar ise tel çerçevelere ve prototiplere tepki verir.

İş Gereksinimleri Belgelerini Düzenlemek İçin Yaygın Kullanılan Araçlar

Gereksinim sayısı birkaç düzineyi geçtiğinde, Word belgesi artık yeterli gelmez. İş analistleri, temel belirleme, inceleme ve daha fazlasını destekleyen amaca yönelik araçlara geçerler. tracVerimlilik ve değişim kontrolü. Aşağıdakiler, sektör genelinde en yaygın kullanılanlardır.

Jira ve Confluence: Çevik ekipler için varsayılan kombinasyon. Gereksinimler Jira'da epikler ve hikayeler olarak yer alırken, BRD anlatımını ve diyagramlarını içeren Confluence sayfaları tarafından desteklenir.
Jama Bağlantısı: Gereksinim yönetimi, temel belirleme ve canlı çözümlere odaklanan kurumsal platform. tracTıbbi cihazlar ve havacılık gibi düzenlemeye tabi sektörler için uygunluk.
IBM Engineering Requirements Yönetim KAPILARI: Savunma, otomotiv ve güvenlik açısından kritik sistemlerde uzun zamandır kullanılan, her gereksinimin karşılanması gereken bir araç. tracmümkün.
Modern Requirements için Azure DevOps: Uzattı Azure DevOps, inceleme, onaylama, temel belirleme ve Word tarzı BRD dışa aktarımını doğrudan iş öğelerinden gerçekleştirme imkanı sunar.
Miro or Lucidchart: BPMN, ERD'ler, kullanıcı yolculukları ve atölye notlarının taslaklarını oluşturmak için kullanılan beyaz tahta ve diyagram çizim araçları, daha sonra resmi BRD'ye katkıda bulunur.
Balsamiq ve Figma: Kullanıcı arayüzü gereksinimlerini metinsel yerine görsel olarak sunan tel çerçeve ve prototip araçları.

Projenin ölçeğine ve denetim ihtiyaçlarına uygun araç setini seçin. Daha küçük projeler Confluence ve Jira ile başlayabilirken, düzenlemeye tabi programlar genellikle Jama veya DOORS'a ihtiyaç duyar. tracEhliyet denetimleri.

İş Gereksinimlerini Sunarken Yapılan Sık Hatalar

İyi araştırılmış bir gereksinim bile, kötü sunulursa reddedilebilir. Aşağıdaki hatalar çoğu iş analizi sonrası incelemesinde görülür ve inceleme sırasında bunlardan kaçınılmalıdır.

Neleri ve nasıl karıştırmak: kaymaping Gereksinim ifadesine uygulama detaylarını eklemek, analiz tamamlanmadan önce tasarım ekibini bir çözüme kilitler.
Belirsiz ifade: “Hızlı”, “kullanıcı dostu” veya “esnek” gibi kelimeler test edilemez. Bunların yerine ölçülebilir kabul kriterleri kullanın.
Her paydaş için tek bir format: Yöneticilere, geliştiricilere ve son kullanıcılara aynı görüşü sunmak genellikle hiçbirini memnun etmez. Formatı hedef kitleye göre uyarlayın.
Eksik tracYetenek: İş hedefleri, tasarım unsurları ve test senaryolarıyla bağlantılı olmayan gereksinimler, değişiklik talebi geldiğinde savunulamaz.
Önceliklendirme yok: MoSCoW, ağırlıklı puanlama veya benzer bir çerçeve olmadan yüzlerce gereksinimi sunmak, paydaşları değer yerine kapsam hakkında tartışmaya zorlar.
Aşırı yüklenmiş belgeler: Her diyagramı, log kaydını ve gerekçeyi tek bir 200 sayfalık PDF'ye sıkıştırmak, önemli gereksinimleri gizler. İş gereksinim belgesini (BRD) net bir içindekiler tablosuyla mantıksal bölümlere ayırın.
Atlamakping bitirmek: BRD'yi resmi bir onay aşaması olmadan sunmak, daha sonra teslimatta kapsam genişlemesine ve suçlamalara yol açabilir.

RevHer paydaş toplantısından önce BRD'yi bu listeyle karşılaştırmak, sonraki aşamalarda yeniden çalışmaya neden olan sorunların çoğunu yakalamayı sağlar.

SSS

Yapay zeka araçları, ilgili gereksinimleri kümelendirir, tekrarları ve çelişkileri işaretler, kabul kriteri taslakları oluşturur ve paydaş görüşmelerini yapılandırılmış kullanıcı hikayelerine dönüştürür. İş analistleri, onay vermeden önce oluşturulan her ifadeyi iş hedefine göre doğrulamaya devam eder.

Copilot ve GPT, toplantı notlarından bir BRD iskeleti taslağı oluşturabilir, kullanıcı hikayelerini genişletebilir ve ilk aşama kabul kriterlerini üretebilir. Revİncelemeciler, belge temel alınmadan önce her gereksinimin test edilebilir, açık ve paydaş ihtiyacına uygun olduğunu teyit ederler.

BRD (İş Gereksinimleri Belgesi) iş ihtiyaçlarını ve hedeflerini yakalar, FRD (Fonksiyonel Davranış Belgesi) çözümün sağlaması gereken fonksiyonel davranışı tanımlar ve SRS (Yazılım Gereksinimleri Belgesi) ise fonksiyonel ve fonksiyonel olmayan gereksinimleri kapsayan geliştiriciye yönelik bir spesifikasyondur. Her belge farklı bir hedef kitleye ve detay seviyesine yöneliktir.

Yaygın kullanılan çerçeveler arasında MoSCoW (Olması Gereken, Olması Gereken, Olabilir, Olmaz), ağırlıklı puanlama, Kano analizi, gecikme maliyeti ve değer-çaba matrisleri yer almaktadır. Paydaşlar ve ürün sahipleri gereksinimleri sıralayarak, teslimat ekibinin her zaman en yüksek değere sahip öğe üzerinde çalışmasını sağlarlar.

RTM (Requirement to Mechanism), her gereksinimi kaynağına, tasarım öğesine, kod bileşenine ve test senaryosuna bağlayan bir belgedir. Hem ileriye hem de geriye dönük uyumluluğu destekler. tracUygunluk, değişiklik talepleri sırasında kapsamın korunması ve denetimler sırasında kanıt sunulması.

Tek bir en iyi araç yok. Çevik ekipler Confluence ile Jira kullanırken, düzenlenmiş programlar Jama Connect veya benzeri araçları kullanıyor. IBM KAPILAR ve Microsoft dükkanlar kullanmak Modern Requirements için Azure DevOps. Ekip büyüklüğüne, denetim ihtiyaçlarına ve entegrasyon gereksinimlerine uygun aracı seçin.

Çevik ekipler, gereksinimleri ürün birikim listesinde epikler, kullanıcı hikayeleri ve kabul kriterleri olarak sunar. İş analisti, her hikayenin sprint başlamadan önce küçük, test edilebilir ve bağımsız olmasını sağlamak için Ürün Sahibi'ne geliştirme, iyileştirme ve Hazırlık Tanımı incelemelerinde destek olur.

İyi yazılmış bir gereksinim, atomik, test edilebilir olmalıdır. tracUygulanabilir, açık ve öncelikli. Sistemin ne yapması gerektiğini belirtir, nasıl yapacağını değil; ve geliştiricilerin ve test uzmanlarının teslimatı belirsizlik olmadan doğrulayabilmeleri için ölçülebilir kabul kriterleri içerir.