bilişen gençlik 004 gereksinim analizi / requirement analysis

Gereksinim Analizi-Gerekli olanın ortaya çıkarılması(ihtiyaçların belirlenmesi)

alt başlıklar

Gereksinim Analizinin Amacı

Sistem Araştırması

Gereksinimler Kataloğu

Fonksiyonel gereksinimler ve fonksiyonel olmayan gereksinimler

Gereksinim Kataloğuna girilen bir örnek

PG Topic:Bütünüyle gereksinim analizinin imkansızlığı

3.1 Gereksinim analizinin amacı

Daha önceki konularda bahsedildiği gibi bir sistem analistinin önemli görevlerinden biride yeni bir sistemde nelerin gerekli olacağını belirlemesidir,bunları ortaya çıkarmasıdır Requirement Analysis(gereksinim analizi)'ne bir çok isim verilmiştir,req.determination,req. acquisition gibi ancak bizim için önemli olan 1998 de Donal Flynn'ın önerdiği 'requirement determination' dır.Bu da gereksinim belirlenmesi diye türkçeye çevrilebilir.Donal Flynn'in tanımı şu şekilde:

Gereksinimlerin belirlenmesi fazı birçok bölümlerden oluşur. bunlar problemin belirlenmesi,gereksinimlerin elde edilmesi ve son olarakta gereksinimlerin modellenmesi bölümleridir. Burda amaç kullanıcının içerik çerçevesinde açıkladığı,ihtiyaç duyabileceği şeyleri tanımlayabilmektir.

Biz yinede genel olarak requirement analysis i kullanacağız.Gereksinim Analizinin amacı; yeni sistemin gereksinimlerini doğru anlayabilmek ve projenin kalan kısmını düzgün yönlendirip,uygulayabilmektir.G.A(gereksinim analizi)'nde plan yaparak ve çalışmanın başlangıç kapsamında anlaşarak projenin analiz fazı oluşturulur.

G.A'nin amacı:

yeni oluşturulacak sistemde ne tür data(veri) ve işlemler gerekeceğinin belirlenmesi

yeni oluşturulacak sistemde fonksiyonel olan ve olmayan gereksinimlerin belirlenmesi

menejerlerin anlayacağı dilde çeşitli işlem seçeneklerinin kurgulanması,kurulması

gereksinimlerin teknolojik detaylar(özellikle bilgisayar içerikli) olmadan belirlenmesi

3.2 Sistem araştırması

Mevcut çoğu bilgi sistemlerinde amaç kağıt işlerini bilgisayara aktarmaktır,yani paperwork denen kısmı mümkün olduğunca azaltmaktır.G.A.nde en önemli aktivitelerden biride şuanki mevcut sistemin nasıl işlediğini incelemektir.Neye ihtiyaç duyulacağının belirlenmesi için,mevcut sistemin iyi anlaşılmış olması gerekmektedir. G.A kullanıcıların öncelikle neye ihtiyaç duyacağını belirtmeli, ayrıca güvenlik,kontrol gibi konularıda dikkate almalıdır. Yani yapılması gereken araştırmanın sonucunda mevcut sistem modellenebilmelidir(diagram ve kelimelerle) Mevcut sistem fiziksel olarak var olduğu için buna Mevcut Fiziksel Sistem denir.

3.2.1 Röpotajlar (Görüşmeler)

Kullanıcıların yeni sistemde ne istediklerini öğrenmenin belki de en kolay yolu onlarla görüşmektir. Mevcut sistemdeki problemleri öğrenip,yeni sistemdeki gereksinimler ortaya konur ki problemler tekrar etmesin. Röportajların zorluğu,doğru çalışanı bulmaktadır.Bu yüzden işi temelde yapan,sistemin içinde direk çalışan kişiler yöneticilere oranla daha çok tercih edilmelidir.Yöneticilerle konuşmanın zorluğu şudur,onlar sürekli mevcut sistemin nasıl işlediğini iyi bildiklerini sanırlar halbuki bilmiyorlardır.

3.2.2 Röportaj Etiği (iyi bi röportaj nasıl yapılır?)

Tavsiyeler Her zaman önce evödevinizi yapın,bu da konuşcağınız kişi ve departmanı hakkında bilgi edinmekle olur Bildiklerinizi unutun,herhangi biri sizi yanlış bilgilendirmiş olabilir. Röportaj yapacağınız kişi konuşsun,siz ona sölemesi gerekenleri söylemeyin,amacınız onun ne bildiğini öğrenmek,onun ne bildiğini tahmin etmeniz ve bunu onlara söylemeniz asıl mevzunun kaçmasına neden olur. Departmanında neler döndüğünü sormaya çalışın ki bu çoğu zaman basit ama istediğinizi elde etmenize yarayan bir 2lidir. Röportajı yaptığınız kişi konuşurken,onu bölmeyin,eğer bölmek zorundaysanız da tekrar nereden başlanması gerektiğini belirtmek sizin profesyonelliğinize bağlı

Yapmamanız Gerekenler Üstün olmayın,kendinizi konuştuğunuz kişiden daha üst seviyede görmeyin,itici bir durum olur. Beden dilinizi kullanmamaya çalışın,aynı şekilde argoyu da. İşlerin nasıl yürüdüğünü bildiğinizi göstermeyin,biliyorsanız belli etmeyin,bilmiyorsanız susun. Konuştuğunuz kişinin işinin aptalca,sıkıcı,gereksiz veya tam anlamıyla eksik bir iş olduğunu sakın belirtmeyin, bunu göstermeyin. Konuşmacı yalan söylüyor ise,bunu anlasanız da belli etmeyin,karşılıklı atışmaya girmeyin.

Yapmanız Gerekenler Öncelikle Kendinizi tanıtın,direk içeri girip oturup soru sormaya başlamayın,kim olduğunuzu ve niye orada bulunduğunuzu anlatın. Not alıp alamayacağınızı sorun,kimse sizden konuşulacakları ezberlemenizi beklemiyor ama bu soru nezakaten sorulmalıdır. Kesinlikle izin almadan sesli kayıt yapmayın aksi takdirde bu durum açığa çıkarsa bir daha kimse sizinle röportaj yapmaz. Kibar olun,kaba analistler verimsizdirler ve çoğunlukla yanlış bilgilendirilirler. Mütevazi olun,bildiklerini öğrenmek için ordasınız,uzmanlık taslamayın Gerekirse konuya açıklık getirttirin,anlamadığınız yerlerde mutlaka sorun. Sonunda kendi görüşünüzü belirtin,çıkardığınız sonuçları aktarın ki yanlış anlaşılan bir şey varsa ortaya çıkar ve düzeltilir.Ayrıca bu atlanan konuları da hatırlamaya yardımcı olur. Sonunda teşekkür etmeyi bilin,değerli zamanlarını size ayırdıkları için konuşmacılara teşekkür ediniz.

bilgi edinmenin farklı yolları da vardır,röportaj dışında...döküman toplama ve gözlem mesela

3.2.3 Döküman toplama çok önemlidir.Analist mevcut sistemin çalışmasını sağlayan birçok farklı döküman tiplerini toplamalıdır ve incelemelidir.Form,not,rapor gibi şeyleri.Bu arada analist bütün bu kağıt üstündeki dataların nereden gelip nereye gittiğini incelemelidir.

3.2.4 Gözlem Analist nelerin olup bittiğini aktüel bir şekilde,görmelidir,gözlemlemelidir.Bazen birkaç çalışanla oturup olanların detayını gözlemleyecek durumlar olabilir,hatta işakışında insanları takip etmek bile gerekebilir. Bazı durumlarda analist çalışanları çeşitli görevleri yerine getirirken dikkatlice izlemek için sistemin küçük, geçici bir versiyonunu kendi kurmak durumunda kalabilir.

3.2.5 Problemler ve gereksinimler

Mevcut fiziksel sistemin araştırılması sırasında birçok problem su yüzüne çıkarılacaktır ve de kullanıcıların istedikleri ancak olmayan bazı fonksiyonlarda sözkonusu olacaktır. Problemler ve gereksinimler PRL olarak adlandırılan bir listede tutulmalıdır.Bu problemin veya problemle birlikte gereksinimin yer aldığı,ayrıca muhtemel çözüm önerilerini de içeren bir formdur.Ayrıca PRL'deki içerikler daha sonra resmi bir döküman olan,Gereksinimler Kataloğu(req.catalogue) adı verilen belgeye de işlenmelidir. 3.5'te kitapta örnek şekil var.sayfa 33

3.3 Req.Catalogue (RC-roberto carlos:P,gereksinimler kataloğu)

Herbir problem ve gereksinim düzenlenir ve önceliklerine göre sıralanır ve bu şekilde RC'de kendine yer bulur.

Bu döküman sistem geliştirme yaşam döngüsünün analiz safhasında hazırlanır.Bu dökümanın içeriği için sistem gereksinimlerin açıklamaları denilebilir.

Gereksinimler mümkün olduğu kadar sayılabilir olmalı,tekrarlanmayan şekilde olmalı ve de kararlara temel olabilecek şekilde yeterince detaylandırılmalıdırlar.

Gereksinimler kataloğu şu detayları içerir:

mevcut sistemdeki yanlışlar ne? Öngörülen sistem için arzu edilenler neler? Sistemin fonksiyonel gereksinimleri(sistem ne yapmak zorunda) sistemin fonksiyonel olmayan gereksinimleri (mesela performans seviyeleri ve kaynak kullanımı gibi)

unutulmamalı ki rc'de yazan her detay uygulanmayabilir gerçekte.İyi bir analiz ve gerçekten ihtiyaç var mı yok mu belirlendikten sonra bu karar alınır..

the mean time to failure of a system :sistem hata öncesi ortalama ömrü : sistemin çökmeden önceki tahmini ortalama ömrü

response time : tepkime süresi : kullanıcının bir butona veya klavyede tuşa basmasına verilen tepkimenin süresi,bildiğiniz açma kapama tuşları sonucu oluşan etkide geçen süre

3.4 Fonksiyonel Olan ve Olmayan Gereksinimler

Gereksinim iki tiptir... fonksiyonel olan ve olmayan.

Fonksiyonel olan : sistemin yapması gerekeni belirtir.sistemin ne tür hizmetleri olmalı ve ne aktivitiler taşımalı bu belirtilir.

Fonksiyonel gereksinimler açıklamalarla ilgilenir.Raporları şekillendirir,sorgu ve güncellemeleri içerir,veri kaydını erişimini ve aktarımını ilgilendirir.

Fonksiyonel olmayanlar ise tepkime süreleri(response time),çöküş süresi(mean time failure),güvenlik ihtiyaçları,engelliler için erişim gibi konuları ilgilendirir.

3.4.1 Gereksinimlerin Dökümantasyonu (req.spesification)

Bu analistin sorunların giderilmesi için ne anladığının kağıda dökülmesidir.Kesin durumlar içerir,yeni sistemle ilgili.Mümkün oldğu kadar detaylı bir şekilde maddeler halinde sistemin ne yapması gerektiği anlatılır.Eski sistemin ne yaptığından çok yeni sistemin nasıl olması gerektiği kesin bir şekilde işlenir.Bu döküman genelde müşteri ve iş odaklı hazırlanır.