İyi PRD Nasıl Doğru Yazılır?
İyi yazılım gereksinimlerinin ana işaretleri şunlardır:
- Kesinlik;
- belirsizlik;
- eksiksizlik;
- Bütünlük;
- Önceliklendirme;
- Doğrulanabilirlik;
- Kolay değiştirilebilirlik;
- izlenebilirlik
Kesinlik. Dikkatin merkezinde olması gereken prd’nin3 ana noktasıdır . Tabii ki, spesifikasyonun doğru olmasını istiyorsunuz. Kimse bilerek yanlış özellikler yazmaz. “Doğru ama tanımlanabilir” deyimini tercih ediyoruz. Sipariş, bir spesifikasyonun içinde yanlışlıklar tespit ettiğinizde zamanında güncellenmesidir.
belirsizlik. TK, ancak ve ancak her gereksinimin yalnızca bir yoruma izin vermesi durumunda nettir. Evet, söylemesi yapmaktan daha kolay. TK’nin teslimatı aleyhine bu konuda zaman kaybetmek zaman kaybı olabilir. Ancak belirsizlik bulur bulmaz düzeltin. Bir TK, yalnızca geliştiricilerin yazılım oluşturması için yeterliyse eksiksiz olarak adlandırılabilir.
Bütünlük. TK hem kendi içinde hem de ilgili belgelerle ilgili olarak bütüncül olmalıdır. Bir giriş alanını bir yerde “Başlat ve Durdur” olarak adlandırırsanız, başka bir yerde “Başlat / Durdur” olarak adlandırmayın.
Önceliklendirme. Çoğu zaman, yeni bir sistemin, pazarlama isteklerine daha çok benzeyen gereksinimleri vardır. Bazıları mümkün olmayabilir. Bu bilgilerin TOR’a yansıtılmasında fayda vardır.
Doğrulanabilirlik. “Kullanıcıya hızlı yanıt vermeli” gibi gereksinimler yazmayın. Veya örneğin, bir başkası, benim favorim – “Sistem asla çökmemeli.” Bunun yerine, “Her tuş vuruşu 100 milisaniye içinde yanıt vermelidir” gibi nicel gereksinimler sağlayın.
değişkenlik Farklı yerlerde aynı gereksinimlerin olması mutlaka yanlış değildir – ancak belgenin desteklenmemesine neden olur.
izlenebilirlik Politize olmayan bir ortamda bu genellikle o kadar önemli değildir. Bununla birlikte, çoğu kuruluşta, bazen Görev Tanımındaki gereksinimleri daha üst düzey bir belgeye bağlamak yararlıdır. Neden bu gereksinime ihtiyacımız var?
prd ile yapılabilecek görevlerden biri de sistemin tüm fonksiyonlarını anlatmaktır. Üzerinde çalıştığımız birçok sistemde, bazı işlevler donanımda, bazıları da yazılımda uygulanmaktadır. Sistem Gereksinimleri, işlevselliğin tam bir tanımını ve performans gereksinimlerinde olduğu gibi, bu işlevlerin çeşitli alt sistemler (mekanik, elektrik, yazılım) arasında dağılımının bir ön taslağını sağlamalıdır.
Ek özellikler
Ancak küçük ve orta ölçekli şirketler için yürütülen projelerin çoğunda sistem ve yazılım gereksinimlerini tek bir belgede anlatmak daha pratiktir. Bu, esas olarak, en zor anların yazılımda uygulanması nedeniyle yapılır. Donanımın bazı işlevsel gereksinimleri karşılaması gerekiyorsa, çoğu zaman bu, yazılım için bu yönün iyi belgelenmesinin önemli olduğu anlamına gelir. Çoğu zaman yazılım, mevcut donanımın sistem gereksinimlerini karşılamalıdır. Çoğu zaman sistem departmanı projeye katılmaz ve programcılar aynı anda sistem mühendisleri olarak hareket eder. Küçük projeler için bu çözüm ideal olmasa da iyidir. Bu durumda, gereksinimlerin açıklamasından, neyin yazılım bölümüne, neyin donanıma ve neyin mekaniğe ait olduğu açık olmalıdır.
Genel olarak, yazılım gereksinimleri tasarım gereksinimlerini açıklamamalıdır. Ancak pratikte bunun uygulanması zor olabilir. Fireart profesyonellerine gelince , soruyu nasıl çözeceklerini kesin olarak biliyorlar.
Bu nedenle, gereksinimler, gerekli olan her şeyi ve (tercihen) yeni bir ürün geliştirmek için ihtiyaç duyulan yazılımın bir göstergesi ile açık ve net bir şekilde tanımlamalıdır. Referanslar kullanılan dokümanların versiyon numaralarını içermelidir. Ayrıca, diğer belgeleri eklemenize izin verecek ve gereksinimlerin tam sürümüne kolay erişim sağlayacak bir belge araç takımı kullanmayı düşünün.