Apa perbedaan antara persyaratan dan spesifikasi? [Tutup]

122

Saya telah ditugaskan untuk mengembangkan persyaratan dan spesifikasi untuk proyek yang dimulai oleh grup kami.

Saya menyadari bahwa saya tidak tahu bedanya; pencarian Google hanya membingungkan saya lebih - tampaknya beberapa orang mengatakan bahwa spesifikasi adalah persyaratan, tetapi pada tingkat yang lebih rendah.

requirements specifications

Saya setuju dengan jawaban suara tinggi tetapi saya juga berpikir bahwa spesifikasi istilah kadang-kadang digunakan sebagai istilah yang lebih umum dalam industri perangkat lunak mengacu pada dokumen yang menjelaskan sistem atau perangkat lunak. Sebagai bukti - google "spesifikasi kebutuhan". Ketika digunakan dengan cara itu berarti dokumen yang menentukan sesuatu - yaitu: menentukan persyaratan untuk perangkat lunak. Saya tidak akan menilai apakah itu penggunaan kata yang tepat atau tidak, saya hanya ingin menunjukkan bahwa spesifikasi tidak selalu berarti hal yang sama untuk semua orang.

— Shane Wealti

1

Ya, itu sebabnya orang harus mengatakan "Persyaratan bisnis" dan "Spesifikasi desain" / "Spesifikasi teknis" atau sesuatu. Kata-katanya sendiri cukup samar.

— user606723

Pikirkan seperti ini (secara kasar): Persyaratan = persyaratan dokumen dan spesifikasi = kasus penggunaan / dokumen desain

— PhD

4

Mengapa Anda tidak bertanya kepada orang yang Anda buat ini? Hanya mereka yang dapat menjawab apa yang dibutuhkan dalam kasus spesifik Anda .

— Jaap

Artikel ini menawarkan jawaban menyeluruh: ece.cmu.edu/~koopman/des_s99/requirements_specs

— Julien-L

129

Jawaban yang menggigit adalah bahwa persyaratan adalah apa yang harus dilakukan oleh program Anda, spesifikasinya adalah bagaimana Anda berencana untuk melakukannya.

Cara lain untuk melihatnya adalah bahwa persyaratan mewakili aplikasi dari perspektif pengguna, atau bisnis secara keseluruhan. Spesifikasi tersebut mewakili aplikasi dari sudut pandang tim teknis. Spesifikasi dan persyaratan secara kasar mengomunikasikan informasi yang sama, tetapi kepada dua audiens yang sama sekali berbeda.

— Bryan Oakley
sumber

4

The apa / bagaimana suara-gigitan yang tepat, semacam; tetapi membingungkan, karena Anda juga dapat melihat spesifikasi untuk suatu program sebagai menggambarkan apa yang harus dilakukan, dan desain menjadi bagaimana seharusnya melakukannya. Lain adalah pl deklaratif (seperti prolog dan SQL), di mana Anda menyatakan apa yang bukan bagaimana . Satu resolusi adalah bahwa mereka adalah hirarki abstraksi, dengan orang tua yang menyatakan apa dan anak-anak menyatakan bagaimana (di luar vs di dalam). Saya lebih memilih pandangan kedua, yang lebih dekat ke "apa itu untuk " vs "apa yang " yaitu manfaat fitur vs.

— 13rn

Saya biasanya akan setuju dengan Anda, tetapi itu hanya pendapat 'lain' dan bukan jawaban yang benar. Sebagai contoh, lihat halaman Wiki untuk Persyaratan ( en.wikipedia.org/wiki/Requirement ). Ada persyaratan non-fungsional, yang menurut definisi adalah untuk tim teknis. Atau persyaratan Arsitektur dan Kendala, sekali lagi teknis tetapi belum menyebut mereka 'spesifikasi'. Saya pikir tidak ada jawaban yang benar dan itu akan selalu 'buram' dari perusahaan ke perusahaan dan pengembang ke pengembang.

— Jeach

1

Lihatlah jawaban 'Adam Wuerl' di bawah, saya pikir itu adalah pernyataan yang paling akurat untuk pertanyaan yang diposting.

— Jeach

1

@Jeach: "bellow" [sic] adalah relatif. Mungkin di bawah pos ini saat ini, tetapi bisa bergerak di atas, membuat komentar Anda lebih sulit dimengerti

— Bryan Oakley

1

Perspektif lain .. Wikipedia mendefinisikan spesifikasi sebagai "seperangkat persyaratan". Ini berarti bahwa sebuah spec dapat hanya 1 persyaratan, s: = {r1}. Tampaknya lebih bahwa "persyaratan" sehari-hari adalah persyaratan "tingkat tinggi", sedangkan "spesifikasi teknis" adalah persyaratan tingkat rendah, hal LOD.

— Lance Pollard

38

Dokumen persyaratan apa yang diperlukan - mereka tidak harus menentukan bagaimana, tetapi apa.

Spesifikasi mendokumentasikan bagaimana mencapai persyaratan - mereka harus menentukan caranya.

Di banyak tempat, dokumen-dokumen ini tidak terpisah dan digunakan secara bergantian.

— Oded
sumber

2

Di perusahaan saya, kami biasanya menggunakan istilah "spesifikasi kebutuhan" untuk apa (Anda tentukan, tuliskan perinciannya, apa yang Anda apa), dan "spesifikasi desain" untuk caranya (Anda tentukan, tuliskan perinciannya, bagaimana Anda berencana untuk mengimplementasikannya).

— Giorgio

16

Saya seorang insinyur sistem di bidang dirgantara, di mana kedua istilah tersebut digunakan secara luas. Perbedaannya jelas dan tidak serumit yang dibuat orang lain.

Sebuah spesifikasi adalah dokumen yang menentukan sistem atau produk, misalnya spesifikasi pembangunan prime-item untuk F-14. Ada banyak bagian / konten dalam spesifikasi: persyaratan, definisi, dokumen referensi, glosarium, informasi verifikasi, dll.

Sebuah kebutuhan adalah pernyataan tunggal sesuatu produk atau sistem harus melakukan. Sebuah spec mungkin memiliki ratusan persyaratan di dalamnya. Metodologi old school mengatakan pernyataan persyaratan harus menggunakan kata "wajib", untuk memisahkan persyaratan dari pernyataan fakta, atau definisi. (Tidak yakin apakah anak-anak gesit yang baru fangled menjaga semua ini atau tidak; fastidiousness memiliki penggunaannya tetapi kadang-kadang sedikit cerewet.)

Jadi spec adalah dokumen yang penuh dengan persyaratan, ditambah beberapa informasi pendukung dan tambahan lainnya.

— Adam Wuerl
sumber

4

Seperti yang saya katakan di komentar lain, itu sangat kabur untuk semua orang dan mungkin akan selalu begitu. Tetapi berdasarkan penelitian SANGAT ekstensif saya sendiri pada subjek yang tepat ini, saya akan mengatakan jawaban Anda adalah yang paling akurat untuk temuan / kesimpulan saya sendiri.

— Jeach

2

Selalu membantu untuk mendapatkan input insinyur nyata. Terima kasih!

— LeWoody

Atau, sebuah Spec mungkin memiliki 0 persyaratan di dalamnya. Contoh Anda adalah contoh yang sangat bagus untuk disiplin teknik penerbangan yang sangat spesifik. Saya tidak begitu yakin ini berlaku untuk pengembangan perangkat lunak / domain pemrograman. Ketika sebagian besar perangkat lunak didorong oleh tuntutan bisnis, masuk akal untuk memulai dengan Dokumen Persyaratan Bisnis yang terperinci sebelum mengevaluasi kendala teknis dan merancang solusi. Spesifikasi Teknis akan mengikuti BRD, mendokumentasikan kendala, dan menyediakan pendekatan terperinci dan spesifik untuk memenuhi persyaratan bisnis dalam BRD.

— Bryan 'BJ' Hoffpauir Jr

1

@ Bryan'BJ'Hoffpauir Saya yakin ada beberapa kasus di mana dokumen berlabel spesifikasi dan tidak memiliki persyaratan di dalamnya, tetapi saya akan berpendapat mereka yang menyalahgunakan istilah tersebut. Spesifikasi adalah dokumen persyaratan - akhir cerita. Ini adalah istilah seni yang diterima secara luas di lebih banyak bidang yang dirgantara dan dipertahankan dan tidak dapat disangkal dalam rekayasa sistem, yang merupakan disiplin yang bertanggung jawab untuk persyaratan dan verifikasi. Bahkan jika Anda menjelaskan istilah yang berlaku: BRD adalah sebuah spek, spek teknologi juga terdengar seperti itu, hanya dengan berbagai jenis persyaratan.

— Adam Wuerl

13

Persyaratan:

Tentukan kebutuhan atau ketentuan untuk memenuhi produk baru atau yang diubah, dengan mempertimbangkan persyaratan yang mungkin bertentangan dari berbagai pemangku kepentingan.

Spesifikasi:

Mereka memberikan ide yang tepat tentang masalah yang harus dipecahkan sehingga mereka dapat secara efisien merancang sistem dan memperkirakan biaya alternatif desain. Mereka memberikan panduan kepada penguji untuk verifikasi (kualifikasi) dari setiap persyaratan teknis.

Kutipannya dari "System Engineering Fundamentals ^* ".

Persyaratan didasarkan pada kebutuhan pemangku kepentingan, spesifikasi lebih merupakan dokumen terperinci di dalam dan teknis. Mereka berbeda, tetapi mereka berbicara tentang hal yang sama.

_{* Defense Acquisition University Press, 2001. Teks versi PDF .}

— talabes
sumber

Saya pikir penting bahwa definisi Anda mengatakan bahwa spec menentukan MASALAH. Dengan cara itu, spesifikasi MASALAH adalah persyaratan. Spesifikasi SOLUSI atau DESAIN adalah bagian dari desain.

— LeWoody

6

Persyaratan adalah deskripsi pengguna tentang apa yang harus dilakukan produk jadi, di mata mereka.

Spesifikasi adalah deskripsi teknis dari solusi secara umum, yang mencakup persyaratan dan banyak lagi - misalnya biaya, teknis, masalah, dll.

Oleh karena itu, salah satu poin utama adalah bahwa Persyaratan harus didahulukan sebelum Spesifikasi dapat ditulis.

(Perhatikan terminologi - produk dan solusi - hal yang sama tetapi dari perspektif yang berbeda ...)

— Arj
sumber

1

Saya akan menukar istilah "produk" dan "solusi", karena solusi biasanya dalam hal masalah pelanggan, sedangkan produk biasanya dalam hal penjual (yaitu pelaksana teknis). Sebuah kontras yang sama adalah manfaat / fitur, di mana manfaat adalah dalam hal pelanggan (apa gunanya kepada mereka), dan fitur adalah dalam hal pelaksanaan (apa yang sebenarnya adalah , sehingga kita bisa membuatnya).

— 13ren

1

Saya mengerti maksud Anda, tetapi saya pikir salah satu sudut cukup menggambarkan situasi. Saya berpandangan bahwa seorang pelanggan akan membeli suatu produk - seperti yang Anda lakukan ketika Anda pergi ke toko. Seorang vendor perangkat lunak kemudian akan menawarkan solusi mereka untuk masalah yang mendasarinya. Jika saya pergi berbelanja untuk mencari solusi untuk masalah saya, saya mungkin akan berpikir, "Saya butuh produk yang xyz", bukan, "Saya butuh solusi untuk masalah saya abc". Itu hanya masalah preferensi saya pikir.

— Arj

menarik. Saya bisa melihat pelanggan "mencari produk", ketika ada kategori produk yang sudah mapan. Tetapi mereka mencari produk itu karena mereka sudah bekerja untuk menyelesaikan masalah mereka - yaitu mereka mencari produk itu, bukan untuk kepentingannya sendiri, tetapi sebagai solusi. Benar juga bahwa vendor memang memasarkan produk mereka sebagai "solusi" - tetapi itu karena mereka berusaha berkomunikasi dengan pelanggan (yang mencari solusi untuk masalah mereka), dan membangun sesuatu yang akan diinginkan. Sebenarnya membangun produk (yaitu, hal itu sendiri dan fitur-fiturnya terlepas dari mengapa mereka diperlukan)

— 13ren

Saya bisa melihat pelanggan "mencari produk", ketika ada kategori produk yang sudah mapan - tetapi mereka mencarinya sebagai solusi untuk masalah / kebutuhan yang mereka miliki. Vendor memasarkan produk mereka sebagai "solusi" - karena mereka berkomunikasi dengan pelanggan (yang memiliki masalah yang membutuhkan solusi). Ketika membangun produk (benda itu sendiri dan fitur-fiturnya, bukan mengapa mereka membangunnya). Salah satu argumen adalah bahwa suatu masalah dapat memiliki solusi yang sangat berbeda - tetapi suatu produk adalah satu hal yang spesifik.

— 13ren

[menjelaskan mengapa dua komentar]: SO komentar sangat merepotkan - menekan "kembali" akan mengirimkan komentar, meskipun itu adalah textarea multi-line. Dan jika Anda membutuhkan lebih dari 5 menit untuk menyelesaikannya setelah itu, itu tidak akan menerima hasil edit. Jadi, Anda harus mengirimkannya sebagai komentar kedua. Saya mengedit hanya untuk membuatnya sesuai panjang. desah . Lain kali saya hanya akan menyebarkan dua komentar di tempat pertama ... [Lagi pula, saya setuju bahwa sudut pandang - pembeli / vendor - adalah perbedaan utama. Saya bermasalah dengan terminologi Anda, tetapi saya pikir itu memperdalam pemahaman saya untuk mencoba mengartikulasikan alasannya.]

— 13ren

4

Persyaratan - apa yang harus dilakukan sistem atau subsistem.

Spesifikasi - Apa komponen, subsistem atau sistem itu.

Ini sangat penting dalam industri pembuatan perangkat medis karena Anda harus melakukan Verifikasi terhadap persyaratan (Input) Anda untuk menunjukkan bahwa Anda memiliki spesifikasi (Output) yang valid. Perangkap khas dalam industri ini adalah bahwa perusahaan (1) lupa untuk mendefinisikan persyaratan (karena mereka tidak memahami perbedaan antara persyaratan versus spesifikasi); (2) Melakukan Verifikasi terhadap hanya spesifikasi dan (3) Jangan memastikan bahwa Persyaratan diterjemahkan secara akurat ke dalam subassembly dan spesifikasi komponen.

Setelah semua ini selesai, Anda kemudian diminta untuk memvalidasi persyaratan Pengguna untuk produk yang telah dipenuhi.

— Paul Bacchus
sumber

3

Mungkin kebingungannya adalah bahwa saya telah mendengar spesifikasi merujuk pada dokumen Spesifikasi Kebutuhan Bisnis atau dokumen standar SRS (Spesifikasi Kebutuhan Perangkat Lunak) IEEE.

Contoh Template SRS standar IEEE

Saya juga telah mendengar istilah spesifikasi merujuk secara lebih informal ke Spesifikasi Teknis yang menjelaskan keputusan desain dan rencana implementasi.

EDIT: Saya hanya melihat link salah ... Saya akan memposting link yang benar lama.

— maple_shaft
sumber

1

Poin bagus tentang istilah SRS!

— LeWoody

2

Link sekarang benar-benar rusak. Saya tidak yakin apa yang menunjuk atau bahan apa di luar sana itu harus menunjuk ke.

3

Spesifikasi adalah persyaratan yang lulus kelayakan dan siap untuk diimplementasikan. Ini adalah persyaratan yang telah berkembang ke fase desain.

Dengan kata lain:

Persyaratan adalah perilaku (atau non-perilaku) "sesuai rencana" atau "sesuai keinginan"
Spesifikasi adalah perilaku (atau non-perilaku) "yang akan dibangun" atau "seperti yang dibangun"

Contoh:

persyaratan: 1. pengguna menekan tombol OK 2. sistem mencetak faktur
spesifikasi: 1. pengguna menekan tombol OK 2. sistem mencetak faktur

Seperti yang Anda lihat, konten keduanya bisa sama. Perbedaannya adalah bahwa persyaratan adalah artefak analisis. Spesifikasi adalah artefak desain.

Dalam dokumentasi final as-built, Anda biasanya akan menemukan kata "spesifikasi", alih-alih "persyaratan", karena persyaratan telah dikonversi ke spesifikasi.

Catatan: contoh di atas mengandung elemen desain, karena kendala desain.

— fox.bailey
sumber

0

Persyaratan adalah apa aplikasi TIDAK

Spesifikasinya adalah BAGAIMANA aplikasi melakukan apa yang dilakukannya.

Mereka harus ortogonal!

Manajer produk menulis persyaratan, kepala insinyur menulis spesifikasi.

— jayunit100
sumber

2

Saya tidak yakin mereka sepenuhnya ortogonal, setidaknya dalam praktiknya. Sayangnya ada banyak warna abu-abu.

— LeWoody

Mereka hanya abu-abu jika Anda meninggalkan pengubah - Persyaratan Bisnis, Persyaratan Fungsional, Persyaratan Non-Fungsional mengacu pada kemampuan sistem (APA yang dilakukannya). Spesifikasi Teknis ortogonal untuk Persyaratan Bisnis (BAGAIMANA melakukannya).

— Bryan 'BJ' Hoffpauir Jr

0

Satu cara, mungkin bukan cara yang benar, untuk melihatnya:

Persyaratan adalah hal-hal (kemampuan, fitur, perilaku, dll) yang menghasilkan nilai bagi pengguna. Tidak peduli dengan internal; hanya input dan output kotak (dan mungkin ukuran, bentuk, dan warna) yang penting di sini.

Spesifikasi adalah hal-hal (kemampuan, fitur, perilaku, dll) yang memungkinkan nilai itu bagi pengguna. Di sini, kotak internal adalah penting, karena bersama dengan antarmuka eksternal dan karakteristik yang disebutkan di atas mereka menentukan seluruh sistem.

— berad
sumber

Apakah ini hanya pendapat Anda atau Anda dapat mendukungnya?

— nyamuk

2

@gnat, saya pikir itu dialamatkan di baris pembuka? Tentu, ini dari pengalaman dan saya tidak mengklaim apa pun - dari apa yang saya kumpulkan ini adalah pertanyaan yang agak subyektif di forum yang agak subyektif, dan posting ini menunjukkan bahwa pertanyaan harus seobjektif mungkin tetapi hanya sedikit menyebutkan jawaban. . Tetapi saya memiliki satu dengan nama saya dan Anda memiliki lebih banyak lagi jadi saya terbuka untuk dididik :-)

— berad

0

Dalam penelitian saya, saya telah menemukan Spesifikasi yang akan digunakan untuk paten dan Konstruksi Rumah (sebagai bagian dari kontrak).

Definisi persyaratan dari Webab's Unabridged Dictionary (3rd New Int'l Ed.) Adalah:

a) sesuatu yang diinginkan atau dibutuhkan: Kebutuhan b) sesuatu yang disebut atau diminta: kondisi yang diperlukan atau esensial: kualitas yang diperlukan, kursus, atau jenis pelatihan

Saya pikir hal di atas menunjukkan mereka jelas berbeda. Saya kira Anda bisa memanggil persyaratan tingkat yang lebih rendah dari spec, tapi saya pikir itu adalah penyimpangan dari persyaratan persyaratan imho.

— LeWoody
sumber

0

Di perusahaan sebelumnya yang menciptakan produk komersial, kami memiliki perbedaan sebagai berikut:

Persyaratan adalah apa yang harus dilakukan sistem. Mereka dapat tingkat yang lebih rendah, persyaratan rinci, dan mereka dapat fungsional atau tidak fungsional.

Spesifikasi adalah hal-hal yang sebenarnya dibangun oleh sistem. Misalnya Anda dapat memiliki persyaratan yang menyatakan sistem harus memiliki perilaku X pada –10 ° C. Spesifikasi sebenarnya dari sistem mungkin bahwa sistem melakukan X pada –5 ° C; ini akan berada di lembar dikirim ke pelanggan potensial ketika mereka ingin membeli sistem.

NB dalam hal ini spesifikasinya tidak sama dengan persyaratan.

— RoyD
sumber

-1

Pikirkan, Anda akan membangun gedung bertingkat di atas tanah.

Sekarang Anda perlu mempertimbangkan Persyaratan sebelum memulai, seperti:

Insinyur Arsitektur atau Desain
Insinyur Uji Tanah
Tim Uji Tekanan Angin
Pembongkar
Penggali
Tenaga Pria
Persediaan air
Tempat tinggal / tempat istirahat pekerja
Dana yang cukup
Manajemen proyek
Manajemen mutu
Kontrol Keamanan dan Keselamatan

Dll

Sekarang isi di atas adalah bagian dari Persyaratan untuk membangun gedung bertingkat tinggi. Dari tim di atas, Anda mendapatkan hasil teknis, yang mereka pegang sebagai bagian dari profesi.

Inilah tepatnya, apa yang terjadi dalam industri perangkat lunak, sekelompok orang profesional yang terlibat untuk memberikan pengetahuan untuk membangun spesifikasi teknis, seperti seseorang yang bekerja pada desain UI, desain OO, desain basis data, desain grafis, desain kasus uji, koding, integrasi , tim penempatan, dll.

Para di atas akan menjadi bagian dari buku pegangan, yang dapat Anda sebut Spesifikasi Teknis.

— Mohammed Hoq
sumber

1

Saya pikir Anda membingungkan persyaratan dengan sumber daya ( en.wikipedia.org/wiki/Resource_%28project_management%29 ).

— Jay Elston