Spesifikasi kebutuhan perangkat lunak

**Spesifikasi Kebutuhan Perangkat Lunak** (bahasa Inggris: *Software Requirements Specification*) adalah dokumen yang dibuat ketika deskripsi detail dari semua aspek perangkat lunak yang akan dibangun terspesifikasi sebelum proyek dimulai. Perlu dicatat bahwa SKPL formal tidak harus dalam bentuk tulisan. Namun, ketika perangkat lunak akan dikembangkan oleh pihak ketiga, ketika kurangnya spesifikasi akan membuat masalah kritikal dalam bisnis, atau ketika sistem sangat kompleks atau *business critical*, SKPL harus dijustifikasi.

SKPL adalah pernyataan resmi tentang apa yang harus diterapkan oleh pengembang sistem. SKPL harus mencakup kebutuhan pengguna untuk suatu sistem dan spesifikasi terperinci dari kebutuhan sistem. Terkadang, kebutuhan pengguna dan sistem diintegrasikan ke dalam satu deskripsi. Dalam kasus lain, kebutuhan pengguna didefinisikan dalam pengantar spesifikasi kebutuhan sistem. Jika ada sejumlah besar kebutuhan, kebutuhan sistem terperinci dapat disajikan dalam dokumen terpisah. SKPL sangat penting ketika pihak ketiga mengembangkan sistem perangkat lunak. Namun, metode *[[Agile Development Methods|agile software development]]* berpendapat bahwa kebutuhan berubah begitu cepat sehingga SKPL sudah kedaluwarsa begitu ditulis, sehingga sebagian besar upaya sia-sia. Daripada dokumen formal, pendekatan seperti *[[Extreme programming|Extreme Programming]]*  mengumpulkan kebutuhan pengguna secara bertahap dan menuliskannya pada kartu (CRC) sebagai *user stories*. Pengguna kemudian memprioritaskan kebutuhan untuk implementasi dalam rilis sistem selanjutnya. Untuk sistem bisnis di mana kebutuhannya tidak stabil, pendekatan ini baik untuk digunakan. Namun, tetap lebih baik lagi untuk menulis dokumen pendukung singkat yang mendefinisikan bisnis dan kebutuhan ketergantungan untuk sistem karena hal yang mudah untuk melupakan kebutuhan yang berlaku untuk sistem secara keseluruhan ketika berfokus pada kebutuhan fungsional untuk rilis sistem berikutnya.

Spesifikasi kebutuhan perangkat lunak menetapkan dasar perjanjian antara pelanggan dan pengembang tentang bagaimana produk perangkat lunak harus berfungsi (dalam proyek yang digerakkan oleh pasar, peran ini dapat dimainkan oleh divisi pemasaran dan pengembangan). Spesifikasi kebutuhan perangkat lunak adalah penilaian kebutuhan yang ketat sebelum tahap desain sistem yang lebih spesifik, dan tujuannya adalah untuk mengurangi desain ulang nanti. Ini juga harus memberikan dasar yang realistis untuk memperkirakan biaya, risiko, dan jadwal produk. Bila digunakan dengan tepat, spesifikasi kebutuhan perangkat lunak dapat membantu mencegah kegagalan proyek perangkat lunak.

## Pengguna SKPL
Dokumen kebutuhan memiliki beragam pengguna, mulai dari manajemen senior organisasi yang membayar sistem hingga teknisi yang bertanggung jawab untuk mengembangkan perangkat lunak. Keragaman pengguna menunjukkan bahwa SKPL harus merupakan kompromi antara mengomunikasikan kebutuhan kepada pelanggan, mendefinisikan kebutuhan secara terperinci untuk pengembang dan penguji, dan termasuk informasi tentang kemungkinan evolusi sistem. Informasi tentang perubahan yang diantisipasi dapat membantu perancang sistem menghindari keputusan desain yang terbatas dan membantu teknisi pemeliharaan sistem yang harus menyesuaikan sistem dengan kebutuhan baru.

* *System Customer* menentukan kebutuhan dan membacanya untuk memastikan bahwa sudah memenuhi kebutuhan mereka. Pelanggan menentukan perubahan pada kebutuhan.
* *Manager* menggunakan SKPL untuk merencanakan penawaran untuk sistem dan untuk merencanakan proses pengembangan sistem.
* *System Engineers* menggunakan kebutuhan untuk memahami sistem apa yang akan dikembangkan.
* *System Test Engineers* menggunakan kebutuhan untuk mengembangkan tes validasi untuk sistem.
* *System Maintenance Engineers* menggunakan kebutuhan untuk memahami sistem dan hubungan antara bagian-bagiannya.

Tingkat detail yang harus disertakan dalam dokumen SKPL tergantung pada jenis sistem yang sedang dikembangkan dan proses pengembangan yang digunakan. *Critical system* perlu memiliki kebutuhan terperinci karena keselamatan dan keamanan harus dianalisis secara rinci. Ketika sistem akan dikembangkan oleh perusahaan terpisah (mis., Melalui ''outsourcing''), spesifikasi sistem harus terperinci dan tepat. Jika *in-house*, proses pengembangan *iterative* digunakan, dokumen kebutuhan dapat menjadi kurang detail dan ambiguitas dapat diselesaikan selama pengembangan sistem.

## Struktur SKPL
Tabel 1 menunjukkan sebuah organisasi yang mungkin untuk SKPL yang didasarkan pada standar IEEE untuk dokumen kebutuhan. Standar ini adalah standar umum yang dapat disesuaikan dengan penggunaan khusus. Dalam hal ini, terdapat perluasan standar untuk memasukkan informasi tentang prediksi evolusi sistem. Informasi ini membantu para pengelola sistem dan memungkinkan para perancang untuk menyertakan dukungan untuk fitur-fitur sistem di masa depan.

Secara alami, informasi yang termasuk dalam dokumen SKPL tergantung pada jenis perangkat lunak yang dikembangkan dan pendekatan pengembangan yang akan digunakan. Jika menggunakan pendekatan *evolutionary* untuk produk perangkat lunak, maka dokumen SKPL akan meninggalkan banyak bab terperinci yang disarankan di atas. Fokusnya akan pada pendefinisian kebutuhan pengguna dan kebutuhan sistem non-fungsional tingkat tinggi. Dalam hal ini, perancang dan pemrogram menggunakan penilaian mereka untuk memutuskan bagaimana memenuhi garis besar kebutuhan pengguna untuk sistem.

Namun, ketika perangkat lunak merupakan bagian dari proyek sistem besar yang mencakup perangkat keras dan sistem perangkat lunak yang berinteraksi, biasanya diperlukan untuk menentukan kebutuhan ke tingkat yang lebih detail. Ini berarti bahwa dokumen SKPL cenderung sangat panjang dan harus mencakup sebagian besar atau semua bab yang ada pada Tabel 1. Untuk dokumen panjang, sangat penting untuk memasukkan tabel isi dan indeks dokumen yang komprehensif sehingga pembaca dapat menemukan informasi yang mereka butuhkan.

## Referensi