Write a title that briefly explains what it is about. Between 20 and 90 characters, Schemes and Mind Maps of Software Development

Download Write a title that briefly explains what it is about. Between 20 and 90 characters and more Schemes and Mind Maps Software Development in PDF only on Docsity!

Yazılım Gereksinim Analizi

<007>

hazırlayan

Yazılım Gereksinim Analizi Page ii

İçerik

İçerik...............................................................................................................................................ii

Değiştirme Geçmişi

• 1. Giriş Değiştirme Geçmişi........................................................................................................................ii
  • 1.1 Amaç.................................................................................................................................................
  • 1.2 Doküman Standartları.......................................................................................................................
  • 1.3 Hedef Kitle ve Okuma Tavsiyeleri...................................................................................................
  • 1.4 Ürün Kapsamı...................................................................................................................................
  • Referanslar..............................................................................................................................................
• 2. Genel Tanımlama
  • Yazılım Bakış Açısı – IPO(Input-Process-OutPut) Diyagramı...............................................................
  • 2.1 Ürün Fonksiyonları, Veri Akış Diyagramları (DFD)........................................................................
  • 2.2 Kullanıcı Sınıfları ve Davranışları Use Case Diyagramları...............................................................
  • 2.3 Ortam, Teknoloji ve Donanımı.........................................................................................................
  • 2.4 Tasarım ve Uygulama Kısıtları.........................................................................................................
  • 2.5 Kullanıcı Dökümantsayonun Taşıması Gereken Özellikler..............................................................
  • 2.6 Kabuller ve Etkileşimler...................................................................................................................
• 3. Harici Arayüz Gereksinimleri
  • 3.1 Kullanıcı Arayüzleri.........................................................................................................................
  • 3.2 Donanım Arayüzleri.........................................................................................................................
  • 3.3 Yazılım Arayüzleri...........................................................................................................................
  • 3.4 İletişim Arayüzleri............................................................................................................................
• 4. Sistem Özellikleri
  • 4.1 Seyehat müdürlüğü Onayı................................................................................................................
  • 4.2 Acente ekranı....................................................................................................................................
  • 4.3 Muhasabe raporları...........................................................................................................................
  • 4.4 Kullanıcı talep girişi.........................................................................................................................
• 5. Diğer Fonksiyonel Olmayan Gereksinimler
  • 5.1 Performans Gereksinimleri...............................................................................................................
  • 5.2 Sağlık Gereksinimleri.......................................................................................................................
  • 5.3 Güvenlik Gereksinimleri...................................................................................................................
  • 5.4 Yazılım Kalite Özellikleri.................................................................................................................
  • 5.5 İş Kuralları........................................................................................................................................
• 6. Diğer Gereksinimler
• 7. Gelecekte Yapılması Planlananlar
• 8. Uzama Planı

1. Giriş

1.1 Amaç

Çalışanların seyehat takibi ve bilet temininin sağlanması.

1.2 Doküman Standartları

<Yazılım gereksinim analizinin yazılması sırasında takip edilen bütün standartlar ve yazım teamülleri tanımlanır. Özel anlamlara sahip fontlar ve renklendirmeler gibi. Her bir gereksinim ifadesinin önceliğinin ne olduğu belirtilir>.

1.3 Hedef Kitle ve Okuma Tavsiyeleri

 Müdür o EK-D belgesini okuyarak başlanır o EK-C müdür senaryosunu okuyunuz o 2. bölüm’ü okuyunuz. o İsteğe bağlı olarak 4. bölüm sistem özelliklerini okuyunuz.  Çalışan o senaryolar (EK-C)’de kullanıcı senaryosunu okuyunuz o  Acente  DBA o ERD tasarımları ve sistem özelliklerini okuyunuz.  Seyahat Müdürlüğü  Yazılım Departmanı

1.4 Ürün Kapsamı

Bilet alım işlemlerinin hızlandırılması, takip edilmesi. Seyehat işlemlerinin sağlıklı bir şekilde garantilenmesi. Departmandan gelen istek talep .. formuna bakınız.

Referanslar

Data flow diyagramı için, std 001 numaralı dökümana bakınız.

2. Genel Tanımlama

Yazılım Bakış Açısı – IPO(Input-Process-OutPut) Diyagramı

Talep formu

Biletin taranmış resimleri buraya konulur

Açıklamalar yapılır.

Mevcut raporlar burada alıntılanır.

Acente bağlantısı için acentenin tek sunmuş olduğu imkan web service’dir.

<Yazılım gereksinim analizi dökümanında açıklanacak olan ürünün içeriği ve orijini tanımlanır. Örneğin ürünün bir ürün ailesinin bir üyesi mi olduğu, var olan bir sistemin yerinimi aldığı veya yeni bir ürün olup olmadığı belirlenir. Eğer yazılım gereksinim analizi dökümanında tanımlanan ürün daha büyük bir sistemin bir parçası ise büyük sistemin gereksinimleri ile üretilen ürünün fonksiyonelliği ilişkilendirilir ve ikisi arasındaki ara yüzler tanımlanır. Burada genel sistemin önemli eklentilerini (component), alt sistem bağlantılarını ve harici ara yüzleri gösteren basit bir diyagram faydalı olabilir.>

2.1 Ürün Fonksiyonları, Veri Akış Diyagramları (DFD)

<Ürünün uygulaması gereken veya kullanıcının uygulamasına izin verdiği önemli fonksiyonlar özetlenir. Üçüncü kısımda ayrıntılar gösterilecektir bu nedenle burada sadece genel bir özetleme (örneğin liste şeklinde) ihtiyacı duyulur. Yazılım gereksinim analizi dökümanını okuyacak kişiler için fonksiyonlar düzenlenerek anlaşılır olmaları sağlanmalıdır. Birbiriyle ilgili gereksinimlerin ve bu gereksinimlerin nasıl ilişkili olduklarını gösteren bir diyagram (örneğin yüksek seviyeli veri akış diyagramı veya nesne sınıf diyagramı gibi) oldukça etkili olacaktır.>

2.2 Kullanıcı Sınıfları ve Davranışları Use Case Diyagramları

<Ürünü kullanacağı tahmin edilen çeşitli kullanıcı sınıfları belirlenir. Kullanıcı sınıfları kulanım sıklına, kullanılan ürün fonksiyonlarının altkümelerine, teknik uzmanlığa, güvenlik ve imtiyaz seviyelerine, öğrenme seviyesine veya tecrübeye göre farklılıklar gösterebilir. Her bir kullanıcı

Bilet Takip

Sistemi

Emir

Talep

Ödeme

Bilet

Raporlar

Acente

3. Harici Arayüz Gereksinimleri

3.1 Kullanıcı Arayüzleri

Kullanıclar raporlarını istedikleri kolona göre sıralayabilmeliler. Her ekran bir help butonu olmalı Her ekranda login olmuş aktif kullanıcı görülecektir. <Yazılım ürünü ve kullanıcılar arasındaki her bir ara yüzün lojiksel davranışları tanımlanır. Bunlar örnek ekran resimleri, herhangi GUI standartları veya takip edilen ürün aile stil talimatları, ekran yerleşim sınırları, her bir ekranda gözüken standart düğmeler ve fonksiyonlar (örn. Yardım) klavye kısayolları, hata mesajı gösterme standartları, vs. olabilir. Bir kullanıcı ara yüzünün ihtiyaç duyacağı yazılım eklentileri tanımlanır.>

3.2 Donanım Arayüzleri

Raporlar printer’dan çıkarılabilecektir. Rezarvasyon bilgileri sms olarak kullanıcıya iletilecektir. Biletler barcode okuyucuyla okunacaktır. <Yazılım ürünü ve sistemin donanım eklentileri arasındaki her bir ara yüzün lojiksel ve fiziksel davranışları tanımlanır. Bunlar desteklenen cihaz tipleri, donanım ve yazılım arasındaki verinin doğası ve kontrol etkileşimleri, ve kullanılan iletişim protokollerini içerebilir.>

3.3 Yazılım Arayüzleri

Kullanıcıların sistem girişi mevcut authentication sistemiyle entegre çalışacaktır. Acente ile web service üzerinden konuşacaktır. Veri tabanına bağlantısını mevcut veritabanı bağlantı katmanını kullanarak yapacaktır. <Veritabanları, işletim sistemleri, araçlar, kütüphaneler ve entegre ticari eklentiler gibi diğer özel yazılım eklentileri ile geliştirilen ürün arasındaki bağlantılar tanımlanır. Sisteme giren ve çıkan veri parçaları ve mesajlar tanımlanır ve her birinin amacı belirlenir. İhtiyaç duyulan servisler ve iletişim niteliği tanımlanır. Yazılım eklentileri arasında paylaşılacak veriler belirlenir. Eğer veri paylaşım mekanizması belirli bir yöntem dahilinde yapılmak zorunda ise (örneğin çok görevli bir işletim sisteminde global bir veri alanının kullanılması) bu durumun bir uygulama kısıtı olarak belirlenmesi gerekir.>

3.4 İletişim Arayüzleri

Acente ile https üzerinden bağlanacaktır.

Veri tabanına ulaşırken vpn kullanacaktır. Raporlar çalışanlara email ile ulaşacaktır bu sırada smtp protokolünü kullanacaktır. Yedekleri aldıktan sonra disaster merkezine ftp ile bağlanıp kopyalayacaktır. <Ürün tarafından ihtiyaç duyulan bütün iletişim fonksiyonları ile ilgili gereksinimler tanımlanır. Bunlar e-mail, web tarayıcı, ağ sunucu iletişim protokolleri, elektronik formlar vs. olabilir. İlgili tüm mesaj formatları tanımlanır. FTP ve HTTP gibi kullanılabilecek iletişim standartları belirlenir. İletişim güvenliği veya şifrelere konuları, veri gönderme oranları ve senkronizasyon mekanizması belirlenir.>

4. Sistem Özellikleri <Bu bölümde sistem özellikleri tarafından ürün için fonksiyonel gereksinimlerin organize edilmesi gösterilir. Bu kısmın use case, işlem modu, kullanıcı sınıfı, nesne sınıfı, fonksiyonel hiyerarşi veya bunların kombinasyonu gibi ürünü mantıksal hale getirebilecek şeyler tarafından organize edilmesi tercih edilebilir.>

4.1 Seyehat müdürlüğü Onayı

Seyehat müdürlüğü karar verme mekanizmasıdır ve bilet talepleri ve alımalrını onaylar

4.1.1 Tanımlama ve Öncelik

Önceliği yüksek, ve sistemin temel fonksiyonlarından birisidir. <Özellik hakkında kısa bir tanımlama yapılır ve yüksek, orta veya düşük öncelikli olup olmadığı belirlenir. Ayrıca burada fayda, kayıp, maliyet ve risk gibi öncelik elemanları tanımlanabilir. Bunların her biri 1 den 9 a kadar puanlanır.>

4.1.2 Uyarı/Cevap Sırası

Çalışandan gelen talebe onay veya red olarka cevap verir.

{sırasıyla gelip giden talepler ve verilen cevaplar burada gösterilebilir}

<Özellik için tanımlanan davranışı harekete geçiren kullanıcı işlemlerinin ve sistem cevaplarının sırası listelenir. Bunlar use case’ler ile alakalı diyalog elemanlarına karşılık gelecektir.>

4.1.3 Fonksiyonellik Gereksinimleri

Çalışanların kotalarını da talepleriyle birlikte raporlar Rapor ekranından onay verebilmelidir. Süresi dolmuş olan onayların takibi yapılabilmelidir. (mesela en fazla 3 gün önce yapılmış taleplere acente tarafından cevap verilmelidir. )

konularını belirten harici talimatlara veya düzenlemelere referans verilir. Belirtilmesi gerektiği düşünülen bütün sağlık tanımları tanımlanır.>

5.3 Güvenlik Gereksinimleri

Use case diyagramlarında kullanılan ekranlar ile kullanıcılar kısıtlıdır, use case’de ilişkilendirlmeyen ekranlara girişi engellenmelidir. Talepler kullanıcı, müdür ve seyahat müdürlüğü dışında kimse tarafından görüntülenemez. Kullanılan database güvenli olmadığı için veriler şifrelenerek saklanmalıdır. <Ürünün kullanılması kapsamında bulunan güvenlik konuları veya gizlilik konuları ile alakalı ya da ürün tarafından kullanılan veya oluşturulan verilerin korunması ile alakalı bütün gereksinimler belirtilir. Her kullanıcının kimlik denetimi gereksinimleri tanımlanır. Ürünü etkileyen güvenlik konularını içeren bütün talimatlara ve mevzuatlara atıfta bulunulur. Belirtilmesi gerektiği düşünülen bütün güvenlik ya da gizlilik tanımları tanımlanır.>

5.4 Yazılım Kalite Özellikleri

Yazılım std007 standartlarına göre en az 5. seviye user friendly olmalıdır. <Müşteriler ve ürün geliştiricileri için önemli olan ürünün bütün ilave kalite davranışları belirlenir. Bunlardan bazıları: adapte olabilirlik, kullanılırlık, doğruluk, esneklik, birlikte işlerlik, dayanıklılık, taşınabilirlik, güvenilirlik, yeniden kullanılırlık, dinçlik, test edilebilirlik ve kullanışlılıktır.>

5.5 İş Kuralları

Genel müdür bilet rezervasyon sisteminin herhangi bir seviyesinde iptal yetkisine sahiptir. Bu iptal işlemi seyehat müdürlüğü aracılığıyla yapılır. <Ürün hakkındaki bütün işlem prensipleri listelenir, örneğin hangi bireyler ya da roller özel durumlarda hangi fonksiyonları kullanabilecek. Bunlar fonksiyonel gereksinimler değildir ancak kuralların uygulanabilmesi için kesin fonksiyonel gereksinimler ifade edebilirler.>

6. Diğer Gereksinimler Bilet fatura yerine kullanılabilmektedir. <Yazılım Gereksinim Analizi dökümanında bahsedilmeyen diğer bütün gereksinimler tanımlanır. Bunlar veritabanı gereksinimlerini, işlemin diğer dillere adapte edilmesi için yapılması gereken

tasarım gereksinimlerini, yasal gereksinimleri, projede nesnelerin yeniden kullanımını ve bunlar gibi diğer şeyleri içerebilir. Proje ile alakalı yeni bölümler eklenir.>

7. Gelecekte Yapılması Planlananlar

Mil puanlar kaydedilecektir

Transferler için ayrıca tasarım yapılacaktır.

Acente ile otel rezervasyonu sistemi ilave edilecektir.

8. Uzama Planı

5. seviyenin altındaki önceliğe sahip özellikler ertelenecektir.

Sistem tek acente ile entegre olacak, çok acente desteği ertelenecektir.

<Projenin uzaması durumlarında projenin hangi adımlarının ya da modüllerinin zamanlamadan çıkartılması gerektiği belirtilir. Yani projenin aksaması durumu için bir b planı hazırlanılır.> Ek A: Sözlük BK: Bilet Kodu <Yazılım gereksinim analizi dökümanını uygun bir şekilde açıklamak için kısaltmalar dahil bütün gerekli terimler tanımlanır. Çoklu projelerde her bir proje için ayrı birer sözlük oluşturmak istenebilir veya bütün organizasyonu içeren tek bir sözlük oluşturmak istenebilinir.> Ek B: Senaryolar

1. Çalışan senaryosu: Çalışan, internet üzerinden ilgili sayfaya şifresi ile girerek bilet talebinde bulunur. Bu sırada talep sebebini yazar (müdür veya kendi isteği olarak) Bilet onayı gelince, biletini acenteden alır. Ek C: Analiz Modelleri Yukarıdaki dökümanda çizilen şemalar referans verilerek buraya konulabilir. DFD1. Use Case 1