Bir hastane sisteminin oluşturulması ile ilgili isterleri belirleme.

Alt Süreç belirleme(Hasta ve Hasta istek takipleri modülü)

1.Adım: Birinci aşama(İnceleme için aktif tanımlamaları hazırla.)
Hangi kriterlere sahip olacağımızı düşün!
İyi bir yapı
Kolay
İşler için yeterli
Esnek
Pratik
Geliştirilmesi Kolay
Standardizyona sahip

2.Adım Dokümantasyonu Hazırla
Varsayımlar açık olun
Bir hastaya ait bilgileri kaydedebilirsiniz.
Bir hasta için tüm randevuları elde etmek mümkündür.
Sistem tarafından rezervasyon belirleyebilir ve randevu durumunu değiştirilebilir.
Bir  randevu aktif veya iptali durumuna karşı açıktır.
Yanlış kullanımı Varsayımlar
Randevu eklemek veya silme işleminden sonra öğeleri kaldırabilir miyim.
Randevu iptal edildiğinde, durumu tekrar aktif olarak ayarlanmış olamaz.
Bir öğe her zaman bir düzene göre eklenir.

3.Adım Tanımlamaları Belirle
Veri yeterliliği(İstenilen bütün dataların program tarafından elde edilip edilmediğine bak)
Verilerin istenilen şekilde alındığını kontrol et.


4.Adım İhtiyaçları Yorumla
Farklı bakış açıları ve uzmanlığa sahip kişiler yorumcular olarak gereklidir.
Programcılar  ve müşteriler , sisteminin diğer özellikleri üzerinde çalışmalı ve yapıyı analizetmelidir.
Programcılar ve analistler genelde hastane bilgi sistemleri ile ilgili bilgisi bulunan kişilerden olmalıdır.

5.Adım Tasarım Anketleri
Yorumcular aktif bir rol almalıdır.
Yorumcular  o ana kadar oluşturulan belgeleri kullanarak yorum oluşturmalıdırlar. Ayrıca sistem hakkındaki bilgileride kullanmalıdırlar.
İstisna durumlar var ise tasarım anketleri içerisinde belirlenmelidir.
Örneğin, yerine "oluşabilir istisnalar yazınız" her bir program için tanımlanan istisnaları var mı? "

Adım 6: Davranış inceleme
Şartname yazarları, doldurulan anketlerle inceleme ve sorularıçözmek için yorumcular ile buluşuyor.
Yorumcular gerektiği gibi özellikleri yazarlar ile toplantı, onların değerlendirmeleri tamamlandı.
Şartname yazarların belirlediği yeni sürümü üretmek.

Belirlediği nitelik kontrol listesi

Tamlık Doğruluk Hassas Tutarlılık Ilgi Fizibilite Kod / Tasarım-özgür Test edilebilir

Şartname terminoloji kontrol listesi
 
Her, hepsi, hiçbiri, hiçbir zaman her zaman ... (kesinlikle emin misin?)
Kesinlikle, bu nedenle, açıkça, belli ki, alışıldığı gibi, en ...
Bazı, bazen, sık sık, genellikle, normal koşullarda, geleneklere göre,en ... (belirsiz)
Vb, vb, vb, gibi ... (test edilebilir değil)
Hızlı İyi, ucuz, verimli, küçük, istikrarlı, ... (ölçülebilir mi?)Işlenmiş Kulplu, reddedilen atlanmış, yok ...Eğer ... sonra ... (başka eksik)


Yorumcular  için en iyi değerlendirme yeri onlara en   uygun olan  bölgelerdir.
Bu kısımlara odaklanmalıdırlar.
Bu sayede Zaman tüm katılımcılar için daha akıllıca kullanılır.
Daha fazla hata bulunması muhtemeldir.
Şartname yazarları ile Bire bir iletişim ve  konuşma çok önemlidir.
Birkaç hatanın bulunması mutlaka şartname iyi
olduğunu göstermez . (Belkide inceleme süreci etkili değildi.)

Şartnamenin Amacı

İşlenmeyen kullanıcı gereksinimleri genellikle şunlardır

Belirsiz
Çelişkili
Pratik veya uygulanması imkansız
Aşırı muğlak ifadeler
Şartnamenin amacı; hangi sistem gereksinimleri ile tasarlandığını bilmek. En az "sürpriz" ile gereksinimleri kullanışlı bir şekilde oluşturmak.

Şartname belge
Sistem geliştiricilerin kullanacakları yazılımın anlatımı içeren bir açıklama bulunmalıdır.
Sistem modelleri, gereksinimlerini tanımlama ve gereksinimleri özellikleri içermelidir.
Bir tasarım belgesi değildir.
fonksiyonel ve fonksiyonel olmayan gereksinimleri içermelidir.
Bakım için bir referans belgesi olarak hizmet vermektedir.


Şartnamedeki gereksimimler ile ilgili olarak.

Gereksinimleri değiştirmek için yapı kolay bir şekilde tasarlanmalıdır.
Sistem değişiklikleri gibi değişikliklere uygun olmalıdır.
Hangi işletim sistemi üzerinde çalışacak?
İşletim sisteminin sonraki versiyonları için uyum olacak mı?
Eskiden sahip olunan verileri dönüştürebilecek mi?

Spesifikasyon özeti

İşletin nasıl uygulanacağı ve ne şekilde yapılacağı belirlenmelidir.
Şartname’ye isterlerin doğru alınması zordur; iyi iletişim becerisi gerektirir.
Gereksinimler zaman içinde değişebilir. Yeni gereksinimler şartname içerisinde iterasyon gerektirir.
Müşteri çoğu zaman ne istediğini iyi bilmez ve kavrayamaz. Gereksinimler aşamasında oluşturulan Bugsların sonradan düzeltmek zordur.

Şartname yorumları
Şartname içerisindeki hatalar olabileceği düşüncesi ile (kusurları keşfetme amacı ile) şartname incelenmesi gerekmektedir.
Yazılım içerisinde ortaya sık çıkan hatalara dikkat edilmelidir. (Yazılım içerisinde ortaya çıkma olasılığı çoktur.)
Hataları keşfetmek için etkili yöntemdir.

Değerlendirme ve test
 
Kesin bir şartname mevcut olmalıdır.
Ekip üyeleri kuruluşun standartlara aşina olması gerekir.
Yönetim kadrosu değerlendirme için yorum kullanmamalıdır.

Belirtim incelemesi nedir?
Bir yazılım sisteminin şartnamede hataları belirleme işlemidir.

Gereksinim: Bir Bakış

Gereksinim: Bir Bakış
 
Temel amacı: Kullanıcı tarafından söylenen sorunu doğru anlamak.
Etkinlikler( Şartnamede sorun çıkartacaktır dikkat edilmelidir.)
Gereksiz ayrıntı ile şartname karmaşıklaştırılmamalıdır.
Önceden belirlediği tasarım kısıtlanmamalıdır.
Şartname yapıldıktan sonra, yazılım tasarımı yapın: çözüm odaklı olunmalı nasıl uygulamaya ne şekilde uygulayacağız sorularına ilk bakış şartname ile yapılmalı.
Gereksinimlerin düzgün olması için anahtar; yazılımcı ile müşterinin arasındaki iletişimin düzgün olmasıdır.
Kılavuz olarak hazırlanan belge varsa o belgedeki sıra ile gereksinimleri belirlemeye çalışın.


Gereksinim

Önerilen yazılım sistemi ile ilgili; tespit ve müşteri beklentilerini tam olarak belirleme sürecidir.
İki tür gereksinim
Işlevsel(Fonksiyonal): Hassas görevler veya fonksiyonlar içeren sistemler için yapmaktır. Örneğin, bir uçuş rezervasyon sisteminin ayrıntıları
Fonksiyonel olmayan(Nonfunctional): Genellikle, sistem ya da yapı üzerinde belirlenen bazı özellikler. örneğin, beklenen performans ve bellek gereksinimleri, süreç modeli kullanılmış, uygulama dil ve platform, diğer araçlar, son başvuru tarihleri ?? ile uyumluluk, ...

Şartname yapısı içerisinde neler olur?

Giriş (sistem için ihtiyaç açıklayın)
Fonksiyonel Gereksinimleri
Non-Fonksiyonel Gereksinimleri
Sistem Evolution (beklenen değişikliklerin açıklayın)
Sözlüğü (teknik ve / veya yeni jargon)
Ekler
Indeks

Çalışma Örnekleri

? Karşılaştırma Operatörü Örnek:

? Karşılaştırma Operatörü Örnek:

    int sayi = 15;
    x = ( sayi < 10 ) ? printf("yazi1") : printf("yazi2");

Girilen il plaka koduna göre ekrana ilgili şehir ismi yazdırılacaktır.

Program tarafından desteklenecek iller:
ANKARA
İSTANBUL
İZMİR
MANİSA

Bunların dışında bir plaka kodu girilirse «TANIMSIZ PLAKA KODU» şeklinde hata mesajı verilecektir.

Girdiğiniz ay bilgisine göre hangi mevsimde olduğumuzu bulan bir program yazınız.

Girdiğiniz ay bilgisine göre hangi mevsimde olduğumuzu bulan bir program yazınız. Yazılacak C programında switch-case karşılaştırma deyimi kullanılacaktır.

·         12, 1, 2. aylar için ekran çıktısı à “Girdiginiz ay kis mevsimindedir”

·         3, 4, 5. aylar için ekran çıktısı à “Girdiginiz ay ilkbahar mevsimindedir”

·         6, 7, 8. aylar için ekran çıktısı à “Girdiginiz ay yaz mevsimindedir”

·         9,10, 11. aylar için ekran çıktısı à “Girdiginiz ay sonbahar mevsimindedir”

·         Farklı bir değer girilmişse ekran çıktısı à “Yanlis bir giris yaptiniz”

Kullanıcının klavyeden 2 gerçel (float) sayı girilmesi istenecek

Kullanıcının klavyeden 2 gerçel (float) sayı girilmesi istenecek ve sonrasında aşağıdaki menü karşısına çıkartılıp, kullanıcının yapacağı işlem seçimine göre ilgili işlem hesaplanarak sonucu 2 ondalıklı olacak şekilde ekrana yazdırılacaktır. Geçersiz bir işlem numarası girilirse “GECERSIZ ISLEM” hata mesajı ekrana yazdırılacaktır. Yazılacak C programında switch-case karşılaştırma deyimi kullanılacaktır.