İş Analizi - Hızlı Kılavuz

İş Analizi nedir?

İş Analizi, iş gereksinimlerini belirlemek ve kurumsal iş sorunlarına çözümler belirlemek için gereken görevler, bilgiler ve teknikler kümesidir. Genel tanım benzer olmakla birlikte, uygulamalar ve prosedürler çeşitli sektörlerde farklılık gösterebilir.

Bilgi teknolojisi endüstrisinde, çözümler genellikle bir sistem geliştirme bileşeni içerir, ancak aynı zamanda süreç iyileştirme veya organizasyonel değişikliği de içerebilir.

Bir kuruluşun mevcut durumunu anlamak veya iş ihtiyaçlarının belirlenmesi için bir temel oluşturmak için iş analizi de yapılabilir. Ancak çoğu durumda, iş ihtiyaçlarını, amaçlarını veya hedeflerini karşılayan çözümleri tanımlamak ve doğrulamak için iş analizi yapılır.

İş Analisti kimdir?

İş analisti, bir kuruluşu veya iş alanını (gerçek veya varsayımsal) analiz eden ve iş modelini veya teknolojiyle entegrasyonunu değerlendirerek işini, süreçlerini veya sistemlerini belgeleyen kişidir. Bununla birlikte, analist, iş analisti, iş sistemleri analisti veya belki sistem analisti gibi organizasyonel unvanlar değişir.

Neden İş Analisti?

Kuruluşlar, aşağıdaki nedenlerle iş analizi kullanır:

  • Bir sistemin kurulacağı organizasyonun yapısını ve dinamiklerini anlamak.

  • Hedef organizasyondaki mevcut sorunları anlamak ve iyileştirme potansiyellerini belirlemek.

  • Müşterinin, son kullanıcının ve geliştiricilerin hedef organizasyon hakkında ortak bir anlayışa sahip olmasını sağlamak.

Bir projenin ilk aşamasında, gereksinimler çözüm ve tasarım ekipleri tarafından yorumlanırken, bir İş analistinin rolü, çözüm belgelerini gözden geçirmek, çözüm tasarımcıları (BT ekibi) ve Proje yöneticileri ile yakın çalışmaktır. gereksinimler açık.

Tipik bir büyük boyutlu BT organizasyonunda, özellikle bir geliştirme ortamında, yukarıda belirtilen rollere sahip olan Yerinde ve denizaşırı teslimat ekiplerini bulabilirsiniz. Her iki ekibi birbirine bağlamak zorunda olan kilit bir kişi olarak hareket eden bir "İş Analisti" bulabilirsiniz.

Bazen, iş kullanıcıları ve bazen de teknik kullanıcılar ve son olarak da belgelere geçmeden önce onay almak ve son başını sallamak için projelerdeki tüm paydaşlarla etkileşime giriyordu.

Bu nedenle, BA'nın rolü, herhangi bir proje için etkili ve başarılı bir hızlı başlangıçta çok önemlidir.

BT İş Analistinin Rolü

Bir İş analistinin rolü, kuruluşun iş alanlarını tanımlamak ve kapsamını belirlemek, ardından gereksinimleri ortaya çıkarmak, gereksinimleri analiz etmek ve belgelemek, bu gereksinimleri uygun paydaşlara iletmek, doğru çözümü belirlemek ve ardından çözümün uygun olup olmadığını bulmak için gereksinimleri beklenen standartları karşılar.

Diğer mesleklerden farkı nedir?

İş analizi; finansal analiz, proje yönetimi, kalite güvencesi, organizasyonel geliştirme, test, eğitim ve dokümantasyon geliştirmeden farklıdır. Bununla birlikte, kuruluşa bağlı olarak, bir İş Analisti bu ilgili işlevlerin bir kısmını veya tamamını gerçekleştirebilir.

Yalnızca yazılım sistemleri geliştirmek için çalışan iş analistleri, BT iş analistleri, teknik iş analistleri, çevrimiçi iş analistleri, iş sistemleri analistleri veya sistem analistleri olarak adlandırılabilir.

İş analizi ayrıca paydaşlar, geliştirme ekipleri, test ekipleri vb. Arasındaki irtibat çalışmalarını da içerir.

Yazılım geliştirme Yaşam Döngüsü

Yazılım Geliştirme Yaşam Döngüsü (SDLC), bir yazılım organizasyonu içinde bir yazılım projesinde izlenen bir süreçtir. Belirli bir yazılımın nasıl geliştirileceğini, korunacağını, değiştirileceğini ve değiştirileceğini veya iyileştirileceğini açıklayan ayrıntılı bir plandan oluşur. Yazılım kalitesini ve genel geliştirme sürecini iyileştirmek için bir metodoloji tanımlar.

  • SDLC, hem müşteriyi hem de gerçek dünyanın gereksinimlerini karşılayan yüksek kaliteli yazılım sistemini geliştirmek veya yeniden tasarlamak için BT analistleri tarafından kullanılan bir süreçtir.

  • Yazılım testi, analizi ve proses sonrası bakımın tüm ilgili yönlerini dikkate alır.

SDLC'nin önemli aşamaları aşağıdaki şekilde tasvir edilmiştir -

Planlama evresi

Her aktivite bir planla başlamalıdır. Planlamada başarısız olmak, başarısız olmayı planlamaktır. Planlamanın derecesi bir modelden diğerine farklılık gösterir, ancak sistemin özelliklerini oluşturarak ne yapacağımızı net bir şekilde anlamak çok önemlidir.

Aşama Tanımlama

Bu aşamada sistemin yapısını analiz edip tanımlıyoruz. Mimariyi, bileşenleri ve bu bileşenlerin çalışan bir sistem oluşturmak için nasıl bir araya geldiğini tanımlıyoruz.

Tasarım Aşaması

Sistem tasarımında, ekran düzenleri, iş kuralları, süreç diyagramları ve diğer dokümantasyon dahil olmak üzere tasarım işlevleri ve işlemleri ayrıntılı olarak açıklanmaktadır. Bu aşamanın çıktısı, yeni sistemi modüller veya alt sistemler topluluğu olarak tanımlayacaktır.

Bina Aşaması

Bu, geliştirme aşamasıdır. Sistemi hayata geçirmek için derleyiciler, yorumlayıcılar, hata ayıklayıcılar kullanarak sistemin tasarımına dayalı olarak kod üretmeye başlıyoruz.

Uygulama

Uygulama, İnşaat Aşamasının bir parçasıdır. Bu aşamada, sistemi hayata geçirmek için derleyiciler, yorumlayıcılar, hata ayıklayıcılar kullanarak sistemin tasarımına dayalı kod üretmeye başlıyoruz.

Test Aşaması

Sistemin farklı bölümleri tamamlandıkça; bir dizi teste tabi tutulurlar. Ürünün ihtiyaç aşamasında ele alınan ihtiyaçları gerçekten çözdüğünden emin olmak için gereksinimlere karşı test edilir.

  • Hataları belirlemek ve sistemin spesifikasyonlara göre çalıştığından emin olmak için test planları ve test senaryoları kullanılır.

  • Bu aşamada birim testi, manuel test, kabul testi ve sistem testi gibi farklı test türleri yapılır.

Testte Kusur Takibi

Yazılım test raporları, yürütülen test planlarının sonuçlarını iletmek için kullanılır. Bu durumda, bir rapor, test edilmekte olan mevcut sistemle ilgili tüm test bilgilerini içermelidir. Raporların eksiksizliği, gözden geçirme oturumlarında doğrulanacaktır.

Bir proje için test yapmak iki ana hedefi gerçekleştirmeyi amaçlar -

  • Sistemdeki arızaları ve kusurları tespit edin.

  • Gereksinimler ve uygulama arasındaki tutarsızlığı tespit edin.

Aşağıdaki akış şeması, Defect Tracking Process -

Ana hedeflere ulaşmak için, önerilen sistem için test stratejisi genellikle dört test seviyesinden oluşacaktır.

Bunlar birim testi, entegrasyon testi, kabul testi ve regresyon testidir. Aşağıdaki alt bölümler, geliştirme ekibi rollerinin bunları geliştirmekten ve yürütmekten sorumlu olduğu bu test seviyelerini ve bunların eksiksizliğini belirleme kriterlerini özetlemektedir.

Dağıtım

Test aşaması sona erdikten sonra sistem serbest bırakılır ve üretim ortamına girer. Ürün test edildikten ve kullanıma hazır hale getirildikten sonra, uygun pazarda resmi olarak piyasaya sürülür. Bazen ürün dağıtımı, kuruluşun iş stratejisine göre aşamalar halinde gerçekleşir.

Ürün ilk olarak sınırlı bir segmentte piyasaya sürülebilir ve gerçek iş ortamında test edilebilir (UAT - Kullanıcı kabul testi). Daha sonra geri bildirimlere göre ürün olduğu gibi veya hedefleme pazarı segmentinde önerilen geliştirmelerle piyasaya sürülebilir.

SDLC Sonrası İşlem

Ürün piyasaya sürüldükten sonra mevcut müşteri kitlesi için bakımı yapılır.

Üretim ortamına girdikten sonra, sistem, tespit edilmeyen hatalar veya diğer beklenmedik olaylar nedeniyle değişikliklere maruz kalacaktır. Sistem değerlendirilir ve sistemin bakımı için döngü tekrarlanır.

SDLC Sürecinde İş Analistinin Rolü

Aşağıdaki diyagramda görebileceğimiz gibi, BA, iş gereksinimlerini artırmaya ve bunları çözüm gereksinimlerine dönüştürmeye dahil oluyor.

Çözüm özelliklerinin yazılım gereksinimlerine çevrilmesiyle ilgileniyor. Daha sonra analiz ve tasarım aşamasında liderlik eder, kod geliştirmede dikte eder, ardından proje ekibinde bir değişiklik temsilcisi olarak hata düzeltme sırasında test aşamasını izler ve nihayetinde müşteri gereksinimlerini karşılar.

İş Analizi - Roller

Bir BT Projesinde bir iş analistinin rolü çok yönlü olabilir. Proje ekibi üyelerinin birden fazla rol ve sorumluluğa sahip olması mümkündür. Bazı projelerde, BA, sınırlı kaynaklar olduğunda İş Zekası Analisti, Veritabanı Tasarımcısı, Yazılım Kalite Güvence Uzmanı, Test Uzmanı ve / veya Eğitmen rollerini üstlenebilir.

Belirli projelerde Proje Koordinatörü, Uygulama Geliştirme Sorumlusu veya Geliştirici'nin İş Analisti rolünü üstlenmesi de mümkündür.

İş Analizi, işin her zamanki gibi çalışması ve işleyişini optimize etme gereksinimlerinin analizi ile büyük ölçüde örtüşmektedir. Bazı İş Analizi örnekleri şunlardır:

  • İş Mimarisi Oluşturmak
  • Bir İş Senaryosu Hazırlama
  • Risk değerlendirmesi yapmak
  • Gereksinimlerin Ortaya Çıkarılması
  • İş Süreçleri Analizi
  • Gereksinimlerin Belgeleri

BA'nın Başlıca Rolleri

Çoğu iş analistinin kilit rolü, işletme ve teknik geliştiriciler arasında bağlantı kurmaktır. İş analistleri, üretkenliği artırmak için bir sistem veya sürecin gereksinimlerini toplamak / tanımlamak için iş müşterileriyle birlikte çalışır ve aynı zamanda sistemi / süreci tasarlamak ve uygulamak için teknik ekiplerle birlikte çalışır.

Katkıda Bulunan Olarak

İş idaresinin temel sorumluluğu, işle ilgili sorunları, ihtiyaçları ve işlevleri belirlemede, paydaşların endişelerini ve gereksinimlerini anlama ve BT için iş senaryosunu geliştirmek için iş girdisine katkıda bulunma konusunda İş kullanıcılarının / kilit kullanıcılarının gelişimine katkıda bulunmaktır. sistem geliştirme projesi.

Kolaylaştırıcı olarak

Bir İş Analistinin ayrıca gereksinimlerin ortaya çıkarılması ve analizini kolaylaştırması / koordine etmesi, paydaşlarla işbirliği ve iletişim kurması ve beklentilerini ve ihtiyaçlarını yönetmesi ve gereksinimlerin eksiksiz, açık ve gerçek zamanlı iş ihtiyaçlarına eşleştirmesini sağlaması beklenir. bir kuruluşun.

Analist olarak

Diğer bir önemli rol, sistem uygulaması için önerilen sistemi ve organizasyonel hazırlığı değerlendirmek ve kullanıcılara destek sağlamak ve BT personeli ile koordinasyon sağlamaktır.

Önerilen BT sisteminin tasarımını iş perspektifinden incelemeye ve girdiler sağlamaya yardımcı olmak, paydaşlar arasındaki sorunları / çatışmaları çözmek, kullanıcılara test senaryoları geliştirmede yardımcı olarak kapsamlı ve kaliteli UAT düzenlemeye yardımcı olmak ve aşağıdakileri sağlamak amacıyla eğitimin düzenlenmesine yardımcı olmak iş gereksinimlerini ve gereksinimlerini karşılamanın yanı sıra beklenen faydaları gerçekleştirebilen yerleşik BT sistemi.

BT sistemi geliştirme projesi için iş analizi ile ilgili faaliyetlerin gerçekleştirilmesi için kapsam geliştirme, zamanlama ve yaklaşım için İş analizi faaliyetlerini planlamak ve izlemek, ilerlemeyi izlemek, Dahili Proje yöneticisi ile koordinasyon sağlamak ve her yerde gelir, karlılık, riskler ve sorunlar hakkında rapor vermek uygun.

Bir İş Analistinin Temel Sorumlulukları

Bir iş analistinin sorumluluk seti, bir projenin farklı aşamalarında farklı görevleri yerine getirmesini gerektirecektir ve bunlar aşağıda açıklanmıştır:

Başlatma Aşaması

Bu aşama yeni bir projenin başlangıcını işaret edecek ve bir iş analisti aşağıdaki sorumlulukları değiştirecektir:

  • Projenin maliyet-fayda analizinin yürütülmesine yardımcı olun.
  • İş durumunu anlayın.
  • Çözümün / projenin / ürünün fizibilitesini tespit edin.
  • Proje sözleşmesinin oluşturulmasına yardımcı olun.
  • Projedeki paydaşları belirleyin.

Planlama aşaması

Bu aşama, ihtiyaçların toplanmasını ve planlamayı, projenin nasıl yürütüleceğini ve yönetileceğini içerecektir. Sorumlulukları aşağıdaki işlevleri içerecektir -

  • Gereksinimleri ortaya çıkarmak
  • Gereksinimleri analiz edin, düzenleyin ve belgeleyin.
  • Kullanım durumları, RTM, BRD, SRS vb. Oluşturarak gereksinimleri yönetin.
  • Önerilen çözümleri değerlendirin.
  • Paydaşlarla iletişim kurun ve iletişimi geliştirin.
  • Proje yönetimi planlarının formüle edilmesine yardımcı olun.
  • Projenin kapsamını, kısıtlamalarını, varsayımlarını ve risklerini bulmada yardımcı olun.
  • Çözümün kullanıcı deneyimini tasarlamaya yardımcı olun.

Yürütme Aşaması

Bu aşama, çözümün toplanan gereksinimlere göre geliştirildiğini gösterir. Sorumluluklar şunları içerir:

  • BT / geliştirme ekibine gereksinimleri açıklayın.

  • Geliştirilmesi önerilen çözümle ilgili şüpheleri ve endişeleri netleştirin.

  • Proje kapsam değişikliklerini tartışın ve önceliklendirin ve anlaşma sağlayın.

  • İlk test için beta testleri komut dosyaları oluşturun.

  • Gelişen modülleri paydaşlarla paylaşmak ve geri bildirimlerini almak.

  • Son başvuru tarihlerini takip edin ve paydaşların beklentilerini yönetin.

  • Çatışmaları çözmek ve proje ekibi ile iletişimi yönetmek.

İzleme ve Kontrol Aşaması

Bu aşamada, proje ilk planlardan herhangi bir sapma için ölçülür ve kontrol edilir. Bu aşama, eşzamanlı olarak yürütme aşamasına kadar çalışır.

  • Test komut dosyaları geliştirmek ve kapsamlı modül ve entegrasyon testleri yürütmek.

  • UAT yürütmek (kabul testini kullanmak) ve test raporları oluşturmak.

  • Müşteriden teslim edilecekler için kabul / onay alın.

  • Geliştirme ekibine değişiklik taleplerini açıklayın.

  • Değişiklik taleplerinin gelişimini izleyin ve projenin hedefine göre uygulanmalarını doğrulayın.

Kapanış Aşaması

Bu aşama, projenin kapanışına işaret eder. Sorumluluklar -

  • Tamamlanan projeyi müşteriye sunmak ve kabulünü kazanmak.

  • Kullanıcı eğitimi kılavuzları, herhangi bir işlevsel materyal ve diğer eğitim kılavuzları oluşturun.

  • Üretim ortamında ayrıntılı entegrasyon testleri yürütün.

  • Nihai ürün belgeleri oluşturun, öğrenilen proje derslerini belgeleyin.

BA Ne Sunması Bekleniyor?

Bir İş Analisti, iş kullanıcıları ile teknik BT çalışanları arasında köprü görevi görür. Varlıkları, BT projelerinin başarısına önemli ölçüde katkıda bulunacaktır. Özel bir iş analistine sahip olmanın birçok faydası vardır. Özel bir iş analisti şunları yapabilir:

  • İş açısından net bir proje kapsamı sunar.

  • Sağlam iş senaryoları geliştirin ve kaynakların ve iş yararlarının daha gerçekçi bir şekilde tahmin edilmesini sağlayın.

  • Özellikle büyük ölçekli BT projeleri için maliyet ve zamanlama açısından proje kapsam belirleme, planlama ve yönetim hakkında daha iyi raporlar hazırlar.

  • BT projesi dış kaynaklı ise daha net ve daha doğru gereksinimler sağlanmasına yardımcı olan açık ve öz gereksinimler üretir.

  • Kullanıcılardan gerçek iş ihtiyaçlarını ortaya çıkarın ve kullanıcı beklentilerini etkili bir şekilde yönetin.

  • Önerilen BT sistemi için tasarım kalitesini, kullanıcı gereksinimlerini karşılayacak şekilde geliştirir.

  • İnceleme ve kabul için son kullanıcılara teslim edilmeden önce geliştirilen sistemin kalitesini garanti eder.

  • Sağlanan sistemler üzerinde kapsamlı kalite testleri düzenler ve teknik BT çalışanlarına geri bildirim sağlar.

İş Analizi - Araçlar ve Teknikler

Bir İş Analisti, BA şapkasını takarken çeşitli analitik araçlara ve ilgili teknolojilere aşina olmalıdır. Yani, eğer bu pozisyondaysanız.

Daha önce öğrendiğimiz gibi, iş analizi, bir iş girişimini anlamaya çalıştığınız ve fırsatları, sorun alanlarını, sorunları belirlediğiniz ve CEO, Başkan Yardımcısı, Direktör ve iş gereksinimlerini anlamak.

Temel olarak, kategorize edebileceğimiz 3 tür İş analizi vardır:

  • Strategic Analysis- Stratejik iş analizi, proje öncesi çalışmayla ilgilenir. Üst yönetime yardımcı olarak iş sorunlarını belirleme, iş stratejileri, hedefleri ve hedefleri oluşturma yöntemi veya sürecidir. Etkili karar alma süreci için yönetim bilgileri raporlaması sağlar.

  • Tactical Analysis - Uygun projede doğru zamanda uygulanacak belirli iş analizi teknikleri bilgisini içerir.

  • Operational Analysis- Bu tür İş analizinde, bilgi teknolojisinden yararlanarak iş yönüne odaklanıyoruz. Aynı zamanda, iş geliştirme için fırsatları belirlemek amacıyla operasyonel sistemleri inceleme sürecidir.

Her bir analiz türü için, piyasada bulunan ve organizasyonel ihtiyaçlara ve gereksinimlere dayalı olarak kullanılacak olan bir dizi araç vardır.

Bununla birlikte, iş gereksinimlerini anlaşılabilir bilgilere dönüştürmek için, iyi bir BA, günlük faaliyetlerinde Gerçek Bulma, Görüşmeler, Dokümantasyon İnceleme, Anketler, Örnekleme ve Araştırma tekniklerinden yararlanacaktır.

İşlevsel ve İşlevsel Olmayan Gereksinimler

Bir gereksinimi, İşlevsel ve İşlevsel Olmayan gereksinimler gibi iki ana türe ayırabiliriz.

Tüm teknoloji projeleri için işlevsel ve işlevsel olmayan gereksinimler ayrıştırılmalı ve ayrı ayrı analiz edilmelidir.

Doğru aracı ve uygun bir tekniği tanımlamak göz korkutucu bir zorluk olabilir. İster yepyeni bir uygulama yapıyor olun, ister mevcut bir uygulamada değişiklik yapıyor olun. İşlevsel süreç için doğru tekniği düşünmek başlı başına bir sanattır.

Şu anda piyasada bulunan ve yaygın olarak kullanılan iş analizi tekniklerine genel bir bakış -

Süreçler Teknikler Süreç Çıktıları (Sonuçlar)
İşlevsel ve İşlevsel Olmayan Gereksinimleri Belirlemek İçin
  • JAD Oturumları
  • Senaryolar ve Kullanım Durumları
  • Örgütsel Modelleme
  • Kapsam Modelleme
  • Fonksiyonel Ayrıştırma
  • Interviews
  • Gözlem (İş Gölgeleme)
  • Odak grupları
  • Kabul ve Değerlendirme
  • Sıra Diyagramları
  • Kullanıcı hikayeleri
  • Brainstorming
  • Storyboarding
  • Prototyping
  • Yapılandırılmış Gözden Geçirme
  • Olay Analizi
  • İş Kuralı analizi
  • Gereksinimler Atölyeleri
  • Risk analizi
  • Sorun kaynağı çözümlemesi

Business Requirements Documents -

  • İş ve İşlevsel Gereksinimler
  • İşlevsel Olmayan Gereksinimler
  • İş kuralları
  • Gereksinim İzlenebilirlik Matrisi

Common Template -

  • İşletme Gereksinimleri Belgesi

Araçların ve Sürecin Uygulanabilirliği

İş analistlerinin kullanabileceği çeşitli araçlar ve prosedürler olmasına rağmen, bunların tümü kuruluşun mevcut uygulamalarına ve bunları nasıl kullanmak istediklerine bağlıdır.

Örneğin, root-cause analysis belirli bir önemli alan veya işleve daha derine inmek gerektiğinde kullanılır.

Bununla birlikte, iş gereksinimleri belgesi, gereksinimleri belgeleme biçiminde koymanın en popüler ve kabul edilen yoludur.

Sonraki bölümlerde, yukarıdaki tekniklerden bazılarını derinlemesine tartışacağız.

İş Analizi - JAD Oturumu

Ortak Uygulama Geliştirme (JAD), bir şirket için yeni bilgi sistemleri geliştirirken iş gereksinimlerini toplamak için kullanılan bir süreçtir. JAD süreci ayrıca kullanıcı katılımını artırmak, geliştirmeyi hızlandırmak ve spesifikasyonların kalitesini iyileştirmek için yaklaşımlar içerebilir. Bir JAD oturumunun amacı, çözümleri ortaya çıkarmak için konu uzmanını / İş analistini veya BT uzmanını bir araya getirmektir.

İş analisti, tüm grupla etkileşime giren ve bilgileri toplayan, analiz eden ve bir belge çıkaran kişidir. JAD seansında çok önemli bir rol oynamaktadır.

JAD Oturumu Kullanımı

JAD oturumları, kısa sürede yüksek kaliteli çıktılar üretmek için müşteri karar vericileri ve BT personelini bir araya getiren oldukça yapılandırılmış, kolaylaştırılmış atölyelerdir.

Başka bir deyişle, bir JAD Oturumu, müşterilerin ve geliştiricilerin bir projenin temel kapsamı, hedefleri ve özellikleri konusunda hızlı bir şekilde anlaşmaya varmalarını veya bir anlaşmaya varmamalarını sağlar, bu da projenin yeniden değerlendirilmesi gerektiği anlamına gelir.

Basitçe söylemek gerekirse, JAD oturumları

  • Simplify - Aylarca süren toplantıları ve telefon görüşmelerini yapılandırılmış bir atölyede birleştirir.

  • Identify - Sorunlar ve katılımcılar

  • Quantify - Bilgi ve işleme ihtiyaçları

  • Clarify - Oturumda kararlaştırılan tüm gereksinimleri netleştirin ve açıklığa kavuşturun.

  • Unify - Geliştirmenin bir aşamasından gelen çıktı, diğerine girdidir.

  • Satisfy- Müşteriler sistemi tanımlar; bu nedenle, bu onların sistemidir. Paylaşılan katılım, sonuçta bir pay getirir; sistemin başarısına bağlı hale gelirler.

JAD Oturumuna katılanlar

Bir JAD oturumuna katılan katılımcılar aşağıdaki gibidir -

Yönetici Sponsoru

Yönetici sponsor, projeyi yönlendiren kişidir - sistem sahibi. Normalde daha yüksek pozisyonlardandırlar ve karar verebilirler ve gerekli strateji, planlama ve yönlendirmeyi sağlayabilirler.

Konu uzmanı

Başarılı bir atölye çalışması için gerekli olan iş kullanıcıları ve dış uzmanlardır. Konunun uzmanları, JAD oturumunun bel kemiğidir. Değişiklikleri onlar yönlendirecek.

Kolaylaştırıcı

Toplantıya başkanlık ediyor; toplantının bir parçası olarak çözülebilecek konuları belirler. Kolaylaştırıcı toplantıya bilgi katmaz.

Kilit kullanıcılar

Anahtar kullanıcılar veya bazı durumlarda süper kullanıcılar olarak da adlandırılan kullanıcılar birbirinin yerine kullanılabilir ve şirketten şirkete farklılık gösterir. Anahtar kullanıcılar genellikle BT projesine daha sıkı bir şekilde uyumlu olan ve projeler sırasında ekip üyelerinin profillerinin yapılandırılmasından sorumlu olan iş kullanıcılarıdır.

Örneğin: Farz edelim ki John bir kilit kullanıcı ve Nancy, Evan bir SAP sisteminin kullanıcıları. Bu durumda, Nancy ve Evan, işlevselliği ve profili değiştirme erişimine sahip değilken, Anahtar kullanıcı olan John, daha fazla yetkiye sahip profil düzenleme erişimine sahiptir.

Daha geleneksel uygulama ile karşılaştırıldığında JAD yaklaşımının, daha hızlı geliştirme sürelerine ve daha fazla müşteri memnuniyetine yol açtığı düşünülmektedir, çünkü müşteri geliştirme süreci boyunca yer almaktadır. Buna karşılık, sistem geliştirmeye geleneksel yaklaşımda, geliştirici, sistem gereksinimlerini araştırır ve bir dizi görüşmeden oluşan müşteri girdisi ile bir uygulama geliştirir.

İhtiyaç Toplama Teknikleri

Teknikler, belirli koşullar altında görevlerin nasıl gerçekleştirildiğini açıklar. Bir görevin hiçbir ilgili tekniği olmayabilir veya bir veya daha fazla ilgili teknik olabilir. Bir teknik en az bir görevle ilişkilendirilmelidir.

Aşağıdakiler, iyi bilinen gereksinim toplama tekniklerinden bazılarıdır -

Beyin fırtınası

Beyin fırtınası, bir grup insandan olabildiğince çok fikir almak için ihtiyaç toplamada kullanılır. Genellikle sorunlara olası çözümleri belirlemek ve fırsatların ayrıntılarını netleştirmek için kullanılır.

Belge Analizi

Mevcut bir sistemin belgelerini gözden geçirmek, AS-IS süreç belgesi oluştururken yardımcı olmanın yanı sıra, geçiş projelerinin kapsamını belirlemek için boşluk analizini teşvik edebilir. İdeal bir dünyada, mevcut gereksinimleri belgelemek için bir başlangıç ​​noktası olan mevcut sistemin oluşturulmasını sağlayan gereksinimleri bile gözden geçiriyor olurduk. Bilgi parçacıkları genellikle, gereksinim eksiksizliğini doğrulamanın bir parçası olarak sorular sormamıza yardımcı olan mevcut belgelere gömülür.

Odak grubu

Odak grubu, bir ürünün kullanıcılarını veya müşterilerini temsil eden kişilerin geri bildirim almak için bir araya gelmesidir. Geri bildirim, gereksinimleri belirlemek için ihtiyaçlar / fırsatlar / sorunlar hakkında toplanabilir veya halihazırda ortaya çıkarılan gereksinimleri doğrulamak ve iyileştirmek için toplanabilir. Bu pazar araştırması biçimi, belirli katılımcılarla yönetilen bir süreç olması açısından beyin fırtınasından farklıdır.

Arayüz analizi

Bir yazılım ürünü için arayüzler insan veya makine olabilir. Harici sistemler ve cihazlarla entegrasyon sadece başka bir arayüzdür. Kullanıcı merkezli tasarım yaklaşımları, kullanılabilir yazılımlar oluşturmamızı sağlamada çok etkilidir. Arayüz analizi - diğer harici sistemlerle temas noktalarının gözden geçirilmesi, kullanıcılar tarafından hemen görülemeyen gereksinimleri gözden kaçırmadığımızdan emin olmak için önemlidir.

Röportaj

Paydaşlar ve kullanıcılarla yapılan görüşmeler, harika yazılımı oluşturmak için kritik öneme sahiptir. Kullanıcıların ve paydaşların hedeflerini ve beklentilerini anlamadan, onları tatmin etme olasılığımız çok düşük. Ayrıca görüşülen her kişinin bakış açısını da tanımalıyız, böylece onların girdilerini uygun şekilde tartıp ele alabiliriz. Dinleme, harika bir analistin bir görüşmeden ortalama bir analistten daha fazla değer elde etmesine yardımcı olan beceridir.

Gözlem

Bir analist, kullanıcıları gözlemleyerek bir süreç akışını, adımları, sıkıntılı noktaları ve iyileştirme fırsatlarını belirleyebilir. Gözlemler pasif veya aktif olabilir (gözlemlerken soru sorma). Aktif gözlemin mevcut bir iş sürecini anlamada daha etkili olduğu bir prototip hakkında geri bildirim almak için (gereksinimleri iyileştirmek için) pasif gözlem daha iyidir. Her iki yaklaşım da kullanılabilir.

Prototipleme

Prototipleme, gereksinimleri toplamak için nispeten modern bir tekniktir. Bu yaklaşımda, çözümün ilk sürümünü - bir prototipi - oluşturmak için kullandığınız ön gereksinimleri toplarsınız. Bunu müşteriye gösterirsiniz, o da size ek gereksinimler verir. Uygulamayı değiştirirsiniz ve müşteriyle tekrar dolaşırsınız. Bu tekrarlayan süreç, ürün kritik iş ihtiyaçlarını karşılayana kadar veya kararlaştırılan sayıda yineleme için devam eder.

Gereksinim Atölyeleri

Atölyeler, gereksinimleri toplamak için çok etkili olabilir. Bir beyin fırtınası oturumundan daha yapılandırılmış olan ilgili taraflar, gereksinimleri belgelemek için işbirliği yapar. İşbirliğini yakalamanın bir yolu, alan modeli yapılarının (statik diyagramlar, aktivite diyagramları gibi) oluşturulmasıdır. Bir çalıştay, iki analistle bir çalışmadan daha etkili olacaktır.

Tersine mühendislik

Bir geçiş projesi mevcut sistemin yeterli dokümantasyonuna erişemediğinde, tersine mühendislik sistemin ne yaptığını belirleyecektir. Sistemin ne yapması gerektiğini belirlemeyecek ve sistemin yanlış bir şey yaptığını belirlemeyecektir.

Anket / Anket

Pek çok insandan bilgi toplarken - bütçe ve zaman kısıtlamaları nedeniyle görüşme yapılamayacak kadar çok kişi - bir anket veya anket kullanılabilir. Anket, kullanıcıları seçimler arasından seçim yapmaya, bir şeyi derecelendirmeye ("Kesinlikle Katılıyorum, Katılıyorum ...") veya serbest biçimli yanıtlara izin veren açık uçlu sorular sormaya zorlayabilir. Anket tasarımı zordur - sorular yanıtlayanları yanıltabilir.

Fonksiyonel Gereksinimler Belgesi

İşlevsel Gereksinimler Belgesi (FRD), bir uygulamanın işlevsel gereksinimlerinin resmi bir ifadesidir. Bir sözleşme ile aynı amaca hizmet eder. Burada, geliştiriciler belirtilen yetenekleri sağlamayı kabul ederler. Müşteri, FRD'de belirtilen yetenekleri sağlıyorsa ürünü tatmin edici bulmayı kabul eder.

İşlevsel gereksinimler, sistemin amaçlanan davranışını yakalar. Bu davranış, sistemin gerçekleştirmesi gereken hizmetler, görevler veya işlevler olarak ifade edilebilir. Belge, belirli bir projenin ihtiyacına uyacak şekilde uyarlanmalıdır. Sistem hesaplamaları, veri işleme ve işleme, kullanıcı arayüzü ve uygulamayla etkileşim gibi şeyleri tanımlarlar.

İşlevsel Gereksinimler Belgesi (FRD) aşağıdaki özelliklere sahiptir -

  • Uygulamanın önümüzdeki birkaç yıl içinde iş hedefleri ve iş süreçleri açısından değer sağladığını göstermektedir.

  • Uygulama için eksiksiz bir gereksinim seti içerir. FRD'de belirtilmeyen herhangi bir şeyi kimsenin varsayması için yer bırakmaz.

  • Çözümden bağımsızdır. ERD, uygulamanın nasıl çalıştığının değil, uygulamanın ne yapması gerektiğinin bir ifadesidir. FRD, geliştiricileri bir tasarıma taahhüt etmez. Bu nedenle, belirli bir teknolojinin kullanımına yapılan herhangi bir atıf, bir FRD'de tamamen uygunsuzdur.

İşlevsel gereksinim aşağıdakileri içermelidir -

  • Açıklamaları data sisteme girilecek

  • Açıklamaları operations her ekran tarafından gerçekleştirilir

  • Açıklamaları work-flows sistem tarafından gerçekleştirilen

  • Açıklamaları system reports veya diğer çıktılar

  • Kimler girebilir data sisteme mi?

  • Sistem uygulanabilirliği nasıl karşılar? regulatory requirements?

İşlevsel özellikler, genel bir izleyici tarafından okunacak şekilde tasarlanmıştır. Okuyucular sistemi anlamalıdır, ancak bu belgeyi anlamak için hiçbir teknik bilgiye ihtiyaç duyulmamalıdır.

Fonksiyonel Gereksinimler Çıktıları

Bir İşletme Gereksinimleri Belgesi (BRD) şunlardan oluşur:

  • Functional Requirements- Geliştirilmekte olan sistem için ayrıntılı gereksinimleri içeren bir belge. Bu gereksinimler, bir sistemin sahip olması gereken işlevsel özellikleri ve yetenekleri tanımlar. İş Senaryosu sırasında belirlenen tüm varsayımların ve kısıtlamaların hala doğru ve güncel olduğundan emin olun.

  • Business Process Model - Sürecin mevcut durumunun bir modeli ("olduğu gibi" model) veya sürecin ne olması gerektiğine dair bir kavram ("olmak" modeli)

  • System Context Diagram - Bir Bağlam Diyagramı, sistem sınırlarını, sistemle etkileşime giren dış ve iç varlıkları ve bu dış ve iç varlıklar arasındaki ilgili veri akışlarını gösterir.

  • Flow Diagrams (as-is or to-be)- Diyagramlar, bir iş süreci için işlemlerin sırasını veya veri hareketini grafik olarak gösterir. Modelin karmaşıklığına bağlı olarak bir veya daha fazla akış diyagramı dahil edilmiştir.

  • Business Rules and Data Requirements - İş kuralları, işin bazı yönlerini tanımlar veya sınırlar ve veri kısıtlamalarını, varsayılan değerleri, değer aralıklarını, kardinaliteyi, veri türlerini, hesaplamaları, istisnaları, gerekli öğeleri ve verilerin ilişkisel bütünlüğünü tanımlamak için kullanılır.

  • Data Models Varlık İlişkisi Diyagramları, Varlık Açıklamaları, Sınıf Diyagramları

  • Conceptual Model - Bir işletme işlevi için farklı varlıkların ve bunların birbirleriyle nasıl ilişkili olduğunun yüksek düzeyde gösterimi.

  • Logical Model - Bir iş fonksiyonunda yer alan belirli varlıkları, öznitelikleri ve ilişkileri gösterir ve bir iş, teknik veya kavramsal ortamdaki verilerin tüm tanımlarını, özelliklerini ve ilişkilerini temsil eder.

  • Data Dictionary and Glossary - Bir veritabanı veya benzer veri yönetim sisteminin altında yatan veri modelini oluşturan veri öğeleri, alanlar, tablolar ve diğer varlıklar hakkında ayrıntılı bilgi koleksiyonu.

  • Stakeholder Map- Önerilen değişiklikten etkilenen tüm paydaşları ve ihtiyaçlar için etki / yetki düzeyini belirler. Bu belge, Proje Yönetim Metodolojisinin (PMM) oluşturulma aşamasında geliştirilmiştir ve Proje Yöneticisine aittir, ancak süreç boyunca yeni / değişen Paydaşlar belirlendiğinden proje ekibi tarafından güncellenmesi gerekir.

  • Requirements Traceability Matrix - Diğer İşlevsel Gereksinimler, Kullanım Örnekleri / Kullanıcı Hikayeleri, Mimari ve Tasarım Öğeleri, Kod Modülleri, Test Örnekleri ve İş Kuralları dahil olmak üzere, ayrı işlevsel gereksinimler ve diğer sistem yapıları türleri arasındaki mantıksal bağlantıları gösteren bir tablo.

Yazılım Gereksinimleri Spesifikasyonu

Yazılım Gereksinimleri Spesifikasyonu (SRS), müşteriler arasında bir iletişim ortamı olarak kullanılan bir belgedir. En temel haliyle bir yazılım gereksinimi belirtimi, müşteri ile geliştirici arasındaki yazılım gereksinimlerinin iletişiminde kullanılan resmi bir belgedir.

Bir SRS belgesi, WHAT yapılması gerekir ve çözümü dikkatli bir şekilde önler (how to do). Geliştirme ekibi ile müşteri arasında bir sözleşme görevi görür. Bu aşamadaki gereksinimler, son kullanıcı terminolojisi kullanılarak yazılır. Gerekirse, daha sonra ondan resmi bir gereksinim spesifikasyonu geliştirilecektir.

SRS, geliştirilecek bir sistemin davranışının tam bir açıklamasıdır ve kullanıcıların yazılımla sahip olacağı etkileşimleri tanımlayan bir dizi kullanım durumu içerebilir.

SRS'nin Amacı

SRS, Müşteri / Müşteri, İş Analisti, Sistem geliştiriciler, Bakım ekipleri arasında bir iletişim aracıdır. Aynı zamanda alıcı ve tedarikçi arasında bir sözleşme olabilir.

  • Tasarım aşaması için sağlam bir temel oluşturacak
  • Proje yönetimi ve kontrolünü destekler
  • Sistemin kontrolüne ve gelişimine yardımcı olur

Bir yazılım Gereksinimi belirtimi Eksiksiz, Tutarlı, İzlenebilir, Kesin ve Doğrulanabilir olmalıdır.

Aşağıdakiler sistem spesifikasyonunda ele alınmalıdır -

  • Sistemlerin işlevlerini tanımlayın
  • Donanım / Yazılım İşlevsel Bölümlemesini Tanımlayın
  • Performans Spesifikasyonunu Tanımlayın
  • Donanım / Yazılım Performans Bölümlemesini Tanımlayın
  • Güvenlik Gereksinimlerini Tanımlayın
  • Kullanıcı Arayüzünü tanımlayın (kullanım kılavuzu)
  • Kurulum Çizimlerini / Talimatlarını Sağlayın
  • Yazılım Gereksinimi şartname şablonu

Revizyon Geçmişi

Tarih Açıklama Yazar Yorumlar
<tarih> <Sürüm 1> <Adınız> <İlk Revizyon>

Belge Onayı

Aşağıdaki yazılım gereksinimleri spesifikasyonu aşağıdakiler tarafından kabul edilmiş ve onaylanmıştır -

İmza Basılı isim Başlık Tarih
<Adınız> Lider Yazılım Müh.
David Eğitmen

İş Analizi - Kullanım Örnekleri

UML'lerin dokuz diyagramından biri Kullanım Durumu Diyagramıdır. Bunlar sadece önemli değil aynı zamanda yazılım projeleri için gerekli gerekliliktir. Temelde Yazılım yaşam döngülerinde kullanılır. Bildiğimiz gibi, geliştirme döngüsünde çeşitli aşamalar vardır ve Kullanım durumları için en çok kullanılan aşama, gereksinim toplama aşamasıdır.

Kullanım Durumu nedir?

Kullanım durumu, bir aktöre değer sağlayan bir sistem tarafından gerçekleştirilen bir dizi eylemi tanımlar. Kullanım senaryosu, paydaşlardan birinin talebine yanıt verirken sistemin çeşitli koşullar altındaki davranışını tanımlar.primary actor.

Oyuncu, sistemin Kimidir, diğer bir deyişle son kullanıcıdır.

Yazılım ve sistem mühendisliğinde kullanım durumu, bir hedefe ulaşmak için tipik olarak bir rol (UML'de "aktör" olarak bilinir) ve sistem arasındaki etkileşimleri tanımlayan adımların bir listesidir. Oyuncu bir insan veya harici bir sistem olabilir.

Kullanım durumu, sistemdeki olayların akışını belirtir. İşlemlerin sırasını gerçekleştirmek için sistem tarafından ne yapıldığı ile daha çok ilgilenir.

Kullanım Durumunun Yararları

Bir kullanım durumu aşağıdaki faydaları sağlar -

  • Kullanıcıya katma değere odaklanarak işlevsel gereksinimi yakalamanın kolay bir yoludur.

  • Kullanım durumlarının yazılması ve okunması geleneksel gereksinim yöntemlerine kıyasla nispeten kolaydır.

  • Kullanım senaryoları, geliştiricileri son kullanıcı perspektifinden düşünmeye zorlar.

  • Kullanım durumu, kullanıcıyı gereksinim sürecine dahil eder.

Bir Kullanım Durumunun Anatomisi

Ad : Kullanım senaryosunun amacını gösteren açıklayıcı ad.

Açıklama : Kullanım senaryosunun birkaç cümleyle ne yaptığını açıklar.

Oyuncu : Kullanım senaryosuna katılan tüm oyuncuları listeleyin.

Ön koşul : Kullanım senaryosuna başlamadan önce karşılanması gereken koşullar .

Olayların akışı : Sistem ve aktör arasındaki etkileşimin tanımı.

Son Durum : Bir kullanım durumu seyrini tamamladıktan sonra sistemin durumunu açıklayın.

Kullanım Örneği Şablon Rehberi

Bu bölümün sonunda verilen şablonu kullanarak her kullanım durumunu belgeleyin. Bu bölüm, kullanım örneği şablonundaki her bölümün bir açıklamasını sağlar.

Kullanım Durumu Tanımlama

  • Use-Case ID- Her bir kullanım senaryosuna hiyerarşik biçimde benzersiz bir sayısal tanımlayıcı verin: XY İlgili kullanım durumları hiyerarşide gruplanabilir. İşlevsel gereksinimler, etiketli bir kullanım durumuna kadar izlenebilir.

  • Use-Case Name- Kullanım senaryosu için kısa ve sonuç odaklı bir ad belirtin. Bunlar, kullanıcının sistemi kullanarak gerçekleştirmesi gereken görevleri yansıtır. Bir eylem fiili ve bir isim ekleyin. Bazı örnekler -

    • Parça numarası bilgilerini görüntüleyin.

    • Köprü metni kaynağını manuel olarak işaretleyin ve hedefe bağlantı kurun.

    • Güncellenmiş yazılım versiyonunun bulunduğu bir CD siparişi verin.

Kullanım Durumu Geçmişi

Burada Usecase dokümanının paydaşları olan kişilerin isimlerinden bahsediyoruz.

  • Created By - Bu kullanım durumunu ilk olarak belgeleyen kişinin adını verin.

  • Date Created - Kullanım senaryosunun başlangıçta belgelendiği tarihi girin.

  • Last Updated By - Kullanım durumu açıklamasına en son güncellemeyi gerçekleştiren kişinin adını verin.

  • Date Last Updated - Kullanım senaryosunun en son güncellendiği tarihi girin.

Kullanım Durumu Tanımı

Aşağıdakiler, Kullanım Senaryosunun temel kavramlarının tanımlarıdır -

Aktör

Bir aktör, sistemle etkileşime giren ve görevleri yerine getirmek için kullanım durumlarını gerçekleştiren, belirtilen yazılım sisteminin dışındaki bir kişi veya başka bir varlıktır. Farklı aktörler genellikle ürünü kullanacak müşteri topluluğundan belirlenen farklı kullanıcı sınıflarına veya rollerine karşılık gelir. Bu kullanım senaryosunu gerçekleştirecek oyuncuları adlandırın.

Açıklama

Bu kullanım senaryosunun nedeni ve sonucunun kısa bir açıklamasını veya eylem dizisinin ve kullanım senaryosunun yürütülmesinin sonucunun üst düzey bir tanımını sağlayın.

Ön koşullar

Kullanım senaryosu başlatılmadan önce gerçekleşmesi gereken etkinlikleri veya doğru olması gereken koşulları listeleyin. Her ön koşulu numaralandırın.

Examples

  • Kullanıcının kimliği doğrulandı.
  • Kullanıcının bilgisayarında görevi başlatmak için yeterli boş bellek var.

Gönderi Koşulları

Kullanım senaryosu uygulamasının sonunda sistemin durumunu açıklayın. Her gönderi koşulunu numaralandırın.

Examples

  • Belge yalnızca geçerli SGML etiketleri içeriyor.
  • Veritabanındaki ürünün fiyatı yeni değer ile güncellendi.

Öncelik

Bu kullanım durumunun yürütülmesine izin vermek için gereken işlevselliği uygulamanın göreceli önceliğini belirtin. Kullanılan öncelik şeması, yazılım gereksinimleri spesifikasyonunda kullanılanla aynı olmalıdır.

Kullanım sıklığı

Bazı uygun zaman birimi başına bu kullanım senaryosunun aktörler tarafından kaç kez gerçekleştirileceğini tahmin edin.

Normal Olaylar

Normal, beklenen koşullar altında kullanım senaryosunun yürütülmesi sırasında gerçekleşecek kullanıcı eylemlerinin ve sistem yanıtlarının ayrıntılı bir açıklamasını sağlayın. Bu diyalog dizisi nihayetinde kullanım senaryosu adı ve açıklamasında belirtilen hedefe ulaşılmasına yol açacaktır. Bu açıklama, "<kullanım örneği adında belirtilen görevi nasıl gerçekleştirebilirim>?" Varsayımsal soruya bir cevap olarak yazılabilir. Bu, en iyi şekilde, sistem tarafından sağlanan yanıtlarla dönüşümlü olarak, aktör tarafından gerçekleştirilen eylemlerin numaralandırılmış bir listesi olarak yapılır.

Alternatif Kurslar

Bu kullanım senaryosunda yer alabilecek diğer meşru kullanım senaryolarını bu bölümde ayrı ayrı belgeleyin. Alternatif rotayı belirtin ve gerçekleşen adımların sırasındaki tüm farklılıkları tanımlayın. Kullanım durumu kimliğini önek olarak kullanarak her alternatif kursu numaralandırın ve ardından "Alternatif Kurs" u belirtmek için "AC" ekleyin. Örnek: XYAC.1.

İstisnalar

Kullanım senaryosunun yürütülmesi sırasında meydana gelebilecek beklenen hata koşullarını açıklayın ve sistemin bu koşullara nasıl yanıt vereceğini tanımlayın. Ayrıca, kullanım senaryosu yürütülmesi beklenmeyen bir nedenle başarısız olursa sistemin nasıl yanıt vereceğini açıklayın. Kullanım durumu kimliğini önek olarak kullanarak her bir istisnayı numaralandırın ve ardından "İstisnayı" belirtmek için "EX" koyun. Örnek: XYEX.1.

İçerir

Bu kullanım senaryosu tarafından dahil edilen ("çağrılan") diğer kullanım durumlarını listeleyin. Birden çok kullanım durumunda görünen ortak işlevsellik, bu ortak işlevselliğe ihtiyaç duyanların içerdiği ayrı bir kullanım durumuna bölünebilir.

Özel gereksinimler

Tasarım veya uygulama sırasında ele alınması gerekebilecek kullanım alanı için işlevsel olmayan gereksinimler gibi ek gereksinimleri tanımlayın. Bunlar, performans gereksinimlerini veya diğer kalite özelliklerini içerebilir.

Varsayımlar

Bu kullanım senaryosunun kabul edilmesine yol açan analizde yapılan tüm varsayımları ürün açıklamasına ve kullanım durumu açıklamasını yazın.

Notlar ve Sorunlar

Bu kullanım durumu hakkındaki ek yorumları veya çözülmesi gereken kalan açık sorunları veya TBD'leri (Belirlenecek) listeleyin. Her sorunu kimin çözeceğini, son tarihi ve nihayetinde çözümün ne olduğunu belirleyin.

Değişiklik Yönetimi ve Sürüm kontrolü

Sürüm kontrolü, belgelerdeki, büyük web sitelerindeki ve diğer bilgi koleksiyonlarındaki değişikliklerin yönetimidir. Değişiklikler genellikle, revizyon numarası veya revizyon seviyesi olarak adlandırılan bir sayı veya harf kodu ile tanımlanır. Her revizyon bir zaman damgası ve değişikliği yapan kişi ile ilişkilendirilir.

Kullanım Durumu Diyagramları

Birleşik Modelleme Dilinin (UML) önemli bir kısmı, kullanım senaryosu diyagramlarının çizilmesine yönelik olanaklardır. Kullanım durumları, bir projenin analiz aşamasında sistem işlevselliğini tanımlamak ve bölümlemek için kullanılır. Sistemi aktörlere ve kullanım durumlarına ayırırlar. Aktörler, sistem kullanıcıları tarafından oynanabilecek rolleri temsil eder.

Bu kullanıcılar insanlar, başka bilgisayarlar, donanım parçaları ve hatta diğer yazılım sistemleri olabilir. Tek kriter, kullanım durumlarına bölünen sistemin bir kısmının dışında olmaları gerektiğidir. Sistemin o kısmına uyarıcı sağlamalı ve ondan çıktı almalıdır.

Kullanım senaryoları, aktörlerin bir hedef peşinde koşarken sisteminizin yardımıyla gerçekleştirdiği faaliyetleri temsil eder. Bu kullanıcıların (aktörlerin) sistemden neye ihtiyaç duyduklarını tanımlamamız gerekiyor. Kullanım senaryosu, kullanıcı ihtiyaçlarını ve hedeflerini yansıtmalı ve bir aktör tarafından başlatılmalıdır. İşletme, aktörler, İş kullanım senaryosuna katılan müşteriler, kullanım durumuna dernek yoluyla bağlanmalıdır.

Kullanım Durumu Diyagramlarının Çizimi

Aşağıdaki Şekil, bir kullanım durumunun UML şematik formu gibi görünebileceğini göstermektedir. Kullanım alanının kendisi bir oval gibi görünür. Oyuncular küçük çubuk figürler olarak çizilir. Oyuncular kullanım senaryosuna çizgilerle bağlıdır.

Use-case 1 - Satış Görevlisi bir ürünü kontrol eder

  • Müşteri ürünü tezgahta ayarlar.
  • «Swipe UPC Reader kullanır».
  • Sistem, ürün açıklamasını ve fiyatını temin eden veritabanında UPC kodunu arar
  • Sistem duyulabilir bir bip sesi çıkarıyor.
  • Sistem, ürün açıklamasını ve fiyatını ses çıkışı üzerinden duyurur.
  • Sistem cari faturaya fiyat ve kalem tipi ekler.
  • Sistem, doğru vergi ara toplamına fiyat ekler

Bu nedenle, "kullanım" ilişkisi, bir işlev çağrısı veya bir alt yordama çok benzer.

Bu şekilde kullanılan kullanım durumuna soyut kullanım durumu denir çünkü kendi başına var olamaz, ancak diğer kullanım durumları tarafından kullanılması gerekir.

Örnek ─ Para Çekme Kullanım Durumu

Para otomatımızla (ATM) ilgili olarak bir müşterinin amacı para çekmektir. Yani ekliyoruzWithdrawalkullanım durumu. Satış makinesinden para çekmek, yapılacak işlemler için bir banka içerebilir. Yani, başka bir oyuncu da ekliyoruz -Bank. Kullanım senaryosuna katılan her iki aktör de kullanım senaryosuna dernek yoluyla bağlanmalıdır.

Para otomatı, müşteri ve Banka aktörleri için Para çekme kullanım durumu sağlar.

Aktörler ve Kullanım Örnekleri Arasındaki İlişkiler

Kullanım senaryoları aşağıdaki ilişkiler kullanılarak organize edilebilir:

  • Generalization
  • Association
  • Extend
  • Include

Kullanım Durumları Arasında Genelleme

Aktörlerin benzer kullanım durumlarıyla ilişkilendirildiği durumlar olabilir. Böyle bir durumda, bir Çocuk kullanım durumu, ebeveyn kullanımının özelliklerini ve davranışını devralır. Dolayısıyla, işlevlerin kalıtımını göstermek için aktörü genelleştirmemiz gerekiyor. Büyük, içi boş üçgen bir ok ucuna sahip düz bir çizgi ile temsil edilirler.

Kullanım Durumları Arasındaki İlişki

Aktörler ve kullanım durumları arasındaki ilişkiler, kullanım durumu diyagramlarında düz çizgilerle gösterilir. Bir aktör, kullanım senaryosu tarafından tanımlanan bir etkileşime dahil olduğunda bir ilişki vardır.

Uzat

İsteğe bağlı olarak tetiklenen bazı işlevler vardır. Bu gibi durumlarda uzatma ilişkisi kullanılır ve buna uzantı kuralı eklenir. Unutulmaması gereken şey, temel kullanım durumunun, genişleyen kullanım durumu çağrılmasa bile kendi başına bir işlevi gerçekleştirebilmesi gerektiğidir.

Uzatma ilişkisi, genişletilmiş kullanım durumundan genişletilmiş (temel) kullanım durumuna yönlendirilmiş açık bir ok başıyla kesikli bir çizgi olarak gösterilir. Ok, "uzatma" anahtar kelimesiyle etiketlenmiştir.

Dahil etmek

Birden fazla kullanım durumunda çoğaltılan kullanım durumu parçalarını çıkarmak için kullanılır. Aynı zamanda, birkaç kullanım durumuna bölerek geniş kullanım durumunu basitleştirmek ve iki veya daha fazla kullanım durumunun davranışlarının ortak kısımlarını çıkarmak için kullanılır.

Temel kullanım durumundan dahil edilen kullanım durumuna kadar açık bir ok başı olan kesikli bir okla gösterilen kullanım durumları arasındaki ilişkiyi dahil edin. Ok, "dahil et" anahtar kelimesiyle etiketlenmiştir.

Kullanım senaryoları, yalnızca bir sistemin işlevsel gereksinimlerini ele alır. İş kuralları, hizmet kalitesi gereksinimleri ve uygulama kısıtlamaları gibi diğer gereksinimler ayrı ayrı temsil edilmelidir.

Aşağıda gösterilen şema, işaretlenmiş tüm unsurları içeren basit bir kullanım durumu diyagramı örneğidir.

Kullanım Durumlarının Başarılı Bir Şekilde Uygulanması İçin Temel İlkeler

  • Hikayeler anlatarak işinizi basit tutun
  • Kusursuzluk olmadan üretken olun
  • Büyük resmi anlayın
  • Kullanım durumları için yeniden kullanım fırsatını belirleyin
  • Değere odaklanın
  • Sistemi dilimler halinde oluşturun
  • Sistemi aşamalı olarak sunun
  • Ekibin ihtiyaçlarını karşılamak için uyum sağlayın

Kullanım Durumu Şablonu

Burada, bir İş Analistinin doldurabileceği bir Kullanım Durumunun örnek bir şablonunu gösterdik, böylece bilgiler teknik ekibin proje hakkındaki bilgileri tespit etmesi için yararlı olabilir.

Kullanım durumu kimliği:
Kullanım alanı Adı:
Tarafından yaratıldı: Son Güncelleyen
Tarih oluşturuldu: Son Güncelleme Tarihi
Aktör:
Açıklama:
Ön koşullar:
Gönderi koşulları:
Öncelik:
Kullanım sıklığı:
Normal Olaylar:
Alternatif Kurslar:
İstisnalar:
İçerir:
Özel gereksinimler:
Varsayımlar:
Notlar ve Sorunlar:

İş Analizi - Gereksinimler Mngmt

Yazılım gereksinimlerinin toplanması, tüm yazılım geliştirme projesinin temelidir. İş gereksinimlerini istemek ve toplamak, her proje için kritik bir ilk adımdır. İş ve teknik gereksinimler arasındaki boşluğu doldurmak için, iş analistleri verilen bağlamda iş ihtiyaçlarını tam olarak anlamalı, bu ihtiyaçları iş hedefleriyle uyumlu hale getirmeli ve ihtiyaçları hem paydaşlara hem de geliştirme ekibine doğru şekilde iletmelidir.

Kilit paydaşlar, birinin müşteri / müşteri gereksinimlerini sade bir İngilizce ile açıklayabilmesini diler. Bu, değeri üst düzeyde anlamalarına fayda sağlayacak mı? Dokümantasyonu gereksinimlerle ve iş idaresinin mümkün olan en iyi şekilde nasıl iletişim kurabileceğiyle eşleştirmeye çalışacaklarından bu ana odak alanı olacaktır.

Projeler Neden Başarısız Olur?

Projelerin başarısız olmasının birçok nedeni vardır, ancak bazı ortak alanlar aşağıdakileri içerir -

  • Pazar ve Strateji Başarısızlığı
  • Organizasyonel ve Planlama Başarısızlıkları
  • Kalite Hataları
  • Liderlik ve Yönetişim başarısızlıkları
  • Beceriler, Bilgi ve yeterlilik başarısızlıkları
  • Katılım, ekip çalışması ve iletişim hataları

Sorunun temelinde, projelerin giderek daha karmaşık hale gelmesi, değişikliklerin meydana gelmesi ve iletişimin zorlaşması var.

Neden Başarılı Takımlar Gereksinim Yönetimini Yapar?

Gereksinim yönetimi, ekibinizi korumakla ilgilidir in-sync ve sağlamak visibility bir proje içinde neler olup bittiğine.

Projelerinizin başarısı için tüm ekibinizin neyi ve neden inşa ettiğinizi anlaması çok önemlidir - ihtiyaç yönetimini böyle tanımlarız. "Neden" önemlidir çünkü hedefler, geri bildirimler ve gereksinimlerle ilgili alınan kararlar için bağlam sağlar.

Bu, gelecekteki başarının ve olası sorunların öngörülebilirliğini artırarak ekibinizin herhangi bir sorunu hızla düzeltmesine ve projenizi zamanında ve bütçe dahilinde başarıyla tamamlamasına olanak tanır. Başlangıç ​​noktası olarak, dahil olan herkesin gereksinimlerin ne olduğu ve bunların nasıl yönetileceği konusunda temel bir anlayışa sahip olması değerlidir.

Temellerden Başlayalım

Gereksinim, paydaşın bir sorunu çözmek veya bir hedefe ulaşmak için ihtiyaç duyduğu bir koşul veya kabiliyettir. Bir sistem veya sistem tarafından karşılanması veya sahip olunması gereken bir koşul veya yetenek. Bir sözleşmeyi, standardı, şartnameyi veya diğer resmi olarak dayatılmış belgeleri karşılayan bileşen.

Bir mühendise neyin inşa edileceğini ve bir QA yöneticisine neyin test edileceğini en iyi ileten bilgiler ne olursa olsun, bir gereksinim metin, eskizler, ayrıntılı örnekler veya modellerle ifade edilebilir. Geliştirme sürecinize bağlı olarak, gereksinimleri yakalamak için farklı terminoloji kullanabilirsiniz.

Üst düzey gereksinimler bazen basitçe şu şekilde anılır: needs veya goals. Yazılım geliştirme uygulamalarında gereksinimler, "kullanım durumları", "özellikler" veya "işlevsel gereksinimler" olarak adlandırılabilir. Çevik geliştirme metodolojileri içinde daha spesifik olarak, gereksinimler genellikle şu şekilde ele alınır:epics ve stories.

Ekibinizin onlara ne ad verdiğine veya hangi süreci kullandığınıza bakılmaksızın; tüm ürünlerin geliştirilmesi için gereksinimler çok önemlidir. Gereksinimleri açıkça tanımlamadan eksik veya kusurlu bir ürün üretebilirsiniz. Süreç boyunca, gereksinimlerin tanımlanmasına dahil olan birçok kişi olabilir.

Bir paydaş, ürünün bir problemin çözümünde nasıl değer sağlayacağını açıklayan bir özellik talep edebilir. Bir tasarımcı, son ürünün bir kullanılabilirlik veya kullanıcı arayüzü açısından nasıl görünmesi veya performans göstermesi gerektiğine bağlı olarak bir gereksinim tanımlayabilir.

Bir iş analisti, belirli teknik veya organizasyonel kısıtlamalara uyan bir sistem gereksinimi oluşturabilir. Günümüzün karmaşık ürünleri ve geliştirilmekte olan yazılım uygulamaları için, bir projenin veya bir sürümün kapsamını yeterince tanımlamak genellikle yüzlerce veya binlerce gereksinim gerektirir. Bu nedenle, gereksinimler geliştirme sürecinde zaman içinde doğal olarak değişip geliştikçe, ekibin her bir gereksinime erişebilmesi, işbirliği yapabilmesi, güncelleyebilmesi ve tamamlanana kadar test edebilmesi zorunludur.

Gereksinim yönetiminin değerini üst düzeyde tanımladığımıza göre, şimdi her ekip üyesinin ve paydaşın anlayıştan yararlanabileceği dört temel ilkeye daha derine inelim -

  • İyi gereksinimleri planlama: "Ne halt inşa ediyoruz?"
  • İşbirliği ve katılım: "Spesifikasyonu şimdiden onaylayın!"
  • İzlenebilirlik ve değişiklik yönetimi: "Bekle, geliştiriciler bunun değiştiğini biliyor mu?"
  • Kalite güvencesi: "Merhaba, bu şeyi test eden oldu mu?"

Herkes ne inşa ettiğimizi biliyor mu ve neden? Gereksinim yönetiminin değeri budur.

Paydaşlardan İşbirliği ve Satın Alma

Herkes döngüde mi? İlerlemek için gereksinimler konusunda onayımız var mı? Bu sorular, geliştirme döngüleri sırasında ortaya çıkar. Herkesin gereksinimler üzerinde anlaşması harika olurdu, ancak birçok paydaşın bulunduğu büyük projeler için bu genellikle olmaz. Herkesin aynı fikirde olmasını sağlamaya çalışmak, kararların ertelenmesine veya daha kötüsü hiç alınmamasına neden olabilir. Her karar üzerinde fikir birliğine varmak her zaman kolay değildir.

Uygulamada, mutlaka “fikir birliği” istemezsiniz, gruptan “katılım” ve projeyi ileriye taşıyabilmek için kontrolü elinde tutanların onayını istersiniz. Mutabakatla, herkesin ödün vermesini ve karar üzerinde anlaşmasını sağlamaya çalışıyorsunuz. Buy-in ile, insanların en iyi çözümü desteklemelerini, akıllıca bir karar vermelerini ve ilerlemek için gerekli olanı yapmalarını sağlamaya çalışıyorsunuz.

Kararın en iyisi olduğu konusunda herkesin hemfikir olmasına gerek yok. Herkesin kararı desteklemesine ihtiyacın var. Ekip işbirliği, kararlar konusunda destek almaya ve iyi gereksinimleri planlamaya yardımcı olabilir.

İşbirlikçi ekipler, herkesin projelerde pay sahibi olduğundan emin olmak için çok çalışır ve geri bildirim sağlar. İşbirlikçi ekipler sürekli olarak fikirleri paylaşır, tipik olarak daha iyi iletişim kurar ve projenin hedeflerine ilişkin ortak bir bağlılık duygusu ve anlayış olduğu için alınan kararları destekleme eğilimindedir.

Geliştiriciler, test uzmanları veya diğer paydaşlar, iletişim sorunları ortaya çıktığında, insanlar sinirlendiğinde ve projeler ertelendiğinde "döngü dışında" hissettiğinde. Herkes işin kapsamına girdiğinde, gereksinimlerin açık ve iyi belgelenmesi zorunludur. Tüm gereksinimleri takip etmek, işlerin zorlaştığı yerdir.

Tamamlanması gereken birden fazla kişiyle işbirliği yapmayı içeren, bir mil uzunluğunda bir yapılacaklar listesine sahip olduğunuzu hayal edin. Tüm bu öğeleri nasıl düz tutarsınız? Bir maddede yapılacak bir değişikliğin projenin geri kalanını nasıl etkileyeceğini nasıl izlersiniz? İzlenebilirlik ve değişim yönetiminin değer kattığı yer burasıdır.

İyi Gereksinimleri Planlama

Öyleyse, iyi bir gereksinim yapan nedir? İyi bir gereksinim değerli ve uygulanabilir olmalıdır; bir ihtiyacı tanımlamalı ve çözüme giden bir yol sağlamalıdır. Takımdaki herkes bunun ne anlama geldiğini anlamalı. Gereksinimler karmaşıklığa göre değişir.

  • İyi bir Gereksinimler Belgesi, üst düzey gereksinimleri alt gereksinimlere bölünmüş bir grubun parçası olabilir.

  • Ayrıca, son ürünün davranışını veya bileşenlerini açıklayan bir dizi işlevsel gereksinimi içeren çok ayrıntılı spesifikasyonları da içerebilirler.

  • İyi gereksinimlerin kısa ve net olması ve "neye ihtiyacımız var?" Sorusuna cevap vermesi gerekir. "Bir ihtiyacı nasıl karşılayabiliriz?" Yerine

  • İyi gereksinimler, tüm paydaşların planın kendi bölümlerini anlamasını sağlar; Parçalar net değilse veya yanlış yorumlanmışsa, nihai ürün kusurlu veya arızalı olabilir.

Gereksinimler geliştikçe süreç boyunca ekipten sürekli olarak geri bildirim alarak, gereksinimlerin başarısızlık veya yanlış yorumlanmasını önlemeye yardımcı olunabilir. Herkesle sürekli işbirliği ve satın alma, başarının anahtarıdır.

İhtiyaç Toplama ve Analizi

Gereksinim, paydaşın bir sorunu çözmek veya kurumsal bir hedefe ulaşmak için ihtiyaç duyduğu bir koşul veya kabiliyettir; bir sistem tarafından karşılanması veya sahip olunması gereken bir koşul veya yetenek.

Yazılım mühendisliğinde gereksinim analizi , çeşitli paydaşların olası çatışan gereksinimlerini dikkate alarak, yeni veya değiştirilmiş bir ürün için ihtiyaçların veya koşulların belirlenmesi, yazılım veya sistem gereksinimlerinin analiz edilmesi, belgelenmesi, doğrulanması ve yönetilmesi ile ilgili görevleri kapsar.

Gereksinimler şöyle olmalıdır -

  • Documented
  • Actionable
  • Measurable
  • Testable
  • Traceable

Gereksinimler, belirlenen iş ihtiyaçları veya fırsatları ile ilgili olmalı ve sistem tasarımı için yeterli bir ayrıntı düzeyinde tanımlanmalıdır.

Bir İş analisti, mevcut sistemleri gözlemleyerek, mevcut prosedürleri inceleyerek, müşterilerle ve son kullanıcılarla tartışarak bilgi toplar. Analist, çalışan bir Sistemin yokluğunda da yaratıcı ve yaratıcı becerilere sahip olmalıdır. Eksik halkaları bulmak için toplanan gereksinimi analiz etmek, gereksinim analizidir.

Yaklaşımı Kolaylaştırmak

Hedefleri ortaya çıkarmak için iş uzmanına, geliştirme yöneticisine ve proje sponsoruna aşağıdaki soruları sorun:

  • Bu proje şirketin hangi iş hedeflerine ulaşılmasına yardımcı olacak?

  • Neden şimdi bu projeyi yapıyoruz?

  • Daha sonra yaparsak ne olur?

  • Ya hiç yapmazsak?

  • Bu projeden kimler yararlanacak?

  • Bundan yararlanacak insanlar, bunu şu anda yapılabilecek en önemli gelişme olarak görüyor mu?

  • Bunun yerine farklı bir proje mi yapmalıyız?

Muhtemel hedefler maliyetleri düşürmek, müşteri hizmetlerini iyileştirmek, iş akışını basitleştirmek, eski teknolojiyi değiştirmek, yeni bir teknolojiyi kullanmak ve diğerleri olabilir. Ayrıca, önerilen projenin belirtilen hedefe ulaşılmasına tam olarak nasıl yardımcı olacağını anladığınızdan emin olun.

Farklı Gereksinim Türleri

Bir İş analistinin ilgilendiği en yaygın gereksinim türleri aşağıdakiler olacaktır:

İş gereksinimleri

İş gereksinimleri, bir işletmenin, çözümden bağımsız kalırken kurumsal hedefleri karşılamak için gerçekleştirilmesi gereken kritik faaliyetleridir. Bir iş gereksinimleri belgesi (BRD), müşteri ihtiyaç ve beklentilerinin dokümantasyonu dahil olmak üzere bir proje için iş çözümünün ayrıntılarını verir.

Kullanıcı gereksinimleri

Kullanıcı gereksinimleri, kullanıcının yazılım projesinden inşa edilecek yazılımdan beklediği / istediği özel gereksinimleri belirtmelidir. Bir kullanıcı gereksinimi Doğrulanabilir, Açık ve öz, Tam, Tutarlı, İzlenebilir, Uygulanabilir olmalıdır.

Kullanıcı gereksinimleri belgesi (URD) ​​veya kullanıcı gereksinimleri belirtimi, genellikle yazılım mühendisliğinde kullanılan ve kullanıcının yazılımın ne yapabilmesini beklediğini belirten bir belgedir.

sistem gereksinimleri

Sistem gereksinimleri, bir uygulamanın en iyi şekilde çalışmasını sağlamak için bir bilgisayara yüklenmesi gereken yazılım kaynakları gereksinimlerini ve ön koşullarını tanımlama ile ilgilidir.

İşlevsel gereksinimler

İşlevsel gereksinimler, geliştirilmekte olan sistemin belirli amaçlanan davranışını yakalar ve belirtir. Sistem hesaplamaları, veri işleme ve işleme, kullanıcı arayüzü ve uygulamayla etkileşim ve kullanıcı gereksinimlerinin nasıl karşılandığını gösteren diğer özel işlevler gibi şeyleri tanımlarlar. Her gereksinime benzersiz bir kimlik numarası atayın.

İşlevsel Olmayan Gereksinimler

İşlevsel olmayan gereksinim, belirli davranışlar yerine bir sistemin işleyişini yargılamak için kullanılabilecek kriterleri belirleyen gereksinimdir. Sistem mimarisi, işlevsel olmayan gereksinimleri uygulama planı hakkında konuşuyor.

İşlevsel olmayan gereksinimler, sistemin nasıl görünmesi gerektiğinden bahseder veya “sistem olacak” gibi bahsedilebilir. İşlevsel olmayan gereksinimler, sistemin nitelikleri olarak adlandırılır.

Geçiş Gereksinimleri

Geçiş Gereksinimleri, işletmenin mevcut durumundan gelecekteki istenen bir duruma geçişi kolaylaştırmak için çözümün yerine getirmesi gereken yetenekleri tanımlar, ancak bu geçiş tamamlandıktan sonra buna ihtiyaç duyulmaz.

Doğaları gereği her zaman geçicidirler ve hem mevcut hem de yeni bir çözüm tanımlanana kadar geliştirilemeyecekleri için diğer ihtiyaç türlerinden ayrılırlar. Genellikle mevcut sistemlerden veri dönüşümünü, ele alınması gereken beceri boşluklarını ve istenen gelecek durumuna ulaşmak için diğer ilgili değişiklikleri kapsar. Çözüm değerlendirme ve doğrulama yoluyla geliştirilir ve tanımlanırlar.

İzlenebilirlik ve Değişim Yönetimi

Gereksinim izlenebilirliği, ilk fikir üretiminden test aşamasına kadar tüm gereksinimlerinizi organize etmenin, belgelemenin ve takip etmenin bir yoludur.

Gereksinim izleme yeteneği matrisi (RTM), işlevsel gereksinimleri ve geliştirme süreci boyunca bunların uygulanmasını izlemek için bir yöntem sağlar. Her gereksinim, ilgili bölüm numarasıyla birlikte matrise dahil edilir.

Proje ilerledikçe, RIM her bir gereksinimin durumunu yansıtacak şekilde güncellenir. Ürün sistem testi için hazır olduğunda, matris her bir gereksinimi, hangi ürün bileşeninin buna hitap ettiğini ve hangi testin doğru şekilde uygulandığını doğruladığını listeler.

RTM'de aşağıdakilerin her biri için sütunlar ekleyin -

  • Gereksinim açıklaması
  • FRD'de gereksinim referansı
  • Doğrulama metodu
  • Test Planında gereksinim referansı

Example- Projenizdeki öğeler arasındaki ilişkileri belirlemek için noktaları birleştirmek. Bu, ortak aşağı akış konektörüdür.

Fikir Gereksinimleri Tasarım Testi İşletme Hedefleri

Gereksinimlerinizin her birini orijinal iş hedefine kadar takip edebilmelisiniz.

Gereksinimleri takip ederek, dalgalanma efekti değişikliklerini belirleyebilir, bir gereksinimin tamamlanıp tamamlanmadığını ve doğru bir şekilde test edilip edilmediğini görebilirsiniz. İzlenebilirlik ve değişim yönetimi, yöneticilere sorunları önceden tahmin etmek ve kalitenin sürekliliğini sağlamak için gereken huzur ve görünürlüğü sağlar.

Kalite güvencesi

Gereksinimlerin ilk seferde doğru şekilde sunulması, daha iyi kalite, daha hızlı geliştirme döngüleri ve ürünle daha yüksek müşteri memnuniyeti anlamına gelebilir. Gereksinim yönetimi yalnızca doğru yapmanıza yardımcı olmakla kalmaz, aynı zamanda ekibinizin geliştirme süreci boyunca paradan ve birçok baş ağrısından tasarruf etmesine yardımcı olur.

Kısa ve öz, özel gereksinimler, sorunları daha sonra düzeltmenin çok daha pahalı olduğu durumlarda değil, erken tespit etmenize ve düzeltmenize yardımcı olabilir. Ek olarak, mal olabilir100 times daha sonra kodlandıktan sonra geliştirme sürecinde bir kusuru düzeltmek, bir gereksinim sırasında erkenden düzeltmekten daha fazlasını yapar.

Gereksinim yönetimini kalite güvence sürecinize entegre ederek, ekibinizin verimliliği artırmasına ve yeniden çalışmayı ortadan kaldırmasına yardımcı olabilirsiniz. Dahası, yeniden çalışma, maliyet sorunlarının çoğunun meydana geldiği yerdir.

Diğer bir deyişle, geliştirme ekipleri bütçelerinin çoğunu ilk seferde doğru şekilde gerçekleştirilmeyen çabalara harcıyor. Örneğin, bir geliştirici eski bir özellik belgesine dayalı olarak bir özelliği kodlar, ancak daha sonra bu özelliğin gereksinimlerinin değiştiğini öğrenmek için. Etkili gereksinim yönetimi en iyi uygulamaları ile bu tür sorunlar önlenebilir.

Özetle, ihtiyaç yönetimi karmaşık bir disiplin gibi görünebilir, ancak bunu basit bir konsepte indirgediğinizde, ekiplerin "Ne inşa ettiğimizi ve nedenini herkes anlıyor mu?" İş analistlerinden, ürün yöneticilerine ve proje liderlerinden geliştiricilere, QA yöneticilerine ve test görevlilerine, ilgili paydaşlar ve müşterilerle birlikte - çoğu zaman proje başarısızlığının temel nedeni projenin kapsamının yanlış anlaşılmasıdır.

Herkes işbirliği yaptığında ve projenin yaşam döngüsü boyunca gerekliliklerle ilgili tartışmalara, kararlara ve değişikliklere tam bağlam ve görünürlüğe sahip olduğunda, yani başarı tutarlı bir şekilde gerçekleştiğinde ve sürekli kaliteyi koruduğunuzda. Ayrıca süreç, katılan herkes için daha az sürtünme ve hayal kırıklığı ile daha sorunsuzdur.

Note- Araştırmalar, proje ekiplerinin gereksinimleri etkin bir şekilde yöneterek proje kusurlarının% 50-80'ini ortadan kaldırabileceğini göstermiştir. Carnegie Mellon yazılım mühendisliği enstitüsüne göre, "yazılım geliştirme maliyetinin yüzde 60-80'i yeniden işleniyor."

Gereksinimleri Alma İmzalama

Gereksinimlerin imzalanması, belgelenen gereksinimlerin içeriği ve sunumunun doğru ve eksiksiz olduğu konusunda proje paydaşları tarafından yapılan anlaşmayı resmileştirir. Resmi anlaşma, uygulama sırasında veya sonrasında bir paydaşın yeni (önceden karşılaşılmamış) bir gereklilik getirmesi riskini azaltır.

Gereksinimlerin onaylanmasının elde edilmesi, tipik olarak, her proje paydaşıyla belgelendiği şekilde gereksinimlerin yüz yüze nihai incelemesini içerir. Her incelemenin sonunda, paydaştan incelenen gereksinimler belgesini resmi olarak onaylaması istenir. Bu onay fiziksel veya elektronik olarak kaydedilebilir.

Gereksinimlerin onayını elde etmek, genellikle Gereksinim İletişimi içindeki son görevdir. İş Analisti, gözden geçirme sürecinde ortaya atılan yorumların veya itirazların düzenlenmesi dahil olmak üzere Resmi Gereksinim İncelemelerinin çıktılarını isteyecektir.

İş Analizi - Modelleme

Bir İş Modeli, destekleyici metin ve diğer bileşenlerle ilişkilerle birlikte genellikle bir grafik bileşen içeren bir iş veya çözümün temsili olarak tanımlanabilir. Örneğin, bir şirketin iş modelini anlamamız gerekirse, aşağıdaki gibi alanları incelemek isteriz:

  • Şirketin temel değerleri
  • Neye hizmet ediyor?
  • Farklı kümeler nedir?
  • Temel kaynakları
  • Başlıca ilişkiler
  • Teslimat kanalları

Modelleme tekniklerinin yardımıyla, işletme tarafından kullanılan mevcut ve önerilen organizasyon yapılarının, süreçlerinin ve bilgilerin eksiksiz bir tanımını oluşturabiliriz.

İş Modeli, geliştirilecek nihai ürün için bir plan gibi yapılandırılmış bir modeldir. Planlama için yapı ve dinamik verir. Aynı zamanda nihai ürün için temel sağlar.

Purpose of Business Modelling

Business modelling is used to design current and future state of an enterprise. This model is used by the Business Analyst and the stakeholders to ensure that they have an accurate understanding of the current “As-Is” model of the enterprise.

It is used to verify if, stakeholders have a shared understanding of the proposed “To-be of the solution.

Analyzing requirements is a part of business modelling process and it forms the core focus area. Functional Requirements are gathered during the “Current state”. These requirements are provided by the stakeholders regarding the business processes, data, and business rules that describe the desired functionality which will be designed in the Future State.

Performing GAP Analysis

After defining the business needs, the current state (e.g. current business processes, business functions, features of a current system and services/products offered and events that the system must respond to) must be identified to understand how people, processes and technology, structure and architecture are supporting the business by seeking input from IT staff and other related stakeholders including business owners.

A gap analysis is then performed to assess, if there is any gap that prevents from achieving business needs by comparing the identified current state with the desired outcomes.

If there is no gap (i.e. the current state is adequate to meet the business needs and desired outcomes), it will probably not be necessary to launch the IT project. Otherwise, the problems/issues required to be addressed in order to bridge the gap should be identified.

Techniques such as SWOT (Strengths, Weaknesses, Opportunities and Threats) Analysis and document analysis can be used.

To Assess Proposed System

BA should assist the IT project team in assessing the proposed IT system to ensure that it meets the business needs and maximizes the values delivered to stakeholders. BA should also review the organization readiness for supporting the transition to the proposed IT system to ensure a smooth System Implementation.

BA should help the IT project team to determine whether the proposed system option and the high-level system design could meet the business needs and deliver enough business value to justify the investment. If there are more than one system options, BA should work with the IT staff to help to identify the pros and cons of each option and select the option that delivers the greatest business value.

Guiding Principles for Business Modelling

The primary role of business modelling is mostly during inception stage and elaboration stages of project and it fades during the construction and transitioning stage. It is mostly to do with analytical aspects of business combined with technical mapping of the application or software solution.

  • Domain and User variation − Developing a business model will frequently reveal areas of disagreement or confusion between stakeholders. The Business Analyst will need to document the following variations in the as-is model.

  • Multiple work units perform the same function − Document the variances in the AS-IS model. This may be different divisions or geographies.

  • Multiples users perform the same work − Different stakeholders may do similar work differently. The variation may be the result of different skill sets and approaches of different business units or the result of differing needs of external stakeholders serviced by the enterprise. Document the variances in the AS-IS model.

  • Resolution Mechanism − The Business Analyst should document whether the ToBe solution will accommodate the inconsistencies in the current business model or whether the solution will require standardization. Stakeholders need to determine which approach to follow. The To-Be model will reflect their decision.

Example of BA role in Modelling ERP Systems

A Business analyst is supposed to define a standard business process and set up into an ERP system which is of key importance for efficient implementation. It is also the duty of a BA to define the language of the developers in understandable language before the implementation and then, utilize best practices and map them based on the system capabilities.

A requirement to the system is the GAAP fit analysis, which has to balance between −

  • The need for the technical changes, which are the enhancements in order to achieve identity with the existing practice.

  • Effective changes, which are related to re-engineering of existing business processes to allow for implementation of the standard functionality and application of process models.

Functional Business Analyst

Domain expertise is generally acquired over a period by being in the “business” of doing things. For example,

  • A banking associate gains knowledge of various types of accounts that a customer (individual and business) can operate along with detailed business process flow.

  • An insurance sales representative can understand the various stages involved in procuring of an Insurance policy.

  • A marketing analyst has more chances of understanding the key stakeholders and business processes involved in a Customer Relationship Management system.

  • A Business Analyst involved in capital markets project is supposed to have subject matter expertise and strong knowledge of Equities, Fixed Income and Derivatives. Also, he is expected to have handled back office, front office, practical exposure in applying risk management models.

  • A Healthcare Business Analyst is required to have basic understanding of US Healthcare Financial and Utilization metrics, Technical experience and understanding of EDI 837/835/834, HIPAA guidelines, ICD codification – 9/10 and CPT codes, LOINC, SNOMED knowledge.

Some business analysts acquire domain knowledge by testing business applications and working with the business users. They create a conducive learning environment though their interpersonal and analytical skills. In some cases, they supplement their domain knowledge with a few domain certifications offered by AICPCU/IIA and LOMA in the field of Insurance and financial services. There are other institutes that offer certification in other domains.

Other Major Activities

Following a thorough examination of current business processes, you can offer highly professional assistance in identifying the optimal approach of modelling the system.

  • Organizing the preparation of a formalized and uniform description of business processes in a manner ensuring efficient automation in the system.

  • Assistance to your teams in filling out standard questionnaires for the relevant system as may be furnished by the developers.

  • Participation in working meetings requirements towards the developers are defined.

  • Check and control as to whether the requirements set by you have been properly “reproduced” and recorded in the documents describing the future model in the system (Blueprints).

  • Preparation of data and assisting for prototyping the system.

  • Assistance in preparation of data for migration of lists and balances in the format required by the system.

  • Review of the set-up prototype for compliance with the requirements defined by the business process owners.

  • Acting as a support resource to your IT teams in preparing data and actual performance of functional and integration tests in the system.

In the next section, we will discuss briefly about some of the popular Business Modelling Tools used by large organizations in IT environments.

Tool 1: Microsoft Visio

MS-Visio is a drawing and diagramming software that helps transform concepts into a visual representation. Visio provides you with pre-defined shapes, symbols, backgrounds, and borders. Just drag and drop elements into your diagram to create a professional communication tool.

Step 1 − To open a new Visio drawing, go to the Start Menu and select Programs → Visio.

Step 2 − Move your cursor over “Business Process” and select “Basic Flowchart”.

The following screenshot shows the major sections of MS-Visio application.

Let us now discuss the basic utility of each component −

A − the toolbars across the top of the screen are like other Microsoft programs such as Word and PowerPoint. If you have used these programs before, you may notice a few different functionalities, which we will explore later.

Selecting Help Diagram Gallery is a good way to become familiar with the types of drawings and diagrams that can be created in Visio.

B − The left side of the screen shows the menus specific to the type of diagram you are creating. In this case, we see −

  • Arrow Shapes
  • Backgrounds
  • Basic Flowchart Shapes
  • Borders and Titles

C − The center of the screen shows the diagram workspace, which includes the actual diagram page as well as some blank space adjacent to the page.

D − The right side of the screen shows some help functions. Some people may choose to close this window to increase the area for diagram workspace, and re-open the help functions when necessary.

Tool 2: Enterprise Architect

Enterprise architect is a visual modeling and design tool based on UML. The platform supports the design and construction of software systems, modeling business processes and modeling industry based domains. It is used by business and organizations to not only model the architecture of their systems. But to process the implementation of these models across the full application development life cycle.

The intent of Enterprise architect is to determine how an organization can most effectively achieve its current and future objectives.

Enterprise architect has four points of view which are as follows −

  • Business perspective − The Business perspective defines the processes and standards by which the business operates on day to day basis.

  • Application Perspective − The application perspective defines the interactions among the processes and standards used by the organization.

  • Information Perspective − This defines and classifies the raw data like document files, databases, images, presentations and spreadsheets that organization requires in order to efficiency operate.

  • Technology Prospective − This defines the hardware, operating systems, programming and networking solutions used by organization.

Tool 3: Rational Requisite Pro

The process of eliciting, documenting organizing tracking and changing Requirements and communicating this information across the project teams to ensure that iterative and unanticipated changes are maintained throughout the project life cycle.

Monitoring status and controlling changes to the requirement baseline. The Primary elements are Change control and Traceability.

Requisite Pro is used for the above activities and project administration purposes, the tool is used for querying and searching, Viewing the discussion that were part of the requirement.

In Requisite Pro, the user can work on the requirement document. The document is a MS-Word file created in Reqpro application and integrated with the project database. Requirements created outside Requisite pro can be imported or copied into the document.

In Requisite Pro, we can also work with traceability, here it is a dependency relationship between two requirements. Traceability is a methodical approach to managing change by linking requirements that are related to each other.

Requisite Pro makes it easy to track changes to a requirement throughout the development cycle, so it is not necessary to review all your documents individually to determine which elements need updating. You can view and manage suspect relationships using a Traceability Matrix or a Traceability Tree view.

Requisite Pro projects enable us to create a project framework in which the project artifacts are organized and managed. In each project the following are included.

  • General project information
  • Packages
  • General document information
  • Document types
  • Requirement types
  • Requirement attributes
  • Attribute values
  • Cross-project traceability

Requisite Pro allows multiple user to access the same project documents and database simultaneously hence the project security aspect is to very crucial. Security prevents the system use, potential harm, or data loss from unauthorized user access to a project document.

It is recommended that the security is enabled for all RequisitePro projects. Doing so ensures that all changes to the project are associated with the proper username of the Individual who made the change, thereby ensuring that you have a complete audit trail for all changes.