Örnekle Yazılım Gereksinim Analizi
Charles Moore
⚡ Akıllı Özet
Yazılım gereksinimleri analizi, paydaş ihtiyaçlarını işlevsel ve işlevsel olmayan ifadeler olarak ayırır, bunları iş, mimari ve sistem düzeylerinde sıralar, ardından test edilebilir bir çözüm sağlamak için her birini kalite özelliklerine göre kontrol eder. tracUygun, öncelikli özellik belirleme.
Yazılım gereksinimi, sistemde uygulanması gereken işlevsel veya işlevsel olmayan bir ihtiyaçtır. İşlevsel, kullanıcıya belirli bir hizmet sunmak anlamına gelir.
Örneğin, bir bankacılık uygulaması bağlamında, işlevsel gereklilik, bir müşteri "Bakiyeyi Görüntüle" seçeneğini seçtiğinde, en son hesap bakiyesini görebilmesidir.
Bir yazılım gereksinimi, performans gereksinimi gibi işlevsel olmayan bir gereksinim de olabilir. Örneğin, işlevsel olmayan bir gereksinim, sistemin her sayfasının kullanıcılar için 5 saniye içinde yüklenmesi gerektiğini belirtebilir.
Yani temelde yazılım gereksinimi bir
- Fonksiyonel veya
- İşlevsiz
gerek bunun sisteme uygulanması gerekiyor. Yazılım gereksinimleri genellikle ifadeler şeklinde dile getirilir.
Gereksinim Türleri
İş gereksinimleriBunlar, projenin iş planından alınan üst düzey gereksinimlerdir. Örneğin, bir mobil bankacılık hizmet sistemi Güneydoğu Asya'ya bankacılık hizmetleri sunmaktadır. Hindistan için belirlenen iş gereksinimi hesap özeti ve para transferi iken, Çin için hesap özeti ve fatura ödemesidir.
| Ü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 gereksinimleriBu gereksinimler, iş gereksinimlerinden daha ayrıntılıdır ve çözüm mimarisini yönlendirir. İş gereksinimini uygulamak için gereken genel tasarımı belirlerler. Bir eğitim kurumu için tipik mimari ve tasarım kullanım örnekleri arasında oturum açma, ders detayları ve kayıt yer alır. Gereksinimler 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 Tesisi. Müşteri, kayıtlı fatura sağlayıcılarına ait ödenmemiş faturaların listesini görebilir. Müşteri, fatura sağlayıcı bilgilerini ekleyebilir, değiştirebilir ve silebilir. Müşteri, farklı faturalama işlemleri için SMS ve e-posta uyarıları yapılandırabilir. Müşteri, geçmişte ödenmiş faturaların geçmişini görüntüleyebilir. Bu kullanım senaryosunu başlatan aktörler banka müşterileri veya destek personelidir. |
Sistem ve Entegrasyon gereksinimleriEn alt seviyede, sistem ve entegrasyon gereksinimleri bulunur. Her gereksinimin ayrıntılı bir açıklamasını sağlar. Günlük iş dilinde yazılmış kullanıcı hikayeleri olarak yakalanabilir. Gereksinimler, geliştiricilerin kodlamaya başlayabilmesi için bol miktarda ayrıntı içerir. Bill Aşağıdaki ödeme modülü örneği, fatura gönderici ekleme gereksinimini göstermektedir.
| Bill Ödeme | Yer Alan Kurallar |
|---|---|
| Ekle Billers | Hizmet Sağlayıcı Adı, Müşteri İlişkisi Numarası, Otomatik Ödemeler – Evet/Hayır, Tamamını Öde Bill – Evet/Hayır, Otomatik Ödeme Limiti – Eğer ödeme yapmayacaksan Bill belirtilen miktarın üzerinde |
Bazen bir proje için çalışacağınız herhangi bir gereksinim veya belge alamayabilirsiniz. Böyle bir durumda bile, yazılım veya test tasarımınızı temel alabileceğiniz başka gereksinim bilgisi kaynakları vardır. Güvenebileceğiniz diğer gereksinim kaynakları aşağıda listelenmiştir.
Diğer Gereksinim Kaynakları
- Halihazırda o proje üzerinde çalışan meslektaşlardan veya çalışanlardan bilgi aktarımı
- Projeyi İş Analisti, Ürün Yöneticisi, Proje Lideri ve Geliştiricilerle görüşün.
- Daha önce uygulamaya konulmuş olan sistemin önceki sürümünü analiz edin.
- Projeye ait eski gereksinim belgelerini analiz edin.
- RevGeçmiş hata raporlarını inceleyin; bazı hata raporları, mevcut sürümde uygulanabilecek iyileştirme isteklerine dönüştürülür.
- Varsa, kurulum kılavuzuna bakarak hangi kurulumların gerekli olduğunu kontrol edin.
- Ekibin uygulamaya çalıştığı alan veya sektör bilgisini analiz edin.
Gereksinimler için hangi kaynağı kullanırsanız kullanın, bunları ortak bir formatta belgeleyin ve deneyimli ekip üyeleri tarafından gözden geçirilmesini sağlayın.
Gereksinimler Nasıl Analiz Edilir?
Öğrencilerin farklı derslere kayıt olabildiği bir eğitim yazılım sistemini örnek olarak ele alalım.
Gereksinimlerin nasıl analiz edileceğini inceleyelim. Her gereksinim, aşağıdakileri içeren bir dizi standart kalite özelliğini korumalıdır:
- Atomic
- Benzersiz olarak tanımlanmış
- Tamamla
- Tutarlı ve net
- Tracyenilebilir
- Öncelikli
- Test edilebilir
Aşağıdaki tabloda her bir özellik üç sütun halinde gösterilmiştir:
- İlk sütun şunu gösterir: “gereksinim kalitesi”
- İkinci sütun şunu gösterir: "bazı problemlerle birlikte kötü gereksinim"
- Üçüncü sütun, aynı gereksinimin "iyi bir gereksinime dönüştürülmüş" halini göstermektedir.
| Gereksinim Kalitesi | Kötü gereksinim örneği | İyi gereksinim örneği |
|---|---|---|
| Atomic | Öğrenciler lisans ve yüksek lisans derslerine kayıt yaptırabilecekler | Öğrenciler lisans derslerine kayıt olabilecekler. Öğrenciler yüksek lisans derslerine kayıt olabilecekler. |
| Benzersiz olarak tanımlanmış | 1- Öğrenciler lisans derslerine kayıt olabilecekler. 1- Öğrenciler yüksek lisans derslerine kayıt olabilecekler. | Ders Kaydı. Öğrenciler lisans derslerine kayıt olabileceklerdir. Öğrenciler yüksek lisans derslerine kayıt olabileceklerdir. |
| 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 |
| Tracyenilebilir | 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 1. Kullanıcı Bilgilerini Yönet - Öncelik 1. Derslere Kayıt Ol - Öncelik 1. Karneyi Görüntüle - Öncelik 1 | Öğrenci Kaydı - Öncelik 1. Kullanıcı Bilgilerini Yönetme - Öncelik 2. Ders Kaydı - Öncelik 1. Karne Görüntüleme - Öncelik 3 |
| 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 özelliklerin her birini daha ayrıntılı olarak inceleyelim, şunlarla başlayalım: Atomic.
Atomic
Her gereksinim atomik olmalıdır; yani en düşük detay seviyesinde olmalı ve daha fazla bileşene ayrılamaz. Aşağıdaki örnekler atomik ve atomik olmayan gereksinimleri karşılaştırmaktadır.
Eğitim alanı sistem örneğine devam edersek: Burada kötü şart, “Öğrenciler lisans ve yüksek lisans derslerine kayıt olabileceklerdir” şartıdır. Bu kötü bir şarttır çünkü atomik değildir; iki farklı unsuru, lisans ve yüksek lisans derslerini birbirine karıştırır. Buna karşılık gelen iyi şart ise bunu iki ayrı şarta ayırır. Bir şart lisans derslerine kaydı, diğeri ise yüksek lisans derslerine kaydı kapsar.
Benzersiz Olarak Tanımlanmış
Bir sonraki kalite özelliği benzersiz tanımlamadır. Kötü örnekte, iki ayrı gereksinim aynı ID#1'i paylaşıyor. Bir ekip bir gereksinime ID'siyle atıfta bulunursa, ikisinden hangisinin kastedildiği belirsiz hale gelir. İyi gereksinim, bunları Bölüm 1 - Ders Kaydı altında, 1.1 (lisans derslerine kayıt) ve 1.2 (lisansüstü derslere kayıt) alt gereksinimleriyle yeniden gruplandırır.
Tamamla
Her gereksinim eksiksiz olmalıdır. Örneğin, burada kötü bir gereksinim şöyle diyor: "Profesör kullanıcı, kullanıcı adı, şifresi ve diğer ilgili bilgileri sağlayarak sisteme giriş yapacaktır." "Diğer ilgili bilgiler" belirsizdir. Eksiksiz bir gereksinim, profesörün sağlaması gereken bölüm kodu gibi tam alanları listeler.
Tutarlı ve Kesin
Her şart tutarlı ve açık olmalıdır. Kötü örnekte, bir şart "Bir öğrenci ya lisans dersleri ya da yüksek lisans dersleri alacaktır, ikisini birden alamaz" derken, bir diğeri "Bazı dersler hem lisans hem de yüksek lisans öğrencilerine açık olacaktır" demektedir.
Birinci şart, derslerin iki ayrı kategoriye ayrılması gerektiğini ima ederken, ikinci şart bazı dersleri her iki gruba da açarak bununla çelişmektedir.
Bu iyi düzenleme, her dersin lisans veya yüksek lisans olarak sınıflandırıldığını ve bir öğrencinin yalnızca bir kategoriye ait derslere kayıt olabileceğini açıkça belirterek çelişkiyi çözmektedir.
Tracyenilebilir
Her şartın yerine getirilmesi gerekir. tracBu mümkün çünkü gereksinimler birden fazla düzeyde mevcut: iş, mimari ve tasarım, sistem ve entegrasyon.
Bir iş gereksinimini mimari ve tasarım gereksinimlerine veya mimari ve tasarım gereksinimlerini sistem ve entegrasyon gereksinimlerine dönüştürdüğünüzde, tracİşlevsellik korunmalıdır. Her iş gereksinimi, bir veya daha fazla mimari ve tasarım gereksinimine karşılık gelmelidir. Kötü örnek olan "Öğrenci bilgilerini muhafaza et – BRD gereksinim kimliğine karşılık geliyor mu?" ifadesinde, gereksinim kimliği eksiktir.
İyi gereksinim aynı ifadeyi kaydeder ancak açıkça BRD gereksinim kimliği 4.1'e eşlenir. Her gereksinim bir ifade içermelidir. tracyetenek haritasıpingSistem ve entegrasyon gereksinimleri, bunları uygulayan kodla ve bunları doğrulayan test senaryolarıyla da eşleşmelidir.
TracBu nedenle, proje genelinde verimlilik baştan sona sağlanmaktadır.
Öncelikli
Her gereksinim önceliklendirilmelidir ki ekip önce neyi uygulayacağını ve hangisinin bekleyebileceğini bilsin. Kötü örnekte, Öğrenci Kaydı, Kullanıcı Bilgilerini Yönetme, Ders Kaydı ve Karne Görüntüleme gereksinimlerinin tümü 1. Öncelik olarak ayarlanmıştır. Her şey 1. Öncelik olamaz, bu nedenle gereksinimler gerçekçi bir şekilde sıralanmalıdır. İyi örnekte ise Öğrenci Kaydı ve Ders Kaydı en yüksek 1. Öncelik, Kullanıcı Bilgilerini Yönetme 2. Öncelik ve Karne Görüntüleme 3. Öncelik olarak belirlenmiştir.
Test edilebilir
Her gereksinim test edilebilir olmalıdır. Kötü örnek olan "sistemin her sayfası kabul edilebilir bir zaman diliminde yüklenecektir" ifadesi iki nedenden dolayı test edilemez. Birincisi, "her sayfa" onlarca sayfa anlamına gelebilir ki bu da test çabasını artırır. İkincisi, "kabul edilebilir zaman dilimi" tanımlanmamıştır - kime göre ve hangi ölçüte göre kabul edilebilir? İyi bir gereksinim, belirli sayfaları ("öğrenci kaydı ve ders kaydı sayfaları") adlandırarak ve 5 saniyelik ölçülebilir bir hedef belirleyerek her iki sorunu da çözer.
