İşlevsel ve işlevsel olmayan gereksinimler arasında neden ayrım yapmak?

İkisi arasındaki farkı anlıyorum, ancak meslektaşlarım tarafından gereksinimleri işlevsel veya işlevsel olmayan (veya geçişli) olarak etiketlemenin yararları hakkında sorgulanıyorum. Neden bunu yapmak zahmet ediyor? Dediğini iki gün geçirdi ve bir proje için bir gereklilikler listesinden geçti ve hiçbir fayda görmedi, çünkü sonuç belgeyi "Hepsini yap" emriyle başka bir ticari işletmeye sunmaktı.

Korktuğum şey, tek bir belgede toplanan gereksinimler. Faydayı pratik terimlerle açıklamaya çalıştım, ancak satamadım. Hangi gereksinimlerin işlevsel ve hangilerinin işlevsel olmadığını belgelemenin yararını nasıl satabilirim.

Gereksinimleri açıkça ayırmak, doğru sistemi tasarlamayı kolaylaştıracaktır.

İşlevsel olmayan gereksinimlerle (kavram / terim kalite özelliklerini tercih ediyorum - işlevsel değil işlevsel değil ötesinde yeni bilgiler sağlamalıyım), işlevsellikten ziyade yazılımın özellikleriyle daha fazla ilgilenirsiniz . Yani nasıl sistem bazı işlev değil, basitçe gerçekleştirir ne sistem yok. Kalite gereklilikleri, fonksiyonel gerekliliklerin yapmadığı şekillerde sistemin mimarisi üzerinde önemli bir etkiye sahiptir ve bu nedenle farklı şekilde ele alınmalıdır.

Kalite niteliklerini fonksiyonel gereksinimlerden ayrı tutmak, farklı gereksinimleri farklı şekillerde analiz etmenize, belirlemenize ve önceliklendirmenize olanak tanır. Örneğin, kalite öznitelikleri normalde bir kalite özniteliği senaryosu kullanılarak belirtilirken , işlevsel gereksinimler öyküler, kullanım senaryoları , kurallar veya diğer herhangi bir sayıda biçim şeklinde olabilir. Üzerinde çalıştığım sistemlerin çoğunun bir düzineden az kalite özelliği ve daha birçok fonksiyonel gereksinimi vardı.

Aslında başka bir tür gereksinim getireceğim - teknik kısıtlamalar . Yine, gereksinimleri bu üç kovaya açıkça ayırmak, sistemi kurarken doğru değiş tokuşların nasıl yapılacağına dair ipuçları verir. İşlevsel gereksinimler genellikle oldukça tartışılabilir, kalite özellikleri mimarinizi ve seçtiğiniz yapıları büyük ölçüde etkiler, teknik kısıtlamalar pazarlık edilemez.

Bu benim ekibim olsaydı, mimaride önemli bir şeyi kaçırmamamız için gereksinimlerin türüne açıkça eklenmesi gerektiğini söylerdim. Sadece işlevselliği değil, mimari sürücüleri de düşünün.

Mimar Yazılım Yoğun Sistemlerde Anthony Lattanze : Bir Uygulayıcı Kılavuzu , mimari sürücülere ve neden farklı muamele görmeleri gerektiğine dair pratik bir genel bakış sunuyor, buradaki özetimden çok daha kapsamlı.

Her gereksinim eşit önceliğe / ağırlığa (özellikle "Zorunlu") sahip olduğunda, endişelenmeniz gereken sadece İşlevsel ve İşlevsel olmayan gereksinimleri bölmekten daha fazlasına sahip olmanızdır.

Bununla birlikte, iki gereksinim kategorisini ayırmak için birkaç neden vardır:

Uygulama Sorumluluğu İşlevsel olmayan birçok gereksinimin - özellikle performansa odaklananların - geliştirici için yalnızca orta derecede uygulanabilir olduğunu gördüm. Bir tasarım ölçeklenebilirliği ve hızı destekleyebilse de (ve belirli kod bölümleri ayarlanabilir) genel olarak herhangi bir performans gereksinimini karşılayabilmek Mimariye bağlıdır ve genellikle donanım yapılandırmasına bağlıdır.

Test Sorumluluğu Kullanıcı veya KG ekibi Güvenlik, Hata Toleransı, Güvenlik ve Güvenilirlik gerekliliklerinin karşılandığını inceleme konusunda ne kadar yeterlidir?

Kendinizi Tekrar Etmeyin Dokümantasyon, kodla aynı KURU prensibine uymalıdır. Genel kullanıcı arayüzü stil oluşturma gereksinimleri birlikte gruplandırılmalıdır. Gereksinimlerden sorumlu kişi gerçekten isterse, fonksiyonel gereksinimlerdeki fonksiyonel olmayan gerekliliklere (bireysel veya grup olarak) başvurabilir.

Sürüm oluşturma Çok sayıda "standart" a sahip kurumsal bir ortamdaysanız, sürümlendirilebilen özel kullanıcı arayüzü veya Güvenlik (birkaç ad vermek için) gereksinimlerini yazabilirsiniz. Bu şekilde uygulamaya özgü gereksinimlere (çoğunlukla İşlevsel Gereksinimler) yazabilirsiniz: "Uygulama, XYZ-Company-SecReq-DocumnentNamingStandard.docx içinde tanımlanan Güvenlik Gereksinimlerinin V2.3'üne uymalıdır".

İşlevsel ve işlevsel olmayan gereksinimler arasında neden ayrım yapmak?

Farklılaşmanın bir nedeni, iki tür arasındaki soyutlama seviyesidir. İşlevsel olmayan gereksinimler sistem düzeyindedir ve sistemin bir bütün olarak nasıl davranması gerektiğini söyler. İşlevsel gereksinimler, belirli bir özelliğe ve istemcilere hangi özelliklerin ve işlevlerin sağlanması gerektiğini ifade eder.

İşlevsel olmayan gereksinimler de sistemi kısıtlarken işlevsel gereksinimler sistemin ne yapması gerektiğini söyler. İşlevsel olmayan gereksinimler, işlevsel gereksinimlerin daha sonra nasıl tasarlanıp uygulanacağı konusunda sınırlamalar sağlar. Bunları ayırarak, özellikleri kısıtlamalardan ve sınırlamalardan açıkça tanımlamak mümkün olur.

Korktuğum şey, tek bir belgede toplanan gereksinimler. Faydayı pratik terimlerle açıklamaya çalıştım, ancak satamadım. Hangi gereksinimlerin işlevsel ve hangilerinin işlevsel olmadığını belgelemenin yararını nasıl satabilirim.

Deneyimlerime göre, işlevsel ve işlevsel olmayan gereksinimler aslında aynı belgede gruplandırılır veya aynı sistemde izlenir. Ancak, belgenin kendi ayrı bölümlerinin yanı sıra her birini karşılamak için başarı kriterleri verilir.

Genellikle, ekibin onlara karşı sunum yapmasına yardımcı olacak gereksinimleri kategorilere ayırırsınız. Özellikle mimari bir ihtiyacı hedefleyen bir gereksinim varsa, buna "Mimari" gereksinimi adı vermek, mimari üzerinde çalışırken takıma yardımcı olmalıdır.

Tüm gereklilikleri içeren büyük tek bir belge mutlaka kötü bir şey değildir ... 2 gününü gözden geçirmek de kötü değildir. Sorun tipik olarak, bir kişi gereksinimleri inceledikten sonra, onları anlamasıdır, ancak başkalarının aynı şeyi yapması daha kolay değildir. Projeye katılan diğer kişilere yardımcı olacak meta verilerle etiketleme gereksinimlerini başlatmak büyük bir yardımcı olabilir.

Belki bir soyutlama sorunu olarak tarif etmeye çalışın. Eski bir kod tabanında çalışmanız gerekiyorsa, yalnızca mevcut tüm kod satırlarını okumazsınız ve çalışmaya başlayabilirsiniz. Size yardımcı olmak için kodun yapısını takip edersiniz. İhtiyaçlarda bir yapıya sahip olmak aynı şekilde yardımcı olur.

Ayrılmanın birçok faydası vardır.

1. Testte zaman kazanın (yani yalnızca fonksiyonel gereksinimleri test edin)
2. İhtiyaçlarda gelecekte yapılacak değişiklikler için zaman tasarrufu sağlar (örneğin, işlevsel olmayan gereksinimlerin incelenmesi / onaylanması / uygulanması / test edilmesi daha az zaman alır)
3. Düzenlenmiş (yani FDA, vb.) Bir dünyada, işlevsel olmayan gereksinimler, işlevsel bir gereksinimin gerektirdiği evrak miktarının 1 / 10'unu gerektirir.
4. Takıma işi kıdemli (işlevsel) ve genç (işlevsel olmayan) ekip üyeleri arasında bölme yeteneği verir.

Devam edebilirdim ...

Yüzeyde iki gün uzun bir süre gibi görünüyor, uzun vadede haftalar hatta aylar boyunca gelecekteki çalışmalardan tasarruf edebilir.