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.[1]
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 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 [2] mengumpulkan kebutuhan pengguna secara bertahap dan menuliskannya pada kartu (CRC) sebagai user stories. Pengguna kemudian memprioritaskan kebutuhan untuk implementasi dalam rilis sistem selanjutnya.[3] 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.[3]
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.[4] Bila digunakan dengan tepat, spesifikasi kebutuhan perangkat lunak dapat membantu mencegah kegagalan proyek perangkat lunak.[5]
Pengguna SKPL sunting
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 mengkomunikasikan 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.[3]
- System Customer menentukan kebutuhan dan membacanya untuk memastikan bahwa sudah memenuhi kebutuhan mereka. Pelanggan menentukan perubahan pada kebutuhan.[3]
- Manager menggunakan SKPL untuk merencanakan penawaran untuk sistem dan untuk merencanakan proses pengembangan sistem.[3]
- System Engineers menggunakan kebutuhan untuk memahami sistem apa yang akan dikembangkan.[3]
- System Test Engineers menggunakan kebutuhan untuk mengembangkan tes validasi untuk sistem.[3]
- System Maintenance Engineers menggunakan kebutuhan untuk memahami sistem dan hubungan antara bagian-bagiannya.[3]
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.[3]
Struktur SKPL sunting
Tabel 1 menunjukkan sebuah organisasi yang mungkin untuk SKPL yang didasarkan pada standar IEEE untuk dokumen kebutuhan.[6] 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.[3]
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.[3]
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.[3]
| Bab | Deskripsi |
|---|---|
| Preface | Mendefinisikan pembaca dokumen yang diharapkan dan menjelaskan riwayat versinya, termasuk alasan untuk pembuatan versi baru dan
ringkasan perubahan yang dibuat di setiap versi.[3] |
| Introduction | Menggambarkan kebutuhan sistem. Bagian ini harus menjelaskan secara singkat fungsi-fungsi sistem dan menjelaskan bagaimana sistem itu akan bekerja dengan sistem lain. Bagian ini juga harus menggambarkan bagaimana sistem tersebut cocok dengan keseluruhan bisnis atau sasaran strategis organisasi yang menginginkan perangkat lunak tersebut.[3] |
| Glossary | Mendefinisikan istilah teknis yang digunakan dalam dokumen. Tidak boleh membuat asumsi tentang pengalaman atau keahlian pembaca.[3] |
| User Requirement Definition | Menggambarkan layanan yang disediakan untuk pengguna. kebutuhan sistem non-fungsional juga harus diuraikan dalam bagian ini. Deskripsi ini dapat menggunakan bahasa alami, diagram, atau notasi lain yang dapat dimengerti oleh pelanggan. Standar produk dan proses yang harus diikuti harus ditentukan.[3] |
| System Architecture | Bab ini harus menyajikan tinjauan tingkat tinggi dari arsitektur sistem yang diantisipasi, menunjukkan distribusi fungsi di seluruh modul sistem. Komponen arsitektur yang digunakan kembali harus disorot.[3] |
| System Requirements Specification | Bab Ini harus menggambarkan kebutuhan fungsional dan non-fungsional secara lebih rinci. Jika perlu, detail lebih lanjut juga dapat ditambahkan ke bab Non-Functional Requirements. Antarmuka ke sistem lain dapat didefinisikan.[3] |
| System Models | Termasuk model sistem grafis yang menunjukkan hubungan antara komponen sistem, sistem, dan lingkungannya. Contoh model yang mungkin adalah model objek, model aliran data, atau model data semantik.[3] |
| System Evolution | Menggambarkan asumsi mendasar yang menjadi dasar sistem, dan setiap perubahan yang diantisipasi karena evolusi perangkat keras, perubahan kebutuhan pengguna, dan sebagainya. Bagian ini berguna untuk perancang sistem karena dapat membantu mereka menghindari keputusan desain yang akan membatasi kemungkinan perubahan di masa depan pada sistem.[3] |
| Appendices | Memberikan informasi rinci dan spesifik yang terkait dengan aplikasi yang sedang dikembangkan; misalnya, deskripsi perangkat keras dan basis data. Kebutuhan perangkat keras menentukan konfigurasi minimal dan optimal untuk sistem. kebutuhan basis data mendefinisikan organisasi logis dari data yang digunakan oleh sistem dan hubungan antara data.[3] |
| Index | Beberapa indeks pada dokumen dapat dimasukkan. Seperti halnya indeks alfabet normal, mungkin ada indeks diagram, indeks fungsi,dan seterusnya.[3] |
Referensi sunting
- ^ Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534.
- ^ Beck, Kent. (2005). Extreme programming explained : embrace change (edisi ke-2nd ed). Boston, MA: Addison-Wesley. ISBN 0321278658. OCLC 56526718.
- ^ a b c d e f g h i j k l m n o p q r s t u v w Sommerville, Ian (2011). Software Engineering. Addison-Wesley. ISBN 978-0-13-703515-1.
- ^ 830-1984 IEEE Guide to Software Requirements Specifications. ISBN 9780738144184. OCLC 958660391.
- ^ 830-1993 IEEE Recommended Practice for Software Requirements Specifications. ISBN 9780738147239. OCLC 958660392.
- ^ IEEE Recommended Practice for Software Requirements Specifications, IEEE, diakses tanggal 2019-07-31