Ünite 4: Sistem Gereksinimlerinin Belirlenmesi

Giriş

Yeni geliştirilmiş bilgi sistemlerindeki hatalardan bahseden cümleler genellikle “sistem teknik olarak çok iyi çalışıyor ancak bizim istediklerimizi yapmıyor” biçimindedir. Buradaki problem, sistemin ne yapması gerektiğini açıklayan gereksinimleri belirleme fazının atlanmış olmasıdır.

Sistem Gereksinimleri

Gereksinimler, işlevsel gereksinimler ve işlevsel olmayan gereksinimler olarak iki grupta toplanabilir. Bazı işlevsel gereksinimler:

• Randevu almak isteyen hastalar kliniklerdeki boş randevu saatlerini görebilmeli ve randevusunu alabilmeli.
• Doktorlar çıkan tahlil sonuçlarını ve röntgen filmlerini bilgisayar ekranında görebilmeli.

Bazı işlevsel olmayan gereksinimler:

• Dâhilî kullanıcılar verilen kartlar aracılığıyla kendilerini sisteme tanıtarak sistemi kullanabilmelidir.
• Gün içinde sistemin arızalı olma süresi 5 dakikadan uzun olmamalıdır

biçiminde sıralanabilir. Ssitem gereksinimleri, gereksinim çeşidine göre sınıflandırılır. Bunlar: Performans gereksinimleri, Bilgi gereksinimleri, Ekonomi gereksinimleri, Kontrol ve güvenlik gereksinimleri, Etkinlik gereksinimleri ve servis gereksinimleridir.

Gereksinimlerin belirlenmesinin temel amacı; bilgi sisteminin kullanıcıları için bilgi, süreç ve haberleşme ihtiyaçlarının doğru tanımlanmasıdır. Sistem gereksinimleri doğru tespit edilemez ise Sistem öngörülen maliyetten pahalı olabilir, Sistem, kullanıcıların beklentilerini karşılamayabilir ve bunun sonucu sistem satın alınmayabilir.

Yüksek maliyetlere katlanmamak için sistem gereksinimleri aşağıdaki ölçütlere uygun olarak tanımlanmalıdır.

• Tutarlılık
• Tamlık
• Gerçeklenebilirlik
• Gereklilik
• Doğruluk
• Takip edilebilirlik
• Onaylanabilirlik

Gereksinimleri belirleme süreci zaman alıcı, zor ve sinir bozucu olabilir. Bu durum işletmelerin ve kişilerin zamandan ve paradan tasarruf amacıyla genelde kısa yolu tercih etmelerine sebep olur.

Gereksinimleri Belirleme Süreci

Problemi Belirleme ve Analiz

Sistem analistinin başarılı olması problem analizi konusunda yetenekli olmasına bağlıdır. Problemi analiz ederken tecrübesiz sistem analistlerinin yaptığı ortak hatalardan en önemlisi bir belirtiyi problem olarak belirlemeleridir. Bunun sonucu olarak tasarlayıp gerçekleştirecekleri çözüm, gerçek problemi çözemeyecek ve belki de yeni problemlere yol açacaktır. Problemleri belirleme, analiz ve çözümünde yaygın olarak kullanılan bir araç Ishikawa diyagramıdır. Balık kılçığı diyagramı, diyagramın sağına (balık kafası) problemin adını yazarak başlar. Problemin muhtemel sebepleri ana omurgaya bağlı kılçıkların etrafına yazılır ve oklar ana omurgaya doğru çizilir. Kılçıklar genelde malzeme, makine, insan gücü, çevre ve metot olarak adlandırılır. İzleyen şekilde bir balık kılçığı diyagramı örneği verilmiştir.

Gereksinimlerin Tanımlanması

Gereksinimleri tanımlayabilmesi için, sistem analistinin etkili bilgi toplama (gerçeklerin bulunması) teknikleri konusunda bilgili olması gerekir. Gerçeklerin bulunması, sistem geliştirmenin tüm fazlarında kullanılır.

Gereksinimlerin Analizi ve Belgelendirilmesi

Sistem analisti, gerçeklerin bulunması sürecinde toplanan bilgileri düzenli bir biçimde, anlaşılır ve anlamlı olarak bir araya getirmeli ve belgelendirmelidir.

Taslak gereksinimlerin belgelendirilmesi: Sistem analisti ilk bulgularını belgelendirmek için çeşitli araçlar kullanır. Haricî kullanıcıların bakış açısından ve onların anlayacağı terminolojiyi kullanarak sistem fonksiyonlarını tanımlayan kullanım durumlarını yazar.

Gereksinimlerin analizi: Birçok durumda, gerçeklerin bulunması faaliyetleri sonucunda birbiriyle çelişen gereksinimler belirlenir. Gereksinim analizinin amacı; gereksinimler arasındaki çelişkileri bulmak, çözümlemek ve paydaşları tatmin edecek şekilde uyarlayarak bir uzlaşmaya varmaktır. Bu aşamada “proje için doğru sistem gereksinimlerine ulaştık mı?” sorusu sorulmalıdır. Taslak belge eksik, çelişkili, geçersiz, çakışan ve belirsiz gereksinimler içerebilir.

Gereksinimlerin resmileştirilmesi: Sistem gereksinimleri, temel paydaşlarla paylaşmak amacıyla resmî olarak belgelendirilir. Bu belge (gereksinim tanımları belgesi), sistem sahipleri ile sistem geliştirme ekibi arasında, yeni sistemde nelerin olacağı konusunu içeren bir kontrat olarak kullanılır. Sistem modelindeki hataları, yazım veya dil bilgisi hatalarını ve çelişen gereksinimleri düzeltmek için son taslak üzerinde gereksinim onaylama işlemi yapılmalıdır.

Gereksinimlerin Yönetimi

Projenin yaşam çevrimi içinde yeni gereksinimler ortaya çıkabilir veya gereksinimlerde değişiklik yapılması gerekebilir. Bazı çalışmalar, sistem üretime başlamadan önce belirlenen gereksinimlerin %50 veya daha fazlasının değiştiğini ortaya koymuştur. Değişimin getireceği problemleri haffiletmek için gereksinimlerin yönetimi süreci kullanılmalıdır.

Gerçekleri Belirleme Teknikleri

Bu bölüm 7 grup altında ele alınabilir.

Mevcut Belge, Form ve Dosyaların Örneklenmesi

Bilgi sisteminin kullanılacağı işletme hakkında bilgi edinmek için bakılabilecek ilk belge organizasyon şemasıdır. Organizasyon şeması, projenin sahipleri ve kullanıcıları arasındaki ilişkileri tanımlamakta faydalı olur. Analist aynı zamanda projenin geçmişini de öğrenmek isteyecektir. Bu aşamada ofis içi yazışmalar, muhasebe kayıtları, performans ve çalışma özetleri faydalı olacaktır. önceki sistem analistleri ve danışmanları tarafından yapılan sistem çalışmaları ve tasarımları hakkındaki belgeler de kontrol edilmelidir. Toplanan tüm belgeler güncel olup olmadığı konusunda analiz edilmelidir. Toplanan bilgileri onaylamak veya güncellemek için gerekli olabileceklerinden eski tarihli belgeler de gözardı edilmemelidir.

Her formu, bir dosyadaki veya veritabanındaki her kaydı incelemek pratik olmadığı için, analist örnekleme tekniklerini kullanarak sistemde olan bitenleri anlamak üzere yeterli sayıda veriyi inceler. Örnek sayısının tüm kayıt ya da belgeleri temsil edip etmediği, istatistiksel örnekleme tekniklerini kullanarak belirlenebilir.

Araştırma ve Yerinde Ziyaret

Bu nedenle kabul edildiği takdirde, benzer problemi çözen işletmeyi yerinde ziyaret ederek çözümleri konusunda bilgi alınabilir. Bu şekilde kazanılan bilgi, bilgi sisteminin geliştirme süresi ve maliyetinde büyük oranda düşüş sağlayacaktır.

İş Ortamının gözlemlenmesi

Sistem analisti gözlem yaparak gerçekleri nasıl tespit edebilir? Doğrudan gözlem bölgesine gidip gördüklerini kayıt altına almalı mıdır? Bu sorunun cevabı “hayır” olacaktır. İş ortamının gözlemlenmesinden önce birçok hazırlık yapılmalıdır. Analist gözlemlerini normal iş yükü koşullarında yapmalı, daha sonra yoğun zamanda da gözlem yaparak iş hacmindeki artışın etkilerini ölçmelidir.

İyi bir gözlem de gözlem sırasında sessiz kalınmalı, gözlem için uygun şef veya yöneticilerden izin alınmalı, kimlerin hangi amaçla gözlemleneceği bildirilmelidir.

Anketler

Anketler aracılığıyla çok sayıda kişiden veri toplanabilir. Avantaj ve dezavantajları dikkate alınmalıdır. Anketlerin hızlı cevaplanması, Göreceli ucuz olarak çok sayıda kişiden veri toplama tekniği olması avantajlar iken sistem analistinin anketi cevaplayan kişinin vücut dilini görmesi ve analiz etmesinin mümkün olmaması, iyi anket hazırlamanın zor olması anketlerin dezavantajı olarak öne çıkmaktadır. Serbest format anketi ve sabit format anketi olmak üzere iki tip anket bulunmaktadır.

Serbest format anketleri kullanıcıya soruları cevaplamakta daha fazla serbestlik verir. Sabit formatlı anketler kullanıcının önceden hazırlanmış cevap şıkları arasından seçim yapmasına izin verir. Bu, sonuçların daha kolay tablo hâline getirilmesini sağlar. Ancak anketi cevaplayandan faydalı olabilecek ilave bilgilerin elde edilmesini sağlayamaz.

Anket hazırlanırken; Toplanmak istenen gerçekler ve fikirlere bağlı olarak en iyi cevapları üretecek serbest veya sabit formatlı anket kararı verilir. Sorular, az sayıda cevaplayana uygulanır. Bu cevaplayanların sorularla ilgili problemi olursa sorular düzeltilir.

Mülakatlar

Kişisel mülakatlar en önemli ve en çok başvurulan gerçekleri tespit etme tekniğidir. Mülakatlar, doğrudan ve yüz yüze temasla gerçeklerin bulunması, onaylanması, anlaşılması, gereksinimlerin belirlenmesi, fikir ve önerilerin sorulması amacıyla gerçekleştirilir. Bir mülakatta iki rol bulunmaktadır. Sistem analisti, mülakatı düzenlemekten ve gerçekleştirmekten sorumlu olan mülakat yapan rolündedir. Sistem kullanıcısı veya sahibi ise sorulan bir dizi soruya cevap veren mülakat veren kişidir. Mülakatta birden fazla mülakat yapan ve/veya mülakat veren kişi olabilir.

Mülakat, mülakat verenin soruları açık ve serbest şekilde cevaplamasına ve Mülakatlar, sistem analistinin soruları kişiye göre değiştirmesine izin verir iken Mülakatın başarısı, mülakat yapanın insan ilişkileri yeteneğine bağlıdır . Yapısal ve yapısal olmayan olmak üzere iki çeşit mülakat vardır. Y

apısal olmayan mülakatta konuşmayı mülakat verenin yönlendirmesine izin verilir. Bu tür mülakatta “Toplanamayan alacaklar raporunu neden beğenmiyorsun?” gibi açık uçlu sorular sorulur. Bazen konuşmalar yörüngesinden çıkabilir, bu durumda sistem analistinin müdahale ederek mülakatı ana hedefe ve konuya yönlendirmesi gerekir. Yapısal mülakatlarda kısa ve doğrudan cevap alınması beklenen kapalı uçlu sorular sorulur. Üçüncü tip soru şekli soruşturma sorusudur. En kuvvetli ve basit soruşturma sorusu “Neden?” dir. Bir başka soruşturma sorusu örneği “Çevrimiçi fatura ödeme sisteminizde karşılaştığınız güvenlik problemlerini örnekler vererek açıklar mısınız?” olabilir. Soruşturma sorusunun amacı daha fazla bilgi edinmek için başlangıç cevabının ötesine geçmektir. Bu sorular açık uçlu veya kapalı uçlu olabilir. Soruların sıralanmasında tümevarım ve tümdengelim biçiminde iki yol izlenebilir. Tümevarım sıralama, piramit yapıda düşünülebilir. Buna göre önce ayrıntılı ve kapalı sorularla başlanır, sonra daha genel cevapların alındığı açık uçlu sorulara yer verilir. Piramit yapısı mülakat vereni konuya ısındırmak amacıyla kullanılabilir. Tümdengelim yaklaşımında ise açık uçlu, genel cevaplı sorularla başlayıp kapalı sorularla devam edilir.

Prototipleme

Prototipleme genelde bir tasarım tekniğidir, ancak bu yaklaşım sistem geliştirme yaşam döngüsünün ilk dönemlerinde gerçeklerin bulunması ve gereksinimlerin analizi amacıyla da kullanılabilir. Prototipin hızla geliştirilmesi, daha sonra geliştirme fazında kullanılabilmesi açısından önemlidir. Genelde sadece gereksinimlerin belirlenemediği alanlarda prototipleme yapılır, bu nedenle birçok istenen işlev ve kalite garantisi ihmal edilebilir. Prototiplemede performans ve güvenilirlik gibi işlevsel olmayan gereksinimlere son ürüne göre daha az önem verilir.

Bu tekniğin bazı avantajları:

• Yüksek geliştirme masra arı oluşmadan sistemin yapılabilirliğinin ve faydasının anlaşılmasına yardımcı olur.
• Sistemin test sürecinde kullanılacak test planları ve senaryolarının geliştirilmesine yardımcı olur.
• Gerçekleri bulma sürecini kısaltabilir, daha kararlı ve güvenilir gereksinimlerin tanımlanmasına yardımcı olur.

Bu tekniğin bazı dezavantajları:

• Kullanıcılar prototipin performansı, güvenilirliği ve özelliklerine bakarak gerçekçi olmayan gereksinimler geliştirebilir. Prototipler sadece sistemin işlevselliğini taklit eder ve doğal olarak tam değildir. Kullanıcılar bu konuda eğitilmeli ve yanlış yön- lenmeleri önlenmelidir.
• Prototip yapımı sistem geliştirme sürecini uzatabilir ve geliştirme maliyetlerini arttırabilir.

Ortak gereksinim planlaması

Birçok işletme ayrı ve sayısız mülakatlar yerine grup çalışma oturumlarını kullanmaktadır. Grup çalışma oturumu uygulamalarının bir örneği de ortak gereksinim planlamasıdır. Bu teknik geniş bir aralıkta katılımcı ve rol gerektirir. Her katılımcının tüm oturumlara katılımı ve aktif olması beklenir.

Sponsor

Genelde işletmenin üst yönetimindeki bir kişidir. Sistem projelerindeki tüm bölümleri ve kullanıcıları bilen birisidir. Sponsor, muhtemel kullanıcıların oturumlara isteyerek ve aktif katılımlarını teşvik ederek projeye destek verir. Sponsor, projenin devam edip etmeyeceğine karar veren kişidir.

Kolaylaştırıcı

Toplantılarda lider veya kolaylaştırıcı rolünü üstlenen bir kişi olmalıdır. Kolaylaştırıcı, bir sistem projesi için yapılan tüm toplantıları yönlendirir. Kolaylaştırıcı, çok iyi iletişim kurabilen, pazarlık yapabilen ve grup çatışmalarını çözebilen biri olmalıdır. Kolaylaştırıcının görevi, toplantıyı planlamak, toplantıyı yönetmek ve sonuçlarını takip etmektir. Toplantı sırasında tartışmayı yönetir ve katılımcıların aktif olmasını teşvik eder. Çıkan çatışmaları çözümlemekten ve toplantının amaç ve hede erinin gerçekleşmesini garanti etmekten sorumludur.

Kullanıcı ve Yöneticiler

Kullanıcıların toplantıdaki rolü, iş kuralları ve gereksinimlerini etkili olarak anlatmak, prototip tasarımları gözden geçirmek ve kabul kararı vermektir. Yöneticilerin görevi ise proje hede erini onaylamak, proje önceliklerini belirlemek, maliyet ve süreleri onaylamak ve belirlenen eğitim ihtiyaçları ve uygulama planlarını onaylamaktır.

Yazıcılar

Toplantıda tartışılan her konuyla ilgili kayıtları tutan kişilerdir. Tutulan kayıtlar, toplantıdan hemen sonra basılmalı ve katılımcılara dağıtılmalıdır. Yazıcılar, sistem analizi ve tasarımında CASE araçlarını kullanma kabiliyetine sahip olmalıdır.

Bilgi teknolojileri çalışanları

Genelde bilgi teknolojileri per-soneli soru sorulmadıkça konuşmaz, modellerin ve gerçeklerle ilgili diğer belgelerin geliştirilmesi için yazıcılarla çalışırlar. Gerekirse bazı teknik konularda kolaylaştırıcı bir bilgi teknolojileri uzmanına söz verilebilir.

Toplantı Hazırlıkları ve Yürütülmesi

Çoğu ortak gereksinim planlama toplantısı üç ila beş gün, bazı durumlarda iki hafta kadar sürebilir. Toplantı tarihinden çok önce toplantı planı yapılmalıdır. Sistem analisti, sponsor ile çalışarak toplantının çerçevesini belirler. Aynı zamanda toplantının yüksek düzeyli gereksinimleri ve beklentileri belirlenmelidir. Bu amaçla, sistem projesinde çalışacak bölümlerden veya projenin gerçekleştireceği fonksiyonlardan sorumlu seçilmiş kişilerle mülakatlar yapılır. Planlama sırasında yer, katılımcılar ve toplantının gündemi belirlenir. Toplantılar için farklı büyüklükte odalar gerekir.

Kolaylaştırıcı, toplantıların hede eri ve içeriği konusunda katılımcıları bilgilendirmek üzere belgeler hazırlamalıdır. Gündem üç parçadan oluşturulur: giriş, gövde ve sonuç. Girişte toplantılardan beklentiler, uygulanacak kurallar ve katılımcıları motive edecek cümleler olmalıdır. Gövde, toplantılarda konuşulacak konuları detaylandırmak amacıyla yazılır. Sonuçta ise günlük toplantının özeti ve çözülemeyen konuların katılımcılara hatırlatılması yapılır.Ortak gereksinim planlama toplantısının amacı bir problemi çözmek için muhtemel fikirlerin ortaya çıkarılmasıdır. Bunun için izlenecek yollardan biri beyin fırtınasıdır. Beyin fırtınasında, söylenenlerin geçerliliğini onaylamak için, analiz etmeden katılımcılar tarafından mümkün olduğu kadar çok fikir ortaya atılması sağlanır. Beyin fırtınası durumunda;

Katılımcıların rahatsız edilmeyeceği ve kesintisiz çalışabileceği bir ortam hazırlanmalıdır.

Katılımcılardan biri fikirleri kayıt altına almak üzere görevlendirilmelidir. Kayıt altına alınan fikirlerin herkes tarafından görülebilmesi için büyük yazı kâğıtları, tahta veya projeksiyon cihazı kullanılmalıdır.

Fikirler üretilirken hiçbir şekilde eleştirilmemeli, analiz edilmemeli ve değerlendirilmemelidir. Bir fikir ancak bir başka fikri tetiklerse faydalıdır.

Grubun yeni fikir üretemediği durumda beyin fırtınası durdurulur ve tüm fikirler kayıt altına alınır. Daha sonra fikirler analiz edilmeli ve değerlendirilmelidir.

Gerçekleri Bulma Etiği

Gerçekleri bulma sürecinde sistem analisti çok hassas bir bilgiyle karşılaşabilir veya bilgiyi analiz etmesi gerekebilir. Örneğin işletmenin bir ihalede vereceği teklifin yapısını, çalışanların ücretini, performans ve medikal geçmişini ve kariyer planlarını içeren bilgileri görebilir. Analist bu tür bilgilerin güvenlik ve gizliliğini korumak konusunda çok dikkatli davranmalıdır. Hassas bir bilginin yanlış ellere geçmesi hâlinde sistem analisti, kullanıcılar ve yönetimin gözünde saygı ve güvenilirlik kaybına uğrar.