Yazılım Gereksinimi Belirtimi Yazma


15

Bir şartname yazma hakkında birkaç sorum var ve bunlar:

  1. Bir yazılım belirtimi yazdığımızda, "Kullanıcı gereksinimleri tanımı" başlığı altında sadece "İşlevler" ve "Kısıtlamalar" belirtmeliyiz?

  2. "Kullanıcı Arayüzü" "işlevler" veya "kısıtlamalar" a mı giriyor?

  3. Bir yazılımın bölünebileceği başlıca kilit alanlar (gereksinimler) nelerdir (örn. UI)?


Bu makale yardımcı olabilir: Özelliklerdeki 10 Tipik Hata
yegor256

Yanıtlar:


16

Tüm gereksinimleri ön plana çıkarmak için büyük bir hayran olmasam da (önemsiz bir proje boyunca çok fazla değişikliğe maruz kaldıkları için), gereksinim belgeleri yazıyorsanız, Volere gereksinimleri spesifikasyon şablonu mükemmel bir rehberdir .

Bazı projeler için aşırıya kaçabilir olsa da, sadece bu gereksinim için o öğeye ihtiyaç duymadığınız listeyi zihinsel olarak kontrol etmek olsa bile, düşünülmesi gereken şeylerin harika bir kontrol listesini sağlar.

Şablon hakkında daha fazla bilgi için bir bağlantı:

http://www.volere.co.uk/template.htm

Şablonun kendisi (ve aslında Şablondan biraz daha ucuz olan ve tam şablon metnini içeren Gereksinim Sürecinde Ustalaşma adlı kitap ), çeşitli bölümlerde her bölümde neler yapılması gerektiğine dair birçok bilgi, örnek ve tavsiye içerir.

İçindeki bölümlerin bir özeti (yukarıdaki bağlantıdan alıntılanmıştır):

  1. Projenin Amacı

  2. Paydaşlar

  3. Zorunlu Kısıtlamalar

  4. Adlandırma Kuralları ve Tanımlar

  5. İlgili Olgular ve Varsayımlar

  6. İşin Kapsamı

  7. İş Veri Modeli ve Veri Sözlüğü

  8. Ürünün Kapsamı

  9. İşlevsel ve Veri Gereksinimleri

  10. Görünüm ve Hissetme Gereksinimleri

  11. Kullanılabilirlik ve İnsanlık Gereksinimleri

  12. Performans gereksinimleri

  13. Operasyonel ve Çevresel Gereksinimler

  14. Sürdürülebilirlik ve Destek Gereksinimleri

  15. Güvenlik gereksinimleri

  16. Kültürel ve Politik Gereklilikler

  17. Yasal yükümlülükler

  18. Açık sorunlar

  19. Hazır Çözümler

  20. Yeni Sorunlar

  21. Görevler

  22. Yeni Ürüne Geçiş

  23. Riskler

  24. Maliyetler

  25. Kullanıcı Belgeleri ve Eğitimi

  26. Bekleme odası

  27. Çözümler için Fikirler


10

Yazılımda Joel'i okumanızı tavsiye ederim. Belirli sorularınızı yanıtlayıp yanıtlamadığından emin değilim, ancak işlevsel özellikler yazmanın ne anlama geldiğine dair mükemmel bir genel bakışa sahip :

Bir spesifikasyonun en önemli fonksiyonu programı tasarlamaktır . Kod üzerinde tek başınıza çalışıyorsanız ve yalnızca kendi yararınıza bir özellik yazsanız bile, spesifikasyonun yazılması - programın nasıl ayrıntılı bir şekilde çalıştığını açıklayan - sizi programı gerçekten tasarlamaya zorlayacaktır ...

... ürününüzü bir insan dilinde tasarladığınızda, çeşitli olasılıkları düşünmeye, tasarımınızı gözden geçirmeye ve geliştirmeye çalışmak sadece birkaç dakika sürer. Kelime işlemcideki bir paragrafı sildiklerinde kimse kendini kötü hissetmez. Ancak ürününüzü bir programlama dilinde tasarladığınızda, yinelemeli tasarımların yapılması haftalar alır . Daha da kötüsü, sadece bir kod yazarak 2 hafta geçiren bir programcı, ne kadar yanlış olursa olsun, bu koda oldukça bağlı olacak ...

... Bir spesifikasyon yazdığınızda, programın sadece bir kez nasıl çalışması gerektiğini bildirmeniz gerekir . Takımdaki herkes spesifikasyonu okuyabilir. KG çalışanları programın nasıl çalışması gerektiğini ve neyi test edeceklerini bilmeleri için okudu. Pazarlama insanlar bu web sitesinde henüz oluşturulmamış ürünler hakkında kusmak için belirsiz vaporware beyaz kağıtları yazmak için kullanın. İş geliştirme insanları, ürünün kellik ve siğilleri nasıl tedavi edeceğine dair garip fantezileri döndürmek için yanlış anlıyorlar, ancak yatırımcıları alıyor, bu yüzden sorun değil. Geliştiriciler hangi kodu yazacaklarını bildikleri şekilde okurlar. Müşteriler, geliştiricilerin ödemek istedikleri bir ürün oluşturduklarından emin olmak için bunu okurlar. Teknik yazarlar okudu ve güzel bir el kitabı yazdı ...

Spesifikasyonunuz olmadığında, tüm bu iletişim hala gerçekleşir, çünkü zorunludur , ancak geçici olur . QA halkı, programla aptalca dalga geçiyor ve bir şey garip göründüğünde, programcılara bir daha çalışmayı kesmeleri için bir kez daha aptalca bir soru sormak için yine ara veriyorlar ...

ayrıntılı bir spesifikasyon olmadan, bir program yapmak imkansız ... Çok fazla programlama organizasyonunda, her tasarım tartışması olduğunda, kimse genellikle siyasi nedenlerle karar veremez. Yani programcılar sadece tartışmasız şeyler üzerinde çalışıyorlar. Zaman geçtikçe, tüm zor kararlar sonuna kadar itiliyor ... Spesifikasyon yazmak, spesifikasyonunuz yoksa örtülü olan irili ufaklı tüm tasarım kararlarını çivilemek için harika bir yoldur. ..


@gnat Makale alıntısının gerekli olduğunu düşünmüyorum. Alıntı seçiminizi vurgulamak isterseniz, soruya kendi cevabınızı göndermenizi tavsiye ederim.
Jonathan Swinney

Cevabınızı başka bir kalede okumanızı düşünün : bir cevap ne zaman bir cevap değildir? "açık konuşmama izin verin: bu tür bir yanıt bir cevap değildir . Bunu görürseniz işaretleyin. Moderatörler, işaretlendiğini görürseniz silin "
gnat

1
Alıntılanan alıntılara katılmıyorsanız, lütfen bunları düzenlemekten çekinmeyin. Bununla birlikte, sadece bir bağlantı olan bir cevaba sahip olmak iyi bir cevap olarak kabul edilmez ve kalite politikalarımız altında silinmeye tabidir. Site dışı bir kaynağa veya referansa gönderme yapan bir gönderi, bağlantı herhangi bir nedenle erişilebilir değilse değer katmaya devam etmek için yeterli bilgi sağlamalıdır.
Thomas Owens

6

Bir yazılım belirtimi yazdığımızda, "Kullanıcı gereksinimleri tanımı" başlığı altında sadece "İşlevler" ve "Kısıtlamalar" belirtmeliyiz?

Bir gereklilik iki şeyin birleşimidir ...

  1. Şey ne yapar. İşlevsel gereksinim.
  2. Ne kadar iyi yapıyor. İşlevsel olmayan gereksinim veya "Kısıtlama"

"Kullanıcı Arayüzü" "işlevler" veya "kısıtlamalar" a mı giriyor?

"Kullanıcı Arabirimi" nin, son sorunuzda belirlediğiniz gibi, gereksinimler kategorisi olacağını söyleyebilirim.

Bir yazılımın bölünebileceği başlıca kilit alanlar (gereksinimler) nelerdir (örn. UI)?

Yazılıma bağlıdır. Gereksinimleri sistemin bölümlerine göre gruplandırabilir veya bunları kullanım durumuna veya işlevlerin yerine getirdiği iş gereksinimlerine göre gruplayabilirsiniz.

Tabii ki tüm bunlar, yazılım sisteminin net, açık ve test edilebilir bir tanımını belirlemek olan gerçek hedefinize ikincildir.


4

Bir gereksinimin temel şartı test edilebilir olmasıdır. Bir gereksinimi nasıl test edeceğinizi anlayamıyorsanız, olasılıklar yazarın istediği şekilde uygulanmayacaktır.

Daha önce sadece İşlevler ve Kısıtlamalar ile sınırlı bir gereksinimler belgesi görmedim, ancak böyle bir yapıya sahip olmanın bazı değerlerini görebiliyorum - yazarı, gereksinimleri "yazılımın yapması gereken şeyler" olarak sınıflandırmaya zorlar ve yazılımın izlenmesi gerekiyor. "

Bir kullanıcı arayüzünün her iki kategoride de gereksinimleri olduğunu düşünüyorum

Kısıtlamalar:

  • "başlangıç ​​ekranında iki düğme görüntülenecektir:" Başlat "ve" Durdur "
  • "Ekran yazı tipi 10 puntodan küçük olmamalıdır."

Fonksiyonlar:

  • "Ne zaman Starttuşuna basıldığında, yazılım için bir TCP / IP bağlantısı kurar WOPR "

Örnekleriniz gereksinim değil, tasarımdır. Gerekliliğin nasıl yerine getirileceğine ilişkin ayrıntılar, bir gereklilik değil bir tasarım kararıdır. Bu nedenle, "iki düğme" bir tasarım kararıdır. Aynı hedefe ulaşmak için geçerli başka birçok yol olduğunu fark ettiğinizde ortaya çıkar (Bir şey Başlat veya Durdur). Bu nedenle, daha çok bir gereklilik haline getirmek için "Kullanıcı arayüzü bir şeyleri başlatmak ve durdurmak için bir araç sağlayacaktır" diyeceksiniz. Ama daha ileriye gideceğim, çünkü bir UI kullanmak da bir tasarım kararı. Bu nedenle sistem gereksinimi için "Sistem bir şeyleri başlatmak ve durdurmak için bir yol sağlayacaktır"
Dunk
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.