Analisa Kebutuhan Perangkat Lunak (SRS)

SRS sendiri merupakan sebuah dokumentasi dari hasil analisa kebutuhan yang bertujuan untuk menyamakan visi antara pengembang perangkat lunak dengan pengguna mengenai perangkat lunak yang akan dibuat. IEEE mendefinisikan SRS sebagai dokumentasi dari kebutuhan pokok (fungsi, kinerja hambatan desain dan atribut) dari perangkat lunak dan antar muka eksternal dari perangkat lunak tersebut.

SRS sendiri sebagai hasil dari analisa kebutuhan perangkat lunak harus memperlihatikan lima hal penting didalamnya :

  1. Fungsi dari perangkat lunak
    Apa yang nanti akan dilakukan oleh perangkat lunak tersebut dan apakah fungsi utama yang diharapkan muncul di dalam SRS.
  2. Antar muka eksternal

Bagaimanakan hubungan perangkat lunak dengan pengguna, perangkat keras yang akan digunakan serta pengaruh dengan perangkat lunak lainnya.

  1. Kinerja

Bagaimana kinerja yang diharapkan dari perangkat lunak tersebut, baik dari sisi keamanan, kecepatan, kemampuan serta waktu respon terhadap masalah yang ditimbulkan.

  1. Atribut

Bagaimana dengan atribut yang terkait dalam perangkat lunak tersebut, dari sisi pemeliharaan ataupun kebenaran dari input serta output yang diharapkan.

  1. Kendala Desain

Apakah terdapat batasan khusus yang harus ada di dalam desain perangkat lunak, seperti masalah kultur, peraturan oraganisasi dan keterbatasan perangkat keras.

Setelah selesai memahami mengenai pentingnya melakukan analisa kebutuhan perangkat lunak dan hasil apa yang harus dikeluarkan setelah proses analisa selesai, maka selanjutnya adalah mempelajari sekilas mengenai cara atau metode analisa. Model yang digunakan dalam analisa kebutuhan perangkat lunak sangatlah beragam.

Sebelum melangkah ke pembahasan model analisa, patut diperhatikan dengan seksama bahwa model apapun yang nanti digunakan di dalam analisa kebutuhan sistem selalu membutuhkan informasi yang akurat di dalamnya. Informasi tersebut dapat dengan beragam cara dan wajib memenuhi syarat-syarat berikut ini agar layak dijadikan modal dalam melakukan analisa kebutuhan sistem :

  1. Dimensi waktu

Informasi yang baik untuk dianalisa harus dikeluarkan tepat waktu dalam artian informasi tersebut adalah informasi yang tidak “basi” dalam organisasi tersebut. Selain itu, informasi harus merupakan informasi yang dapat disampaikan dalam waktu yang tidak terlalu lama.

  1. Dimensi isi

dari segi isi informasi yang disampaikan oleh pengguna dan kemudian diolah ulang oleh analis sistem, maka informasi tersebut haruslah akurat dan “cukup”. Untuk mendapatkan informasi yang “cukup”, berarti informasi tersebut tidak boleh berlebihan serta relevan dengan kebutuhan perangkat lunak yang akan dibuat.

  1. Dimensi format

Secara umum, sesungguhnya tidak ada sebuah format informasi yang baku dalam lingkup analisa kebutuhan, tetapi format yang diharapkan “keluar” dari kumpulan informasi adalah format yang jelas, serta dapat dipahami (dan juga disepakati) oleh kedua belah pihak (dari pengembang maupun pengguna).

Dalam ruang lingkup RPL, umumnya model analisa terbagi menjadi dua jenis yakni model klasik dan model modern. Model klasik merupakan model yang lebih berdasarkan kepada urutan analisa dari pihak pengembang perangkat lunak yang kemudian diterjemahkan ke dalam model tertentu sehingga dapat menjadi bahan untuk melakukan perancangan perangkat lunak. Sedangkan model modern umumnya diasumsikan sebagai model analisa yang melakukan penerjemahan sistem ke dalam komponen yang saling berkaitan atau juga lazim disebut sebagai analisa berorientasi obyek.

Model klasik yang banyak digunakan untuk analisa kebutuhan data adalah ER (Entitiy Relationship) Diagram. ER Diagram yang menggambarkan struktur tabel serta relasi antar tabel dalam sebuah database, hingga saat ini merupakan “senjata utama” bagi para pengembang perangkat lunak, khususnya perangkat lunak jenis sistem informasi.

Model berikutnya adalah DFD (Data Flow Diagram) yang lebih fokus terhadap aliran data dalam sebuah perangkat lunak yang akan dibangun. DFD merupakan gambaran dari proses bisnis yang terjadi di dalam desain perangkat lunak.

Sedangkan model analisa yang dianggap lebih baru dan modern adalah dengan menggunakan UML (Unified Modeling Language). UML terdiri dari beberapa komponen diagram tersebut sering kali hanya diambil komponen terpenting (dan juga paling umum) yakni use case modeling.

            Inti dari penggunaan model use case dalam analisa kebutuhan perangkat lunak adalah memilah komponen-komponen yang terlibat dalam proses prosedural perangkat lunak, sehingga dapat didetailkan (break down) ke dalam diagram lain yang bersifat lebih teknis. Hasil dari diagram-diagram tersebut nantinya yang menjadi dasar bagi proses desain perangkat lunak selanjutnya.

Selain menggunakan model-model analisa yang telah dijelaskan tersebut, analisa kebutuhan perangkat lunak juga membutuhkan studi kelayakan (feasibility study) sebagai salah satu rangkaian kegiatan penting di dalamnya. Studi kelayakan merupakan sebuah gabungan dari berbagai disiplin ilmu, baik dari akuntansi maupun manajemen. Karena umumnya, studi kelayakan dalam lingkup analisa kebutuhan perangkat lunak, lebih fokus kepada kelayakan finansial. Dengan satu pertanyaan besar, apakah proyek perangkat telah ditetapkan. Sehingga studi kelayakan lebih menghasilkan jawaban mengenai langkah apa yang akan dikerjakan oleh pihak pengembang dalam menerima (atau tidak menerima) proyek perangkat lunak yang dimaksud.

Sebagai lanjutan “kecil” dari proses analisa kebutuhan, studi kelayakan memiliki empat pertanyaan besar yang harus dijawab oleh seorang analis sistem. Jawaban dari pertanyaan-pertanyaan tersebut yang nanti akan menjadi dasar penerimaan sebuah proyek perangkat lunak. Pertanyaan-pertanyaan yang dimaksud adalah :

  • Berapa : Merupakan pertanyaan awal yang sangat vital, yakni berapa anggaran yang telah atau harus dialokasikan dalam pembuatan proyek perangkat lunak tersebut
  • Apa : Patut pula diketahui tujuan utama dari pembuatan perangkat lunak tersebut. Apakah nanti perangkat lunak merupakan sebuah kebutuhan pokok yang mendesak atau hanya berupa               “aksesori” yang menempel ke sebuah sistem yang
  • Bagaimana : Yang dimaksud dengan pertanyaan “bagaimana” adalah mengenai prosedur dan proses bisnis yang terlibat dalam perangkat lunak tersebut.
  • Kapan : Pertanyaan yang terakhir adalah mengenai penjadwalan dan alokasi waktu yang  disediakan untuk membangun perangkat lunak tersebut