İsteğe Bağlı Gereksinimler için daha iyi bir kelime? [kapalı]

Yazılım mühendisliğinde isteğe bağlı bir gereksinim için daha iyi bir kelime nedir? İfade çelişkilidir. Önceki projelerde "Temel Olmayan Gereksinimler" i kullandım.

"Kapsam dışı gereklilik" terimi muhtemelen kullanılabilir. Bu, gereksinimin işleminiz dahilinde yakalandığı ve izlenebilir olduğu anlamına gelir, ancak bütçenin, programın, zamanın, veya fizibilite.

Bununla birlikte, "isteğe bağlı gereksinim" ifadesi, kapsam dahilinde olan ancak sistem tarafından zorunlu olarak gerekli olmayan bir şeyi belirtmek için yaygın olarak kullanılır. Bu, gereksinimin önceliğinin bir ölçüsüdür. Deneyimlerime göre, gereksinimler genellikle zorunlu, istenen veya isteğe bağlı olarak önceliklendirilir (ancak başka şemalar da vardır). Bir projenin eksiksiz ve tamamen işlevsel olarak kabul edilebilmesi için tüm zorunlu gereksinimlerin karşılanması gerekir. Yeterli kaynaklar göz önüne alındığında, daha sonra istenen gereksinimler uygulanacaktır. Son olarak, isteğe bağlı kabul edilen herhangi bir şey dahil edilecektir.

Ben karışıklığın "şart" teriminden geldiğine inanıyorum. İngilizce dilinde bir gereklilik "gerekli olan bir şey" veya "zorunlu, zorunlu veya zorunlu bir koşul" dur. Bununla birlikte, yazılım mühendisliğinde, gereksinim terimi bir yazılım sisteminin belgelenmiş bir özelliğidir. İsteğe bağlı ve zorunlu kavram, yazılım sisteminin belgelenmiş özelliğinin önceliğini tanımlar.

Bunlardan, gereksinimlerin aksine "sahip olmak güzel" özellikler olarak adlandırıyoruz.

Yazılım gereksinimleri belgeleri için, bu terimi RFC 2119 Gereksinim Seviyelerini Belirtmek için Anahtar kelimeler - yani gerçekten isteğe bağlı öğeleri belirtmek için kullandığınız sürece İsteğe Bağlı Gereksinimler ifadesi mükemmel bir şekilde uygundur .

Spesifikasyon metniniz sıfat yerine fiil gerektirdiğinde, "İSTEĞE BAĞLI" yerine "MAYIS" kullanın.

Küçük ve okunması kolay olduğundan, RFC metni aşağıda tamamen alıntılanmıştır:

    Ağ Çalışma Grubu S. Bradner
    Yorum İsteği: 2119 Harvard Üniversitesi
    BCP: 14 Mart 1997
    Kategori: En İyi Güncel Uygulama


            Gereksinim Düzeylerini Göstermek için RFC'lerde kullanılan anahtar kelimeler

    Bu Notun Durumu

       Bu belge, aşağıdakiler için İnternet En İyi Geçerli Uygulamaları belirtir:
       İnternet Topluluğu ve tartışma ve öneriler talep ediyor
       iyileştirmeler. Bu notun dağıtımı sınırsızdır.

    Öz

       Birçok standartta parça belgelerini göstermek için birkaç kelime kullanılır
       şartnamedeki gereksinimler. Bu kelimeler genellikle
       harfle. Bu belge bu kelimeleri olması gerektiği gibi tanımlar
       IETF belgelerinde yorumlanır. Bu yönergeleri izleyen yazarlar
       bu ifadeyi belgelerinin başına yakın bir yerde içermelidir:

          Anahtar kelimeler "ZORUNLULUK", "ZORUNLU DEĞİL", "GEREKLİ", "SHALL", "SHALL
          NOT "," SHOULD "," NOT SHOULD "," ÖNERİLEN "," MAYIS "ve
          Bu belgedeki "İSTEĞE BAĞLI" ifadesi,
          RFC 2119.

       Bu kelimelerin kuvvetinin gereksinimle değiştirildiğine dikkat edin
       kullanıldıkları belgenin düzeyi.

    1. ZORUNLU Bu kelime veya "GEREKLİ" veya "SHALL" terimleri,
       tanım, şartnamenin mutlak bir gereksinimidir.

    2. Bu ifade veya "SHALL NOT" ifadesi,
       tanım, tarifnamenin mutlak bir yasağıdır.

    3. Bu kelime veya "ÖNERİLEN" sıfatının,
       belirli durumlarda göz ardı etmek için geçerli nedenler olabilir.
       ancak tüm çıkarımların anlaşılması ve
       Farklı bir kurs seçmeden önce dikkatlice tartılır.

    4. Bu ifade veya "ÖNERİLMEDİ" ifadesi,
       belirli durumlarda geçerli nedenler olabilir.
       belirli davranış kabul edilebilir veya hatta yararlıdır, ancak tam
       sonuçları anlaşılmalı ve vaka dikkatle tartılmalıdır
       bu etiketle açıklanan herhangi bir davranışı uygulamadan önce.

    5. MAYIS Bu kelime veya "İSTEĞE BAĞLI" sıfatı, bir öğenin
       gerçekten isteğe bağlı. Bir satıcı öğeyi eklemeyi seçebilir, çünkü
       belirli bir pazar yeri bunu gerektirir veya satıcı bunu hissettiğinden
       başka bir satıcı aynı öğeyi atlayabilirken ürünü geliştirir.
       Belirli bir seçeneği içermeyen bir uygulama OLMALIDIR
       başka bir uygulama ile birlikte çalışmaya hazır
       belki de sınırlı işlevsellik ile seçenek dahil. İçinde
       aynı damar belirli bir seçeneği içeren bir uygulama
       Başka bir uygulama ile birlikte çalışmaya hazır OLMALIDIR
       seçeneği içermez (elbette, özellik için
       seçeneği sağlar.)

    6. Bu Zorunlulukların kullanımıyla ilgili rehberlik

       Bu notta tanımlanan tipteki zorunluluklar dikkatli kullanılmalıdır
       ve idareli. Özellikle, sadece olduğu yerde KULLANILMALIDIR
       birlikte çalışma ya da
       zarar verme potansiyeli (örneğin, yeniden iletimlerin sınırlandırılması)
       örneğin, belirli bir yöntem uygulamak için kullanılmamalıdırlar
       birlikte çalışabilirlik için yöntemin gerekli olmadığı uygulayıcılarda.

    7. Güvenlik Konuları

       Bu terimler güvenlikli davranışı belirtmek için sıklıkla kullanılır
       etkileri. Bir ZORUNLUK uygulamamanın güvenliğine etkileri veya
       SHOULD, ya da şartname söylediği bir şey YAPMAMALIDIR
       YAPILMAMASI çok ince olabilir. Belge yazarları zaman ayırmalı
       takip etmemenin güvenlik sonuçlarını açıklamak
       çoğu uygulayıcının sahip olmayacağı için öneriler veya gereksinimler
       deneyim ve tartışma yaratan
       Şartname.

    8. Teşekkür

       Bu terimlerin tanımları, alınan tanımların bir birleşimidir
       birkaç RFC'den. Ayrıca, öneriler
       Robert Ullmann, Thomas da dahil olmak üzere birçok kişiden
       Narten, Neal McBurnett ve Robert Elz.

Belgeleriniz tanımların kaynağı olarak RFC'ye başvuruyorsa zarar vermez:

Bu belgede RFC 2119'da belirtilen tanımlara dayalı tanımlar kullanılmaktadır .

Bunun sorunuza bir cevap olmadığını takdir ediyorum, ama benim dünyamda, herhangi bir nedenden dolayı onu yerine getirmeyecekseniz bile, hala bir gereklilik.

Gibi Moskova yaklaşımı benim regüle dünyada diğer faktörler (birlikte kullanıcılarla gereksinimlerini kategorize etmek (bu zaman yok olacak, alabilir, Must Have olmalı), gereksinimler kritik veya kritik olmayan ve birçok bir olabilir argüman isteğe bağlı ancak kritik gereklilikler üzerine alevlenir.)

İsteğe bağlı bir gereklilik için daha iyi bir kelime " Öneri " dir.

İsteğe bağlı bir özellik veya isteğe bağlı görevler olarak tanımlamaya ne dersiniz? Bunlar sadece projenin belirli bir noktasında bu özellikleri tamamlamak için zaman ve para olduğu tespit edilirse yapılacaktır.

Harici bir olay meydana gelirse de tetiklenebilirler. Müşteriler Windows 8'e geçerse, aşağıdaki görevlerin yapılması gerekir ...

Özelliğin açıklaması, yapıp yapamayacaklarını belirlemek için bir son tarih içermelidir.

Yazılım Mühendisliği'nde gereksinimler 4 alanda sınıflandırılmıştır:

1. İş Gereksinimleri : Genel iş hedefleri ve sistemin hedeflerine odaklanır
2. Kullanıcı Gereksinimleri : Kullanıcının hedeflerine ve kullanıcıların iş hedeflerine ulaşmak için sistemi kullanmak için ne yapması gerektiğine odaklanır
3. İşlevsel Gereksinimler : İş hedeflerine ulaşmak için sistemin gerçekleştirmesi gereken işlevler ve görevler
4. İşlevsel Olmayan Gereksinimler : İşlevsel gereksinimler dışında hangi gereksinimler vardır. Buna çevre, kısıtlamalar, arayüz, bakım sorunları vb. Dahildir.

Şimdi yukarıda belirtilen 4 kategoriye bağlı olarak gereksinimler İsteğe Bağlı veya Zorunlu olabilir . İsteğe bağlı gereklilikler, söz konusu sistemin kapsamı dahilinde veya kapsamı dışında da olabilir. İsteğe bağlı gereksinimler Kapsam Sünmesini önlemek ve kapsamınızı kesin olarak tanımlamak için iyi bir araçtır .

İsteğe Bağlı Gereksinimler, kapsamı belirlememize yardımcı olduğu ve Scope Creep'ten kaçınmanın iyi bir yolu olduğu için Yazılım Mühendisliğinin bir parçası olacaktır. SDLC'nin mühendislik uygulamalarıyla çeliştiklerini asla söyleyemezsiniz. Ancak, gereksinimlere öncelik verilmeli ve iyi tanımlanmalıdır.

In Volere şablona dönem "Bekleme odası" kullanılır.

... Bu şablon ihtiyaç özelliklerinizin temeli olarak kullanılmak üzere tasarlanmıştır. Şablon, günümüzün iş, bilim ve yazılım sistemleri için uygun gereksinimlerin her birini sağlar. Gereksinimleriniz için bir kontrol listesi, yapı ve izlenebilirlik sağlar ... Şablon araçtan bağımsızdır ve Yonix, Requisite, DOORS, Caliber RM, IRqA ve diğer popüler araçlarla başarıyla kullanılmıştır ...

Volere teknikleri, Suzanne Robertson ve James Robertson'ın Gereksinim Sürecinde Ustalaşmak kitabında açıklanmıştır ...

Benim işimde (uzay aracı) bunlara ya "hedefler" deniyor, bu da belgelendirildiklerini ve onları karşılamak için harcanacaklarını gösterecek, ancak karşılanmadığı takdirde sistem yine de başarılı kabul edilecek; "arzular" (gerçek bir kelime değil, ama siz oradasınız), birisinin onları istediğini ve hedeflerin statüsüne ulaşmaya çalıştıklarını ancak henüz kabul edilmediklerini veya belgelenmediklerini gösterir; ya da kaynakları ele geçirmeye çalışan, ancak gerçek gereksinimleri tehlikeye atacak ya da tehdit edecekleri “yeterince iyi” başarmaya çalışan bir projede buna değmeyecek şeyleri belirten daha aşağılayıcı bir istek versiyonu olan “sürünen gereksinimler”.

Gereksinimlerinize öncelik tanınırsa , bunların düşük öncelikli gereksinimler olduğunu düşünebilirsiniz .

Kimsenin bunlara "hedef" denildiğinden bahsetmediğine oldukça şaşırıyorum. Çalıştığım her şirket onlara böyle seslendi. Bunlar, "olacaktır" yerine "irade" veya "gerekir" sözcükleri kullanılarak belirtilir. Bazen sayılar hakkında konuşurken Parantez içine dahil edilirler. Örneğin, sistem 100 {250} saat boyunca operatörün dikkatine ihtiyaç duymadan sürekli çalışmalıdır. Bu, yerine getirilmesi gereken şartın 100 saat, ancak hedefin 250 saat olduğu anlamına gelir.

Bir yan not olarak, bir tür teşvik söz konusu olmadıkça, nadiren herkes nesnel gereksinimi karşılamak için tasarlar.

"Desirement" terimi bazen isteğe bağlı gereksinimler için kullanılır. Ancak, resmi bir belge için uygun olmayabilir.

Tüm yanıtların proje geliştirmedeki izleme gereklilikleri ile ilgilendiğine şaşırdım. Bir geliştirici olmama rağmen, bu bağlamda bu terminoloji hakkında hiç endişelenmedim. Soruyu ilk okuduğumda, ürünün geliştirilmesi ile değil, kullanıcı ürün spesifikasyonu ile ilgili olduğunu varsaydım. Örneğin, bir ansiklopedi isteğe bağlı bir gereksinim olarak renkli bir yazıcıyı listeleyebilir. Uygulamanın tam faydasını istiyorsanız, ancak ekranı görüntülemek istiyorsanız isteğe bağlıdır. Peki ya örneğin tek renkli bir yazıcınız varsa? Uygulamanızın bazı fotoğrafların bu kadar iyi görünmeyebileceği zorlayıcı kısıtlama ile çalışıp çalışmadığını nasıl netleştirebilirim? Veya başka bir örnek olarak hiç yazdırmayacak mısınız? Çok işlevli bir yazıcıda mürekkebin veya isteğe bağlı bir gereksinimin olup olmadığını kontrol etmek için bir yazıcı incelemesini nasıl kontrol etmeliyim? Başka bir deyişle hala tarayabilir miyim? Terminoloji ve neyin aranacağına dair bazı ipuçları hem ürün geliştiricisi / satıcı hem de tüketici olarak kabul edilir.

Onlara "isteğe bağlı özellikler" diyebilirim, isteğe bağlı gereksinimleri değil. Gereksinimler , sahip olmanız gereken bir şey gibi görünürken, özellikler orijinal ürüne bir eklenti gibi geliyor.