Skip to main content

System Requirements Definition (Definisi Kebutuhan Sistem) Menurut Ian Sommerville

 Untuk menentukan apa yang harus dilakukan oleh sistem dan properti sistem yang penting dan diinginkan, definisi persyaratan sistem diperlukan. Seperti yang dibahas dalam analisis kebutuhan perangkat lunak, membuat definisi kebutuhan sistem melibatkan diskusi dengan pelanggan sistem dan pengguna akhir. Fase definisi persyaratan ini umumnya fokus pada tiga jenis persyaratan yang harus dipenuhi:

  1. Abstract functional requirements (Persyaratan fungsional abstrak). Dalam rekayasa sistem, fungsi dasar yang diperlukan oleh sistem didefinisikan secara abstrak, sementara spesifikasi kebutuhan fungsional yang lebih terperinci biasanya dibuat pada tingkat sub-sistem. Sebagai contoh, dalam sistem kontrol lalu lintas udara, persyaratan fungsional abstrak mungkin menentukan bahwa sebuah database rencana penerbangan harus digunakan untuk menyimpan rencana penerbangan semua pesawat yang memasuki wilayah udara yang dikendalikan. Namun, rincian tentang database tersebut biasanya tidak dijelaskan kecuali jika mempengaruhi persyaratan sub-sistem lainnya.
  2. System properties (Properti sistem). Properti sistem yang bersifat darurat dan non-fungsional, seperti ketersediaan, kinerja, dan keamanan, telah dibahas sebelumnya. Properti non-fungsional ini memengaruhi persyaratan dari semua subsistem.
  3. Characteristics that the system must not exhibit (Karakteristik yang tidak boleh ditunjukkan oleh sistem). Ada kalanya menetapkan apa yang tidak boleh dilakukan oleh sistem sama pentingnya dengan menetapkan apa yang harus dilakukan oleh sistem. Sebagai contoh, dalam merancang sistem kontrol lalu lintas udara, kita dapat menentukan bahwa sistem tersebut tidak boleh memberikan terlalu banyak informasi kepada pengontrol.

Sebagian besar dari tahapan definisi kebutuhan sistem melibatkan menetapkan seperangkat tujuan keseluruhan yang harus dicapai oleh sistem, meskipun tujuan tersebut mungkin tidak terkait dengan fungsinya secara langsung. Tujuan ini harus menjelaskan alasan mengapa sistem dibutuhkan dalam lingkungan tertentu dan harus dipertimbangkan secara cermat selama proses pengembangan sistem.

Untuk memberikan gambaran, misalkan Anda mendefinisikan sistem untuk gedung kantor yang akan memberikan perlindungan kebakaran dan mendeteksi intrusi. Pernyataan tujuan yang didasarkan pada fungsionalitas sistem dapat berupa:

Tujuan sistem yang ditetapkan adalah untuk memberikan perlindungan dari kebakaran dan penyusupan melalui sistem alarm yang memberikan peringatan baik secara internal maupun eksternal.

Tujuan tersebut dengan jelas menyatakan bahwa sistem alarm diperlukan untuk memberikan peringatan mengenai kejadian yang tidak diinginkan. Pernyataan seperti itu mungkin cocok jika Anda mengganti sistem alarm yang ada. Namun, sebuah pernyataan tujuan yang lebih umum mungkin lebih tepat:

Agar pekerjaan yang dilakukan di dalam gedung tidak terganggu secara serius oleh kejadian seperti kebakaran dan intrusi yang tidak sah, perlu dipastikan dengan tujuan yang lebih luas.

Jika tujuan yang ditetapkan adalah seperti ini, maka akan memperluas dan membatasi opsi desain sistem. Sebagai contoh, tujuan ini dapat memungkinkan penggunaan teknologi kunci yang lebih canggih untuk melindungi gedung dari penyusup, tanpa adanya alarm internal. Namun, tujuan ini juga dapat menghindari penggunaan sprinkler untuk melindungi gedung dari kebakaran karena dapat mempengaruhi sistem kelistrikan gedung dan mengganggu aktivitas di dalamnya.

Gambar 1

Untuk menetapkan persyaratan sistem, ada kesulitan mendasar karena masalah yang dibangun untuk membantu mengatasi sistem kompleks cenderung menjadi "wicked problem" (Rittel dan Webber, 1973). 'Wicked problem' merujuk pada masalah yang sangat kompleks, di mana spesifikasi masalah tidak pasti karena ada begitu banyak entitas terkait. Sebagai hasilnya, sifat sebenarnya dari masalah baru muncul ketika solusinya dikembangkan. Perencanaan gempa adalah contoh ekstrem dari 'wicked problem' karena tidak mungkin memprediksi pusat gempa, waktu terjadinya, atau dampaknya pada lingkungan. Oleh karena itu, bagaimana mengatasi gempa bumi besar hanya bisa ditentukan setelah gempa terjadi.



Source: Sommerville, Ian. 2007. Software Engineering Eight Edition. s.l. : Addison-. Wisley, 2007.

Comments

Popular posts from this blog

Proses Perangkat Lunak Menurut Roger S. Pressman

Suatu proses adalah gabungan dari beberapa kegiatan, aksi, dan pekerjaan yang dikerjakan saat akan membuat beberapa produk. Setiap kegiatan memiliki tujuan yang luas (seperti komunikasi dengan pemangku kepentingan) dan diterapkan secara universal, tidak peduli pada domain aplikasi, ukuran proyek, kompleksitas usaha, atau tingkat ketelitian rekayasa perangkat lunak yang digunakan. Aksi (contohnya, desain arsitektur) mencakup rangkaian tugas yang menghasilkan produk utama (sebagai contoh, model desain arsitektural). Sebuah tugas berfokus pada tujuan yang kecil namun terdefinisi dengan baik (seperti melakukan pengujian unit) yang menghasilkan hasil yang konkret. Dalam dunia rekayasa perangkat lunak, suatu proses tidaklah berarti resep yang kaku untuk membuat perangkat lunak. Sebaliknya, proses ini merupakan pendekatan yang dapat disesuaikan yang memungkinkan tim pengembang perangkat lunak untuk memilih dan mengeksekusi serangkaian tindakan dan tugas yang sesuai. Tujuannya adalah untuk sel...

Extreme Programming (XP) Menurut Roger S. Pressman

 Untuk memberikan gambaran yang lebih rinci tentang proses agile, saya akan memaparkan Extreme Programming (XP), suatu pendekatan yang banyak digunakan dalam pengembangan perangkat lunak agile. Meskipun ide dan metode yang terkait dengan XP telah muncul pada akhir 1980-an, Kent Beck telah menulis secara ekstensif mengenai topik ini. Baru-baru ini, sebuah varian XP yang disebut Industrial XP (IXP) telah diajukan. IXP telah menyempurnakan XP dan dirancang untuk digunakan khusus dalam organisasi besar dengan proses yang lebih fleksibel. 1.1 XP Values Sebuah seperangkat lima nilai yang menjadi dasar bagi seluruh pekerjaan yang dilakukan dalam XP telah didefinisikan oleh Beck. Nilai-nilai ini mencakup communication, simplicity, feedback, courage, dan respect, dan masing-masing nilai ini digunakan sebagai motivasi dalam aktivitas, tindakan, dan tugas XP yang spesifik. XP menekankan pada kolaborasi yang erat namun tidak formal secara verbal untuk mencapai komunikasi yang efektif anta...

Other Agile Process Models (Model Process Agile Lainnya) Menurut Roger S. Pressman

 Sejarah pengembangan perangkat lunak telah dicatat dengan banyak deskripsi dan metodologi proses yang telah usang, alat-alat, dan teknologi, serta notasi pemodelan. Semua hal tersebut telah mencapai popularitasnya masing-masing sebelum akhirnya digantikan oleh yang baru dan lebih baik. Dalam upaya mencapai penerimaan di komunitas pengembangan perangkat lunak, berbagai agile process model telah diperkenalkan dan bersaing satu sama lain, mengikuti pola yang sama dengan gerakan sebelumnya. Sudah saya sampaikan pada bagian terakhir bahwa Extreme Programming (XP) merupakan agile process models yang paling sering digunakan. Meskipun demikian, terdapat banyak agile process models lain yang telah diusulkan dan diterapkan dalam berbagai industri. Beberapa model yang paling umum meliputi: Adaptive Software Development (ASD) Scrum Dynamic Systems Development Method (DSDM) Crystal Feature Drive Development (FDD) Lean Software Development (LSD) Agile Modeling (AM) Agile Unified Process (AUP) P...