Yazılım Gereksinim Analizi

1. 1. Gereksinim Geliştirme

1.1. Amaç

Gereksinim geliştirmenin amacı; kullanıcı, ürün ve ürün bileşeni gereksinimlerinin analizi ve üretilmesidir.

1.2. Giriş

Bu işlem alanı CMMI’da belirtildiği üzere 3 tip gereksinim tanımlar : Müşteri gereksinimi, ürün gereksinimi ve ürün bileşen gereksinimleri. Bu gereksinimler ilgili paydaşların gereksinimlerini adresler. Bununla beraber gereksinimler aynı zamanda tasarım çözümleri tarafından seçilen kısıtları da adresler.

Yazılım geliştirme süreci aşamaları:

• Gereksinim Analizi / Requirements (Requirements Analysis)
• Spesifikasyon / Specification (Functional Specification)
• Mimari / Architecture (Software Architecture)
• Dizayn / Design (Software Design)
• İmplementasyon (Programlama) / Implementation (Computer Programming)
• Test / Testing (Software Testing)
• Sahaya Yerleştirme / Deployment (Software Deployment)
• Bakım / Maintenance (Software Maintenance)

Bütün geliştirilen projelerin gereksinimleri vardır. Bir projenin bakımına odaklanıldığında, ürün ya da ürün bileşenlerinde değişiklik yapılırken varolan gereksinim, tasarım ve implementasyondaki değişiklikler baz alınır. Müşteri ya da kullanıcının isteklerinde bir değişiklik olursa ya da gereksinim geliştirme işleminden alınan yeni gereksinimlerin formunda bir değişiklik olursa, gereksinimler değişebilir.

Gereksinim geliştirme şu aşamaları içerir:

• Müşteri ihtiyaçlarının, beklentilerinin ve paydaşlara ne sağlayacağını anlamaya yönelik müşteri gereksinimlerini sağlayan kısıtların meydana çıkarılması, analizi, geçerlemesi ve bağlantısı.
• Paydaşların ihtiyaçlarının koordine edilmesi ve toplanması
• Ürünün yaşam döngüsü gereksinimlerinin geliştirimi
• Müşteri gereksinimlerinin belirlenmesi
• Müşteri gereksinimleriyle tutarlı ilk ürün ve ürün bileşen gereksinimlerinin belirlenmesi

Bu işlem alanı tüm müşteri gereksinimlerini adresler. Müşteri gereksinimleri, ürün ve ürün bileşen gereksinimlerinde çıkarılmıştır. Müşteri gereksinimlerine ek olarak, ürün ve ürün bileşen gereksinimleri seçilmiş tasarım çözümlerinden türetilir.

Analiz; rakip alternatiflerden tüm seviyelerde tüm seviyelerde gereksinimleri anlamak, tanımlamak ve seçmek için kullanılır. Analiz aşağıdakileri içerir:

• İlgili paydaşların ihtiyaçları, operasyonel çevre ve genel müşteri ve son kullanıcı beklentilerini ve memnuniyetini yansıtan faktörleri de içeren, her ürün yaşam döngüsü fazı için ihtiyaçların ve gereksinimlerin analizi
• Bir operasyonel konseptin gelişimi
• Gerekli işlevselliğin tanımı

İşlevselliğin tanımı, yazılım geliştirmedeki yapısal analizle aynı olmayan işlevsel analiz olarak da ifade edilebilir.

İlerlemek için ayrıntılı tasarımı ve ürünün testini mümkün kılan etkin bir tanım varolana kadar bir ürün mimarisinin daha ayrıntılı katmanlarında tekrarlı olarak analiz meydana gelir. Gereksinim analizi ve işlevsel konseptin bir sonucu olarak, fabrikasyon ve üretim konsepti aşağıdaki hususları dikkate alarak türetilmiş gereksinimler üretir.

• Çeşitli tiplerin kısıtları
• Teknolojik limitler
• Maliyet ve maliyet sürücüleri
• Zaman kısıtları ve iş takvimi sürücüleri
• Riskler
• Müşteri ve son kullanıcı tarafından tespit edilmemiş fakat belirtilmiş konuların ifadesi
• Geliştiricilerin biricik iş düşüncesi, denetimi ve yasaları tarafından tanıtılmış faktörler

1.3. Gereksinim Türleri

1.3.1. Kullanıcı Gereksinimleri

Nesne misyonunun, ortamın, kısıtların ve etkililik ve uygunluğun ölçülmesinde sistemin beklentilerini tanımlayan gerçek ve varsayımların durumudur. Kullanıcılar; sistem mühendisliğinin sekiz birincil fonksiyonun gerçekleştirirler. İşlevsel gereksinimler temel ihtiyacı ve aşağıdaki soruları cevaplayacak şekilde tanımlıdır:

• İşlevsel dağıtım ve yayılma : Sistem nerede kullanılacak?
• Profil misyonu ya da senaryo : Sistem nesne misyonunu nasıl tamamlayacak?
• Performans ve ilgili parametreler : Misyonu tamamlamak için kritik sistem parametreleri nelerdir?
• Gereksinimlerin etkililiği : Misyonu gerçekleştirirken sistem nasıl etkin ve etken olacak?
• İşlevsel yaşam döngüsü : Sistem kullanıcı tarafından nasıl kullanılacak?
• Ortam : Etkin bir biçimde çalışabilmek için hangi ortamlar sistem tarafından beklenir?

Bu gereksinimler doğal dille yazılabilen, diyagramlarla gösterilebilen ve müşteriler için hazırlanan gereksinimlerdir. Kullanıcı senaryoları için temel oluşturur.

• Use-case’ler ayrı ayrı ve use-case diyagramlarıyla belirtilir. Bir use-case senaryoların toplamını belirtir.
• Veri akış diyagramı : Veri öğlerinin çeşitli fonksiyonlara geçmek için nasıl bir akış gösterdiğini açıklar. Sistem fonksiyonlarını açıklamak için kullanışlıdır.
• Durum geçiş diyagramı : Bir ya da daha fazla işleme cevapta sistemin durumunu açıklar.
• Kullanıcı arayüzü : Genellikle gereksinim analizinin bir parçası olmamakla beraber dahil edilebilir.

Veri akış diyagramı :

Durum Geçiş Diyagramı:

1.3.2. Mimari Gereksinimler

Bir sistemin gerekli sistem mimarisini tanımlamak için ne yapılması gerektiğini tanımlar.

1.3.3. Yapısal Gereksinimler

Bir sistemin gerekli yapısını tanımlamak için ne yapılması gerektiğini tanımlar.

1.3.4. Davranışsal Gereksinimler

Bir sistemin gerekli davranışını tanımlamak için ne yapılması gerektiğini tanımlar.

1.3.5. Fonksiyonel Gereksinimler

Sistemin sunacağı hizmetler ile sistemin işlevsel altyapısını tanımlarlar. Sistemin ne yapacağını yapısal ve işlevsel olarak ortaya koyarlar. Geliştirmeden bağımsız çoğunlukla giriş, çıkış arabirimleri, süreçler ile hata yönetimine yönelik gereksinimlerdir. Sistem girişindeki izin verme ve yetkilendirme gereksinimleri de bu tiptedir. Sistemin neler yapacağını soyut olarak değil de detaylandırılmış biçimde belirler.

Fonksiyonel gereksinim analizi fonksiyonel analiz için yüksek seviye fonksiyonlarda kullanılır.

1.3.6. Fonksiyonel Olmayan Gereksinimler

Sistemin daha çok kısıtları ile fiziksel ortam, arayüzler, kullanıcı odaklı olma, güvenlik, güvenilirlik, kalite güvence gibi soyut niteliklerini belirleyen gereksinimlerdir. Yazılımlara işlevsellik katmamasına rağmen bu tip gereksinimler özellikle yazılım kalitesi açısından kritik rol oynarlar. Bu gereksinimler yazılımda karşılanmadığı sürece yazılımın kullanılabilirliği yetersiz kalacaktır.

1.4. Paydaşların Gereksinim Tanımı

Uluslararası standartta paydaş gereksinimleri tanımı işlemi ISO/IEC 15288’in paydaş gereksinimleri tanım işleminin özelleştirilmiş halidir.

Paydaş gereksinimlerinin tanımının amacı, tanımlı ortamda kullanıcılar ve diğer paydaşlar tarafından ihtiyaç duyulan servisleri sağlayan sistem için gereksinimleri tanımlamaktır.

Paydaşları ya da paydaş sınıflarını sistem yaşam döngüsü içinde ihtiyaçlarını ve isteklerini tanımlar.

Paydaş gereksinimleri tanım işlemi sonucunda;

a)     Gerekli karakteristikler ve servis kullanımının içeriği belirlenir.

b)    Sistem çözümündeki kısıtlar tanımlanır.

c)     Paydaş gereksinimlerinin izlenilebilirliği başarılır.

d)    Sistem gereksinimleri tanımı için temel tanımlanır.

e)     Servislerin uygunluğu geçerlemek için temel tanımlanır ve

f)     Bir ürünün ya da servisin temin edilmesinde görüşme ve anlaşma için temel sağlanır.

Paydaş gereksinim tanım işlemiyle ilgili uygulanabilir organizasyon politikaları ve yordamlarıyla uyum içinde projenin şu aktiviteleri implemente etmesi gerekir:

• Paydaş tespiti
• Gereksinim tespiti
• Gereksinim değerlendirme
• Gereksinim görüşülmesi
• Gereksinim kaydı

1.4.1. Paydaşların Tespiti

Proje bireysel paydaşları ya da sistem yaşam döngüsü içinde sistemde yasal bir ilgiye sahip paydaş sınıflarını tanımlamalıdır.

1.4.2. Gereksinim Tespiti

Proje paydaş gereksinimlerini meydana çıkarmalıdır.

Paydaş gereksinimleri, ihtiyaçları, istekleri, arzuları, beklentileri ve tanımlı paydaşların seçilmiş kısıtlarını tanımlar. Bunlar, sistem amaç ve davranışına yoğunlaşan ve işlevsel ortam ve durumların bağlamında tanımlı, metne dayalı ya da formal olabilen bir modele dayanarak açıklanır. Paydaş gereksinimleri, topluluk tarafından empoze edilen ihtiyaçları ve gereksinimleri, organizasyon ve kullanıcı ve teknik personelin yetenek ve işlevsel karakteristikleri tarafından empoze edilen kısıtları içerir. Bu belgelerin ve anlaşmaların taleplerini, onların gerekçeleme ve gerekçe ve paydaşların ve gereksinimlerinin tatmininde yer alan değerlerin varsayımını içeren kaynakların belirlenmesinde faydalıdır. Anahtar paydaş ihtiyaçları için, etkililiğin ölçümü, işlevsel performansın ölçülebilir ve tayin edilmiş olacak şekilde tanımlanır.

Proje, varolan anlaşmanın kaçınılmaz sonuçları, yönetim kararları ve teknik kararlardan oluşan bir sistem çözümünde kısıtlarını tanımlamalıdır.

Bu 1) paydaş tanımlı çözümün örnekleri ya da alanlarından; 2) sistemin hiyerarşik yapısının yüksek seviyede yapılan implementasyon kararlarından; 3) tanımlı mümkün sistemlerin, kaynakların ve personelin gerekli kullanımından çıkarılabilir.

Proje, beklenen işlevsellikle uyumlu ve senaryoları ve ortamı destekleyen tüm gerekli servisleri tanımlamak için etkinlik sırasının temsili bir kümesini tanımlamalıdır.

Senaryolar, kendine ayrılmış ortamda paydaşların herhangi biri tarafından formal olarak belirtilmemiş gereksinimleri tanımlamak için sistemin işletimini analiz etmek için kullanılır. Sistemin kullanım bağlamı tanımlanır ve analiz edilir. Kullanıcıların sistem nesnelerini, sistemin son kullanıcısının ilgili karakteristiklerini, fiziksel ortamı ve kullanılacak herhangi bir ekipmanı sağlamak için kullanıcıların işleteceği etkinlikleri bağlam dahilinde analiz eder.

Sistem, kullanıcı ve sistem arasındaki etkileşimi insan kapasitesini ve yetenek sınırlarını dikkate alarak tanımlamalıdır.

Kullanılabilirlik gereksinimleri minimumda en etkin, etken ve güvenilir insan performans ve insan sistem etkileşiminde tanımlanır, onaylanır. Mümkünse, uygulanabilir standartlar ve kabul edilebilir profesyonel uygulamalar tanımlamak için kullanılır:

a)     Fiziksel, mental ve öğrenilmiş yetenekler;

b)    İş yeri, ortamı ve özellikleri

c)     Normal, olağandışı ve acil durumlar

d)    Operatör ve kullanıcı kaydı, eğitimi ve kültürü.

Eğer kullanılabilirlik önemliyse, kullanılabilirlik gereksinimleri, planlanmalı, belirtilmeli ve yaşam döngüsü işleminde implemente edilmelidir.

Proje, sağlığı, emniyeti, güvenliği, ortamı ve diğer paydaş gereksinimlerini ve kritik kalitelerle ilişkili fonksiyonları belirtmelidir ve insan sağlığı ve güvenliğinde sistemin kullanımının ters etkileri adreslenmelidir.

Güvenlik riskini tanımla ve eğer garantiliyse, gereksinimleri ve güvenliği sağlamak için fonksiyonları belirt.

1.4.3. Gereksinimlerin Değerlendirilmesi

Proje ortaya çıkarılan gereksinimlerin tümünü analiz etmelidir.

1.4.4. Gereksinimlerin Görüşülmesi

Proje gereksinim problemlerini çözmelidir.

Proje ihtiyaçların ve beklentilerin tatmin edici bir şekilde ele alındığı ve ifade edildiğinden emin olmak için uygulanacak paydaşlara analiz edilmiş gereksinimleri geri bildirim dönmelidir.

Proje gereksinimlerin tamamen ifade edildiğine dair paydaşlarla birlikte onay almalıdır.

1.4.5. Gereksinim Kaydı

Proje, paydaşların gereksinimlerini yaşam döngüsü içinde gereksinim yönetimi için uygun bir formda kaydetmelidir.

Proje, paydaş ihtiyaçlarının kaynaklarına paydaş gereksinimleri izlenebilirlik bakımını yapmalıdır.

1.5. Gereksinim Analizi

Analizler; paydaşların ihtiyaçlarını, beklentilerini, kısıtlarını ve arayüzlerini sağlayacak yetenekte işletim ortamının vuruşuna karar vermek için gerçekleştirilir. Olurluk, misyon ihtiyaçları, maliyet kısıtları, potansiyel market büyüklüğü ve elde edilen strateji gibi düşünceler ürün bağlamında hesaba katılmalıdır. Gerekli fonksiyonelliğin bir tanımı tanıtılmalıdır. Ürün için tüm belirtilmiş kullanım modları  düşünülmelidir, ve fonksiyonların zaman kritik sırası için bir zaman hattı analizi üretilir.

Analiz amaçları aday gereksinimleri tanımlamak içindir. Parametreler ise ürünün etkiliğini ölçmek için kullanılır.

Analiz amaçları;

• Yeni sistemin ya da yazılımın sınırlarını ve yeni problem alanında kendi ortamıyla nasıl etkileşim içinde olmak zorunda olacağını bulunması
• Kullanıcı gereksinimleri arasındaki çelişkileri bulunması ve çözümlenmesi
• Paydaşların önceliklerini görüşülmesi
• Gereksinim belirtim belgesinde tanımlı sistem gereksinimlerini ortaya çıkarılması
• Gereksinim bilgisinin çeşitli kategorilere sınıflandırılması ve gereksinimlerin alt sistemlere ayrılması
• İstenen kaliteler için gereksinimlerin değerlendirilmesi

1.5.1. İşlevsel Kavram ve Senaryoların Tanıtılması

Senaryo; paydaşların ihtiyaçlarının bazılarını belirtmekte kullanılan, ürünün kullanımında meydana gelen olayların bir sırasıdır. Bir ürün için işlevsel kavram, hem tasarım çözümüne hem de senaryoya bağlıdır. İşlevsel kavramlar, çözüm kararlarının yapılması ve düşük seviyeden ayrıntılı gereksinimlerin geliştirilmesinden tanımlanır.

Bir ürün bileşeni için bir gereksinimin ürün olması tasarım karı olduğu gibi, işlevsel kavram ürün bileşenleri için senaryolar olabilir. İşlevsel kavramlar ve senaryolar ürün bileşenlerinin ortamla, kullanıcılarla ve diğer ürün bileşenleriyle ilişkisini belgeler.

Tipik iş ürünleri:

1. İşlevsel kavram
2. Ürün ve ürün bileşeni kurulumu, işlevsel, bakım ve destek bağlamları
3. Satış kavramları
4. Use-case’ler
5. Zaman hattı senaryoları
6. Yeni gereksinimler

Alt uygulamalar:

1. Fonksiyonelliği, performansı, bakımı, desteği ve satışı içeren işlevsel kavramları ve senaryoları geliştir.
2. Limitler ve kısıtları içeren ürün ve ürün bileşeninin işleyeceği ortamı tanımlar
3. İşlevsel kavram ve senaryoları gereksinimleri tanımlamak ve keşfetmek için gözden geçir
4. Ayrıntılı bir işlevsel kavram geliştir. Bu işlevsel kavram seçili ürün ve ürün bileşenlerinden oluşsun, ürün, son kullanıcı ve oram etkileşimini tanımlasın ve işlevsel bakım, destek be satış ihtiyaçlarını sağlasın.

1.5.2. Gerekli Fonksiyonelliğin Tanımının Tanıtılması

Fonksiyonelliğin tanımı fonksiyonel analiz olarak da referans edilebilir. Fonksiyonel analiz yazılım geliştirmedeki yapısal analizle aynı değildir.

Tipik iş ürünleri:

1. Fonksiyonel mimari
2. Etkinlik diyagramı ve use-case’ler
3. Servislerle ve metotlarla tanımlı nesne tabanlı analiz

Alt uygulamalar:

1. Son kullanıcı tarafından gereksenen fonksiyonelliği analiz et
2. Mantıksal ve fonksiyonel kısımları tanımlamak için gereksinimleri analiz et
3. Gereksinim analizine odaklanmak için onaylanmış kriter taban alınarak gereksinimleri gruplara parçala
4. Ürün bileşen gelişimi boyunca hem zaman-kritik fonksiyonların sırasını düşünmek
5. Müşteri gereksinimlerini çözümün sentezini kanıtlamak kanıtlanmış nesnelere ya da fonksiyonel parçalar, nesneler, insanlara paylaştır
6. Fonksiyonel ve performans gereksinimlerini fonksiyonlara ve alt fonksiyonlara paylaştır.

1.5.3. Gereksinimlerin Analizi

Analiz edilmiş gereksinimler, daha ayrıntılı gereksinimler için temel oluşturur. Gereksinimler tanımlandığı gibi, yüksek seviye gereksinimlere ve yüksek seviyeden tanımlı fonksiyonelliğe ilişkisi anlaşılmalıdır.

Tipik iş ürünleri:

1. Gereksinimler raporlardan ayrılır
2. Sunulmuş gereksinimler çözümlere dönüşür
3. Anahtar gereksinimler
4. Tenkil performans ölçülür

Alt uygulamalar:

1. Paydaşların ihtiyaçlarının, beklentilerinin, kısıtlarının ve dış arayüzlerin karışıklığın ortadan kaldırılması ve ilgili öznelerin organize edilmesi için analizi
2. Gereksinimlerin yüksek seviye gereksinimlerin amaçlarını sağlayıp sağlamadığına karar vermek için gereksinimlerin analizi
3. Gereksinimlerin tam, olur, güvenilir, doğrulanabilir olduğundan emin olmak için gereksinimlerin analizi
4. Maliyette, iş takviminde, fonksiyonellikte, riskte ya da performansta güçlü bir etkiye sahip anahtar gereksinimlerin belirtilmesi
5. Geliştirim boyunca izlenecek teknik performans ölçümlerinin belirtimi
6. Müşteri ihtiyaçlarını, kısıtlarını, ve arayüzlerini tanımlamak için ve yeni gereksinimler keşfetmek için işlevsel kavramların ve senaryoların analizi

1.5.4. Dengeyi Sağlamak için Gereksinimlerin Analizi

Paydaş ihtiyaçları ve kısıtları, maliyet, iş takvimi, performans, fonksiyonellik, tekrar kullanılabilir bileşenler, bakım yapılabilirlik ya da risl olarak adreslenebilir.

Tipik iş ürünleri:

1. Gereksinimlerle ilişkili risklerin keşfi

Alt uygulamalar:

1. Kanıtlanmış modelleri, simülasyonları ve prototipleri paydaş ihtiyaç ve kısıtlarını analiz etmek için kullan
2. Gereksinimler ve fonksiyonel mimaride bir risk keşfi çalıştır
3. Risk gereksinimlerinin vurgusu için ürün yaşam döngüsü kavramlarının gözden geçirilmesi

1.6. Sistem Gereksinim Analizi

Sistem gereksinim analizi, gereksinim analizinin özelleşmiş bir şeklidir. Amacı; tanımlı paydaş gereksinimlerini sistem gereksinimlerine dönüştürmektir.

Sistem gereksinim analizi sonucunda;

a)     Sistemin fonksiyonel ve fonksiyonel olmayan gereksinimlerinin bir kümesi tanımlanır.

b)    Seçilen proje çözümünü optimize etmek için uygun teknikler işletilir.

c)     Sistem gereksinimleri doğruluk ve test edilebilirlik için analiz edilir.

d)    İşletim ortamı üstünde sistem gereksinimlerinin vuruşu anlaşılır.

e)     Gereksinimler önceliklendirilir, onaylanılır ve gerekliyse güncellenir.

f)     Sistem gereksinimleri ve müşteri gereksinimleri arasında tutarlılık ve izlenebilirlik onaylanır.

g)    Temelin üstüne değişiklikler maliyet, iş takvimi ve teknik vuru için değerlendirilir.

h)     Sistem gereksinimleri tüm parçalara ve temele iletilir.

Sistem gereksinim analizi, gereksinim belirtimi ve gereksinim değerlendirmesi aşamalarından oluşur.

Gereksinim belirtiminde, geliştirilecek sistemin özel kullanımı sistem gereksinimlerini belirlemek için analiz edilir. Sistem gereksinim analizi; sistemin fonksiyonlarını ve yeteneklerini, iş, örgütsel ve kullanıcı gereksinimlerini, sağlamlık, güvenlik, ergonomikleri, arayüzleri, işlemleri ve bakım gereksinimlerini, tasarım kısıtlarını ve kalite gereksinimlerini tanımlar.

Gereksinim değerlendirmesi ise şu aşamalardan oluşur:

a)            Elde edilen ihtiyaçların izlenebilirliği

b)            Elde edilen ihtiyaçlarla tutarlılık

c)            Test edilebilirlik

d)            Sistem mimari tasarımının olurluğu

e)            İletim ve bakımın olurluğu

1.7. Gereksinimlerin Geçerlenmesi

Gereksinimlerin uyumluluğunu kontrol etmek için son kullanıcıyla beraber geliştirmenin erken aşamalarında işletilir.

Gereksinimlerin geçerlenmesi için şu teknikler kullanılabilir:

1)      Analiz

2)      Simülasyon

3)      Prototip çıkarma

4)      İspat

Alt uygulamalar:

1)     Amaçlanan kullanım ortamında ürün çalıştırılmadığında ortaya çıkacak riskler için gereksinim analizi

2)     Gereksinimlerin yeterlik ve tamlığını ürünün sunum geliştirmesiyle (prototipler, simülasyonlar, senaryolar ve hikaye tahtaları, vb) ve iligli paydaşlardan geri bildirimler alarak kontrol edilmesi

3)     Geçerleme konularına ve bildirilmemiş ihtiyaç ve müşteri gereksinimlerinin tanımlanmasında geçerleme ortamı gereksinimleri kapsamında tasarımın tayin edilmesi.

Referanslar:

• ISO/IEC 12207:2008(E)

IEEE Std 12207:2008

• CMMI® for Development,

Version 1.2

• http://en.wikipedia.org/wiki/Requirements_analysis
• http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html
• http://en.wikipedia.org/wiki/Software_Requirements_Specification
• http://www.teknoturk.org/docking/yazilar/tt000141-yazi.htm
• http://www.site.uottawa.ca/~bochmann/SEG3101/Notes/index.html
• http://yilmazfunda.blogspot.com/p/software-development-process-bolum-1.html
• http://profs.etsmtl.ca/claporte/english/VSE/Deploy%20Pack/DP-Software%20Requirements%20Analysis-V1_2.doc
• http://www.cs.purdue.edu/homes/apm/courses/BITSC461-fall03/uml-slides/
• http://www.cs.toronto.edu/~sme/CSC444F/
• http://groups.engin.umd.umich.edu/CIS/course.des/cis375/ppt/
• http://cnx.org/content/m14621/latest/
• http://en.wikipedia.org/wiki/Natural_language_processing
• http://www.utdallas.edu/~kcooper/research/INCOSE_2002_SRRS.pdf
• http://www.eden-study.org/articles/2008/lepus3-oo-design-description-lang.pdf
• http://www.uml-diagrams.org/
• http://www.ece.msstate.edu/~jwbruce/rtes/urn.pdf
• http://www.education.vic.gov.au/devreskit/appdev/Standards/Documentation/documentation-standards-details.htm
• http://paulmathiesen.wordpress.com/2010/01/06/business-process-modelling-bpm-best-practice/
• http://en.wikipedia.org/wiki/Data_model
• http://www.cellsoft.de/telecom/tmninformationmodels.htm
• http://www.ibm.com/developerworks/
• http://www.sanelson.com/Work/SSD%20Pages/Model%20Systems%20with%20Scenario%20Sequence%20Diagrams%20page%20SSD.htm
• http://www.jot.fm/issues/issue_2008_11/article3/index.html
• http://ftp.cs.hacettepe.edu.tr/pub/dersler/BIL4XX/BIL445_YMK/ders%20notlari/hafta-03%20(19%20ekim)/BIL-445-DN03-6li.pd