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 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. |
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 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 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. 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 öğrenmek,onun ne bildiğini tahmin etmeniz ve bunu onlara söylemeniz yarayan bir 2lidir. gerektiğini belirtmek sizin profesyonelliğinize bağlı |
Yapmamanız Gerekenler bunu göstermeyin. |
Yapmanız Gerekenler bulunduğunuzu anlatın. sorulmalıdır. röportaj yapmaz. ve düzeltilir.Ayrıca bu atlanan konuları da hatırlamaya yardımcı olur. |
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 ve incelemelidir.Form,not,rapor gibi şeyleri.Bu arada |
3.2.4 Gözlem olanların detayını gözlemleyecek durumlar olabilir,hatta işakışında insanları takip etmek bile gerekebilir. 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. 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? |
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.