ANKARA ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ YÜKSEK LİSANS TEZİ DOĞAL DİLDE YAZILMIŞ YAZILIM GEREKSİNİMLERİNİN KALİTELERİNİN DİLBİLİMSEL ANALİZ TEKNİKLERİYLE ARTTIRILMASI İbrahim Berk YILMAZ ELEKTRONİK MÜHENDİSLİĞİ ANABİLİM DALI ANKARA 2010 Her hakkı saklıdır

İbrahim Berk YILMAZ tarafından hazırlanan Doğal Dilde Yazılmış Yazılım Gereksinimlerinin Kalitelerinin Dilbilimsel Analiz Teknikleriyle Arttırılması adlı tez çalışması aşağıdaki jüri tarafından oy birliği ile Ankara Üniversitesi Fen Bilimleri Enstitüsü Elektronik Mühendisliği Anabilim Dalı nda YÜKSEK LİSANS TEZİ olarak kabul edilmiştir. Danışman : Yrd. Doç. Dr. Asım Egemen YILMAZ Jüri Üyeleri : Doç. Dr. Onur Demirörs Ortadoğu Teknik Üniversitesi Enformatik Enstitüsü Yrd. Doç. Dr. Murat Efe Ankara Üniversitesi Elektronik Mühendisliği Bölümü Yrd. Doç. Dr. Asım Egemen Yılmaz Ankara Üniversitesi Elektronik Mühendisliği Bölümü Yukarıdaki sonucu onaylarım. Prof. Dr.Orhan ATAKOL Enstitü Müdürü

ÖZET Yüksek Lisans Tezi DOĞAL DİLDE YAZILMIŞ YAZILIM GEREKSİNİMLERİNİN KALİTELERİNİN DİLBİLİMSEL ANALİZ TEKNİKLERİYLE ARTTIRILMASI İbrahim Berk YILMAZ Ankara Üniversitesi Fen Bilimleri Enstitüsü Elektronik Mühendisliği Anabilim Dalı Danışman: Yrd. Doç. Dr. Asım Egemen Yılmaz Günümüzde geliştirilen yazılım ürünlerindeki hataların %85 i başlangıçta yanlış tanımlanmış gereksinimlerden kaynaklanmaktadır. Bu kapsamda, Yazılım Gereksinim Mühendisliği faaliyetlerinde, tanımlanan isterlerin belirli bir kaliteye, doğruluğa ve tutarlılığa sahip olması, neticede ortaya çıkacak yazılım ürününün olgunluğu için vazgeçilmezdir. Bu bağlamda, bütün bu faaliyetleri yerine getirmeyi amaçlayan bir Gereksinim Kalite Yönetimi, daha etkin sonuçlar elde edebilmek için insan muhakemesini ve değerlendirmesini destekleyecek bir takım yardımcı yaklaşımlara ve bu yaklaşımlar neticesinde yapılacak bir gereksinim analizi de bu işlemi kolaylaştırıcı araçlara ihtiyaç duymaktadır. Bu doğrultuda bu çalışmada, doğal dilde yazılmış gereksinimlerin kalitesini arttırmaya yönelik üç aşamalı bir yaklaşım ve bu yaklaşım uyarınca gereksinim analizi yapan bir yazılım aracı geliştirilmiştir. Yaklaşımın birinci aşaması gereksinimlerdeki tutarsızlıkların, muğlaklıkların tespit edilmesini, ikinci aşaması gereksinimlerin işlevlerine göre sınıflandırılmasını ve üçüncü aşaması ise benzer gereksinimlerin tespit edilerek tekrarların ve çelişkilerin önüne geçilmesini içermektedir. Bu faaliyetleri desteklemek üzere geliştirilen yazılım aracı da üç temel fonksiyonu yerine getirmektedir. Bunlar, birinci olarak dilbilgisel analiz temelinde sözlüksel analiz yöntemleri kullanılarak hatalı ve muğlak gereksinimlerin tespit edilmesi, ikinci olarak sözlüksel analiz teknikleriyle işlevsel olan ve işlevsel olmayan gereksinimlerin tespit edilmesi ve işlevsel olmayan gereksinimlerin konularına göre sınıflandırılması ve üçüncü olarak, benzer gereksinimlerde, ihtiyaçları anlatmak üzere yazılmış tekrar edilen gereksinimlerin elenmesi ve çelişen benzer gereksinimlerin düzeltilmesi amacıyla benzer gereksinimlerin dilbilgisel ve anlambilimsel tekniklere başvurmadan istatistiksel metin analizi yöntemleriyle tespitidir. Yazılım, çalışma kapsamında Türkçe hazırlanmış bir gereksinim kümesi üzerinde denenerek başarılı sonuçlar alınmış ve bu sonuçlar yorumlanmıştır. Mart 2010, 67 sayfa Anahtar Kelimeler: Gereksinim Analizi, Benzerlik Analizi, İşlevsel Olmayan Gereksinimler, Doğal Dilde Yazılmış Gereksinimler, Gereksinim Kalite Yönetimi, Sözlüksel Metin Analizi i

ABSTRACT Master Thesis QUALITY IMPROVEMENT OF THE SOFTWARE REQUIREMENTS WRITTEN IN NATURAL LANGUAGE BY MEANS OF LINGUISTIC ANALYSIS TECHNIQUES İbrahim Berk YILMAZ Ankara University Graduate School of Natural and Applied Sciences Department of Electronic Engineering Supervisor: Asst. Prof. Dr. Asım Egemen Yılmaz In the recently developed software products, 85% of the defects are caused by the requirements defined at the beginning of the work. Hence, in the Software Requirement Engineering activities, it is indispensible to have a degree of quality, completeness and consistency for the maturity of all requirements. As a result, a Requirement Quality Management activity adressing these goals, needs some new approaches and tools, which will support human cognition and evaluation to get better results. For this purpose, in this study, a three-phase approach and a new software tool related with this approach is developed to improve the quality of the requirements written in natural language. In the first step of this approach, detection requirement defects due to inconsistencies and vaguenesses, in the second step the classification of the requirements according to functionality, and in the third and final step detection of the similar requirements to overcome redundancies and contradictions, are suggested. The software tool which is developed to support this approach, also has three basic functions: First, detection of the defective and vague requirements using linguistic lexical analysis techniques. Second, detection and classification of the non-functional requirements using linguistic lexical analysis techniques. Third, detection of the similar or identical requirements applying similarity analysis to eliminate the redundancy and contradictions in a requirement set using statistical similarity analysis approach. The new developed software tool is applied on the requirement sets written in Turkish natural language and successful results are obtained and evaluated in the scope of this study. March 2010, 67 pages Key Words: Requirement Analysis, Similarity Analysis, Non-Functional Requirements, Requirements Written in Natural Language, Requirement Quality Management, Lexical Text Analysis ii

TEŞEKKÜR Bu tez çalışmasının hazırlanması sırasında, bilgi ve tecrübesiyle bana her konuda yardımcı olan, değerli danışmanım Yrd. Doç. Dr. Asım Egemen YILMAZ a (Ankara Üniversitesi Elektronik Mühendisliği Anabilim Dalı), çalışmalar sırasında bana desteğini esirgemeyen değerli mesai arkadaşım Alpaslan TÜRKBOYLARI na, anne ve babama, ve kardeşlerim Burak ve Nur a sonsuz teşekkür ederim. İbrahim Berk YILMAZ Ankara, Mart 2010 iii

İÇİNDEKİLER ÖZET... i ABSTRACT... ii TEŞEKKÜR... iii SİMGELER DİZİNİ... v ŞEKİLLER DİZİNİ... vi ÇİZELGELER DİZİNİ... vii 1. GİRİŞ... 1 1.1 IT Proje Performansını Etkileyen Problemlerin Tespiti... 1 1.2 Yazılım Gereksinim Kalite Yönetimi... 4 2. KURAMSAL TEMELLER... 8 2.1 Doğal Dilde Hazırlanmış Gereksinim Metinlerinin Yapıları... 8 2.2 Gereksinim Kalite Öznitelikleri... 11 2.3 Gereksinim Hata Tipleri... 12 2.4 Gereksinim Hata Tipleri-Kalite Öznitelikleri İlişkileri... 14 2.5 Gereksinim Hatalarının Tespit Edilmesine Yönelik Yapılmış Çalışmalar... 15 2.5.1 Dilbilimsel analizler yaparak hatalı veya arızalı gereksinimleri belirlenmesine yönelik araçlar... 16 2.5.1.1 ARM (Automated Requirements Measurement) yazılımı... 17 2.5.1.2 QuARS (Quality Analyzer for Requirements Specifications) yazılımı... 17 2.5.1.3 RAST (Requirement Analysis Support Tool) yazılımı... 19 2.5.1.4 Tiger PRO yazılımı... 19 2.5.1.5 Türkçe için Kızılca ve Yılmaz (2008) tarafından yapılan çalışma... 20 2.5.2 Aynı veya benzer gereksinimlerin tespitine yönelik araçlar... 21 2.5.3 Gereksinimlerin türlerine ve alt türlerine ayrılarak sınıflandırılmasına yönelik araçlar... 23 3. MATERYAL VE YÖNTEM... 28 3.1 Materyal... 28 3.2 Yöntem... 29 3.2.1 Yazılımın fonksiyon ve kabiliyetleri:... 30 3.2.1.1 Yazılımın girdileri... 31 3.2.1.2 Muğlaklık hata tiplerinin analizi... 33 3.2.1.3 İşlevsellik analizi... 36 3.2.1.4 Benzerlik analizi... 38 4. ARAŞTIRMA BULGULARI VE TARTIŞMA... 45 5. SONUÇ... 49 5.1 Çalışmanın Kısıtları ve Geleceğe Yönelik Çalışma Önerisi... 50 EKLER... 58 EK 1 Literatürde İşlevsel Olmayan Gereksinim Türleri (Chung vd. 2000)... 59 EK 2 Hata Tipi Sözlükleri... 60 EK 3 İOG Alt Türü Sözlükleri... 61 EK 4 Türkçe Durak Kelimeler (Turkish Stopwords)... 63 EK 5 İngilizce Durak Kelimeler (English Stopwords)... 64 EK 6 Contract Weakness Analyser v1.0 Yazılımı (CD içeriğinde)... 67 ÖZGEÇMİŞ... 68 iv

SİMGELER DİZİNİ ARM İOG QuARS RAST TDK UML XML Automated Requirements Measurement İşlevsel Olmayan Gereksinimler Quality Analyzer for Requirements Specifications Requirement Analysis Support Tool Türk Dil Kurumu Unified Modeling Language Extensible Markup Language v

ŞEKİLLER DİZİNİ Şekil 1.1 Gereksinim Kalite Yönetimi Süreci... 5 Şekil 3.1 Yazılım Ana Sayfasının Örnek Görüntüsü... 32 Şekil 3.2 Dosya Seçim Menüsü... 32 Şekil 3.3 Örnek Şartname Dosyası... 33 Şekil 3.4 Örnek Hata Tipi Sözlüğü... 34 Şekil 3.5 Analiz sonucunda oluşan Analysis-Result.txt ve SRS.txt dosyaları... 35 Şekil 3.6 Dictionaries.txt dosyasında yer alan ve Hata Tipi analizinde kullanılacak sözlükler... 36 Şekil 3.7 Örnek İOG Alt Türü Sözlüğü... 39 Şekil 3.8 Dictionaries.txt dosyasında yer alan İOG Alt Türü Sözlükleri... 39 Şekil 3.9 İOG Alt Türü Analizi için Örnek Sonuç Ekranları... 40 Şekil 3.10 Otomatik benzerlik analizi algoritmasının gösterimi... 41 Şekil 3.11 % 75 eşik seviyesi için benzerlik katsayılarına göre yazılım çıktısı..44 Şekil 3.12 %65 eşik değeri için oluşturulan örnek Similarity_Results.txt dosyası...44 vi

ÇİZELGELER DİZİNİ Çizelge 1.1 Hatanın bulunduğu faz ile düzeltme maliyeti arasındaki ilişki... 3 Çizelge 2.1 DOD MIL-STD-490A ve IEEE Std 830-1993 a göre Kalite Öznitelikleri. 12 Çizelge 2.2 Gereksinim Hata Tipleri... 13 Çizelge 2.3 Gereksinim Hata Tipleri ve Bu Hatalar Dolayısıyla Etkilenen Kalite Öznitelikleri 14 Çizelge 2.4 Gereksinim Hata Tiplerine İlave Olarak Yapılan Hatalar ve Bu Hatalar Dolayısıyla Etkilenen Kalite Öznitelikleri.14 Çizelge 2.5 Hata Tipi Analizi Yapan Yazılımlar ve Kullandıkları Analiz Yöntemleri. 20 Çizelge 2.6 ISO 9126 dan Çıkarılan İşlevsel Olmayan Gereksinim Türleri... 26 Çizelge 4.1 İhtimal Tablosuna göre Değerlendirme Referansları (Natt och Dag vd., 2001) 46 Çizelge 4.2 İhtimal Tablosuna göre Değerlendirme 48 vii

1. GİRİŞ İleri Teknoloji Projeler ekonomik büyüme için vazgeçilmezdir. Örneğin, günümüzde dünyada parasal yatırımların önemli bir kısmı bilişim, elektronik ve haberleşme alanında yapılmaktadır. Bu yatırımlar projeler yoluyla teknolojiyi pratik uygulamalarda kullanarak değer oluşturmaktadır. Ancak, Standish Group tarafından Amerika Birleşik Devletlerinde yapılan bir araştırmaya göre ise yine ileri teknoloji IT alanındaki projelerin %28 i ve haberleşme alanındaki projelerin %25 i başarılı sonlanmakta diğer %75 i ise zaman ve bütçe aşımına uğramaktadır. Ayrıca, bu projelerin %53 ü teknik gereksinim dokümanındaki fonksiyonalitelerin yalnızca %60 ını karşılayabilmektedir (Biggs 2000). Yine bu alanda yürütülen benzer bir araştırmada, 2003 yılında İngiltere de ileri teknoloji içeren bilişim alanında 421 Proje incelenerek performansları değerlendirildiğinde, projelerin %9 u başarısızlıkla sonuçlanmış, %23 ü süresinde tamamlanamamış, %18 i bütçeyi aşmış, %7 si amaç ve hedeflerinin tamamına ulaşamamış, ancak %16 sı başarıyla tamamlanabilmiştir. Bu çalışmanın en anlamlı sonuçlarından birisi de başarısız olan projelerin %75 inde temel etkenin anlaşılamayan gereksinimler olmasıdır (Sauer ve Cuthbertson 2003). Şüphesiz ki bu sonuçlar proje performanslarının ve sonuç olarak projelerin başarılarının yükseltilmesi ve iyileştirilmesi için problemlerin kaynağının tespit edilmesine yönelik çalışmalar yapılmasını ve bu problemleri giderici yöntemler geliştirilmesini zorunlu kılmaktadır. 1.1 IT Proje Performansını Etkileyen Problemlerin Tespiti Sauer ve Cuthbertson (2003) tarafından İngiltere de 421 projede görev alan 1500 proje yöneticisinin katılımıyla gerçekleşen ve sonuçları yukarıda verilen anket çalışmasının verilerine göre sık karşılaşılan 21 adet proje riskinin proje başarısını etkilemedeki 1

etkinlik ve önem sırası incelenmiş, ve sonuçta Üst Yönetimin Projeye Destek Vermemesi nin ardından en etkili ikinci risk olarak Kapsam, Amaç ve İsterlerin Anlaşılamaması tespit edilmiştir. Buradan çıkan sonuç, sağlıklı bir IT projesi için kapsam, amaç ve isterlerin projenin başında tüm taraflarca anlaşılacak şekilde düzgün tanımlanması, kurumsal problemlerin dışında en etkin faktördür. Projelerin başlangıcında hazırlanan ve projenin amacını, kapsamını ve isterlerini tanımlayan doküman Proje Gereksinimleri Dokümanı dır. Gereksinim belirli bir alandaki ihtiyaç hakkında bilgi taşıyan ifade veya metnin adıdır. Young (2001) tarafından yürütülen bir başka çalışmanın sonucuna göre belirli bir proje kapsamında geliştirilmiş yazılım ürünlerindeki hataların %85 i başlangıçta yanlış tanımlanmış gereksinimlerden kaynaklanmaktadır. Burada gereksinimlerde ne tür hatalar yapıldığının tespit edilmesi önem kazanmaktadır. Hooks (1993) a göre gereksinimlerin yazılmasında sıklıkla görülen problemler aşağıdaki gibi sıralanmıştır: Kötü varsayımlar yapılması Gereksinimden (ne yapılacağı) ziyade uygulamaların (nasıl yapılacağı) belirtilmesi Gereksinimlerden ziyade faaliyetlerin açıklanması Yanlış terimlerin kullanılması Yanlış cümle yapısı ve kötü gramer kullanılması Gereksinimlerin eksik tanımlanması Maksadı aşma Yine Hooks ve Kristin (2001) in çalışmalarının sonuçlarına göre gereksinim hatalarının; %49 u yanlış bir takım varsayımlar ve gereksinimlerin yanlış yazılmasından; 2

%29 u gereksinimlerin unutulmuş veya atlanmış olmasından; %13 ü yazılan gereksinimlerin birbiriyle çelişiyor veya tutarsız olmasından; %5 i ise gereksinimlerin farklı yorumlanabilir, muğlâk ifadelerle yazılmış olmasından kaynaklanmaktadır. Bu aşamada, gereksinimlerin yanlış yazılması ya da eksik yazılması/atlanması daha ziyade gereksinimin içeriği ile ilgili olduğundan insan muhakemesi ile düzeltilmelidir. Ancak gereksinimlerdeki çelişkiler ve muğlaklıklar gereksinimlerin kalitesini artırmaya yönelik birtakım araçlar kullanılarak düzeltilebilmektedir. Boehm (1981) ün çalışmasına göre gereksinim ve tasarım aşamasında fark edilen hataların, gelecekteki olası düzeltme faaliyetlerini %40-50 oranında azalttığını ve yine Boehm (2001) ün sonuçlarına göre hataların ileri geliştirme evrelerinde tespit edilmesinin hata düzeltme maliyetlerini 5 katına çıkarttığı, sistemin sahadaki kullanımı esnasında tespit edilmesinin ise bu maliyetlerin zaman zaman 100 katına kadar çıkabildiği tespit edilmiş ve bu veriler doğrultusunda Gause ve Weinberg (1989) tarafından düzenlenen ve çizelge 1.1 de sunulan Göreceli Düzeltme Maliyetleri sıralanmıştır. Çizelge 1.1 Hatanın bulunduğu faz ile düzeltme maliyeti arasındaki ilişki (Gause ve Weinberg 1989) Hatanın Bulunduğu Faz Göreceli Düzeltme Maliyeti Gereksinim Analizi 1 Tasarım 3-6 Kodlama ve Birim Testi 10 Geliştirme Testi 15-40 Kabul Testi 30-70 İşletim 40-1000 Dolayısıyla, projelerin ilerleyen aşamalarında büyük sıkıntılar yaşamamak için herhangi bir yazılım projesinde daha başından itibaren bütün gereksinimlerin, ilerideki bölümlerde açıklanacak olan kalite kriterlerini sağladıklarının doğrulanması amacıyla mutlaka gözden geçirilmesi gerekmektedir. 3

1.2 Yazılım Gereksinim Kalite Yönetimi Yazılım projelerinde ihtiyaçları tanımlamak ve projenin temelinin oluşturmak amacıyla oluşturulan yazılım gereksinimlerinin ifade edilmesinde; genelde okuyucu kitlesinin geniş tutulabilmesi amacıyla doğal dil kullanılmakta, ancak söz konusu ifadelerde çoğu zaman bir takım hatalar yapılmaktadır. Bu kapsamda, ihtiyaçların açık olarak tanımlanmaması, gerekli performans kriterlerinin açıklanmaması, ucu açık ihtiyaçlar belirtilmesi ve bir ihtiyaç belirlenirken bunun ölçümü ile ilgili kıstasların tanımlanmaması gibi yapılan dilbilgisel hatalar, projenin ilerleyen safhalarında maliyetin artması, proje takviminin uzaması ve mevcut iş gücünün yetersiz kalması gibi olumsuzluklar doğurmaktadır. Proje yönetiminde yaşanan bu olumsuzlukları giderebilmek ve kaynakların etkin kullanımını sağlamak amacıyla, yazılım gereksinimlerinin yazılmasında yapılan hataları ayıklayacak araçların geliştirilmesine duyulan ihtiyaç artmaktadır. Bu aşamada, yazılım gereksinimlerinin kalitesini sağlamak için DOD MIL-STD-490A (1985), IEEE Std 830-1993 (1993) ve ISO 9126 (1991) gibi yazılım gereksinim kalite standartları geliştirilmiştir. Bu standartların kapsam ve detayı Bölüm 2 de açıklanmıştır. Bu anlamda, yazılım projelerindeki gereksinimlerin kontrolü incelenmesi ve iyileştirilmesi faaliyetine Yazılım Gereksinim Kalite Yönetimi denilebilir. Yılmaz ve Kızılca (2009) nın ifade ettiği gibi, Yazılım Gereksinim Kalite Yönetimi işlevsel olan/olmayan bütün gereksinimlerin doğal dilde ifade edilerek yazılmasının ardından öncelikle söz konusu gereksinimlerin dilbilimsel açıdan belirli koşulları sağlayıp sağlamadığının kontrol edilmesini ve gereksinimlerin belirli ölçütlere göre sınıflandırılmasını kapsar. Bu faaliyetlerin devamında, eğer gereksinimler birçok kişinin oluşturduğu teknik ve idari bir topluluk tarafından hazırlanmışsa, muhtemel benzer veya aynı gereksinimlerin ayıklanması için gereksinim kümesini gözden geçirilmesini de içerir. Bu süreçler şekil 1.1 de açıklanmaktadır. Yazılım Gereksinim Kalite Yönetimi, konu ile ilgili uzmanların ya da Gereksinim Dokümanı nı hazırlayan Gereksinim Mühendisleri tarafından gereksinimlerin yukarıda 4

ana hatları belirtilen kriterleri sağlayıp sağlamadığının değerlendirilmesidir. Bu değerlendirme herhangi bir araç kullanılmadan, dokümanın hazırlandıktan sonra alınıp incelenmesi şeklinde insan muhakemesi ile yapılabileceği gibi, bu amaca yönelik hazırlanmış veya hazırlanacak bir takım vasıtalar veya yazılımlarla da yapılabilir. Aday Gereksinim Dilbilgisel Olgunluk Analizi Kullanıcı Geribeslemesi İşlevsellik Analizi ve Önceliklendirme Analizi Benzerlik Analizi Hazır Gereksinim Kümesi Tasarım Modeline Geçiş Şekil 1.1 Gereksinim kalite yönetimi süreci (Yılmaz ve Yılmaz 2010) Birinci durumda, projenin önemli kaynaklarından Yazılım Sistem Mühendislerini oldukça külfetli bir işte ve daha projenin başında işba edilmektedir. Ayrıca Kızılca ve Yılmaz (2008) ın ifadesiyle zaten teknik ekipler tarafından bürokratik ve sıkıcı, yöneticiler tarafından ise projenin erken evresinde paydaşlar arasında problem çıkarabilecek ve iyi ilişkileri bozabilecek potansiyel bir tehlike olarak değerlendirilen bu gözden geçirme işlemi, çoğunlukla geliştirme takvimlerinin sıkışıklığı mazeret gösterilerek ihmal veya iptal edilmektedir. Bu durumda, yukarıda önemini ve yapılmaması halinde risklerini belirttiğimiz önemli bir kalite yaklaşımı ihmal edilmektedir. Yazılım Gereksinim Kalite Yönetimi için bir vasıta veya yazılım kullanılmasını içeren ikinci durumda ise, gereksinim olabilecek her türlü, doküman, ses kaydı, standart, toplantı notu vb. doküman ve kaynağın öncelikle üzerinde teknik araçlarla analiz yapılabilecek bir metin haline getirilmesi ve bu metin üzerinde Yazılım Gereksinim Kalite Yönetimi yaklaşımıyla kullanıcılara geri besleme ve öneri sağlayarak uygun olmayan gereksinimlerin daha baştan düzeltilmesi sağlanabilmektedir. 5

Bu amaçla, İngilizce de çeşitli seviyede dilbilimsel analizler yaparak gereksinim kalitesini artırmaya yönelik Wilson vd. (1997) tarafından geliştirilmiş olan ARM, Noh ve Gadia (2003) tarafından geliştirilmiş olan RAST, Fantechi vd. (1994) ve Lami (2005) tarafından geliştirilmiş olan QuARS ve Kasser (2002) tarafından geliştirilmiş olan Tiger PRO gibi yazılımları ortaya çıkmıştır. Bu yazılımlarla ilgili açıklamalar ve kısa bilgiler ikinci bölümde verilmiştir. Ancak Türkçe için benzer teknikler kullanarak analizler gerçekleştirebilen yazılımların mevcut olmaması, bu konu üzerine yapılacak bir çalışmanın önemini arttırmaktadır. Bu çalışmada, yazılım projelerinde gereksinimlerin iyi tanımlanmaması neticesinde yaşanan sıkıntıları azaltmaya katkı sağlamayı amaçlayan yeni bir yazılım ve düşünce yaklaşımı anlatılacaktır. Bu yaklaşımın ileri teknoloji içeren elektronik, haberleşme ve savunma alanındaki projelere de uygulanabileceği değerlendirilmektedir. Bu çalışmanın kapsamı ve amacı, doğal dilde yazılmış olan yazılım kümesinin kalitesinin arttırılmasına yardımcı olmak amacıyla dilbilimsel analiz teknikleri ve istatistiksel değerlendirme yaklaşımı uygulayan bir yazılım geliştirilmesi, söz konusu yazılım ile gerçek proje verilerinin incelenmesi ve iyileştirilmesidir. Bu amaçla, metin haline getirilmiş herhangi bir aday gereksinim kümesinden; Sözlüksel analizler yaparak yanlış anlamaya sebep olabilecek muğlak ifade edilmiş, hatalı veya arızalı gereksinimleri belirlenmesi, Birden fazla yazılmış aynı veya benzer gereksinimlerin istatistiksel değerlendirme yaklaşımı kullanılarak tespiti, Gereksinimlerin ileride test aşamasında kolaylık sağlamak amacıyla türlerine (işlevsel olan/olmayan vb.) ve alt türlerine (performans, kalite, güvenlik vb.) ayrılarak sınıflandırılması, Bütün bu işlemler esnasında kullanıcının müdahalesine imkân sağlanması, işlevlerini içeren bir yaklaşım önerilmesi, bu doğrultuda bir yazılımın geliştirilmesi söz konusu yazılım ile gerçek proje verilerinin incelenmesi ve iyileştirilmesi hedeflenmiştir. 6

Bu tez, Giriş, Kaynak Özetleri/Kuramsal Temeller, Materyal ve Yöntem, Araştırma Bulguları ve Tartışma, ve Sonuç ve Gelecek Çalışma Önerileri olmak üzere beş ana bölüme ayrılmaktadır. Konu ve amacı anlatan kısa bir girişin ardından, konuya yönelik Dünya da ve Türkiye de yapılmış benzer çalışmalar ve yaklaşımlar 2 nci bölüm olan Kaynak Özetleri/Kuramsal Temeller de anlatılmaktadır. Materyal ve Yöntem adındaki üçüncü bölümde yukarıda açıklanan yaklaşım ve yazılımın geliştirilmesinde faydalanılan fikir ve yöntemler açıklanmakta, 4 üncü bölüm olan Araştırma Bulguları ve Tartışma kısmında ise geliştirilmiş olan yazılımın gerçek projelere uygulanması neticesinde elde edilen sonuçlar ve bu sonuçların yorumları yer almaktadır. Son bölüm olan Sonuç ve Gelecek Çalışma Önerileri bölümünde ise bu çalışmanın neticesinde tarafımızdan elde edilen sonuçların açıklanması, çalışmada eksik kalan kısımların belirtilmesi ve bu doğrultuda çalışmanın geliştirilmesi için yapılabilecekler anlatılmaktadır. 7

2. KURAMSAL TEMELLER Yazılım projelerinde gereksinim ile ilgili faaliyetlere Gereksinim Mühendisliği denilmektedir. Somerville (1995), Gereksinim Mühendisliği ni bir sistemin sağlaması gereken hizmetlerin ve çalışabileceği koşulların şekillendirilmesi olarak tanımlamıştır. Yazılım Gereksinim Kalite Yönetimi kapsamında gereksinimlerin belirli kalite kriterlerini sağladığının kontrol ve garanti edilmesi de Gereksinim Mühendisliği nin görevlerinden birisidir. Bu bölümde, gereksinimlerin kalitesini değerlendirmedeki yaklaşımlar ve literatürde yer alan gereksinim mühendisliğinin gereksinimlerin kalitelerini ölçme ve kontrol etmede uyguladığı yöntemler ve kullandığı araçlar anlatılmıştır. Çalışmamızda doğal dilde yazılmış gereksinimler üzerine odaklanıldığından; öncelikle metin haline getirilmiş ve yapılandırılmış, doğal dildeki gereksinimlerin yapıları açıklanmıştır. 2.1 Doğal Dilde Hazırlanmış Gereksinim Metinlerinin Yapıları Bir eserin, bir yazının öz ibaresi; ileri sürülen fikri anlatmak için kullanılmış bulunan kelimelerin topluluğuna metin denir (TDK 2010). Metinler, tekrar, kafiye vb. belirli söz sanatlarını veya devrik cümle, mizah gibi ifade tekniklerini içeren edebi metinler, belirli resmi iletişim kurallarına uymayan gayrı resmi metinler ve belirli bir konudaki ihtiyacı ya da amacı ifade eden resmi, sade ve doğrudan metinler olarak gruplanabilir. Sade ve doğrudan metinler hazırlandığı alanla ilgili kişilerin okuduğunda aynı şeyi anlayacakları açıklıkta, resmi dili kullanacak ve amacı veya ihtiyacı doğrudan ifade edecek şekilde yazılmalıdır. Bu kapsamda, bu metinlerin, düzenli ve kısa cümleler kullanma, eşanlamlı sözcüklerden genelde sık kullanılanı tercih etme, imla hatası yapmama, gerektiğinde hukuki, teknik veya idari taslağa uyması için alan disiplinine uygun kelimeler seçme gibi belirli bir yapıda hazırlanması gerekir. Bu çalışmada, bu tür metinler Yapılandırılmış Metinler olarak isimlendirilmiştir. 8

Bu bağlamda herhangi bir yazılımın veya sistemin gereksinimlerini açıklamak amacıyla hazırlanan Gereksinim Dokümanları birer yapılandırılmış metindir. Yazılım veya Sistem gibi somut nesnelerin gereksinimlerini ve özelliklerini tanımlamakta ya gereksinimler arasındaki bağlantıları şekli olarak ifade eden Telelogic DOORS (Anonymous 2010a), Rational RequisitePro (Anonymous 2010b) ve Enterprise Architect (Anonymous 2010c) gibi gereksinim geliştirme yazılımları ve modelleme dili ya da yukarıda bildirilen üçüncü grup olan resmi, sade ve doğrudan metinler kullanılmaktadır. Bu tip metinlere doğal dilde yazılmış metinler de denmektedir. Lami (2005) nin tespitlerine göre piyasada gereksinim tanımlamak için yeterince araç olmasına rağmen, gereksinim kalitesini kontrol etmeye yönelik araçların sayısı azdır. Son yıllarda, Lami (2005) nin referanslarına göre gereksinim tanımlamalarındaki muğlaklıkları, tutarsızlıkları ve yanlışlıkları düzeltmek amacıyla birçok modelleme dili geliştirilmiştir. Unified Modeling Language (UML) gibi Görsel Nesne Modelleme (graphical object modeling) dilleri ya da Z Notation (Spivey 1992) ve B-Method (Abrial 1996) gibi modelleme dilleri, muğlaklıkları önlemek için kullanılmaktadır. Ancak bu dillerin dezavantajı, konunun uzmanı olmayan kişiler tarafından anlaşılmalarının ve kullanımlarının oldukça zor olması ve bu yüzden pratik olarak kullanılamamalarıdır. Ryan (1992) bunu müşterilerin bildikleri dışında bir dili (örneğin bir modelleme dili) öğrenmelerini beklemenin gerçekçi olmadığını, zira bu durumda müşterinin her aldığı ürün için yeni bir dil öğrenmesi gerektiğini ifade ederek açıklamıştır. Lui vd. (2004) nin açıkladığına göre günümüzde bilim camiası tarafından modelleme diline yönelik gereksinim teknikleri geliştirilmiştir; ancak, gereksinimleri dokümantasyonunda doğal dil hala yaygın olarak kullanılmaktadır. Mich vd. (2004) nin çalışmasının sonuçlarına göre gereksinim dokümanlarının %71,8 i doğal dilde yazılmaktadır. Ancak gereksinimlerin yazılmasında doğal dilin kullanılmasının getirdiği bazı mahsurlar da söz konusudur. Doğal dilin barındırdığı muğlâklıklardan dolayı (yazılı 9

resmi dokümanlar yaratılmış olsa bile) zaman zaman karşılıklı taraflarca farklı algılanmaya sebep olabilmektedir. Bu durum, özellikle gittikçe karmaşıklaşan teknik ihtiyaçların izah edilmesinde daha sık görülmektedir. Özellikle gereksinimlerin konun hâkimi olmayan ihtiyaç sahipleri tarafından tanımlandığı durumlarda bu husus daha belirgindir. Raffo vd. (2007) tarafından belirtildiği gibi, gereksinimlerin doğal dilde yazılması onları hataya açık hale getirmektedir. Bu kapsamda, bu gereksinimleri analiz etmek için tetkik tabanlı teknikler ve senaryo bazlı gözden geçirme teknikleri gibi birtakım insan yoğun hata ayıklama teknikleri mevcuttur. Bununla birlikte gereksinim analizinde kullanılan ve sözlüksel ve/ veya sözdizimsel analiz teknikleriyle analitik olarak gereksinimleri analiz edebilen yazılım tabanlı uygulamalar da mevcuttur. Bunların detayı, Bölüm 2.5 de açıklanmıştır. Lami (2005) ye göre, analitik yaklaşım ve teknikler büyük potansiyel vaat etmektedir. Örneğin, Raffo vd. (2007) tarafından yapılan araştırmaya göre 100,000 satır kod içeren bir yazılım geliştirme projesinde bu yaklaşımla geliştirilen bir gereksinim analiz yazılımı olan QuARS yazılımı ile gereksinim analizinin yapılması 5,000 adam-saatten fazla efor tasarrufu sağlamış; QuARS yazılımının proje süresini kısaltarak ve kalitesini arttırarak projeye ilave değer kattığı gözlemlenmiştir. Bu dezavantajına rağmen, doğal dilde yazılmış ve yapılandırılmış metinler, üzerinde herhangi bir yazılım aracı kullanılarak, dilbilimsel ve/veya istatistiksel tekniklerle analiz yapılabilecek metinlerdir. Günümüzde özellikle Yazılım Gereksinim Kalite Yönetimi nde, doğal dilde yazılmış ve yapılandırılmış gereksinim metinleri üzerinde dilbilimsel analizler yapabilecek bazı yaklaşımlar ve ilgili yazılımlar İngilizce için geliştirilmiştir. Bu yazılımların çoğu ticari ürünler olarak henüz yaygın olarak kullanılmasa da, ileriye yönelik olarak bu alanda uygulamaların artacağını ve gelişeceğini göstermektedir. 10

Bu analizler kapsamında bir gereksinim kümesinin sahip olması arzu edilen kalite öznitelikleri ve bu niteliklerin sağlanmasını zorlaştıran gereksinim hata tipleri belirlenmiştir. 2.2 Gereksinim Kalite Öznitelikleri Kalite öznitelikleri bir gereksinim kümesinin sahip olması arzu edilen niteliklerini açıklamakta olup bu niteliklerin belirlenmesinde gereksinimlerle ilgili standartlardan faydalanılabilmektedir. Bu alanda sık başvurulan standartlar olan DOD MIL-STD-490A ve IEEE Std 830-1993 standartları bu analizlerde öznitelik olarak kullanılabilecek özellikleri açıklamaktadır. Yılmaz ve Kızılca (2009) DOD MIL-STD-490A ve IEEE Std 830-1993 den faydalanarak 9 adet kalite özniteliği türeterek çizelge 2.1 deki gibi Türkçe leştirmiş ve her birinin ne anlama geldiğini açıklamıştır. Bu kriterler, gereksinim kalitesini artırmaya yönelik araçlarda birbirine çok yakın ifadelerle sıklıkla vurgulanmaktadır. Bu nitelikler bir yazılım gereksiniminin muğlak ifadelere yol açmaması ve karmaşıklık içermemesi için sahip olması gereken nitelikleri tanımlamaktadırlar. Bu kalite özniteliklerine ilave olarak bir gereksinim dokümanının okunabilirliği de bu metinlerin kalitesine katkıda bulunacak bir nitelik olarak ele alınabilir. Bu kapsamda dokümanın okunabilirliğini ölçmede Flesch Reading Ease index (Flesch 1948), Flesch- Kincaid Grade Level index (Kincaid vd 1975), Coleman-Liau Grade Level index (Coleman ve Liau 1975), Bormuth Grade Level index (Bormuth 1966) gibi İngilizce okuma indeksleri ve Türkçe için Ateşman Okunabilirlik İndeksi (Ateşman 1997) kullanılabilmektedir. 11

Çizelge 2.1 DOD MIL-STD-490A ve IEEE Std 830-1993 a göre kalite öznitelikleri (Yılmaz ve Kızılca 2009) Kalite Niteliği Bütünlük (Completeness) Tutarlılık (Consistency) Doğruluk (Correctness) Değiştirilebilirlik (Modifiability) Doğrulanabilirlik (Verifiability) İzlenebilirlik (Traceability) Mutlaklık (Unambigouity) Anlaşılabilirlik (Understandibility) Sıralandırılabilirlik (Rankedness) Açıklama Gereksinim kümesinin Daha sonra belirlenecektir gibi ifadeler içermiyor olması Gereksinim kümesinin birbirleriyle veya üst seviye gereksinimler ile çelişen ifadeler içermiyor olması Gereksinim kümesinin gerçek operasyon ortamını düzgün bir şekilde tarif ediyor olması Gereksinim kümesinin farklı/bağımsız konulardaki hususları tek bir gereksinim içerisinde ifade etmiyor olması Gereksinim kümesindeki ifadeler ile test adımı ve prosedürü yazılabiliyor olması Gereksinim kümesinin elemanlarının hem üst, hem de alt seviye gereksinim ve tasarım modülleri ile ilişkilendirilebilir olması Gereksinim kümesinde farklı şekilde yorumlanmaya müsait ifadeler olmaması Gereksinim kümesinin ifadelerin düzgün bir dilbilgisi ile yazılmış olması Gereksinim kümesindeki ifadelerin önem, aciliyet, değişkenlik, konu vb. ölçütlere göre sıralanabilir veya gruplanabilir olması 2.3 Gereksinim Hata Tipleri Konu ile ilgili standartlardan türetilen kalite öznitelikleri doğrultusunda bu kalite özniteliklerinin sağlanmasına engel olabilecek hatalar ve bunların tiplerinin belirlenmesi ihtiyacı ortaya çıkmıştır. Bu kapsamda kalite özniteliklerinden faydalanılarak bir gereksinim dokümanının sahip olmaması gereken hata tipleri ortaya çıkmıştır. Bu hata tiplerinden en sık kullanılanları kısaca çizelge 2.2 de açıklanmıştır. Bu hata tipleri genellikle gereksinim dokümanındaki her bir gereksinimin içerebileceği hataya odaklanmakla birlikte bazı hata tipleri dokümanın bütünü incelenerek ortaya çıkarılabilecek hatalardır. 12

Bununla birlikte gereksinim kalite özniteliklerini olumsuz etkileyebilecek diğer bazı hatalar da gereksinim dokümanında yapılabilmektedir. Bunlardan, literatürde üzerine çalışma yapılmış iki ana alan şu şekildedir: Birincisi, aynı ya da benzer gereksinimlerin doküman içerinde yer almasıdır. İkincisi, dokümanda, işlevsel olan ve işlevsel olmayan gereksinimlerin bulunması ve bunların sınıflandırılmamış olmasıdır. Bu iki alan hata tipi olarak adlandırılmaktan ziyade ayrı bir analiz alanı olarak karşımıza çıkmaktadır. Bu kapsamda, bu iki konu Bölüm 2.5.2 ve Bölüm 2.5.3 de ayrı olarak ele alınmıştır. Çizelge 2.2 Gereksinim hata tipleri (Yılmaz ve Kızılca 2009 dan uyarlanarak alınmıştır.) İfade Edicilik İle İlgili Hata Tipleri Belirsizlik (Vagueness) Açıklamaları Gereksinimde niceleyici ifadeler bulunmayıp, tartışma yaratacak hızlı, güçlü, kullanımı kolay vb. belirsiz niteleyici ifadeler bulunması Öznellik (Subjectivity) Gereksinimin kişisel algıyla değişebilecek, genellikle de başka bir kavram ile karşılaştırma yapılarak benzer, daha iyi, göz önüne alınacaktır, göz önünde bulundurulacaktır vb. ifadeler içeriyor olması. Seçeneklilik (Optionality) Üstü Kapalılık (Implicity) Gereksinimin okuyana kesin bir bilgi vermeyen, mümkün olduğunca vb. ifadeler içeriyor olması. Gereksinim üstü kapalı bir şekilde yukarıdaki, aşağıdaki, bütün bu vb. ifadeler ile başka gereksinimlere atıf yapıyor; tek başına ele alındığında anlamsız hale geliyor olması. Zayıflık (Weakness) Gereksinimin zorunluluk bildiren bir ifade içermiyor olması; örneğin - ecektir, -acaktır, -meli, -malı kiplerini içermemesi. Maksadını Aşma (Over-specification) Çokluk (Multiplicity) Eksiklik (Incompleteness) Gereksinimin, tasarımda ele alınması gereken hususları içeriyor olması. Gereksinimin aslında birden fazla gereksinim ifadesi içeriyor olması Gereksinimde daha sonra belirlenecek vb. ifadeler bulunması 13

2.4 Gereksinim Hata Tipleri-Kalite Öznitelikleri İlişkileri Gereksinim kalite öznitelikleri ve bu özniteliklerde bozulmaya yol açan hata tipleri arasındaki birbirini etkileyen bir ilişki mevcuttur. Bu ilişki temel olarak çizelge 2.3 de gösterildiği şekilde tanımlanmıştır. Bu ilişki sayesinde belirli bir kalite özniteliğini sağlamak için aranacak hata tipi ve bunun özellikleri belirlenebilmektedir. Çizelge 2.3 Gereksinim hata tipleri ve bu hatalar dolayısıyla etkilenen kalite öznitelikleri (Yılmaz ve Kızılca 2009 dan uyarlanarak alınmıştır.) Gereksinim Hata Tipleri Seçeneklilik Öznellik Belirsizlik Üstü Kapalılık Zayıflık Eksiklik Çokluk Maksadını Aşma Etkilenen Kalite Öznitelikleri Tutarlılık Değiştirilebilirlik Doğrulanabilirlik İzlenebilirlik Mutlaklık Bütünlük Anlaşılabilirlik Doğrulanabilirlik Bununla birlikte, gereksinim dokümanında aynı veya benzer ifadelerin yer alması dokümanın tutarlılığını etkilemektedir. Benzer şekilde, gereksinim dokümanında işlevsel olmayan gereksinimlerin belirlenmemiş olması da gereksinim dokümanının doğrulanabilirliğini ve doğruluğunu olumsuz etkilemektedir. Bu iki hatanın çizelge 2.3 deki literatürde yer alan hata tiplerine eklenmesinin faydalı olacağı değerlendirilmekte olup bu durumda çizelge 2.3 deki ilişkiye ilave olarak çizelge 2.4 de anlatılan hata-kalite özniteliği ilişkisi doğmaktadır. Çizelge 2.4 Gereksinim hata tiplerine ilave olarak yapılan hatalar ve bu hatalar dolayısıyla etkilenen kalite öznitelikleri Gereksinimde Yapılan Hata Etkilenen Kalite Öznitelikleri Benzer Gereksinimlerin Yer Alması Tutarlılık İşlevsel Olmayan Gereksinimlerin Belirlenmemesi Doğrulanabilirlik / Doğruluk 14

Gereksinim dokümanlarının analiz edilmesi ve kalitesinin arttırılması amacıyla yukarıda belirtilen hata tiplerinin bir doküman içerisinde tespit edilerek ayıklanmasına yönelik olarak yazılım destekli analiz ve yaklaşımlar mevcuttur. Literatürde, bu çalışmanın ilgi alanı kapsamında, metin haline getirilmiş herhangi bir aday gereksinim kümesinden; 1. Dilbilimsel analizler yaparak hatalı veya arızalı gereksinimleri belirlenmesi, 2. Birden fazla yazılmış aynı veya benzer gereksinimlerin tespiti, 3. Gereksinimlerin türlerine ve alt türlerine ayrılarak sınıflandırılması, 4. Bütün bu işlemler esnasında kullanıcının müdahalesine imkân sağlanmasına olanak veren yaklaşımlar ve bu doğrultuda geliştirilen yazılımlar mevcuttur. 2.5 Gereksinim Hatalarının Tespit Edilmesine Yönelik Yapılmış Çalışmalar Yukarıdaki tüm boyutları birden içermese bile, bu işlevlerden bazılarını İngilizce için yerine getirenleri Yılmaz ve Kızılca (2009) aşağıdaki gibi özetlemiştir: Dilbilimsel analizler ile gereksinimlerdeki hataların tespit edilmesi, gereksinim kalitesinin artırılması üzerine dört adet bağımsız çalışma: o Wilson vd. (1997), o Noh ve Godia (2003), o Fantechi vd. (1994), o Kasser vd. (2005); Birbirine anlamsal olarak yakın olan gereksinim ifadelerinin tespit edilmesi konusunda bir adet çalışma: (Natt och Dag vd. 2001); İşlevsel olmayan gereksinimlerin alt türlerine ayrıştırılması konusunda bir adet çalışma:( Cleland-Huang vd. 2007) Ayrıca Yılmaz ve Kızılca (2009) tarafından hata tiplerinin sözlüksel tekniklerle dilbilimsel analizine yönelik bir çalışma mevcuttur. Literatürdeki bu çalışmalar, yukarıda açıklanan dört boyuttan bir ya da ikisini karşılamakta ve hiçbiri dört adet boyutu karşılamamaktadır. Bu çalışmalar grup olarak aşağıda kısaca açıklanmıştır. 15

2.5.1 Dilbilimsel analizler yaparak hatalı veya arızalı gereksinimleri belirlenmesine yönelik araçlar Dilbilimsel yöntemler, sözcüklerin kullanımına dair analizlerin yapıldığı sözlüksel (lexical) yöntemler, sözcüklerin cümle içerisindeki dizilimlerine dayalı sözdizimsel (syntactic) yöntemler ve doğal dildeki ifadelerin anlamlarına dayalı anlambilimsel (semantic) yöntemler olarak üç ana dala ayrılır. Anlambilimsel yöntemler uygulanması en zor yöntemlerdir. Bu aşamada sözlüksel ve sözdizimsel yöntemlerle gereksinim analizi yapan yaklaşımlar, geliştirme neticesinde aşağıda sıralanan yazılımlara dönüşmüştür: Wilson vd. (1997) tarafından geliştirilmiş olan ARM, Noh ve Gadia (2003) tarafından geliştirilmiş olan RAST, Fantechi vd. (1994) ve Lami (2005) tarafından geliştirilmiş olan QuARS, Kasser (2002) tarafından geliştirilmiş olan Tiger PRO, Bu çalışmalardan hemen hemen hepsinin ana amacı ve çıkış noktası aynıdır; bunu Wilson vd. (1997) şöyle açıklamaktadır: modelleme dilinde gereksinim yaratmanın önemli avantajlarına rağmen bunların kullanımı yoğun ve yaygın değildir. Zira gereksinim aynı zamanda ihtiyaç sahibinin ihtiyacını kontratsal olarak sağlaması ve bunun tüm kontrat paydaşlarınca ortak şekilde anlaşılması için doğal dilde yazılmaktadır. Özellikle yazılım ihtiyaçları alanında doğal dilin kullanımı üç temel sahada problem yaratmaktadır: Muğlâklık, Yanlışlıklar, Tutarsızlık. Bunu sebebi doğal dilde bir kavramı tanımlamak için çoğu zaman birden fazla kelime bulunması veya bazı sıfatların nicel değil nitel anlamlar içermesi ya da bazı kavramların istenmeden yanlış kullanılması gibi hatalara müsait olmasıdır. 16

Yukarıda sözü edilen yazılımlar, İngilizce yazılmış gereksinimlerin kalitesini artırmaya yönelik olarak geliştirilmiştir. Bu yazılımların, sözlüksel yöntemlerin sözdizimsel yöntemlere kıyasla daha kolay gerçekleştirilebilir olmalarından dolayı, sözlüksel özellikleri de genellikle sözdizimsel özelliklerine göre daha güçlüdür (Kızılca ve Yılmaz 2008). 2.5.1.1 ARM (Automated Requirements Measurement) yazılımı Bu yazılım NASA ya bağlı Goddard Uzay Uçuş Merkezi (GSFC) Yazılım Güvence Teknoloji Bölümü (SATC) tarafından doğal dilde hazırlanmış gereksinimler üzerine uygulanmak için geliştirilmiştir. Bu yazılım gereksinim dokümanını SATC uzmanlarınca daha önceden belirlenmiş kalite özniteliklerine (quality attributes) göre dilbilgisel olarak taramakta, analitik analiz yöntemleriyle muğlâklık, tutarsızlık ve yanlışlıkları gösteren bir rapor çıkarmaktadır. Bunun neticesinde sözlüksel ve cümle yapısı açısından dokümanın geliştirilmesi gereken kısımlarını kullanıcıya bildirmektedir (Wilson vd. 1997). Bu yapıya göre kalite öznitelikleri bir gereksinim kümesinin sahip olması arzu edilen niteliklerini açıklamakta olup, DOD MIL-STD-490A ve IEEE Std 830-1993 den alınan ve açıklamaları çizelge 2.1 de verilen öznitelikler kullanılmaktadır. Buna ilave olarak gereksinim kalitesinin ayrı bir boyutu olan Okunabilirliğin ölçülmesi için Bölüm 2.2 de açıklanan İngilizce okuma indekslerini kullanılarak dokümanın okunabilirliği ölçülmektedir. 2.5.1.2 QuARS (Quality Analyzer for Requirements Specifications) yazılımı QuARS yazılımını geliştiren ekibin bir üyesi olan Lami (2005) nin tarifine göre, yapılandırılmış gereksinim metninde QuARS, sözlüksel gereksinim hatalarını tespit ederek karmaşıklığa yol açan ifadeleri ayıklamaya yönelik bir araçtır. Bu yazılım, 17

dilbilgisel analiz tekniklerini kullanarak ve analitik yaklaşım ile gereksinim metinlerindeki muğlaklıkları yakalamayı amaçlamaktadır. Bu yazılımın temelinde, çizelge 2.1 deki yazılım gereksinim dokümanlarının sahip olması gereken temel kalite özniteliklerini üç grupta toplanmış ve bu üç grup kriter Lami (2005) tarafından şu şekilde açıklanmıştır: İfade edicilik (Expressiveness): Bu kriter gereksinimin anlamı hakkında yanlış anlamaya sebep verebilecek özelliklerle ilgilidir. Gereksinim dokümanındaki muğlaklıklar ve zor okunabilirlik genelde bu tip problemlerin kaynağıdır. Tutarlılık (Consistency): Bu kriter gereksinim dokümanında yer alabilecek anlambilimsel çelişkilerle ilgilidir. Bütünlük (Completeness): Bu kriter gereksinim dokümanının içerisinde gerekli bilgilerin yer alıp almadığıyla ilgilidir. Bu aşamada Lami (2005) ye göre Tutarlılık ve Bütünlük kriterleri ile ilgili analizler daha ziyade anlambilimsel analizler gerektirmekte, birinci grup olan İfade edicilik ile ilgili kriterler sözlüksel ve sözdizimsel yöntemlerle analiz edilebilmektedir. QuARS yazılımı birinci grup olan ifade ediciliği ölçmeye ve değerlendirmeye, ikinci ve üçüncü grup olan Tutarlılık ve Bütünlük analizlerine ise destek vermeye yönelik tasarlanmış bir yazılımdır. QuARS tarafından Tutarlılık ve Bütünlük konularındaki analizlere destek olabilmek amacıyla, benzer konudaki gereksinimler ve benzer nesnelerle alakalı gereksinimler belirlenmekte, daha sonra bunlar kullanıcıya bir fikir vermek amacıyla bir ekran altında gruplanmaktadır. Örneğin ürünün fonksiyonalitesi, kullanıcı ara yüzü vb. QuARS yazılımının kullanıcı tarafından sağlanacak girdileri: analizi yapılacak gereksinim dokümanı ve Sözlüksel analizleri oluşturabilmek için kullanılacak sözlüklerdir. Sözlükler de yine metin formatında olmalıdır. 18

2.5.1.3 RAST (Requirement Analysis Support Tool) yazılımı Diğer iki yazılım gibi RAST yazılımının da çıkış noktası gereksinim dokümanlarında zayıf ifadelerin ve hatalı cümle yapılanın daha sağlam ifadelere dönüştürülmesidir. Bu amaçla tutarsızlık ve yanlışlıkları gidermeye yönelik geliştirilmiş bir yazılımdır. Noh ve Gadia (2003) nın bildirdiğine göre bu yazılım gereksinim dokümanlarından isim ve yüklem (fiil) sözlükleri oluşturarak dilbilgisel veriler oluşturmaktadır. Zira bu yaklaşıma göre, bir gereksinimi tanımlayan elemanlar isimler ve yüklemlerdir. Oluşturulacak isim ve yüklem sözlüklerine göre kullanıcılara her isim ve yüklemi ifade edecek bir sembol yaratılmakta ve bu semboller mantıksal ifadelere çevrilmekte ve bu ifadeler gereksinim içinde veya gereksinimler arasında bir tutarsızlık varsa bunu yakalamakta kullanılmaktadır. Önceki iki yazılımın aksine, RAST muğlâklıkları gidermek için hata tipi sözlükleri kullanmamakta ve sözlüksel analiz yapmamaktadır. Bunun yerine cümlelerin sözdizimsel analizlerle isimlerini ve yüklemlerini sınıflandırmakta ve bu kapsamda isim ve yüklem sözlükleri oluşturmakta ve birbirleriyle ilişkilerini incelemektedir. Bu açıdan yalnızca sözdizimsel analiz yapan bir araçtır. 2.5.1.4 Tiger PRO yazılımı Tiger PRO yazılımı, Kasser (2005) tarafından bildirildiğine göre tıpkı ARM yazılımı gibi, çizelge 2.1 de sıralanan IEEE 830-1993 standardı gereği gereksinim dokümanlarının sahip olması gereken kalite özniteliklerine göre hata sözlükleri oluşturup sözlüksel analiz ve buna ilave olarak İngilizce için oluşturulmuş okunabilirlik indekslerine göre okunabilirlik analizi yapan daha basit ve pratik bir algoritmadır. Bu yazılımda sözdizimsel analiz bulunmamaktadır. 19

2.5.1.5 Türkçe için Kızılca ve Yılmaz (2008) tarafından yapılan çalışma Gereksinim analizine yönelik olarak Türkçe de dilbilgisel analiz yöntemlerini kullanan en kapsamlı çalışma Yılmaz ve Kızılca (2008, 2009) tarafından önerilmiştir. Gereksinimlerin doğal dilde düzgün bir şekilde ifade edilmesi için gereksinimlerden beklenen genel özellikleri ve kalite kriterlerini, Yılmaz ve Kızılca (2009) IEEE STD 830-1993 ve DOD MIL-STD-490A dan faydalanarak çizelge 2.1 deki gibi oluşturmuştur. Buna benzer bir yaklaşım ile Kızılca ve Yılmaz (2008) tarafından gereksinim dokümanında yapılan hata tipleri çizelge 2.2 deki şekilde belirlenmiştir. Bu kapsamda geliştirdikleri yazılım aracında temelde sözlüksel teknikler kullanarak gereksinim dokümanında yapılan hatalara odaklanarak yazılım yardımıyla bunu en aza indirmeye çalışmışlardır. Çizelge 2.5 Hata tipi analizi yapan yazılımlar ve kullandıkları analiz yöntemleri Analiz Yazılımı Kullanılan Analiz Yaklaşımı ARM QuARS RAST Tiger PRO Yılmaz ve Kızılca (2009) Sözlüksel Sözdizimsel Anlambilimsel 20

Bu kapsamda İngilizce de ve Türkçe de gereksinim hata tipi analizi yapan yazılımlar ve kullandıkları analiz yöntemleri çizelge 2.5 deki gibi listelenebilir. 2.5.2 Aynı veya benzer gereksinimlerin tespitine yönelik araçlar Benzerlik analizinin amacı, birbirine benzer ya da yanlışlıkla iki veya daha fazla kere yazılmış birbirinin aynı gereksinimleri tespit ederek ayıklamak ve benzer gereksinimleri tek gereksinim altında toplamaktır. Zira aynı yada benzer gereksinimlerin bir gereksinim dokümanında birden fazla kere yer alması gereksinim dokümanının Tutarlılığını (bir kalite özniteliği) ve dolayısıyla kalitesini düşüren bir faktördür. Ayrıca bu tip bir durum gereksiz işgücü kaybına ve ileride geliştirilecek yazılımın veya sistemin testleri esnasında karmaşıklığa yol açabilir. Bu amaçla gereksinim dokümanlarında benzerlik analizi yapan bir yazılım Natt och Dag vd. (2001) tarafından geliştirilmiş ve İngilizce gereksinim dokümanlarına uygulanmıştır. Natt och Dag vd. (2001) nin bildirdiğine göre, gereksinim dokümanlarının benzerlik analizinde kullanılabilecek iki metin işleme yöntemi vardır: 1. İstatistikî Yaklaşım, 2. Dilbilgisel Yaklaşım. Bunlardan istatistiksel yaklaşım Luhn (1957) tarafından önerilen ve iki cümledeki sözcüklerin benzerliğinin benzerlik katsayıları kullanarak ve belirli bir benzerlik eşik değeri atayarak ölçülmesi ve belirli bir eşik değerin üstünde olanları benzer olarak belirlenmesini içermektedir. Dilbilgisel yaklaşım ise, bir eşanlamlılar sözlüğü ve anlambilimsel (semantic) yöntemler kullanarak kelimeler ve cümleler arasındaki anlamsal benzerliklerin tespitine yönelik bir çalışmadır. Bu yaklaşım Yücesoy ve Öğüdücü (2007) nün ifade ettiği gibi iki terimin anlamca yakınlığını ilgilendirdiğinden çok kapsamlı bir eşanlamlılar sözlüğü ihtiyaç duymakta, ve Mitra vd. (1997) nin tespit ettiği gibi pahalı ve külfetli bir çalışma 21

gerektirmekte ve iyi uygulanmış bir istatistiksel yaklaşımdan daha iyi sonuçlar vermemektedir. Natt och Dag vd. (2001) tarafından üzerinde uygulama yaptıkları gereksinim metinlerinde, istatistiksel yaklaşım ile hazırladıkları yazılımın, gereksinim uzmanları (mühendisleri) tarafından aynı dokümanlarda İnsan muhakemesiyle bulunan benzerlikleri büyük oranda yakaladığı ifade edilmiştir. Bu çalışma istatistiksel yaklaşımın değerli bir yaklaşım olduğunu göstermektedir. Natt och Dag vd. (2001) tarafından hazırlanan yazılım istatistiksel yaklaşımı kullanmaktadır. Bu yazılım, istatistiksel yaklaşımın gerektirdiği gibi, gereksinim dokümanındaki gereksinimleri cümle cümle ayırmakta, daha sonra iki gereksinim cümlesi (X,Y) arasındaki benzerliği (S X,Y ) benzerlik katsayıları kullanarak ve belirli bir benzerlik eşik değeri atayarak ölçmekte ve belirli bir eşik değerin üstünde olanları benzer olarak belirlemektedir. Ancak bunun öncesinde cümlelerdeki benzerliğin ölçülebilir hale getirilmesi için sözcüklere ayırma, bağlaçları ve durak kelimeleri ayıklama ve ekleri ayıklama işlemlerinden geçirildikten sonra benzerlik hesaplanmaktadır. Burada, yazılım boşlukları ve noktalama işaretlerini algılayarak cümleleri öncelikle sözcüklere ayırmakta, daha sonra Durak Kelime (stop word) adı verilen ve bağlaçlardan, ayrık eklerden oluşan kelimeler ayıklanmakta, daha sonra kelimelerin başına ve sonuna temel ekler ve yapım ekleri ayıklanarak geriye kalan kelimelerin düğer cümledeki kelimelerle benzerlikleri istatistiksel olarak ölçülmektedir. Natt och Dag vd. (2001) tarafından hazırladıkları yazılımda benzerlik katsayıları için literatürdeki Dice, Jaccard ve Cosine (Pang-Ning vd., 2005) benzerlik katsayıları kullanılmaktadır. 22

2.5.3 Gereksinimlerin türlerine ve alt türlerine ayrılarak sınıflandırılmasına yönelik araçlar Gereksinimler bir ihtiyaç hakkında bilgi taşıyan metinlerdir. Natt och Dag vd. (2001) ne göre gereksinimin taşıdığı bilgi iki türlüdür; gereksinimin açıkladığı ihtiyaç konusundaki açık bilgi, gereksinimin ait olduğu alana ait tüm kabuller, kurallar ve standartları bünyesinde barındıran üstü kapalı bilgi. Burada açık bilgi gereksinimleri açıklamak için yazılan dokümanları, şekilleri ve diğer hazırlanmış nesneleri, üstü kapalı bilgi ise bir gereksinim konusunun alanındaki tüm varsayımlar, kurallar ve standartlardan oluşmaktadır. Bu kapsamda, açık bilgi içeren ve gereksinimde, ilgili yazılımın ne yapacağını anlatan ifadelere işlevsel (functional) gereksinimler; üstü kapalı bilgi içeren ve gereksinimde ilgili yazılımın nasıl çalışacağını anlatan ifadelere ise işlevsel olmayan (nonfunctional) gereksinimler adı verilmektedir. İşlevsel olmayan gereksinimler, işlevsel olanların aksine geliştirilen yazılım üzerinde uygulanacak bir işlevi açıklamaz. Tersine, işlevsel gereksinimlerin uyması gereken durumları ve kısıtlamaları tanımlar, bu açıdan işlevsel olmayan gereksinimler işlevsel olanlarla ilişkilidir. Kısaca işlevsel olmayan gereksinimleri işlevsel olanların uyması gereken kısıtlamalar ve kalite vasıfları olarak açıklanabilir (Cysnerios vd. 2001). Yazılım alanındaki bir gereksinim kümesinde işin doğası gereği hem işlevsel, hem de işlevsel olmayan gereksinimler bulunmalıdır. Zira hem yazılımın sahip olması gereken kabiliyet ve kapasite, hem de uyması gereken standartlar ve nasıl çalışması gerektiği anlatılmalıdır. Bu anlamada işlevsel olmayan gereksinimler istenilmeyen kötü bir şey değildir. Ancak, Duan vd. (2009) nin açıkladığı gibi, gereksinimler yazılırken çoğu zaman işlevsel ve işlevsel olmayan gereksinimler birbirine karıştırılmakta ve gereksinim dokümanında ürünün nasıl çalışacağı anlatılmakla birlikte, temel olarak ne yapacağı ve hangi fonksiyonları yerine getireceği genelde eksik belirtilmektedir. Bu durum, 23

gereksinim dokümanının Doğruluğuna (bir kalite özniteliği) zarar vermekte ve bu açıdan ilk bölümde açıklanan gereksinim kalitesini olumsuz etkilemektedir. Ya da, Cleland-Huang vd. (2007) nin ifade ettiği gibi, ürünün uyması gereken kurallar ve standartları ifade eden, ürünün yapısal tasarımını etkileyen ve ürünün sahip olması gereken çok önemli vasıfları tanımlayan işlevsel olmayan gereksinimler, başlangıçta tamamen unutulmakta, projede görevli insanların (tarafların) bunları zaten bilip kabul ettiği ve varsaydığı düşünülmekte ve ilerleyen süreçlerde plansız bir şekilde gereksinim dokümanına dahil edilmeye çalışılmaktadır. Yine bu durum da gereksinim dokümanının Doğruluğuna (bir kalite özniteliği)zarar vermektedir. Cleland-Huang vd. (2007) tarafından 15 yazılım projesine ait SRS (Yazılım Gereksinimleri Dokümanı) incelenmiş ve neredeyse tamamında işlevsel olmayan gereksinimlerin eksik olduğu bildirilmiştir. Örnek vermek gerekirse: simülatör yazılımı, öğrenci pilotların uçuş not puanlarını öğrencilerin bilgi dosyasına aktaracak bir veri girişi sağlayacaktır. ifadesi işlevsel bir gereksinim; öte yandan öğrenci pilotun not puan değerine göre, yalnızca bir öğretmen pilot öğrenci notunu öğrenci bilgi dosyasına aktarabilecektir. ifadesi ise yetki güvenliği ile ilgili bir işlevsel olmayan gereksinimidir. Eğer bu gereksinim ilave edilmez ise yazılımın yapısal tasarımında önemli bir hususu eksik kalmış olur ve ileride ilave etmek oldukça zor ve külfetli olacaktır. Blackburn vd. (2001) ne göre test faaliyetleri bir yazılım geliştirme çalışması maliyetinin %40-75 ine mal olmaktadır; ayrıca testlerdeki hataların %50 si gereksinimlerin hatalı veya yanlış adreslenmiş olmasından kaynaklanmaktadır. Bununla birlikte, genel olarak geliştirip biten bir yazılım ürününün testlerinde, işlevsel gereksinimler doğrudan test yöntemi ile, işlevsel olmayan gereksinimler ise gösterim (demonstration) veya sertifikasyon (certification) ile yapılmaktadır. Bu anlamda bu sınıflandırmayı daha baştan gereksinim aşamasında yapmamak gereksinim dokümanının Doğrulanabilirliğine (bir kalite özniteliği) zarar vermektedir. Bu durum ileride ürünün kabulünde test eforunu oldukça artıracak bir hatadır.. 24

Ayrıca işlevsel olmayan gereksinimler de kendi aralarında bir ürünün etkiledikleri özelliğine göre gruplara ayrılmaktadır. Bu anlamda işlevsel olmayan gereksinimleri de kendi içinde yazılımın yapısal tasarım aşamasında sıkıntı yaşamamak ve ilgili standartları tutturmak açısından önemlidir. Yazılımın işlevi ile ilgili olmayan ancak sağlaması gerekli standartları ve sahip olması gereken kalite vasıflarını açıklayan, yazılım gereksinimleri ile ilgili olarak, Chung vd. (2000), kapsamlı bir İşlevsel Olmayan Gereksinim (İOG) (Non-Functional Requirements) türleri listesi vermiştir. Bu liste, 65 tür işlevsel olmayan gereksinim türü içermekte olup, tamamı Ek 1 de yer almaktadır. Bu türler, literatürde işlevsel olmayan gereksinimleri sınıflandırmak için kullanılmaktadır. Buradaki türler üzerinde analiz yapılacak gereksinim kümesinin özelliklerine göre, analizlerde kullanılmak üzere eksiltilip artırılarak ihtiyaca göre uyarlanabilmektedir. Bununla birlikte, yazılım kalite standartlarından biri olan ISO-9126 bir yazılım ürününü sahip olması gereken kalite vasıflarını daha öz ve olgun bir şekilde içermektedir. ISO- 9126 yazılım gereksinimlerinin sahip olması gereken çalışma koşullarını ve ürününün çalışmasında sahip olması gereken kalite vasıflarını çizelge 2.6 daki gibi sınıflandırmıştır. Bu türler, aynı zamanda işlevsel olmayan gereksinimlerin sınıflandırılmasında kullanılabilir. Zira bu özellikler yazılımın uyması gereken kısıtları ve kalite vasıflarını anlatmaktadır. Ayrıca, Cysnerios vd., (2001) çalışmalarında bu vasıflar işlevsel olmayan gereksinimleri sınıflandırmada kullanılmış ve etkin bir sınıflandırmaya imkan verdikleri görülmüştür. Burada, işlevsel olmayan gereksinimler 6 temel sınıfa ayrılmış ve bu altı temel sınıf da kendi içerisinde sınıflara ayrılmıştır. Bu sınıflar yazılım gereksinim dokümanında, yazılımın sağlaması gereke standartların ve çalışma şartlarının türlerini ifade etmektedir. Her sınıfın anlamı ve kapsadığı işlevsel olmayan gereksinim özellikleri çizelge 2.6 da sınıfların yanına yazılmıştır. Bu çizelgede, Sınıfların Türkçesi Aydın vd. (2006) çalışmasından alınmıştır. 25

Çizelge 2.6 ISO 9126 dan çıkarılan İşlevsel Olmayan Gereksinim türleri İOG Türleri İOG Alt Türleri Açıklama İşlevsellik Uygunluk (Suitability) Belirlenmiş fonksiyonlar setini yazılımın sahip olması ve buna (Functionality) fonksiyonlar etine uygunluk becerisine ilişkin gereksinimler. Güvenilirlik (Reliability) Kullanılabilirlik (Usability) Verimlilik (Efficiency) İdame Ettirilebilirlik (Maintainability) Doğruluk (Accurateness) Birlikte Çalışabilirlik (Interoperability) Uyumluluk (Compliance) Emniyet (Security) Olgunluk (Maturity) Hata Toleransı (Fault Tolerance) Düzeltilebilirlik (Recoverability) Anlaşılabilirlik (Understandability) Öğrenilebilirlik (Learnability) Çalıştırılabilirlik (Operability) Zamansal Davranış (Time Behaviour ) Kaynak Kullanımı (Resource behaviour) Analiz Edilebilirlik (Analyzability) Yazılımın üzerinde uzlaşıya varılmış veya doğru etkiyi veya sonucu doğurması becerisine ilişkin gereksinimler. Yazılımın belirlenmiş sistemlerle etkileşim içinde olabilme becerisine ilişkin gereksinimler. Yazılımın uygulama ile ilişkili standartlara, anlaşmalara veya kanuni düzenlemelere ve dengi talimatlara uygun olması becerisine ilişkin gereksinimler. Hatayla veya kasten programlara ve verilere yetkilendirilmemiş erişimi önleyebilme özelliğine ilişkin gereksinimler. Yazılımdaki hatalar nedeniyle yazılımın çökme frekans sıklığının düşük olması becerisine ilişkin gereksinimler. Yazılım hatalarında veya tanımlanmış ara yüzün ihlal edilmesi durumlarında yazılımın belirlenmiş performans seviyesini sürdürebilme becerisine ilişkin gereksinimler. Sistemin çökmesi durumunda doğrudan etkilenen verinin geri yüklenebilme ve performans seviyesinin yeniden oluşturulabilme becerisine ilişkin gereksinimler. Yazılımın mantıksal yapısının ve onun uygulanabilirliğinin kullanıcı tarafından tanınabilmesi için harcanması gereken kullanıcı çabasına ilişkin gereksinimler. Yazılım uygulamalarının kullanıcı tarafından öğrenilebilmesi için harcanması gereken kullanıcı çabasına ilişkin gereksinimler. İşlerlik: Operasyon ve operasyon kontrolü için gereken kullanıcı çabası ile ilgilenen yazılım becerisine ilişkin gereksinimler. Üretilen iş oranı ve işlem zamanları fonksiyonunu yerine getirirken talebin yanıtlaması ile ilgili yazılım becerisine ilişkin gereksinimler. Kaynak kullanımı ve kaynak kullanım süresinin fonksiyonları yerine getirirken kullanılan miktarına ilişkin gereksinimler. Tanı eksikliği ve çökme sebepleri veya düzenlenecek parçaların belirlenmesinde tanımlama için gereken çabaya ilişkin gereksinimler. Taşınabilirlik (Portability) Değiştirilebilirlik (Changeability) Hata giderme, uyarlama veya çevresel değişiklik için gereken çabaya ilişkin gereksinimler. Kararlılık (Stability) Modifikasyon sonucunda yazılımın beklenmeyen etki doğurması riskine ilişkin gereksinimler. Test Edilebilirlik Uyarlanan yazılımın onaylanması için gereken çabaya ilişkin (Testability) gereksinimler. Uyumlandırılabilirlik Göz önüne alınan yazılım için belirlenen amacın (Adaptability) sağlanabilmesinde değişiklik gerçekleştirmeden yazılımın belirli bir farklı çevrede adapte edilebilmesine ilişkin gereksinimler. Kurulum Kolaylığı (Installability) Standartlara Uygunluk (Conformance) Yer Değiştirilebilirlik (Replacability) Tanımlanmış çevrede yazılımın kurulumu için gereken çabaya ilişkin gereksinimler. Taşınabilirlik ile ilgili anlaşmalar veya standartlara bağlı yazılım geliştirilmesine ilişkin gereksinimler. yazılımın başka bir yazılım ortamında kullanılabilmesi için fırsat sağlama ve harcanması gereken çabaya ilişkin gereksinimler. 26

Bu sınıflandırma belirli bir çalışma standardı ile ilgili işlevsel olmayan gereksinimlerin sınıflandırılmasında ve birbirleriyle ilişkilendirilmesinde kullanılabilir. Cleland-Huang vd. (2007) tarafından, Chung vd. (2000) tarafından sıralanan İOG türleri kullanılarak, İOG lerin sınıflandırılmasına yönelik bir yaklaşım ve bu doğrultuda hazırlanan bir yazılım önerilmiştir. Bu yazılımda anahtar kelimelerden oluşan sözlükler oluşturularak her İOG türüne yönelik sınıflandırma yapılması amaçlanmıştır. Bu kapsamda, İOG türü sözlükleri oluşturulmuştur. Bu amaçla, hazırladıkları yazılım üzerinde iteratif bir öğrenme algoritması ile anahtar kelimeler tespit edilerek türüne göre her bir İOG sözlüğüne konulmuş ve daha sonra sözlüksel analiz yöntemi ile İOG ler tespit edilmeye çalışılmış ve başarılı sonuçlar elde edilmiştir. Bu çalışmadan çıkan sonuç şudur: doğru anahtar kelimelerle oluşturulacak sözlükler kullanılarak yapılacak bir sözlüksel analiz İOG lerin tespit edilerek sınıflandırılmasında kullanılabilmektedir. 27

3. MATERYAL VE YÖNTEM Bu çalışmada, Bölüm 1.2 de belirtildiği gibi Türkçe bir gereksinim kümesi üzerinde; Sözlüksel analizler yaparak yanlış anlamaya sebep olabilecek muğlak, hatalı veya arızalı gereksinimlerin belirlenmesi; birden fazla yazılmış aynı veya benzer gereksinimlerin istatistiksel değerlendirme yaklaşımı kullanılarak tespiti; gereksinimlerin ileride test aşamasında kolaylık sağlamak amacıyla türlerine (işlevsel olan/olmayan vb.) ve alt türlerine (performans, kalite, güvenlik vb.) ayrılarak sınıflandırılması; ve bütün bu işlemler esnasında kullanıcının müdahalesine imkân sağlanmasına yönelik analizlerin yapılması amaçlanmıştır. Ancak yazılım kalitesini artırmaya yönelik dört aşamalı analizimizde kullanmak üzere tüm bu boyutları içeren ve fonksiyonları yerine getiren bir araç/yazılım ve yöntem mevcut durumda literatürde bulunmamaktadır. Bu amaçla, bu fonksiyonları yerine getirmek üzere bir yazılım geliştirilerek bu çalışmada elde edilen bir gereksinim materyali üzerinde analiz yöntemi olarak kullanılmıştır. 3.1 Materyal Bu çalışmada, materyal olarak 203 yazılım gereksinimi içeren ve bir simülatörün kabiliyet gereksinimlerini açıklayan bir Türkçe gereksinim kümesi kullanılmıştır. Bu gereksinim kümesi her bir gereksinimi ayrı birer cümle olarak ifade eden ve arzu edilen nitelikleri açıklayan metin halindeki bir gereksinim dokümanından oluşmaktadır. Bu kapsamda çalışmamızda kullanılabilir hale getirmek üzere başlangıçta elde edilen dokümandaki her bir cümleye bir gereksinim numarası verilerek gereksinimler sıralanmıştır. Dağınık bir dokümanda gereksinim olabilecek cümleleri noktaları kullanarak tanımak da mümkün olabilecek bir yaklaşımdır; ancak bu aşamada yazılıma fazla karmaşa getireceğinden bu kabiliyet yazılıma eklenmemiş ve bunun yerine cümleler manuel olarak sıralanarak bir numara verilmiştir. 28

Materyal olarak kullandığımız gereksinim metni Windows ortamında word formatından alınarak yazılımımızın gerektirdiği ve analizlerde kolaylık sağlayan text formatına çevrilerek yazılımımızda kullanılmıştır. 3.2 Yöntem Gereksinim kümelerinin hata analizinde kullanılacak bir yazılım aracının sahip olması gereken iki ana amaç Kiyavitskaya vd. (2008) tarafından; Gereksinim kümesindeki hatalı gereksinim cümlelerinin bulunması ve, Hatalı olarak tespit edilen gereksinim cümlesinin neden hatalı olduğunun kullanıcıya açıklanarak, kullanıcı tarafından o hatanın düzeltilmesi ve gereksinim kalitesinin arttırılması olarak ifade edilmiştir. Bu çalışmada, yukarıda belirtilen bu iki amacı sağlamak için gereksinim hatalarını otomatik olarak tespit edecek bir yazılım geliştirilmiştir. Yine Kiyavitskaya vd. (2008) tarafından, gereksinim hata analizinde kullanılacak başarılı bir yazılımın: % 100 geriye alma, kullanıcıyı bu aracı kullanmaktan vazgeçirmemek için çok fazla hatalı tespit yapmama, yeterince hassasiyete sahip olma, ve kullanıcının hızlıca yorum çıkarabilmesi ve pratik olması için analizin sonucunu kısa ve öz olarak kullanıcıya gösterme özelliklerine sahip olması gerektiği bildirilmiştir. Bu amaçla hazırlanan yazılımda, hata analizinde hassasiyetin sağlanması ve sonuçların kısa ve anlaşılır olarak kullanıcıya gösterilmesi hedeflenmiştir. Bununla birlikte hazırlanan yazılım analizler sırasında kullanıcı müdahalesine izin vermektedir. Burada kullanıcı müdahalesine izin verilmesi ayrıca önemlidir. Zira bu imkan hem ihtiyaç sahibi, hem de geliştirmeyi yapacak grubun aynı anda programı 29

kullanabilmesi ve analizleri beraber yorumlamasını sağlayabilir. Aslan (2002) ın ifade ettiği gibi yazılım gereksinim geliştirmesi tedarikçiden çok yüklenicilerin görevi olarak algılanmakta ve mevcut durumda tedarikçinin bu aşamaya dahli genelde ihmal edilmektedir. Bu da, ikinci bölümde açıklandığı gibi gereksinimlerin analizinde bazı sıkıntılara yol açmaktadır. Bu çalışmada Bölüm 1.2 de anlatılan ve yazılım gereksinim kalitesini arttıracağı düşünülen dört (kullanıcı müdahalesi hariç üç) aşamalı süreci Türkçe için uygulamak üzere Microsoft.NET 2.0 ortamında C# programlama dili ile üç aşamalı çalışan bir yazılım geliştirilmiştir. Yazılımın ismi Contract Weakness Analyser v1.0 olarak belirlenmiş ve bu yazılımın bir kopyası Ek 6 daki CD içeriğinde sunulmuştur. Bu yazılım öncelikle yazılım gereksinim kalite yönteminin Gereksinimlerin dilbilimsel açıdan belirli koşulları sağlayıp sağlamadığının kontrol edilmesi ve bu doğrultuda ifadelerle muğlaklığa sebep olan hata tiplerinin analiz edilerek ayıklanmasını içermektedir. Yazılımın ikinci aşamasında gereksinimlerin işlevsel olan ve işlevsel olmayan gereksinimler şeklinde sınıflandırılmasını sağlayacak fonksiyonlar yer almaktadır. Yazılımın üçüncü kısmında ise birbirine benzer ya da aynı ifadelerin tespit edilmesi sağlanmaktadır. 3.2.1 Yazılımın fonksiyon ve kabiliyetleri: Yazılım ana ekranda yer alan menüler yardımıyla Hata Tipi, İşlevsellik ve Benzerlik Analizleri yapabilmektedir. Yazılımın ana girişinde kullanımını açıklamaya yardım etmek için bir Help butonu bulunmakta ve buna tıklandığında yazılım hakkında bilgi vermektedir. Ana sayfada analizi yapılacak gereksinim dokümanının diline göre Türkçe ve İngilizce seçenekleri bulunmaktadır. Hata Tipi ve İşlevsellik analizi için Analyse, Benzerlik analizi için Similarity Check butonu bulunmaktadır. Benzerlik analizinin 30

keskinliğini belirlemek için ana sayfada % cinsinden ifade edilen benzerlik eşik değeri (similarity treshold) nin girilebileceği bir hane bulunmaktadır. Burada bu değer minimum 0 maksimum 100 olmalıdır, aksi halde yazılım yanlış girildiğini anlamakta ve bu girişe izin vermeyerek kullanıcıyı en alt satırdaki bilgiyle uyarmaktadır. Yazılımda çıkış için Exit butonu yer almaktadır. Yazılım analiz sonuçlarını ana ekran üzerinde özet olarak göstermekte, detaylı sonuç dosyalarının isimlerini göstermektedir. Yazılım ana sayfasının örnek görüntüsü şekil 3.1 de yer almaktadır. 3.2.1.1 Yazılımın girdileri Yazılım Windows XP ve üstü işletim sisteminde çalışmaktadır. Yazılımın ilk aşamasında analizi yapılmak istenen gereksinim dokümanı ŞARTNAME isminde bir text dosyası oluşturularak içine kopyalanmalıdır. Bu doküman yazılım ana sayfasındaki Open butonu kullanılarak bilgisayardan şekil 3.2 deki gibi seçilmelidir. Gereksinim dokümanında analizin yapılabilmesi için her bir gereksinimin bir numarası olmalıdır. Çünkü yazılım, sonuçları bu numaralara göre göstermektedir. Türkçe yi desteklemesi için yazılımda text dosyaları UTF-8 formatında seçilmiştir. ŞARTNAME dosyası içine konulan, sıralandırılmış, örnek bir gereksinim dokümanı şekil 3.3 de gösterilmektedir. Bununla birlikte Hata Analizinde kullanılacak hata tipi sözlükleri ve İşlevsellik Analizinde kullanılacak İOG sözlüklerinin içerisi gereksinim dokümanının ait olduğu alana uygun olarak doldurulması yazılımın kabiliyetini artıracaktır. Eğer önerilen hata tipleri ve İOG tiplerine ilave edilecek varsa bu sözlükler de yeni baştan oluşturulmalıdır. Sözlükler ile ilgili ayrıntı ilerleyen bölümlerde verilmektedir. 31

Şekil 3.1 Yazılım ana sayfasının örnek görüntüsü Şekil 3.2 Dosya seçim menüsü 32

Şekil 3.3 Örnek şartname dosyası 3.2.1.2 Muğlaklık hata tiplerinin analizi Yazılımın birinci kısmı olan ve muğlaklıklara sebep olan hata tipleri analizinde Kızılca ve Yılmaz (2008) ın çalışmasından alınan yazılımın birinci sürümü temel alınmıştır. Buna göre yazılım çizelge 2.2 de belirtilen 8 hata tipinden Zayıflık (Weakness) hariç diğer 7 sini yakalamak üzere yapılandırılmıştır. Bunlar: 1. Seçeneklilik (Optionality) 2. Öznellik (Subjectivity) 3. Belirsizlik (Vagueness) 4. Üstü Kapalılık (Implicity) 5. Çokluk (Multiplicity) 6. Maksadını Aşma (Over Specification) 7. Eksiklik (Incompleteness) olarak belirlenmiştir. Bu doğrultuda bu hata tiplerine ait metin formatında 7 adet hata sözlüğü oluşturulmuştur. Bu sözlüklerdeki kelimelerin 33

sözlüksel analizi gereksinim cümlesinde yapılarak şayet bu kelimelerden birisi gereksinim cümlesinde var ise, kelimenin ait olduğu hata tipinin o gereksinimde var olduğu analiz sonucunda bunu ŞARTNAME.txt dosyasının yer aldığı klasörde (bu klasörün ne olduğu önem taşımamaktadır.) yazılım tarafından oluşturulan Analysis_Results.txt ve SRS.txt dosyalarının içinde göstermektedir. Örnek bir hata sözlüğü (Vagueness-Belirsizlik hata tipi için) şekil 3.4 de gösterilmiştir. Hata sözlüklerinde birbirinden bağımsız olduğundan İngilizce ve Türkçe için hata tipine yol açan kelimeler birlikte konulmaktadır. Burada sözlüğe hata yaratacağı düşünülen ifadeler eklenebilmektedir. Analiz sonucunda oluşan örnek Analysis_Results.txt ve SRS.txt dosyaları şekil 3.5 de gösterilmiştir. SRS.txt dosyası Excel formatında da açılabilmekte ve sonuçları daha okunabilir göstermektedir. Bunun için Mouse üzerinden birlikte aç menüsünden Excel programının seçilmesi yeterli olmaktadır. Bu gösterim de yine şekil 3.5 de yer almaktadır. SRS.txt dosyasında bir gereksinim numarasında bir hata tipi için true yazıyorsa bu, söz konusu hata tipinin ilgili gereksinimde olduğu anlamına gelmektedir. Şekil 3.4 Örnek hata tipi sözlüğü 34

Şekil 3.5 Analiz sonucunda oluşan Analysis-Result.txt ve SRS.txt dosyaları Yazılımda ileriye yönelik olarak yeni oluşturulan bir hata tipine ait yeni bir sözlük kolayca ilave edilebilmektedir. Bunun için hata tiplerine ait tüm hata tipi sözlükleri dosyalarının adı Dictionaries.txt isimli bir dosyanın içine yazılmaktadır. Yazılım analizde kullanacağı hata tipi sözlüğü dosyalarını bu dosya içinden seçmektedir. Bu ayrıca, tüm bu hata tiplerine değil de sadece birkaç hata tipine özel sınırlı bir analiz yapılmak isteniyorsa ona da imkan tanımaktadır. Hata tipleri sözlüklerinin Dictionaries.txt dosyasının içine kaydedilişi şekil 3.6 da gösterilmiştir. Diğer hata tipi olan Zayıflık (Weakness) analizi İngilizce için gereksinim cümlesi içinde shall yardımcı fiilinin, Türkçe için gereksinim cümlesindeki yüklemin sonunda - ecektir, -acaktır eklerinin var olup olmadığına bakılarak, yazılım tarafından gömülü olarak yapılmaktadır. Yazılım burada İngilizce ya da Türkçe dilinden hangisi için analiz yapacağını yazılımın ana sayfasındaki menüde yer alan İngilizce ve Türkçe butonlarından hangisinin işaretlendiğine bakarak ayırt etmektedir. 35