Gereksinimler ve özellikler arasındaki fark nedir? [kapalı]

122

Grubumuzun başlattığı bir projenin gereksinimlerini ve özelliklerini geliştirmekle görevlendirildim.

Farkı bilmediğimi farkettim; Bir Google arama sadece beni daha karıştı - bazı insanların özellikleri olduğunu söylemek görünüyor olan gereksinimleri, ancak daha düşük bir seviyede.

requirements specifications

Yüksek oylama cevaplarına katılıyorum ancak şartname teriminin bazen yazılım endüstrisinde bir sistemi veya yazılım parçasını tanımlayan herhangi bir belgeye atıfta bulunarak daha genel bir terim olarak kullanıldığını düşünüyorum. Kanıt olarak - google "gereksinimler belirtimi". Bu şekilde kullanıldığında bir şeyi belirten bir belge anlamına gelir - yani: bir yazılım parçası için gereksinimleri belirtir. Bunun kelimenin doğru bir şekilde kullanılıp kullanılmadığına karar vermeyeceğim ya da sadece şartnamenin her zaman herkes için aynı anlama gelmediğine işaret etmek istemedim.

— Shane Wealti

1

Evet, bu yüzden insanlar “İş gereksinimleri” ve “Tasarım özellikleri” / “Teknik özellikler” veya başka bir şey söylemeliler. Kelimeler kendi başlarına oldukça belirsizdir.

— user606723

Bunu şöyle düşünün (kabaca konuşur): Gereksinimler = gereksinimler belgesi ve özellikleri = kullanım durumu / tasarım belgeleri

— Doktora

4

Neden bunları yaptığınız kişilere sormuyorsunuz? Sadece sizin özel durumunuzda neye ihtiyaç duyduğunuza cevap verebilirler .

— Jaap

Bu makale ayrıntılı bir cevap sunmaktadır: ece.cmu.edu/~koopman/des_s99/requirements_specs

— Julien-L

129

Ses ısırması cevabı, gereksinimlerin programınızın ne yapması gerektiği, spesifikasyonların nasıl yapmayı planladığınız olmasıdır.

Buna bakmanın başka bir yolu da gereksinimlerin uygulamayı kullanıcı veya işletme bütünü açısından temsil etmesidir. Şartname, teknik ekip perspektifinden uygulamayı temsil eder. Spesifikasyonlar ve gereksinimler kabaca aynı bilgiyi ancak iki tamamen farklı izleyiciye iletir.

— Bryan Oakley
kaynak

4

Ne / nasıl ses ısırık haklı, çeşit; Ancak kafa karıştırıcı, çünkü bir programın ne yapması gerektiğini ve tasarımın nasıl yapması gerektiğini açıklayan bir tarifnameye bakabilirsiniz . Diğeri ise neyin nasıl olduğunu neyin belirtmediğine dair bildirici pl'dir (prolog ve SQL gibi) . Bir çözüm, soyutlamaları hiyerarşik yapmalarıdır, ebeveynin neyi ve çocukların nasıl olduğunu belirten (dışarıdan içeriye doğru) belirtenleri . Ben çok daha yakın olduğunu ikinci görünümü, tercih "O ne için karşı" ne " olduğunu özelliği vs yani parası".

— 13ren

Genelde sizinle aynı fikirdeyim, ama bu sadece 'başka' bir fikir ve doğru cevabı değil. Örneğin, Gereksinimler için Wiki sayfasına bakın ( en.wikipedia.org/wiki/Requirement ). Tanım olarak teknik ekip için olan işlevsel olmayan gereksinimler vardır. Veya Mimari ve Kısıtlamalar gereklilikleri, yine teknik ancak henüz onlara 'teknik özellik' demiyorlar. Doğru cevap olmadığını düşünüyorum ve her zaman şirketten şirkete ve geliştiriciden geliştiriciye 'bulanık' olacak.

— Jeach

1

'Adam Wuerl' yazısına verilen cevaba bir göz atın, bu sorunun en doğru ifade olduğunu düşünüyorum.

— Jeach

1

@Jeach: "feryat" [sic] görecelidir. Şu anda bu yazının altında olabilir, ancak yorumunuzun anlaşılmasını zorlaştıracak şekilde yukarı doğru hareket edebilir

— Bryan Oakley

1

Başka bir bakış açısı .. Wikipedia, özellikleri bir "gereksinimler kümesi" olarak tanımlar. Bu, bir özelliğin yalnızca 1 gereksinim olabileceği anlamına gelir, s: = {r1}. "Teknik özellikler" düşük seviye gereksinimlerdir, LOD meselesi ise, konuşma "gereksinimleri" nin "üst düzey" gereksinimler olduğu daha fazla görünmektedir.

— Lance Pollard

38

Gereksinimler, neye ihtiyaç duyulduğunu belgelemektedir - neyin nasıl olduğunu değil neyi belirteceğini belirtmelidir.

Spesifikasyonlar şartların nasıl yerine getirileceğini belgelemektedir - nasıl yapılacağını belirtmelidir.

Birçok yerde bu belgeler ayrı değildir ve birbirlerinin yerine kullanılır.

— Oded
kaynak

2

Şirketimde normal olarak ne için (gereksinimlerinizi, ne olduğunu, ne yazdığınızı) ve ne için (tasarımını belirtin, ayrıntıları nasıl yazdığınızı) "tasarım belirtimi" terimlerini kullanırız. bunu uygulamayı planla).

— Giorgio

16

Ben her iki terimin de yoğun olarak kullanıldığı havacılık alanındaki bir sistem mühendisiyim. Bu ayrım açık ve diğerlerinin yaptığı kadar karmaşık değil.

Bir şartname , bir sistemi veya ürünü belirten bir dokümandır, örneğin bir F-14 için ana ürün geliştirme şartnamesi. Spesifikasyonda birçok bölüm / içerik var: gereksinimler, tanımlar, referans belgeleri, sözlük, doğrulama bilgileri, vb.

Bir gereklilik , ürün veya sistemin yapması gereken tek bir şeydir. Bir spesifikasyonda yüzlerce gereksinim olabilir. Eski okul metodolojisi, gereklilik bildiriminin gereklilikleri gerçekler veya tanımlardan ayırmak için "olur" kelimesini kullanması gerektiğini söylüyor. (Yeni dişi çevik çocukların tüm bunlara devam edip etmediklerinden emin değiliz; titizliğin kullanımı var ama zaman zaman biraz telaşlı.)

Dolayısıyla bir şartname, bazı diğer destekleyici ve yardımcı bilgilerle dolu olan bir belgedir.

— Adam Wuerl
kaynak

4

Başka bir yorumda dediğim gibi, herkes için çok bulanık ve muhtemelen her zaman olacaktır. Ancak bu kesin konuda kendi ÇOK kapsamlı araştırmamı temel alarak, cevabınızın kendi bulguları / sonuçları için en doğru olduğunu söyleyebilirim.

— Jeach

2

Gerçek bir mühendisin girdisini almak her zaman yardımcı olur. Teşekkürler!

— LeWoody

Alternatif olarak, bir Spesifikasyonda 0 şartı olabilir. Örneğiniz çok özel bir havacılık mühendisliği disiplini için gerçekten iyi bir örnek. Genel olarak yazılım geliştirme / programlama alanına uygulanabilir olduğundan emin değilim. Çoğu yazılım işletme talepleri tarafından yönlendirildiğinde, teknik kısıtlamaları değerlendirmeden ve bir çözüm tasarlamadan önce ayrıntılı bir İş Gereksinimleri Belgesiyle başlamak mantıklı olacaktır. Teknik Şartname BRD'yi takip eder, kısıtlamaları belgeler ve BRD'deki iş gereksinimlerini karşılamak için detaylı ve özel bir yaklaşım sunar.

— Bryan 'BJ' Hoffpauir Jr.

1

@ Bryan'BJ'Hoffpauir Belge etiketli şartnamelerin belirtildiği ve bunlarda herhangi bir şartın bulunmadığı durumlar olduğundan eminim, ancak bu terimi kötüye kullananlara itiraz ediyorum. Bir şartname bir şart belgesidir - hikayenin sonu. Bu, havacılık ve savunma alanlarındaki daha çok alanda yaygın olarak kabul edilen bir sanat dönemidir ve gereksinimlerden ve doğrulamadan sorumlu olan disiplin olan sistem mühendisliği kapsamında güvensizdir. Terimin geçerli olduğunu açıklasanız bile: BRD bir özelliktir, teknik özellik de farklı gereklilikler gibi bir ses çıkarır.

— Adam Wuerl,

13

Gereksinimler:

Çeşitli paydaşların muhtemel çelişkili gereklerini dikkate alarak yeni veya değiştirilmiş bir ürün için karşılayacak ihtiyaçları veya koşulları belirleyin.

Özellikler:

Sistemi etkin bir şekilde tasarlayabilmeleri ve tasarım alternatiflerinin maliyetini tahmin edebilmeleri için çözülmesi gereken sorun hakkında kesin bir fikir sunarlar. Her teknik gereksinimin doğrulanması (teslimi) için test uzmanlarına rehberlik ederler.

Alıntı "Sistem Mühendisliği Temelleri ^* " dir.

Gereksinimler paydaşların ihtiyaçlarına dayanmaktadır, şartnameler daha ayrıntılı ve teknik bir belgedir. Farklılar ama aynı şey hakkında konuşuyorlar.

_{* Savunma Edinme Üniversitesi Yayınları, 2001. Metnin PDF versiyonu .}

— talabes
kaynak

Tanımınızın bu özelliğin SORUNU tanımladığını söylemesinin önemli olduğunu düşünüyorum. Bu şekilde bir SORUN belirtimi bir gerekliliktir. Bir ÇÖZÜM veya TASARIM spesifikasyonu tasarımın bir parçasıdır.

— LeWoody

6

Gereksinimler, kullanıcıların bitmiş ürünün, gözlerinde yapması gerekenlerin tanımıdır.

Spesifikasyon, genel olarak çözümün teknik tanımıdır, gereksinimleri ve daha fazlasını içerir - örneğin maliyet, teknik, problem vb.

Bu nedenle, ana noktalardan biri, bir Şartname yazılmadan önce Şartların önce gelmesi gerektiğidir.

(Terminolojiye dikkat edin - ürün ve çözüm - aynı şey ama farklı açılardan…)

— Arj
kaynak

1

"Ürün" ve "çözüm" terimlerini değiştiririm, çünkü bir çözüm genellikle müşterinin problemi, bir ürün ise genellikle satıcı (yani teknik uygulayıcı) anlamındadır. Benzer bir kontrast yararı (ne işe yarar onlara olan) müşteri açısından ise yarar / özelliktir ve özellik (aslında neyi uygulama açısından ise ise bunu, bu yüzden bunu yapabilirsiniz).

— 13ren

1

Amacınızı anlıyorum ama bence her iki açı da durumu yeterince açıklıyor. Bir mağazaya giderken yaptığınız gibi bir müşterinin bir ürün satın alacağı görüşünü aldım. Bir yazılım satıcısı, altta yatan soruna kendi çözümünü sunacaktı. Sorunuma bir çözüm bulmak için alışverişe çıkacak olsam, muhtemelen "abc sorunum için bir çözüme ihtiyacım var" değil, "xyz yapan bir ürüne ihtiyacım var" diye düşünürdüm. Bu sadece bir tercih meselesi olduğunu düşünüyorum.

— Arj kas

ilginç. Belirlenmiş bir ürün kategorisi olduğunda müşterileri "bir ürün arayan" görebilirim. Ancak bu ürünü araştırıyorlar, çünkü problemlerini çözeceklerini çoktan çözdüler - yani bu ürünü kendi iyiliği için değil, bir çözüm olarak ararlar. Ayrıca bir satıcının ürünlerini "çözüm" olarak pazarladığı da doğrudur - bunun nedeni, müşterileriyle iletişim kurmaya çalıştıkları (sorunlarına çözüm arayanlar) ve istenen bir şeyi inşa etmeye çalıştıklarıdır. Aslında ürünü inşa etmek (yani, ihtiyaç ve neden ihtiyaç duyulduğundan bağımsız olan şey )

— 13ren

Yerleşik bir ürün kategorisi olduğunda müşterileri "ürün arayan" olarak görebiliyorum - ancak bunu bir sorun / ihtiyaç için bir çözüm olarak görüyorlar. Satıcılar ürünlerini "çözümler" olarak pazarlarlar - çünkü müşterileriyle iletişim kuruyorlar (çözüm gerektiren sorunları var). Ürünü oluştururken (ürünün kendisi ve özellikleri, neden ürettiklerini değil ). Argümanlardan biri, bir sorunun çok farklı çözümlere sahip olabileceğidir - ama bir ürün belirli bir şeydir.

— 13ren

[neden iki yorumun açıklanması]: SO yorumları çok acı verici - "geri dönüşe" vurmak, çok satırlı bir metin çizelgesi olsa bile yorumu sunacak. Ve bundan sonra bitirmek için 5 dakikadan fazla zaman alırsanız, düzenlemeyi kabul etmez. Bu yüzden ikinci bir yorum olarak sunmalısınız. Sadece boyuna sığdırmak için düzenliyordum. nefes . Bir dahaki sefere ben sadece üstüne iki yorum yayıldı ... [neyse, bakış açısı - alıcı / satıcı - ana ayrım olduğuna katılıyorum. Terminolojinizden dolayı sıkıntı duyuyorum, ancak nedenini açıklamaya çalışmak konusundaki anlayışımı derinleştirdiğini düşünüyorum.]

— 13ren

4

Gereklilik - sistem veya alt sistemin yapması gereken (yapılması gereken).

Şartname - Bileşen, alt sistem veya sistem IS.

Bu, tıbbi cihaz imalat endüstrisinde kritik öneme sahiptir, çünkü geçerli spesifikasyonlara (Çıkışlar) sahip olduğunuzu kanıtlamak için gereksinimlerinize (Girişler) Doğrulama yapmalısınız. Bu sektördeki tipik tuzaklar, şirketlerin (1) gereksinimleri tanımlamayı unutmalarıdır (çünkü şartlar ile şartlar arasındaki farkı anlamadıkları için); (2) Sadece spesifikasyonlara göre Doğrulama Yapın ve (3) Gerekliliklerin alt montaj ve bileşen özelliklerine doğru bir şekilde çevrildiğinden emin olmayın.

Bunların hepsi yapıldıktan sonra, ürün için Kullanıcı gereksinimlerini doğrulamanız istenir.

— Paul Bacchus
kaynak

3

Belki de buradaki karışıklık, spesifikasyonları duyduğumda İş Gereksinimi Şartnamesi belgelerine veya IEEE standardı SRS (Yazılım Gereksinimi Şartnamesi) belgelerine atıfta bulunmamdır.

IEEE standardı SRS Şablon Örneği

Ayrıca, şartname teriminin, tasarım kararlarını ve bir uygulama planını açıklayan Teknik Şartnamelere daha gayrı resmi olarak atıfta bulunduğunu duydum .

EDIT: Sadece bağlantının yanlış olduğunu fark ettim ... Kısa süre içinde doğru bir link göndereceğim.

— maple_shaft
kaynak

1

SRS teriminde iyi nokta!

— LeWoody

2

Bağlantı şimdi tamamen koptu. Neye işaret ettiğini veya hangi materyali göstermesi gerektiğinden emin değilim .

3

Bir şartname, uygulanabilirlikten geçen ve uygulamaya hazır olan bir gereksinimdir. Tasarım aşamasına gelişen bir gerekliliktir.

Başka bir deyişle:

Bir gereklilik "planlandığı gibi" veya "istenildiği gibi" davranış (veya davranış dışı) dır.
Bir şartname "inşa edilecek" davranış veya davranış dışıdır

Örnek:

gereksinimi: 1. kullanıcı OK düğmesine basar 2. sistem faturayı yazdırır
özellikleri: 1. kullanıcı OK düğmesine basar 2. sistem fatura yazdırır

Gördüğünüz gibi, her ikisinin içeriği aynı olabilir. Aradaki fark, gereksinimin bir analiz artefaktı olmasıdır. Şartname bir tasarım eserdir.

Son olarak oluşturulmuş bir belgede, gereksinimler teknik özelliklere dönüştürüldüğünden, "gereksinim" yerine "belirtim" kelimesini bulacaksınız.

Not: Yukarıdaki örnek, tasarım kısıtlaması nedeniyle tasarım unsurlarını içerir.

— fox.bailey
kaynak

0

Gereksinimler uygulamanın ne yaptığını

Teknik özellikler NASIL uygulama yapar ne yapar.

Ortogonal olmalılar!

Ürün yöneticileri gereklilikleri, genel müdürlerin özelliklerini yazar.

— jayunit100
kaynak

2

En azından pratikte tamamen ortogonal olduklarından emin değilim. Maalesef çok fazla gri var.

— LeWoody

Bunlar sadece değiştiricileri bırakırsanız gridir - İşletme Gereksinimleri, İşlevsel Gereksinimler, İşlevsel Olmayan Gereksinimler, sistemin kapasitesine atıfta bulunur (ne yapar). Teknik Özellikler, İş Gereksinimlerine göre diktir (NASIL yapar).

— Bryan 'BJ' Hoffpauir Jr.

0

Bir yol, belki de doğru yol değil, ona bakmak:

Gereksinimler , kullanıcıya değer veren şeylerdir (yetenekler, özellikler, davranışlar vb.). İçişleri ile ilgili değil; Burada sadece kutunun girişleri ve çıkışları (ve belki de büyüklüğü, şekli ve rengi) önemlidir.

Spesifikasyonlar , kullanıcı için bu değeri sağlayan şeylerdir (yetenekler, özellikler, davranışlar vb.). Burada kutu iç kısımları önemlidir, çünkü yukarıda belirtilen dış arabirimler ve özellikler ile birlikte tüm sistemi tanımlarlar.

— Berad
kaynak

Bu sadece senin fikrin mi yoksa bir şekilde mi destekleyebilirsin?

— gnat

2

@gnat, açılış hattında ele alındığını düşündüm? Elbette, bu deneyimden kaynaklanıyor ve başka hiçbir şey talep etmiyorum - topladığımdan itibaren, öznel bir forumda biraz öznel bir soru ve bu yazı , soruların olabildiğince objektif olması gerektiğini, ancak cevaplardan çok az bahsettiğini gösteriyor. . Ama benim adıma göre bir tane var ve çok daha fazlasına sahipsiniz bu yüzden eğitimli

— olmaya açıkım

0

Araştırmamda, patentler ve Konut İnşası için kullanılacak sözleşmeleri (bir sözleşmenin parçası olarak) buldum.

Webster'nın Kısaltılmamış Sözlüğünden (3. Yeni Uluslararası Baskı) bir gereksinimin tanımı şöyledir:

a) aranan ya da ihtiyaç duyulan bir şey: Gereklilik b) aranan ya da talep edilen bir şey: gerekli ya da zorunlu bir koşul: gerekli bir kalite, kurs ya da eğitim türü

Yukarıdakilerin açıkça farklı olduklarını gösteriyor. Sanırım spec'in daha düşük seviyedeki gereksinimlerini arayabilirsin, ama bence bu gereksinim terimi için bir sapmadır.

— LeWoody
kaynak

0

Ticari ürünler yaratan önceki bir şirkette şu ayrıcalığımız vardı:

Gereksinimler sistemin yapması gerekenlerdir. Daha düşük seviyeli, detaylı gereksinimler olabilir ve işlevsel veya işlevsel olmayabilirler.

Spesifikasyonlar, sistemin gerçekte yaptığı gibi şeylerdir. Örneğin, sistemin –10 ° C'de X davranışına sahip olduğunu bildiren bir gereksiniminiz olabilir. Sistemin asıl özellikleri sistemin –5 ° C'de X yapması olabilir; bu, sistemi satın almak istediklerinde potansiyel müşterilere gönderilen sayfada olacaktır.

NB bu durumda şartname şartı eşit değil.

— Royd
kaynak

-1

Bir karada yüksek bina inşa edeceğinizi düşünün.

Şimdi, başlamadan önce Gereksinimleri dikkate almanız gerekir, örneğin:

Mimarlık veya Tasarım Mühendisi
Zemin Test Mühendisi
Rüzgar Basıncı Test Takımı
Demolisher
kazıcı
İnsan Gücü
Su tedarik etmek
Yaşam / dinlenme alanı çalışanları
Yeterli Fon
Proje Yönetimi
Kalite Yönetimi
Güvenlik ve Güvenlik Kontrolü

Vb.

Şimdi yukarıdaki içerik yüksek bina inşa etmek için Gereksinimlerin bir parçasıdır. Yukarıdaki ekipten mesleğin bir parçası olan teknik sonucu alırsınız.

Bu tam olarak, yazılım endüstrisinde ne oluyor, birisi UI tasarımı, OO tasarımı, veritabanı tasarımı, grafik tasarımı, test senaryosu tasarımı, kodlama, entegrasyon üzerinde çalışanlar gibi teknik şartnameyi oluşturmak için bilgi sağlamak için ilgili bir grup profesyonel insandan oluşuyor. dağıtım ekibi vb.

Yukarıdaki paragraf, Teknik Şartname olarak adlandırabileceğiniz el kitabının bir parçası olacaktır.

— Muhammed Hoq
kaynak

1

Sanırım gereksinimleri kaynaklarla karıştırıyorsunuz ( en.wikipedia.org/wiki/Resource_%28project_management%29 ).

— Jay Elston,