Örnekle Yazılım Gereksinim Analizi
Charles Moore
Örneğin, bankacılık uygulaması bağlamında işlevsel gereksinim, müşterinin "Bakiyeyi Görüntüle" seçeneğini seçtiğinde en son hesap bakiyesine bakabilmesi olacaktır.
Yazılım gereksinimi işlevsel olmayan bir gereksinim de olabilir, bir performans gereksinimi de olabilir. Örneğin, işlevsel olmayan bir gereksinim, sistemin her sayfasının kullanıcılara 5 saniye içinde görünür olması gerektiğidir.
Yani temelde yazılım gereksinimi bir
- Fonksiyonel veya
- İşlevsiz
gerek bunun sisteme uygulanması gerekiyor. Yazılım gereksinimleri genellikle ifadelerle ifade edilir.
Gereksinim Türleri
- İş gereksinimleri: Bunlar, projelerden alınan iş senaryosundan alınan üst düzey gereksinimlerdir. Örneğin, bir mobil bankacılık hizmet sistemi Güneydoğu Asya'ya bankacılık hizmetleri sağlar. Hindistan için kararlaştırılan iş gereksinimi hesap özeti ve fon transferi iken Çin için hesap özeti ve fatura ödemesi bir iş gereksinimi olarak kararlaştırılır
| Ülke | Bankacılık İşlevleri veya hizmetleri sağlayan şirket |
|---|---|
| Hindistan | Hesap Özeti ve Fon Transferi |
| Çin | Hesap Özeti ve Bill Ödeme |
- Archiyapısal ve Tasarım gereksinimleri: Bu gereksinimler iş gereksinimlerinden daha ayrıntılıdır. İş gereksinimini uygulamak için gereken genel tasarımı belirler. Eğitim organizasyonumuz için mimari ve tasarım kullanım durumları oturum açma, ders ayrıntısı vb. olacaktır. Gereksinim aşağıda gösterildiği gibi olacaktır.
| Bankacılık kullanım örneği | gereklilik |
|---|---|
| Bill Ödeme | Bu kullanım senaryosu, bir müşterinin internet bankacılığına nasıl giriş yapabileceğini ve Bill Ödeme Kolaylığı.
Müşteri, kayıtlı fatura verenlerin ödenmemiş faturalarının kontrol panelini görebilir. Fatura detayını ekleyebilir, değiştirebilir ve silebilir. Müşteri, farklı faturalandırma işlemleri için SMS ve e-posta uyarılarını yapılandırabilir. Geçmişte ödenen faturaların geçmişini görebilir. Bu kullanım senaryosunu başlatan aktörler banka müşterileri veya destek personelidir. |
- Sistem ve Entegrasyon gereksinimleri: En düşük seviyede, sistem ve entegrasyon gereksinimlerimiz var. Her bir gereksinimin ayrıntılı açıklamasıdır. Gerçekten günlük iş dilini tanımlayan kullanıcı hikayeleri biçiminde olabilir. Gereksinimler, geliştiricilerin kodlamaya başlayabilmesi için bol miktarda ayrıntı içerir. Burada bir örnek Bill Ödeme modülü eklemek için gerekliliğin belirtileceği ödeme modülü Biller
| Bill Ödeme | Yer Alan Kurallar |
|---|---|
| Ekle Billers |
|
Bazen bazı projeler için üzerinde çalışacağınız herhangi bir gereksinim veya belge alamayabilirsiniz. Ancak yine de gereksinim veya bilgi için göz önünde bulundurabileceğiniz başka gereksinim kaynakları da vardır; böylece yazılımınızı veya test tasarımınızı bu gereksinimlere dayandırabilirsiniz. Yani ihtiyaç için güvenebileceğiniz diğer kaynaklar şunlardır:
Diğer Gereksinim Kaynakları
- Halihazırda o proje üzerinde çalışan meslektaşlardan veya çalışanlardan bilgi aktarımı
- İş analisti, ürün yöneticisi, proje lideri ve geliştiricilerle proje hakkında konuşun
- Sisteme halihazırda uygulanmış olan önceki sistem sürümünü analiz edin
- Projenin eski gereksinim belgesini analiz edin
- Geçmiş Hata raporlarına bakın; hata raporlarından bazıları, mevcut sürüme uygulanabilecek geliştirme isteğine dönüştürülür.
- Gerekli kurulumun ne olduğunu görmek için mevcutsa kurulum kılavuzuna bakın
- Ekibin uygulamaya çalıştığı etki alanını veya sektör bilgisini analiz edin
Hangi gereksinim kaynağıyla karşılaşırsanız karşılaşın, bunları bir biçimde belgelediğinizden emin olun, bunların diğer deneyimli ve bilgili ekip üyelerinden incelenmesini sağlayın.
Gereksinimler Nasıl Analiz Edilir?
Bir öğrencinin farklı derslere kaydolabileceği bir eğitim yazılım sistemi örneğini düşünün.
Gereksinimlerin nasıl analiz edileceğini inceleyelim. Gereksinimler, gereksinimlerinin standart kalitesini korumalıdır; farklı gereksinim kalitesi türleri şunları içerir:
- Atomic
- Benzersiz olarak tanımlanmış
- Tamamla
- Tutarlı ve net
- izlenebilir
- Öncelikli
- Test edilebilir
Bunu bir örnekle anlayalım, burada gösterilen tabloda üç sütun var,
- İlk sütun şunu gösterir: “gereksinim kalitesi”
- İkinci sütun şunu gösterir: "bazı problemlerle birlikte kötü gereksinim"
- Üçüncü sütun ikinci sütunla aynıdır ancak “iyi bir gereksinime dönüştürülmüştür”.
| Gereksinim Kalitesi | Kötü gereksinim örneği | İyi gereksinim örneği |
|---|---|---|
| Atomic |
|
|
| Benzersiz olarak tanımlanmış | 1- Öğrenciler lisans derslerine kayıt yaptırabilecekler1- Öğrenciler lisansüstü derslere kayıt yaptırabilecekler |
|
| Tamamla | Profesör kullanıcısı, kullanıcı adını, şifresini ve diğer ilgili bilgileri sağlayarak sisteme giriş yapacaktır. | Profesör kullanıcısı kullanıcı adı, şifresi ve bölüm kodunu girerek sisteme giriş yapacaktır. |
| Tutarlı ve net | Bir öğrenci ya lisans derslerine ya da lisansüstü derslerine sahip olacaktır, ancak her ikisini birden alamaz. Bazı dersler hem lisans hem de lisansüstü öğrencilere açık olacak | Bir öğrencinin ya lisans ya da yüksek lisans mezunu olacaktır, ancak her ikisi birden olamaz |
| izlenebilir | BRD talep kimliğine eşlenen öğrenci bilgileri korunsun mu? | Öğrenci bilgilerini koruyun-BRD talep kimliği 4.1 ile eşlendi |
| Öncelikli | Kayıtlı öğrenci-Öncelik 1Kullanıcı Bilgilerini Koruyun-Öncelik 1Derslere kaydolun-Öncelik 1Karneyi Görüntüle-Öncelik 1 | Öğrenci Kaydı-Öncelik 1Kullanıcı Bilgilerini Koruma-Öncelik 2Derslere kaydolma-Öncelik 1Karneyi Görüntüleme-Öncelik3 |
| Test edilebilir | Sistemin her sayfası kabul edilebilir bir zaman diliminde yüklenecektir | Sistemin öğrenci kayıt ve ders kayıt sayfaları 5 saniye içerisinde yüklenecektir. |
Şimdi bu gereksinimlerin her birini ayrıntılı olarak anlayalım, Atomic.
Atomic
Yani sahip olduğunuz her gereksinim atomik olmalı, yani çok düşük düzeyde ayrıntılara sahip olmalı ve bileşenlere ayrılması mümkün olmamalıdır. Burada gereksinimler için iki örnek göreceğiz, AtomIC ve benzersiz şekilde tanımlanmış gereksinim seviyeleri.
Öyleyse eğitim alanı için sistem oluşturma örneğiyle devam edelim. Burada kötü gereklilik "Öğrenciler lisans ve lisansüstü derslere kayıt yaptırabilecekler"dir. Bu kötü bir gerekliliktir çünkü atomik değildir çünkü iki farklı varlıktan, lisans ve lisansüstü derslerden bahseder. Dolayısıyla açıkça iyi bir gereklilik değil ama kötü bir gerekliliktir, bu yüzden yazışma iyi gerekliliği bunu iki gerekliliğe ayırmak olurdu. Yani biri lisans derslerine kayıttan bahsederken diğeri lisansüstü derslere kayıttan bahseder.
Benzersiz Olarak Tanımlanmış
Benzer şekilde bir sonraki gereksinim kalitesi benzersiz şekilde tanımlanmış olup olmadığını kontrol etmektir, burada iki ayrı gereksinimimiz var ancak her ikisi de aynı ID#1'e sahip. Dolayısıyla, gereksinimimizi ID#'ya referansla belirtiyorsak, ancak her ikisinin de aynı ID#1'e sahip olması nedeniyle tam olarak hangi gereksinime atıfta bulunduğumuz belgeye veya sistemin başka bir kısmına atıfta bulunduğumuz açık değildir. Yani benzersiz kimliklerle ayrılarak, çok iyi bir koşul, bölüm 1- ders kayıtları olarak yeniden geri dönüş olacaktır ve bunun iki şartı vardır: 1.1 id, lisans derslerine kayıt, 1.2 id, lisansüstü derslere kayıt.
Tamamla
Ayrıca her gereksinimin eksiksiz olması gerekir. Örneğin, burada kötü gereksinim şöyle diyor: "Profesör kullanıcı, kullanıcı adını, şifresini ve diğer ilgili bilgileri sağlayarak sisteme giriş yapacaktır." Burada diğer ilgili bilgiler net değildir, bu nedenle gerekliliğin tamamlanması için diğer ilgili bilgilerin iyi bir şekilde açıklanması gerekir.
Tutarlı ve Kesin
Daha sonra her bir gereklilik tutarlı ve net olmalıdır, yani burada örneğin gereksinimlerimiz var "Bir öğrenci ya lisans derslerine ya da lisansüstü derslerine sahip olacak, ancak her ikisine de sahip olmayacak" bu bir gerekliliktir ve şöyle başka bir gereklilik vardır: "Bazı dersler hem lisans hem de lisansüstü öğrencilerine açık olacaktır”.
Bu gereklilikteki sorun, ilk gereklilikten itibaren derslerin lisansüstü dersler ve lisansüstü dersler altında iki kategoriye ayrılmış olması ve öğrencinin ikisinden birini seçebilmesi ancak ikisini birden seçememesidir. Ama diğer şartı okuduğunuzda ilk şartla çelişiyor ve bazı derslerin hem yüksek lisans hem lisansa açılacağını söylüyor.
Dolayısıyla bu kötü şartın, “Bir öğrenci ya lisans ya da yüksek lisans dersi alacak, ikisini birden almayacak” şeklinde iyi bir şarta dönüştürülmesi açıktır. Bu, her dersin lisans dersi veya lisansüstü dersi olarak işaretleneceği anlamına gelir
izlenebilir
Her bir gereksinimin izlenebilir olması gerekiyor çünkü zaten farklı düzeylerde gereksinimler var; en üstte iş gereksinimlerimiz olduğunu, ardından mimari ve tasarım gereksinimlerinin ardından sistem entegrasyon gereksinimlerinin olduğunu zaten gördük.
Artık iş gerekliliklerini mimari ve tasarım gereksinimlerine dönüştürdüğümüzde veya mimari ve tasarım gerekliliklerini sistem entegrasyon gereksinimlerine dönüştürdüğümüzde izlenebilirliğin olması gerekiyor. Bu, her bir iş gereksinimini alıp, onu karşılık gelen bir veya daha fazla yazılım mimarisi ve tasarım gereksinimiyle eşleştirebilmemiz gerektiği anlamına gelir. Burada, "Öğrenci bilgilerinin bakımı - BRD talep kimliğiyle eşleştirilsin mi?" diyen kötü gereksinime bir örnek verilmiştir. gereksinim kimliği burada verilmemiştir.
Yani onu iyi bir gereksinime dönüştürmek aynı şeyi söylüyor ancak gereksinim kimliği 4.1 ile eşleniyor. Dolayısıyla haritalama her gereksinim için mevcut olmalıdır. Aynı şekilde, yüksek seviyeli ve düşük seviyeli eşleme gereksinimimiz var, eşleme aynı zamanda sistem ile entegrasyon gereksinimi arasında, bu gereksinimi uygulayan koda da var ve ayrıca sistem ile entegrasyon gereksinimi arasında, söz konusu gereksinimi test eden test senaryosuna bir eşleme var. .
Yani bu izlenebilirlik projenin tamamında geçerli
Öncelikli
| Öncelikli | Kayıtlı öğrenci-Öncelik 1 Kullanıcı Bilgilerini Koruyun-Öncelik 1 Derslere kaydolun-Öncelik 1 Rapor Kartını Görüntüle-Öncelik 1 |
Öğrenci Önceliği 1'i kaydedin Kullanıcı Bilgilerini Koruyun-Öncelik 2 Derslere kaydolun-Öncelik 1 Rapor Kartını Görüntüle-Öncelik3 |
Daha sonra her bir gereksinimin önceliklendirilmesi gerekir, böylece ekip hangi gereksinimin önce uygulanabileceği ve hangisinin daha sonra yapılabileceği konusunda bir kılavuza sahip olur. Burada kötü önceliğin öğrenciyi kaydettirdiğini, kullanıcı bilgilerini koruduğunu ve her gereksinimin öncelik-1'i verdiğini görebilirsiniz. Her şey aynı öncelikte olamaz, dolayısıyla ihtiyaçlar önceliklendirilebilir. Dolayısıyla buradaki iyi gereksinim örneği, öğrenciyi kaydetme ve derslere kaydolma en yüksek önceliğe 1 verilirken, kullanıcı bilgilerini koruma önceliği 2'de aşağıda gelir ve ardından rapor kartını öncelik-3'te görüntülememiz gerekir.
Test edilebilir
| Test edilebilir | Sistemin her sayfası kabul edilebilir bir zaman diliminde yüklenecektir | Sistemin öğrenci kayıt ve ders kayıt sayfaları 5 saniye içerisinde yüklenecektir. |
Her gereksinim test edilebilir olmalıdır, burada kötü gereksinim "sistemin her sayfasının kabul edilebilir bir zaman diliminde yükleneceğidir". Şimdi bu gereksinimle ilgili iki sorun var; ilki, her sayfanın çok sayıda sayfa olabileceği anlamına gelmesi ve bu da test çabalarını boşa çıkarmasıdır. Diğer sorun ise sayfanın kabul edilebilir bir zaman diliminde yükleneceğinin söylenmesidir, şimdi kabul edilebilir zaman dilimi nedir? Kime göre kabul edilebilir. Bu yüzden test edilemeyen argümanı, özellikle hangi sayfadan bahsettiğimizi “öğrenci kayıt ve derslere kayıt sayfaları” olarak anlatan ve kabul edilebilir zaman dilimi olan 5 saniyenin de verildiği test edilebilir bir argümana dönüştürmemiz gerekiyor.
Sonuç
Dolayısıyla her bir gereksinime uygun düzeyde bu şekilde bakmamız gerekiyor. Mesela sistem ve entegrasyon gereksinimlerine göre bir yazılım yapacaksak. Yazılım gereksinim spesifikasyonlarında veya kullanıcı hikayelerinde verilen sistem ve entegrasyon gereksinimlerine bakmalı ve her gereksinim kalitesine uygulamalıyız. Daha sonra her bir gereksinimin atomik, benzersiz bir şekilde tanımlanmış ve eksiksiz olup olmadığını vb. kontrol edin.
