Doğal Dilde Yazılmış Gereksinimlerin Analiz Yöntemleri ve bu Yöntemlerin Türkçe için Uygulanabilirliği

Doğal Dilde Yazılmış Gereksinimlerin Analiz Yöntemleri ve bu Yöntemlerin Türkçe için Uygulanabilirliği Natural Language Requirement Analysis Methods and Their Applicability for Turkish Halil KIZILCA Barış Kartalı Özel Proje Müdürlüğü Havelsan USA Inc.; Seattle, ABD hkizilca@havelsan.com.tr, halil.kizilca@incose.org A. Egemen YILMAZ Barış Kartalı Özel Proje Müdürlüğü Havelsan A.Ş., Ankara asimegemenyilmaz@yahoo.com Özet Gereksinim analizi, yazılım geliştirme sürecinin önemli adımlarından biridir. Gereksinimlerin düzgün ifade edilmesi, sürecin sonraki adımlarında kolaylık sağlamakla kalmayıp olası hataların azaltılmasına da yaramaktadır. Bu çalışmada doğal dilde gerek İngilizce, gerekse Türkçe yazılmış gereksinimlerin kalitelerinin artırılmasına yönelik bir yazılım önerisi sunulmaktadır. Bu bildiride, gereksinimlerin belirli kalite kriterlerini sağlayıp sağlamadığını temelde sözlüksel ve sözdizimsel teknikler ile kontrol etme prensibine dayanan yazılımın temel işlevleri, geliştirme planı ve mevcut durumu hakkında bilgi verilmektedir. Abstract Requirement analysis is one of the important steps in the software development process. Stating the requirements in a clear manner, not only eases the following steps in the process, but also reduces the number of probable errors. In this work, a software tool for the improvement of the natural language requirements written in English and Turkish, is proposed. In this proceeding, the main functionalities, the development plan and the current status of the relevant software, which principally depends on checking the quality criteria satisfied by the requirements by means of lexical and syntactic techniques, are given. 1. Giriş Yazılım gereksinimleri kalitesi, yazılım kalitesini belirleyen önemli faktörlerden biridir. Yazılım gereksinimlerinin kalite yönetimi, işlevsel olan/olmayan bütün gereksinimlerin doğal dilde ifade edilerek yazılmasının ardından, Söz konusu gereksinimlerin dilbilimsel (linguistic) açıdan belirli koşulları sağlayıp sağlamadığının kontrol edilmesi; Gereksinimlerin belirli ölçütlere göre (örneğin işlevsel olan ve olmayan gereksinimler şeklinde) sınıflandırılması, belirli durumlarda önceliklendirilmesi; Bu gereksinimlerin bir takım formal/yarı-formal yöntemler kullanılarak mümkün olduğunca modellenmesi, görselleştirilerek anlaşılırlığının artırılması şeklinde devam eden bir süreçtir. Gerek sistem, gerekse yazılım seviyesinde gereksinimlerin ifade edilmesi sırasında yaşanan güçlükler, pratikte çok sık rastlanan bir durum olup; geliştirme sürecinin ilerleyen bütün aşamalarında

gereksinimlerin yanlış anlaşılması; proje paydaşları tarafından farklı şekillerde yorumlanması gibi sorunlara yol açmaktadır. Dolayısıyla bütün gereksinimlerin, ileride açıklanan kalite kriterlerini sağladıklarından mutlaka emin olunması için gözden geçirilmesi gerekmektedir. Ancak, 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. İşlevsel gereksinimlerin işlevsel olmayan gereksinimlerden ayrıştırılması; işlevsel olmayan gereksinimlerin kalite, performans, idame ettirilebilirlik, güvenlik vb. şeklinde sınıflandırılması; bilhassa artırımlı (incremental) ve yinelemeli (iterative) projelerde hangi sürümde hangi gereksinimlerin gerçekleştirilip doğrulanacağının ve geçerleneceğinin belirlenmesi gibi faaliyetler de, geliştirme sürecinin önemli basamaklarıdır. Bu aşamalarda sıkça yapılan hatalar ise, işlevsel olmayan gereksinimlerin ileride halledilmek üzere göz ardı edilmesi; gereksinim önceliklendirme işleminin mantıksal bir çerçevede veya gerçekçi bir şekilde, sürümler arasında gereksinim ve iş yükü dağılımının ise dengeli bir şekilde yapıl(a)mamasıdır. Doğal dil ile yazılmış gereksinimlere karşı, farklı araştırmacıların farklı bir takım yaklaşımları olmuştur. Bunlardan bazıları doğal dil gereksinimlerinin tamamen ortadan kaldırılarak gereksinimlerin XML (Extensible Markup Language) [1], UML (Unified Modeling Language) [2], SDL (Specification and Description Language) [3] gibi bir takım modelleme teknikleri veya bir takım özel diller ile sembolize edilmesi gibi köktenci bir takım çözümler ortaya koymaya çalışırken; bazıları ise gereksinim yazımı faaliyetinin doğal dillerin basitleştirilmiş halleri üzerinde yapmanın sonradan yapılacak modellemelerde kolaylık sağlayacağını savunmuşlardır [4]. Şurası gerçektir ki, doğal dil dışındaki gösterimlerin teknik bilgi, beceri ve altyapı gerektiriyor olması, proje paydaşlarının gereksinim analizi faaliyetinden soğumasına ve projenin erken evrelerinde koordinasyon kopukluklarına yol açmaktadır. Dolayısıyla, her ne kadar başarılı ve basit gösterimler bulunsa da doğal dil ile yazılmış olan gereksinimlerin tamamen ortadan kaldırılması kısa vadede pek olası gözükmemektedir. Dünya genelinde, yazılım hatalarının %85 inin gereksinim hatalarından kaynaklanmakta olduğu tahmin edilmektedir [5]. Gereksinim hatalarının %49 unu yanlış bir takım varsayımlar ve gereksinimlerin yanlış yazılması; %29 unu gereksinimlerin unutulmuş veya atlanmış olması; %13 ünü yazılan gereksinimlerin birbiriyle çelişiyor veya tutarsız olması; %5 ini ise gereksinimlerin farklı yorumlanabilir, muğlâk ifadelerle yazılmış olması teşkil etmektedir [6]. Bunların yanı sıra, yapılmış olan diğer çalışmalar ise: Henüz gereksinim ve tasarım aşamasında fark edilen hataların, gelecekteki olası bozup yeniden yapma çalışmalarını (rework) %40-50 oranında azalttığını [7]; Hataların ileri geliştirme evrelerinde tespit edilmesinin hata düzeltme maliyetlerini 5 katına çıkarttığını, sistemin sahadaki kullanımı esnasında tespit edilmesinin ise bu maliyetlerin zaman zaman 100 katına kadar çıkmasına sebep olduğunu [8] göstermiştir. Dolayısıyla, gerek gereksinim analizi faaliyetinin, gerekse gereksinim kalitesinin çok büyük önem arz ettiği yadsınamaz bir gerçektir. Bu bildiriye konu olan çalışmada da, gereksinim kalitesinin artırılmasına yönelik bir yazılım geliştirilmesi hedeflenmiştir. Mevcut çalışmanın kapsamının çizildiği ve mevcut durumunun özetlendiği bu bildirinin 2. bölümünde gereksinim kalitesi ile ilgili tanımlar verilmekte ve literatürde gereksinim kalitesini artırmaya yönelik yapılmış olan diğer çalışmalara değinilmekte; 3. bölümde gereksinim yazılırken yapılan genel hatalar sınıflandırılmakta ve gereksinim dokümanı okunabilirliği üzerine tanımlar yapılmakta olup; 4. bölümde mevcut çalışmanın işlevleri ve geliştirme planı detaylandırılmaktadır. İngilizce metinler üzerinde uygulanmakta olan tekniklerin Türkçe yazılmış gereksinimler üzerine uygulanabilirliğinin tartışıldığı 5. bölümün ardından gelen son bölümde ise, genel tartışmalar yapılmakta ve gelecek çalışmalar özetlenmektedir. 2. Gereksinim Kalitesi ve Literatürdeki Çalışmalar Gereksinimlerin doğal dilde düzgün bir şekilde ifade edilmesi, tasarımdan başlayarak kabule, hatta bakımidame periyoduna kadar giden süreç açısından önemlidir. Bir gereksinim kümesi tarafından sağlanması gereken/beklenen genel özellikler aşağıdaki maddeler ile özetlenebilir [9],[10]: Bütünlük (Gereksinim kümesinin Daha sonra belirlenecektir gibi ifadeler içermiyor olması) Tutarlılık (Gereksinim kümesinin birbirleriyle veya üst seviye gereksinimler ile çelişen ifadeler içermiyor olması) Doğruluk (Gereksinim kümesinin gerçek operasyon ortamını düzgün bir şekilde tarif ediyor olması)

Değiştirilebilirlik (Gereksinim kümesinin farklı/bağımsız konulardaki hususları tek bir gereksinim içerisinde ifade etmiyor olması) Test Edilebilirlik (Gereksinim kümesindeki ifadeler ile test adımı ve prosedürü yazılabiliyor olması) İzlenebilirlik (Gereksinim kümesinin elemanlarının hem üst, hem de alt seviye gereksinim ve tasarım modülleri ile ilişkilendirilebilir olması) Mutlaklık (Gereksinim kümesinde farklı şekilde yorumlanmaya müsait ifadeler olmaması) Anlaşılabilirlik (Gereksinim kümesinin ifadelerin düzgün bir dilbilgisi ile yazılmış olması) Sıralandırılabilirlik (Gereksinim kümesindeki ifadelerin önem, aciliyet, değişkenlik, konu vb. ölçütlere göre sıralanabilir veya gruplanabilir olması) Yukarıdaki tanımlamalardan da anlaşılacağı üzere, gereksinimler ile ilgili kalite ölçütlerinin bazılarının her bir gereksinim başına ölçülmesi/kontrol edilmesi, bazılarının ise tüm gereksinim kümesi üzerinden ölçülmesi/kontrol edilmesi söz konusudur. Ayrıca yukarıdaki hususlardan birçoğunun kontrolü, muhakeme gerektirdiğinden dolayı ancak klasik gözden geçirme yöntemleri ile yapılabilir. Öte yandan belirli bir takım özelliklerin dolaylı veya doğrudan kontrolü, geliştirilen bir takım yazılımlar vasıtasıyla (yarı) otomatik hale getirilebilir. Söz konusu yazılımlarda, dilbilimsel yöntemlerin kullanılması ve gerçekleştirilmesi gerekmektedir. Dilbilimsel yöntemler, sözcüklerin kullanımına dair analizlerin yapıldığı sözlüksel (lexical) yöntemler ve sözcüklerin cümle içerisindeki dizilimlerine dayalı sözdizimsel (syntactic) yöntemler olarak iki ana dala ayrılır. Sözlüksel ve sözdizimsel yöntemlerin gereksinim analizinde kullanılabilirliği konusunda, özellikle 1990lı yıllardan sonra bazı araştırmacılar bir takım incelemeler ve çalışmalar yapmışlardır [11]-[31]. Bunların arasından, gereksinim kalitesini artırmaya yönelik ciddi ve kapsamlı ticari/akademik amaçlı yazılımlara dönüşmüş olanlar (yazarların bilgisi dâhilindekiler) ise aşağıda verilmiştir: Wilson ve diğerleri tarafından geliştirilmiş olan ARM [18],[19], Noh ve Gadia tarafından geliştirilmiş olan RAST [20], Fantechi, Fabbrini, Lami ve diğerleri tarafından geliştirilmiş olan QuARS [21]-[30]. Kasser ve diğerleri tarafından geliştirilmiş olan TIGER Pro [31], Yukarıda sözü edilen yazılımlar, İngilizce yazılmış gereksinimlerin kalitesini artırmaya yönelik olarak geliştirilmiştir. Sözlüksel yöntemlerin sözdizimsel yöntemlere kıyasla daha kolay gerçekleştirilebilir olmalarından dolayı, söz konusu yazılımların sözlüksel özellikleri de genellikle sözdizimsel özelliklerine göre daha güçlüdür. 3. Gereksinim Hataları ve Kalite Ölçütleri 3.1. Gereksinim Hataları Gereksinimlerin yazılması esnasında yapılan hatalar, geçmişte farklı araştırmacılar tarafından farklı şekillerde sınıflandırılmıştır. Bu çalışmada ise, önceden yapılmış olan tüm sınıflandırmalar göz önünde bulundurularak bir üst küme oluşturulmaya çalışılmıştır. Gereksinim mühendisliği faaliyetlerindeki hataların iki temel kaynağı olduğu söylenebilir: Mevcut alanı (domain) kavrama çalışmaları sırasında ortaya çıkan hatalar, ilgili alandaki kavramları ifade etmeye çalışırken ortaya çıkan hatalar. Gereksinimlerin ifade edilmesi sırasında karşılaşılan güçlükler ise: Gereksinimlerin ifade edilişi sırasında karşılaşılan, okunabilirlikle, bütünlük ve tutarlılıkla ilgili dilbilimsel güçlükler, Gereksinimlerin işlevsel olan ve olmayan gereksinimler şeklinde sınıflandırılması ve önceliklendirilmesi ile ilgili güçlükler, Görselleştirmeyle ilgili güçlükler olarak sınıflandırılabilir. 3.2. Gereksinimlerin İfade Edilmesi Bu çalışma esnasında, daha önce geliştirilmiş olan yazılımlarda tanımlanmış olan hata türleri incelenmiş, özellikle ARM ([18],[19]) ve QuARS ([21]-[30]) tarafından kullanılmakta olan tanımlar esas alınarak aşağıdaki sınıflandırma ve tanımlar yapılmıştır: Seçeneklilik (Gereksinimin okuyana kesin bir bilgi vermeyen, mümkün olduğunca vb. ifadeler içeriyor olması) Öznellik (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ı)

Belirsizlik (Gereksinimde niceleyici ifadeler bulunmayıp, tartışma yaratacak hızlı, güçlü, kullanımı kolay vb. belirsiz niteleyici ifadeler bulunması) Üstü Kapalılık (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 (Gereksinimin -meli, -malı kiplerini içermemesi, zorunluluk bildirmemesi) Eksiklik (Gereksinimde daha sonra belirlenecek vb. ifadeler bulunması) Çokluk (Gereksinimin aslında birden fazla gereksinim ifadesi içeriyor olması) Tanım Eksikliği (Gereksinimin, tanımı verilmemiş / belirtilmemiş kavramlar içeriyor olması) Atıf Eksikliği (Gereksinimin, bilinmeyen kaynaklara atıfta bulunuyor olması) Yukarıda belirtilmiş olan hatalardan Belirtim Eksikliği ve Atıf Eksikliği, ancak tüm gereksinim kümesinin analiz edilmesi sonucunda tespit edilebilir. Diğer tür hatalar ise, her bir gereksinimin tek başına analiz edilmesi sonucu bulunabilir. Tablo 1 de, söz konusu hata türlerini bulmaya yönelik gerekli analiz yöntemi listelenmiştir. Tablo 1: Hata Türleri ve Gerekli Analiz Yöntemleri ([18]-[31] Numaralı Referanslardan Uyarlanarak Oluşturulmuştur) Hata Türü Sözlüksel Analiz Sözdizimsel Analiz Seçeneklilik Öznellik Belirsizlik Üstü Kapalılık Zayıflık Çokluk Tanım Eksikliği Atıf Eksikliği 3.3. Gereksinim Doküman Okunabilirliği Okunabilirlik, bir metnin anlaşılabilirliğine dair bir ölçüttür. 1930 lu yıllardan itibaren, gerek A.B.D. de, gerekse İngiltere de İngilizce metinlerin okunabilirliklerine dair birçok ölçüt tanımlanmış; bu ölçütlerin doğrulukları üzerinde birçok araştırma yapılmıştır. Konu ile ilgili detaylı bilgi, DuBay in yapmış olduğu, konunun tarihsel gelişimini de özetleyen bir derleme çalışmasından [32] elde edilebilir. [32] numaralı kaynakta da belirtildiği üzere, 70 yılı aşkın süredir birçok araştırmacı tarafından sayısız okunabilirlik ölçütü tanımlanmaya çalışılmış, bunlardan sadece belli başlı birkaç tanesi başarıları ile ön plana çıkmıştır. Literatürdeki başlıca okunabilirlik ölçütleri: Coleman-Liau Okunabilirlik Endeksi [33], Otomatize Edilmiş Okunabilirlik Endeksi [34], ABD de Department of Defense tarafından resmi dokümanlarda mutlaka göz önünde bulundurulan Flesch Okuma Kolaylığı [35], Flesch-Kincaid Sınıf Seviyesi [36], Gunning Fog Okunabilirlik Endeksi [37], SMOG olarak bilinen Gobbledygook un Basit Ölçütü [38] ve Microsoft Office programları da dâhil olmak üzere birçok yazılım içerisinde kullanılmakta olan, Okuma Gücü Derecesi olarak da bilinen Bormuth Sınıf Seviyesi Endeksi [39] olarak sıralanabilir. İngilizce metinler üzerinde, kapsamlı saha çalışmaları yapılmış olduğundan adı geçen ölçütlerin güvenilirlik dereceleri hayli yüksektir. Bu ölçütlerin çoğu, en temel anlamda, kelime başına düşen harf (veya hece) sayısı ile cümle başına düşen kelime sayısı na bağlı olarak bir değer vermektedir. Bu değerin içinde bulunduğu aralık, metnin okunabilirliği hakkında bilgi (zorluk derecesi, hangi yaş grubuna veya hangi eğitim düzeyine hitap ettiği) vermektedir. Gunning-Fog Okunabilirlik Endeksi ve Gobbledygook un Basit Ölçütü, ise karmaşık kelime kullanımına bağlı ölçütlerdir. Bu ölçütlerin hesabında 3 heceden uzun kelimeler karmaşık olarak kabul edilir. Bormuth Sınıf Seviyesi nde ise kelimeler, gündelik olarak yaygın olarak kullanılanlar ve kullanılmayanlar olarak ikiye ayrılmaktadır. Tablo 2 de, söz konusu bütün ölçütlerin bağımlı olduğu özel parametreler listelenmiştir. İngilizce de hece sayma işlemi, istisnai kurallar içermesi nedeniyle bir yazılımda hayata geçirilmek istenildiğinde karmaşık bir işlemdir. Karmaşık kelime, yaygın kelime gibi özel tanımlar da yazılımcılar açısından zorluk çıkarabilecek kurallar getirmektedir. Gereksinim dokümanlarının okunabilirliğinin, gereksinim kalitesine dair bir kriter oluşturabileceği, daha önce yapılan çalışmalarda da yapılmış olan bir kabuldür. Örneğin QuARS yazılımında Coleman-Liau; ARM yazılımında ise Coleman-Liau nun yanı sıra Flesch, Flesch-Kincaid ve Bormuth ölçütleri

kullanılmıştır. RAST ve TIGER Pro yu geliştiren araştırmacılar ise okunabilirliği, bir kalite kriteri ve analiz konusu olarak ele almamışlardır. Tablo 2. Okunabilirlik Ölçütleri ve Bağımlı Bulundukları Özel Parametreler (İlgili Ölçütlerin Tanımları Kullanılarak Oluşturulmuştur). Ölçüt Adı Hece Karmaşık Sayma Kelime ve Zorunluluğu Yaygın Kelime gibi Özel Tanımlar Coleman-Liau Okunabilirlik Endeksi Otomatize Edilmiş Okunabilirlik Endeksi Flesch Okuma Kolaylığı Flesch-Kincaid Sınıf Seviyesi Gunning Fog Okunabilirlik Endeksi Gobbledygook un Basit Ölçütü Bormuth Sınıf Seviyesi Endeksi 3.4. Gereksinim Dokümanı Bütünlüğü ve Tutarlılığı Gereksinimlerin bütünlük ve tutarlığının kontrolü de hem sözlüksel, hem de sözdizimsel bir takım analizler gerektirmektedir. Bu kapsamda, bütünlüğü sağlamak adına genel olarak sözlüksel, tutarlılığı sağlamak adına da genel olarak sözdizimsel tekniklerin kullanıldığını söylemek yanlış olmaz. Sözlüksel analizler vasıtasıyla gereksinim kümesinin tek el den çıkmış olduğunu garantilemek adına terminoloji bütünlüğü sağlanabilir. Bir başka deyişle, bir kavramın birden fazla eş/yakın anlamlı karşılığı varsa, tüm gereksinim kümesi içinde bunlardan sadece birinin kullanılması sağlanmalıdır. Örneğin İngilizce bir gereksinim kümesinde İnsan Makine Arayüzü manasında yer yer Man-Machine Interface, yer yer Human-Machine Interface kullanılmışsa; bunlar tek bir terminoloji altında toplanmalıdır. Belirli bir konudaki gereksinimlerin farklı kişiler/ekipler tarafından birbirlerinden bağımsız ve koordinasyonsuz olarak yazılması durumunda; bu kümenin içerisinde aynı ihtiyacın benzer ifadelerle tekrarlanmış olma olasılığı yüksektir. Ortak kelime sayılarını toplam kelime sayılarına oranlayarak iki cümlenin birbiri ile ne kadar benzer olduğunu gösteren Jaccard Endeksi, Dice Endeksi ve Kosinüs Endeksi gibi bir takım ölçütler bulunmaktadır [40]. İki cümlenin birbirine yakın olması durumunda 1 e yakın değerler veren bu ölçütler, 2001 yılında yayımlanmış olan bir çalışmada [41] gereksinim mühendisliği alanında da başarıyla uygulanmıştır. Yapılmakta olan çalışmada, sözlüksel analizlerle bütünlük kontrolü; sözdizimsel analizlerle tutarlılık kontrolü yapılması hedeflenmiştir. Benzerlik ölçütleri olarak ise, şu an için başarıları daha önce ([41] numaralı çalışmada) tescillenmiş olan Jaccard Endeksi, Dice Endeksi ve Kosinüs Endeksi ölçütleri seçilmiştir. 3.5. İşlevsel Olmayan Gereksinimlerin Ayrıştırılması ve Sınıflandırılması Daha önce de belirtildiği üzere, işlevsel gereksinimler üzerinde yoğunlaşılıp işlevsel olmayan gereksinimlerin bir kenara itilmesi ve göz ardı edilmesi, yaygın bir problemdir. Özellikle, gereksinimlerin düzgün bir şekilde organize edilmiş bir teknik şartname içerisinde sunulmadığı; geliştirme ekibine örneğin bir takım toplantılarda alınan kararların toplantı tutanakları içerisinde karışık bir formatta verildiği durumlarda: Metin(ler) içerisinden gereksinim olduğu düşünülen ifadelerin tanınması ve gereksinimler oluşturulması, Bu gereksinimlerin işlevsel olan/olmayan gereksinimler olarak ayrılması, İşlevsel olmayan gereksinimlerin konularına göre sınıflandırılması gerekmektedir. Yakın dönemde yapılmış ve yayımlanmış olan bir çalışmada [42] işlevsel olmayan gereksinimler, aslen sözlüksel bir teknik olan anahtar kelimeye dayalı sınıflandırma yöntemi ile sınıflandırılmıştır. Söz konusu çalışmada, her bir konu başlığı için bir takım İngilizce anahtar kelimeler (veya örüntüler, harf öbekleri) belirlenmiş; bu anahtar kelimelerin ayrıştırma işlemindeki güvenilirlik dereceleri yapılan deneyler/denemeler ile test edilmiştir. Bu çalışmada, [42] numaralı kaynakta yapılmış olan çalışmaya benzer şekilde anahtar kelimeye dayalı sınıflandırma yönteminin kullanılması hedeflenmiştir. Ancak daha genel ve daha kapsamlı bir sınıflandırma yapmak amacıyla; [43] ve [44] numaralı kaynaklarda yapılmış olan, işlevsel olmayan gereksinimleri iki seviyede ve daha geniş bir şekilde sınıflandırmakta olan taksonominin kullanılmasına karar verilmiştir. 3.6. Gösterimle İlgili Hatalar Gereksinimlerin görselleştirilerek anlaşılırlığının artırılmasına ilişkin birçok farklı çalışma devam etmektedir. Gösterimle ilgili hatalar, genellikle gösterim şekilleriyle yakından ilişkili olmakla birlikte çeşitli ölçütlerle izlenebilmektedir. Gerek gösterim şekline olan bağımlılığı, gerekse bu gösterim şekillerinin çeşitliliği göz önüne alınarak, gösterimle ilgili hatalar bu çalışma kapsamında henüz ele alınmamıştır.

3.7. Gereksinim Kalite Ölçütleri Bu çalışmada, Bölüm 3.1 de tanımlanmış olan hata türleri baz alınarak ve tespit edilen hatalara dayalı olarak; Seçeneklilik Oranı, Öznellik Oranı, Belirsizlik Oranı, Üstü Kapalılık Oranı, Zayıflık Oranı, Eksiklik Oranı, Çokluk Oranı, Tanım Eksikliği Oranı, Atıf Eksikliği oranı gibi ölçütler tanımlanmıştır. Bu ölçütlerden her biri, 0 a yakın olması durumunda ilgili hususta kalite yüksekliğini, 1 e yakın olması durumunda ise kalite düşüklüğünü belirtmektedir. Bu tanımların yanı sıra, aslında hata olmayıp da her bir gereksinimin veya tüm gereksinim kümesinin kalitesi hakkında fikir verebilecek bir takım ölçütler tanımlamak da mümkündür. Bu çalışmada, ayrıca aşağıdaki ölçütler de tanımlanmış ve kullanılmıştır: Yorum Frekansı (Gereksinimlere yapılan yorumların sayısının toplam gereksinim sayısına oranı) Okunabilirlik Endeksi (İlerleyen paragraflarda daha detaylı açıklanacaktır) Yönlendirme Frekansı (Gereksinim kümesi içerisinde Şekil lere, Tablo lara, Not lara ve Tanım lara yapılan yönlendirmelerin tüm gereksinimlere oranı) Açıklama Eksikliği Oranı (Gereksinim kümesi içerisinde uzun hali verilmemiş olan kısaltmaların sayısının tüm gereksinimlere oranı) 4. Çalışmanın Kapsamı ve Geliştirme Yaklaşımı Gereksinim mühendisliğinin 2 temel aşaması olduğu söylenebilir. 1. Mevcut alanı (domain) kavrama, 2. Kavranılanı düzgün ifade etme. İlk aşamada yapılan en yaygın hatalar; Yanlış kavram/olguların ortaya konması ve Belirli hususların unutulması/atlanması olarak ifade edilebilir. İkinci aşamada sık yapılan hataları ise gereksinimlerin ifade edilmesi esnasında yapılan: Tutarsızlıklar, Yanlışlıklar, Muğlaklıklar vb. teşkil etmektedir. Bu kavramlar ve birbirleri ile ilişkileri, Tablo 3 te listelenmiştir. Bu çalışmanın temel amacı ikinci aşamada yapılan hatalara odaklanarak, yazılım yardımı ile bu hataların en aza indirgenmesini sağlamaktır. Tablo 3. Gereksinim Mühendisliği Aşamaları, Bu Aşamalarda Yapılan Hataların Tipleri ve bu Hataların İlişkili Olduğu Gereksinim Özellikleri Gereksinim Mühendisliği Aşamaları Mevcut Alanı Kavrama İlgili Alandaki Kavramları İfade Etme Gereksinim Hata Tipleri Yanlış Kavram/ Olgular Unutulan/ Atlanan Konular ve Hususlar Seçeneklilik Öznellik Belirsizlik Üstü Kapalılık Zayıflık Çokluk Tanım Eksikliği Atıf Eksikliği Gereksinim Özellikleri Doğruluk Bütünlük Tutarlılık Değiştirilebilirlik Test Edilebilirlik İzlenebilirlik Mutlaklık Anlaşılabilirlik Sıralandırılabilirlik Bu bölümde çizilmiş olan ana resim ile 2. ve 3. bölümlerde yapılmış olan tanımlamaları/tartışmaları toparlamak ve bir başka şekilde ifade etmek gerekirse; bu çalışmanın amacı, sözlüksel ve sözdizimsel teknikler kullanılarak: Tüm gereksinimlerdeki hataları bularak (Bölüm 3.2 ve Tablo 1 de sözü edildiği üzere) türlerine ayıran, belirli hataları otomatik olarak düzelten (TEMEL FONKSİYONALİTE 1); (Bölüm 3.2, 3.3 ve 3.7 de sözü edildiği üzere) gereksinim başına veya gereksinim kümesi için genel olarak kalite ölçütleri çıkaran (TEMEL FONKSİYONALİTE 2); Verilmiş olan bir metin içerisinden gereksinim belirten ifadeleri bularak bir gereksinim kümesi oluşturan (TEMEL FONKSİYONALİTE 3); Söz konusu gereksinimleri (Bölüm 3.5 te sözü edildiği üzere) işlevsel olan ve olmayan gereksinimler olarak ayrıştıran; işlevsel olmayan gereksinimleri konularına göre iki seviyeli bir şekilde sınıflandıran (TEMEL FONKSİYONALİTE 4); Oluşturulan gereksinimleri (Bölüm 3.4 te sözü edildiği üzere) tutarlılık ve bütünlük açısından analiz ederek gerekli indirgemeleri yapan (TEMEL FONKSİYONALİTE 5); Gereksinimleri, XML tabanlı özel bir formatta operasyonel senaryolara çevirerek resimsel

gösterimlerini sağlayan (TEMEL FONKSİYONALİTE 6) bir gereksinim yönetim yazılımının geliştirilmesi hedeflenmiştir. Teknik fizibilite amacıyla, söz konusu yazılımın (yukarıda sözü edilen 1 numaralı TEMEL FONKSİYONALİTE sini gerçekleştirmek üzere): Microsoft Excel deki formülasyon mantığını kullanan, Sonrasında da Microsoft Office uygulamaları içerisinde çalışabilecek makrolar oluşturmak için Visual Basic te yazılmış iki prototipi geliştirilmiştir. Gereksinim hatalarına neden olan İngilizce kelimelerden bir liste oluşturulmuş; söz konusu prototip yazılımların, mevcut bir takım İngilizce gereksinimlerdeki hataları başarı ile bulmakta ve sınıflandırmakta olduğu gözlenmiştir. İlerleyen aşamada, yazılımın MIL-STD-498 de tanımlı geliştirme süreçlerine uyularak ve de artırımlı bir yaklaşım ile geliştirilmesine karar verilmiş olup: Birinci sürümde TEMEL FONKSİYONALİTE 1 ve 2 nin, İkinci sürümde TEMEL FONKSİYONALİTE 3 ve 4 ün, Üçüncü sürümde TEMEL FONKSİYONALİTE 5 in, Dördüncü ve son sürümde ise TEMEL FONKSİYONALİTE 6 nın hayata geçirilmesi planlanmıştır. Geliştirme esnasında yazılımın kendi gereksinimlerinin de sürekli kayıt ve değişiklik kontrolü altında tutulması hedeflenmiştir. Yazılımın kendi gereksinimlerin kalitesinin, yazılımın kendisi kullanılarak artırılması planlanmıştır. Böylece teorik/akademik bir bakış açısıyla yapılmakta olan öneriler, gerçekte geliştirilmekte olan bir yazılımın kendi gereksinimleri üzerinde de pratik/endüstriyel anlamda denenmiş ve kendi saha çalışması üzerinde sınanmış olacaktır. Bu şekilde, özyinelemeli (recursive) bir gereksinim iyileştirme çalışması yapılmış olacağı, bu çalışmanın sonuçlarının da akademik açıdan ayrı bir değeri olacağı değerlendirilmektedir. Konu ile ilgili literatür taramasını müteakip söz konusu yazılımın geliştirme ve sürüm planları ile takvimleri tamamlanmış, hem İngilizce hem de Türkçe hata sözlükleri oluşturulmuştur. Halen, birinci sürümün gereksinim analizi tamamlanmış olup tasarım çalışmalarına devam edilmektedir. 5. Söz Konusu Yöntemlerin Türkçe ye Uyarlanabilirliği Önceki bölümlerde sözü edilmiş olan yöntemlerin hayata geçirilmesi esnasında, söz konusu yöntemlerin Türkçe metinlere uyarlanabilirliğinin tartışılması bu çalışmanın ikincil bir amacıdır. Türkçe nin eklemeli bir dil olması, bazı dilbilimsel analizlerin yapılmasını hayli zorlaştırmaktadır. Sert ünsüzlerin yumuşaması gibi kurallar dolayısıyla zaman zaman ek alan kelimelerin kökleri; ünsüz benzeşmesi ve ünlü uyumu dolayısıyla da zaman zaman ekler değişime uğramakta olup, bu gibi durumlar sözlüksel ve sözdizimsel analizleri zorlaştırmaktadır. Vurgu yapmak amacıyla devrik cümle kullanımının İngilizce ye göre daha yaygın olması, sözdizimsel analizleri zorlaştırmaktadır. Türkçe deki kiplerin fiillere ek olarak gelmesi, İngilizce deki gibi ayrı yardımcı fiiller bulunmaması örneğin zayıflık sınıfındaki hataların analizini farklı kılmaktadır. Ayrıca İngilizce de farklı amaçlar ile kullanılan may, can gibi farklı yardımcı fiillerin Türkçe de tek bir karşılığının bulunması da potansiyel bir problem alanı oluşturmaktadır. Türkçe metinlerin okunabilirliği üzerine yapılmış çalışmaların azlığı da bir başka husustur. Literatürde bu konuda (yazarların bilgisi dâhilinde), sadece Ateşman ın 1997 yılında yapmış olduğu çalışma bulunmaktadır [45]. Ne yazık ki, bu ölçütün güvenilirliği üzerine (yazarların bilgisi dâhilinde) araştırmalar da ancak yakın geçmişte başlamış olup; söz konusu çalışmaların ([46],[47],[48]) sayısı da henüz sınırlıdır. Öte yandan İngilizce metinler için tanımlanmış olan ölçütlerin Türkçe ye bire bir uygulanabileceğini düşünmek, anlamsız bir iyimserlik olacaktır. Zira eklemeli bir dil olması itibarı ile Türkçe kelimelerdeki harf ve hece sayısı hayli yüksek olabilmektedir. Bu da, ölçütlerin bire bir uygulanması halinde Türkçe gereksinim okunabilirliğinin (haksız yere) düşük çıkmasına ve yanlış çıkartımlar yapılmasına yol açabilir. Ayrıca 3 heceden uzun olan kelimelerin karmaşık olarak kabul edilmesi de benzer nedenler ile Türkçe için uygun bir yaklaşım olmayacaktır. İngilizce yazılmış işlevsel olmayan gereksinimlerin otomatik olarak sınıflandırılması çalışmasında [42] yazarlar, sona gelen eklerin yarattığı problemlere değinmişlerdir. Bu nedenle; yazarlar tarafından, söz konusu problemlerin Türkçe de çok daha fazla olacağı düşünülmektedir. Okunabilirlik ölçütlerinde olduğu gibi, Jaccard, Dice ve Kosinüs Endeksleri gibi benzerlik ölçütlerinin de Türkçe ye bire bir uyarlanması çok mümkün olmayabilir. İki cümle arasındaki ortak kelime sayısı temeline dayanan bu ölçütler, aynen kullanılmaları durumunda eklemeli bir dil olması dolayısıyla

Türkçe de yanlış sonuçlara yol açabilirler. Bu nedenle, kelimelerin köklerinin ortaklığına dayalı yeni ölçütlerin tanımlanması gerekebilir. 6. Tartışma ve Sonuç Yazılım geliştirme süreç adımları arasındaki geçişlerin artık otomatize edilmekte olduğu 21. yüzyılda, otomasyon konusundaki en büyük sıkıntılar halen gereksinim analizi aşamasında yaşanmaktadır. Gereksinim ifadelerindeki hataların tespit edilmesi, hatta düzeltilmesi; gereksinim dokümanlarının kalitesinin ölçülmesi; gösterimsel yöntemler ile gereksinimlerden tasarıma geçiş işlemlerinin otomatik hale getirilebilmesinin, söz konusu sıkıntıları bir nebze olsun azaltabileceği yazarlar tarafından değerlendirilmektedir. Bu çalışmada, bu amaçla bir yazılım aracı geliştirilmesi hedeflenmiştir. Geliştirilmekte olan prototip yazılım, bu bildirinin kaleme alındığı tarihte sekiz tipteki hatanın altısını İngilizce metinler içerisinden otomatik olarak başarıyla ayıklayabilmektedir. An itibarı ile ayıklanamayan hatalar ise Tanım Eksikliği ve Atıf Eksikliği olup, bu sınıftaki hataların klasik gözden geçirme yöntemleri ile tespit edilmeye çalışılmasının daha uygun olacağı değerlendirilmektedir. Klasik gözden geçirmeler sırasında Tanım Eksikliği hatalarının fark edilme etkinliğinin artırılması için "Kavramsal Sözlük oluşturulması önerilmektedir. Bu sözlüğün tutarlı kullanılması sayesinde, hem alana özgü kavramlardan birinin tanımsız kalmasının; hem de eş anlamlı olduğu düşünülen, ancak beraber kullanıldığında karışıklıklara yol açabilecek ifadelerin önüne geçilmiş olacağı değerlendirilmektedir. Gereksinim Dokümanı Bütünlüğü ve Tutarlılığı na da hizmet edecek bu işlevselliğin, ilerleyen sürümlerde yazılıma kazandırılması; sözlük terimleri ve eş anlamlı terimlerin gereksinim dokümanı içerisinde kullanımına ilişkin ölçütlerin belirlenmesi, üçüncü sürümde yapılması planlanan faaliyetler arasındadır. Mevcut yazılım ile Türkçe metinlerin analizi yapılmak istenildiğinde, sekiz tipteki hatanın beşi Türkçe metinler içerisinden otomatik olarak ayıklanabilmektedir. İngilizce den farklı olarak, Türkçe metinlerde zayıflık sınıfındaki hataları tespit etmek oldukça güçtür. İngilizce de may, can, should gibi kelimelerin aratılması ile kolayca yapılabilen analizler, sondan eklemeli olan dilimizde sonuç vermemektedir. Mevcut sürümle otomatik olarak ayıklanan örnek hatalı ifadeler ve ilişkili oldukları hata türleri, Tablo 4 de verilmiştir. Söz konusu yazılımın gelecek sürümleri ile gerek Türkçe, gerekse İngilizce metinlerde elde edilecek sonuçlar, ileri tarihlerde sunlacak bildiri ve yazılacak makalelerde daha detaylı olarak akademik dünya ile paylaşılacaktır. Tablo 4. Mevcut Sürümün Ayıklayabildiği Hata Türleri ve Örnekler. Hata Türü Örnek Hatalı İfade Sistem, doküman okunabilirlik veya Seçeneklilik doküman bütünlük analizi yapacaktır. Öznellik Belirsizlik Üstü Kapalılık Eksiklik Çokluk 7. Kaynaklar Sistem, yapılan analiz sonuçlarını açıkça belirtecektir. Sistem, analiz kriteri değişikliklerine zamanında yanıt verecektir. Sistem, aşağıdaki gereksinimleri gerçekleştirecektir. Sistem Coleman-Liau Okunabilirlik Endeksi ni ve daha sonra belirlenecek endeksleri hesaplayacaktır. Sistem işlevsel olan/olmayan gereksinimlerin ayrıştırılmasını ve gösterimle ilgili hataların analizini gerçekleştirecektir. [1] Chi, Y.-L., Lo, K.-M., An XML-based Software Requirement Document for System Development, Workshop on Databases and Software Engineering. Report No: 2002ICS, Feng Shia University, 2006. [2] Subramaniam, K., Liu, D., Far, B. H., Eberlein, A., UCDA: Use Case Driven Development Assistant Tool for Class Model Generation, Proceedings of the 16 th International Conference on Software Engineering and Knowledge Engineering, 2004. [3] Bontemps, Y., Heymans, P., LSCs: That s the Name of the Game! A Specification Framework based on Live Sequience Charts and Game Theory, Proceedings of the International Conference on Requirements Engineering, 2003. [4] Clarke, R. J., Windridge, P. C., Dong, D., Effective XML Representation for Spoken Language in Organisations, Proceedings of the 6 th International Conference on Enterprise Information Systems (ICEIS 2004), pp. 488-494, 2004. [5] Young, R. R., Effective Requirements Practices, Addison-Wesley, Boston, 2001. [6] Hooks I. F., Kristin, A. F., Customer-Centered Products: Creating Successful Products Through Smart Requirements Management, AMACOM, New York, 2001. [7] Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice-Hall, Inc. 1981. [8] Boehm, B., Basili, V.R., Software Defect Reduction Top 10 List, IEEE Computer, vol. 34, no. 1, pp. 135-137, January 2001.

[9] Department of Defense, DoD MIL-STD-490A Specification Practices, June 4, 1985. [10] The Insitute of Electrical and Electronics Engineering, IEEE Std 830-1993: Recommended Practice for Software Requirements Specifications, December 2, 1993. [11] Hooks, I., Writing Good Requirements, Proceedings of the 3rd International Symposium of the INCOSE, vol. 2, 1993. [12] Rolland, C., Proix, C., A Natural Language Approach for Requirements Engineering, Proceedings of the 4th International Conference on Advanced Information Systems Engineering, 1992. [13] Hanks, K.S., Knight, J.C., Strunk E.A., Erroneous Requirements: A Linguistic Basis for Their Occurrence and an Approach to Their Reduction, Software Engineering Workshop - NASA Goddard Space Flight Center, 2001. [14] Hanks, K.S., Knight, J.C., Strunk E.A., A Linguistic Analysis of Requirements Errors and Its Application, Technical Report CS-2001-30 / University of Virginia Department of Computer Science, 2001. [15] Ambriola, V., Gervasi, V., Processing Natural Language Requirements", Proceedings of the 12th IEEE Conference on Automated Software Engineering (ASE '97). [16] Macias, B., Pulman, S.G., Natural Language Processing for Requirement Specifications. in Safety-Critical Systems: Current Issues, Techniques and Standards (ed: Redmill, F., Anderson, T.), London: Chapman-Hall, 1993. [17] Firesmith, D. Specifying Good Requirements, Journal of Object Technology, vol. 2, no. 4, July-August 2003. [18] Wilson, W.M., Rosenberg, L.H., Hyatt, L.E., Automated Quality Analysis of Natural Language Requirement Specifications, http://satc.gsfc.nasa.gov/support/pnsqc_oct96/pnq.ht ml. [19] Wilson W.M., Rosenberg L.H., Hyatt L.E., Automated Analysis of Requirement Specifications, Proceedings of the 19th International Conference on Software Engineering, May 1997. [20] Noh, S.-Y., Gadia, S.K., RAST: Requirement Analysis Support Tool Based on Linguistic Information, Technical Report 03-08, Computer Science - Iowa State University, 2003. [21] Fantechi, A., Gnesi, S., Ristori, G., Carenini, M., Vanocchi, M., Moreschini, P., "Assisting requirement formalization by means of natural language translation", Formal Methods in System Design, vol. 4, no.3, pp. 243-263, 1994. [22] Fantechi, A., Fusani, M., Gnesi, S., Ristori, G., "Expressing properties of software requirements through syntactical rules", Technical Report: IEI-CNR, 1997. [23] Fabbrini, F., Fusani, M., Gervasi, V., Gnesi S., Ruggieri, S., Achieving Quality in Natural Language Requirements, Proceedings of the 11th International Software Quality Week, May 1998. [24] Fabbrini, F., Fusani, M., Gervasi, v., Gnesi, S., Ruggieri, S., "On linguistic quality of Natural Language Requirements", Proceedings of 4th International Workshop on Requirements Engineering: Foundations of Software Quality (REFSQ 98), June 1998. [25] Lami, G., "Towards an Automatic Quality Evaluation of Natural Language Software Specifications", Technical Report B4-25-11-99: IEI-CNR, 1999. [26] Fabbrini, F., Fusani, M., Gnesi, S., Lami, G., Quality Evaluation of Software Requirement Specifications, Proceedings of Software & Internet Quality Week, May 31-June 2, 2000. [27] Fabbrini, F., Fusani, M., Gnesi, S., Lami, G., "An Automatic Quality Evaluation for Natural Language Requirements", Proceedings of the 7th International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ 01), June 2001. [28] Lami, G., Gnesi, S., Fabbrini, F., Fusani, M., Trentanni, M., "An Automatic Tool for the Analysis of Natural Language Requirements", Proceedings of the 7th International Workshop on RE: Foundation for Software Quality (REFSQ'2001), June 2001. [29] Fabbrini, F., Fusani, M., Gnesi, S., Lami, G., "The Linguistic Approach to the Natural Language Requirements Quality: Benefits of the use of an Automatic Tool", Proceedings of 26th Annual IEEE Computer Society - NASA Goddard Space Flight Center Software Engineering Workshop, November 2001. [30] Lami, G., QuARS: A Tool for Analyzing Requirements, Technical Report: CMU/SEI-2005-TR- 014, ESC-TR-2005-014, September 2005. [31] Kasser, J., "A Prototype Tool for Improving the Wording of Requirements," Proceedings of International Symposium on Systems Engineering - International Council on Systems Engineering, 2002. [32] DuBay, W.H, The Principles of Readability: A Brief Introduction to Readability Research, 2004, http://www.eric.ed.gov/ericdocs/data/ericdocs2sql/con tent_storage_01/0000019b/80/1b/bf/46.pdf. [33] Coleman, M., Liau, T. L., A computer readability formula designed for machine scoring, Journal of Applied Psychology, vol. 60, pp. 283-284, 1975. [34] Smith, E. A., Senter, R. J., Automated readability index, AMRL-TR-66-22, Wright-Patterson AFB Aerospace Medical Division, 1967. [35] Flesch, R, A new readability yardstick, Journal of Applied Psychology, vol. 32, pp. 221-233, 1948. [36] Kincaid, J. P., Fishburne Jr., R. P., Rogers, R. L., Chissom, B. S., Derivation of new readability formulas (Automated Readability Index, Fog Count and Flesch Reading Ease Formula) for Navy enlisted personnel, Research Branch Report 8-75, TN: Naval Technical Training, U. S. Naval Air Station, 1975. [37] Gunning, R., The Techniqıe of Clear Writing, New York: McGraw-Hill, 1952. [38] McLaughlin, G. H., SMOG Grading A New Readability Formula, Journal of Reading, pp. 639-646, May 1969. [39] Bormuth, R. H., Readability. A New Aprroach, Reading Research Quarterly, vol. 1, pp. 79-132, 1966. [40] Pang-Ning, T., Steinbach, M., Kumar, V., Introduction to Data Mining, Boston: Addison Wesley, 2005.

[41] Natt och Dag, J., Regnell, B., Carlshamre, P., Andersson, M., Karlsson, J., Evaluating Automated Support for Requirements Similarity Analysis in Market- Driven Development, Proceedings of 7th Int. Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ 2001), June 2001. [42] Cleland-Huang, J., Setimi, R., Zou X., Solc, P., Automated Classification of Non-functional Requirements, Requirements Engineering, vol. 12, pp. 103 120, 2007. [43] Cysneiros, L. M., Leite J. C. S. d. P., Neto J. d. M. S., A Framework for Integrating Non-Functional Requirements into Conceptual Models, Requirements Engineering, vol. 6, pp. 97 115, 2001. [44] Chung, L., Nixon, B., Yu, E., Mylopoulos, J., Nonfunctional Requirements in Software Engineering, Dordrecht: Kluwer Academic Publications, 2000. [45] Ateşman, E. Türkçe de Okunabilirliğin Ölçülmesi, Dil Dergisi, cilt 58, s. 71-74, 1997. [46] Zorbaz, K. Z., Türkçe Ders Kitaplarındaki Masalların Kelime-Cümle Uzunlukları ve Okunabilirlik Düzeyleri Üzerine Bir Değerlendirme, Eğitimde Kuram ve Uygulama (Journal of Theory and Practice in Education), cilt 3, sayı 1, s. 87-101, 2007. [47] Çiftçi, Ö., Çeçen, M. A., Melanlıoğlu, D., Altıncı Sınıf Türkçe Ders Kitaplarındaki Metinlerin Okunabilirlik Açısından Değerlendirilmesi, Elektronik Sosyal Bilimler Dergisi, cilt 6, sayı 22, s. 206-219, Güz 2007. [48] Yazıcı, K., Yeşilbursa, C. C., Sosyal Bilgiler Dersinde Yazılı Materyallerin Öğrencilerin Okuma Seviyelerine Uygunluğunun Belirlenmesinde Kullanılan Ölçme Araçları, Türkiye Sosyal Araştırmalar Dergisi (Turkish Journal of Social Research), cilt 11, sayı 1, Nisan 2007.