STUDY SYSTEM REQUIREMENTS ANALYSIS SOFTWARE RESULT QUALITY

 STUDY SYSTEM REQUIREMENTS ANALYSIS SOFTWARE RESULT QUALITY

RIKI BENI SETIAWAN

Universitas Esa Unggul Kebon Jeruk Jakarta Barat

Program Study of Sistem Infromation

Jl. Arjuna Utara No.9, RT.1/RW.2, Duri Kepa, Kec. Kb. Jeruk, Kota Jakarta Barat, Daerah Khusus Ibukota Jakarta 11510

    E-mail : rikibeni75@gmail.com dan rikibeni75@Student.esaunggul.ac.id

Abstracts: necessities specification is that the need for the first phases of software system engineering and is incredibly vital as a result of it affects the flexibility, reliability, accuracy and

usability. irrespective of however sensible coding and style systems that don't will still be able to

give a real want by the conditions encountered. In fact, the {requirements|the wants} for requirements engineering and quick approach methodology doesn't perpetually guarantee manufacture quality software systems so require system migration. during this method the necessity for requirements analysis ought to additionally take into account factors which will not be by trial and error expressed quantitatively. More needs ability and develop different priority wants in terms of the necessities document. Communication skills, the employment of easy terms, receptive users of the system, and displays a vivid example of what is required and avoid the pitfalls of the intelligence domain to limit the success factors in orienting with the expectations of users of the system.

Keywords : necessities specification analysis, necessities engineering, FAST approach, device migration, quantitative and empirical pitfalls intelligence domain.

1. Pendahuluan            

 Melakukan rekayasa perangkat lunak adalah proses yang agak rumit dan seringkali menimbulkan masalah yang bahkan tidak akan Anda dapatkan hasil yang maksimal. Memahami setiap masalah sistem jelas bukan tugas yang mudah karena memiliki banyak properti. Setiap sistem memiliki konten yang memerlukan deskripsi layanan dan batasan tertentu dan merupakan prasyarat untuk keberhasilan suatu sistem. Untuk memenuhi persyaratan, sistem harus mendefinisikan persyaratan sedemikian rupa sehingga tidak ada solusi yang ditentukan sebelumnya. Hal ini menyebabkan masalah pemisahan yang tidak memadai yang sering terjadi dalam proses rekayasa perangkat lunak: Ada perbedaan yang jelas antara tingkat deskripsi serangkaian layanan dan batas-batas suatu sistem. Persyaratan Persyaratan sistem adalah atribut-atribut yang dibutuhkan dalam sebuah sistem, seperti: persyaratan pengguna, persyaratan sistem atau spesifikasi fungsional dan definisi spesifikasi desain perangkat lunak. Persyaratan yang jelas dan terstruktur dengan baik sangat penting karena mereka membentuk dasar untuk pengembangan pekerjaan lebih lanjut. Segera setelah kebutuhan ditetapkan, pengembang bisa memulai pekerjaan teknis lainnya, Misalnya perancangan sistem, pengembang, pengujian, implementasi & aktivitas operasional sistem bisa berjalan dengan lancar. 

 Pemenuhan persyaratan kebutuhan sistem seseorang pengguna sering ditentukan oleh kemampuan, pemahaman & komunikasi yang tidak sinkron menggunakan cara berpikir menurut personil pengembang sistem. Kondisi ini adalah problem yang seringkali terjadi pada pengembangan software selama ini, bahkan kegagalan primer menurut sejumlah software ketika ini merupakan tidak selarasnya kebutuhan sistem menggunakan output konkret yang diharapkan. Kesalahpahaman tentang persyaratan kebutuhan sistem hanya akan berujung dalam bisnis yang sangat sia-sia & mengharuskan pengerjaan ulang kembali. Selain itu adanya faktor ketidak konsistenan, ketidak lengkapan, maupun ketidakbenaran berdasarkan spesifikasi kebutuhan sistem. Melakukan identifikasi kebutuhan sistem bersifat konkret memerlukan suatu rangkaian proses kebutuhan interaktif & iteratif yang didukung oleh praktek secara efektif, proses, mekanisme, metode, teknik & peralatan. Sejumlah studi yang dirilis oleh The Standish Group (2001) mencatat bahwa persentase kumulatif kegagalan sebuah proses pengembangan software ditimbulkan oleh kegagalan mengantisipasi spesifikasi kebutuhan. Sementara output studi berdasarkan KPMG terhadap 500 perusahaan besar menunjukkan bahwa lebih kurang 74% pengembangan software mengalami kegagalan menjadi dampak berdasarkan aturan yang diresmikan jauh melampaui berdasarkan yang direncanakan atau ditargetkan, durasi pengerjaan proyek jauh menyimpang berdasarkan saat yang sudah ditetapkan, & investasi teknologi fakta yang diperlukan tidak berhasil menaikkan kinerja operasional perusahaan secara berarti.

2. Tinjauan Pustaka

 Persyaratan kebutuhan sistem aplikasi memilih apa yang harus

dilakukan sistem & mendefinisikan batasan-batasan operasi & implementasinya supaya bisa mengkomunikasikan secara sempurna seluruh fungsi yang diberikan (Sommerville, 2011). Melakukan analisis persyaratan merupakan tugas rekayasa aplikasi yang menjembatani kesenjangan antara alokasi aplikasi taraf sistem & perancangan perangkat lunaknya (Pressman, 2010). Analisis kebutuhan aplikasi merupakan proses menerima informasi, model, spesifikasi sistem yang diinginkan pengguna (Simarmata, 2010). Adalah sebuah kenyataan bahwa menjadi fase awal untuk melakukan pengembangan rekayasa aplikasi adalah suatu kondisi yang mempunyai Peranan sangat krusial untuk kelanjutan berdasarkan fase-fase berikutnya. 

 Kelalaian atau ketidak seriusan fase ini akan menyebabkan sistem tidak bisa bekerja sebagaimana mestinya & justru bisa sebagai jebakan buat pengembangan aplikasi. Belum lagi adanya kemenduaan arti berdasarkan pengguna sistem bisa meniadakan komitmen awal berdasarkan pengembangan sistem tadi. Perangkat lunak yang sinkron menggunakan kebutuhan sangat bergantung pada keberhasilan analisis spesifikasi persyaratan kebutuhannya. Kemampuan  pada menuliskan kode aplikasi & mempunyai media antarmuka yang menawan bukan merupakan Kejaminan aplikasi tersebut berguna. Pernyataan ini menerangkan bahwa analisis persyaratan kebutuhan sistem adalah fase yang sangat signifikan. Dalam melakukan analisis kebutuhan mempunyai banyak sekali faktor pembatas misalnya pengguna tidak terlalu mengerti & pemahaman pengetahuan tentang perangkat komputer, teknik pemrograman & entitas teknologi informasi. Pemerolehan kebutuhan yang jelas & benar sesuai menggunakan apa yang dimaksud oleh pengguna menerangkan langkah awal yang baik, yang akan membantu pembuatan aplikasi dalam termin berikutnya. Persyaratan kebutuhan sistem bisa diklasifikasikan menjadi persyaratan fungsional & non-fungsional atau menjadi persyaratan domain yg mewakili berdasarkan sistem ini sendiri (Sommerville, 2011)

 Persyaratan fungsi adalah persyaratan service yang harus diberikan pada sistem supaya bisa melakukan keperilakuannya pada bereaksi terhadap masukan eksklusif & dalam situasi eksklusif. Persyaratan ini wajib  bisa mengilustrasikan secara detail dalam masing-masing strata sistem. Kemenduaan arti terjadi lantaran ketidaktepatan memformulasikan & menerjemahkan spesifikasi persyaratan kebutuhan sistem & adanya indicator buat memudahkan pada penerapannya. Dalam beberapa masalah membentuk software pula memerlukan suatu restriksi yang jelas & terstruktur tentang perlakuan sebuah sistem. Spesifikasi persyaratan fungsional wajib  lengkap & konsisten. Tetapi terdapat kalanya buat sistem yang skalanya besar, ke 2 aspek ini sulit untuk dilaksanakan lantaran kompleksitas sistem & ketidaksesuaian berdasarkan sudut pandang masing-masing. Untuk persyaratan non-fungsional lebih menunjuk pada batasan layanan atau fungsi yang diberikan sistem. Dokumen pernyataan nonfungsional ini meliputi batasan waktu, proses pengembangan & standarisasi keluaran sebuah sistem. Umumnya persyaratan ini dari berdasarkan kebutuhan pengguna sistem misalnya persyaratan produk, organisasi, & eksternal. Kenyataan yang tak jarang dihadapi merupakan persyaratan kebutuhan sistem sulit buat diverifikasi sebagai akibatnya membutuhkan pernyataan yang bersifat kuantitatif & bisa dilakukan pengujian secara objektif. Sementara persyaratan domain bekerjasama eksklusif menggunakan proses komputasinya & bila tidak terpenuhi bisa mengakibatkan sistem bekerja menggunakan tidak memuaskan. Tetapi kenyataannya seluruh pembagian terstruktur mengenai ini merupakan saling menyatu satu dengan lainnya & perbedaannya justru lebih kearah artifisial saja.

 Memahami persyaratan kebutuhan sistem pula tidak akan membentuk sebuah software yang ideal andai saja tidak diikuti menggunakan pernyataan menurut persyaratan kebutuhan pengguna. Dalam tetapkan persyaratan pengguna, pengembang sistem harus mempunyai indikator pengukuran yang jelas buat menghindari cakupan fakta yang terlalu berlebihan tetapi tidak signifikan & bahkan mampu menyebabkan kemenduaan arti & kesalahan pada pemahaman persepsi terkait menggunakan banyak sekali istilah teknis bidang komputer. Untuk meminimalkan kesalahpahaman pada menciptakan pernyataan persyaratan, pengguna bisa memakai sebuah form baku & bahasa yang konsisten terutama antara persyaratan yang diperintahkan & yang diinginkan. Standarisasi format bermanfaat buat meminimalisasi kemungkinan terjadinya kelalaian & juga untuk menciptakan persyaratan lebih sederhana diperiksa dan kelancaran pada proses verifikasinya (Sommerville, 2011). 

 Persyaratan sistem harus menyatakan apa yang harus dilakukan sistem & bukan bagaimana sistem tersebut harus diterapkan. Caranya mulai memakai bahasa natural terstruktur, bahasa penggambaran desain, notasi grafis, & spesifikasi matematis. Tetapi efek berdasarkan aspek variabilitas cenderung masih menyebabkan kemenduaan arti pada sebuah persyaratan kebutuhan sistem. Adapun upayanya merupakan memakai bahasa penggambaran program. Tetapi cara ini terlalu teknis bagi pengguna sistem & cenderung lebih menunjuk pada perancangan spesifikasi sistem daripada membantu pengguna mengerti fungsionalitas sebuah sistem. Persyaratan kebutuhan sistem harus mempunyai perangkat dokumentasi yang lengkap. Dalam dokumen ini harus berisi entitas pengguna sistem dengan tujuan menspesifikasi persyaratan & untuk menyelidiki apakah telah memenuhi kebutuhan, entitas manajer menggunakan tujuan untuk merencanakan penawaran atas sistem & merencanakan proses pengembangan sistem, entitas perekayasa sistem menggunakan tujuan untuk pemahaman sistem apa yang akan dikembangkan, entitas perekayasa pengujian sistem menggunakan tujuan berkembangnya pengujian validasi bagi sistem, & entitas perekayasa pemeliharaan sistem menggunakan tujuan buat membantu mengerti sistem & relasi antara bagian-bagiannya (Sommerville, 2011).

 Persyaratan sistem wajib menyertakan apa yang harus dilakukan oleh sistem & bukannya bagaimana sistem tersebut harus diimplementasikan. Caranya mulai memakai bahasa natural terstruktur, bahasa penggambaran desain, notasi grafis, & spesifikasi matematis. Tetapi efek berdasarkan aspek variabilitas cenderung masih menyebabkan kemenduaan arti pada sebuah persyaratan kebutuhan sistem. Adapun upayanya merupakan memakai bahasa penggambaran program. Tetapi cara ini terlalu teknis bagi pengguna sistem & cenderung lebih menunjuk pada perancangan spesifikasi sistem daripada membantu pengguna mengerti fungsionalitas sebuah sistem. Persyaratan kebutuhan sistem harus mempunyai perangkat dokumentasi yang lengkap. Dalam dokumen ini harus berisi entitas pengguna sistem dengan tujuan menspesifikasi persyaratan & untuk menyelidiki apakah telah memenuhi kebutuhan, entitas manajer menggunakan tujuan untuk merencanakan penawaran atas sistem & merencanakan proses pengembangan sistem, entitas perekayasa sistem menggunakan tujuan untuk pemahaman sistem apa yang akan dikembangkan, entitas perekayasa pengujian sistem menggunakan tujuan berkembangnya pengujian validasi bagi sistem, & entitas perekayasa pemeliharaan sistem menggunakan tujuan buat membantu mengerti sistem & relasi antara bagian-bagiannya (Sommerville, 2011).

 Analisis persyaratan software bisa dibagi sebagai 5 area kerja, yaitu sosialisasi kasus, penilaian & sintesis, pemodelan, spesifikasi & kajian spesifikasi (Pressman, 2010). Analisis persyaratan software selalu dimulai menggunakan komunikasi antara 2 bagian atau lebih melalui media  wawancara. Gause & Weinberg (1989), menyarankan analis memulainya menggunakan mengajukan pertanyaan-pertanyaan bebas konteks supaya lebih gampang mengarahkan pada pemahaman yang mendasar (Pressman, 2010). Tetapi aktivitas ini tidak selamanya berjalan menggunakan lancar, lantaran pengguna & pengembang sistem software tanpa mereka sadari, tak jarang mempunyai konteks pemikiran antara “kita & mereka”. Lebih lanjut Zahniser (1990) menyarankan penggunaan pendekatan FAST (Facilitated Application Specification Techniques). Pendekatan ini mendorong keluarnya tim campuran antara pengguna & pengembang sistem yang bekerja serta buat mengidentifikasi kasus, mengusulkan elemen pemecahan, menegosiasikan pendekatan yang tidak sinkron & mengkhususkan rangkaian persyaratan pemecahan awal (Pressman, 2010).

 Romi Satrio Wahono pada sebuah artikel pada ilmukomputer.com memaparkan bahwa sebuah definisi yang relatif detail & diterima secara generik merupakan yang diuraikan oleh Pamela Zave (1997). Requirements engineering merupakan cabang berdasarkan perangkat lunak engineering yang mengurusi perkara yang berhubungan dengan tujuan (dunia nyata), fungsi, & batasan-batasan dalam sistem perangkat lunak. Termasuk relasi faktor-faktor tadi pada memutuskan spesifikasi yang sempurna menurut suatu perangkat lunak, proses evolusinya baik berhubungan dengan kasus ketika juga menggunakan perangkat lunak lain. Hasil berdasarkan fase requirements engineering terdokumentasi pada bentuk requirements specification. Kegiatan ini berisi konvensi  beserta mengenai konflik yang ingin dipecahkan antara pengembang & pengguna, & adalah titik mulai menuju proses berikutnya yaitu perangkat lunak design. Sistemisasi proses perundingan   pengembang & pengguna pada requirements engineering dibagi pada 3 proses besar yaitu: elicitation, specification, validation and verification.

3. METODOLOGI PENELITIAN

Penelitian ini memakai bentuk survei menggunakan metode deskriptif. Metode pengumpulan datanya terdiri menurut data utama & sekunder. Data utama dari menurut output wawancara & melakukan pengamatan secara eksklusif. Tipe wawancara yang dipakai merupakan wawancara secara eksklusif menggunakan sejumlah responden, pada hal ini respondennya merupakan mereka yang bekerja menjadi programmer pelepasan & beberapa karyawan yang bekerja di bagian teknologi informasi untuk beberapa perusahaan swasta/BUMN yang terdapat pada kota Pontianak. Kriteria penarikan sampel merupakan mereka yang telah bekerja di bidangnya lebih berdasarkan 5 tahun. Sementara untuk penarikan sampelnya memakai teknik purposive sampling. Untuk kebutuhan data sekunder diperoleh berdasarkan sejumlah dokumen & laporan tentang kegiatan melakukan proses rekayasa software. Penelitian ini memakai variabel tunggal yaitu studi analisis persyaratan kebutuhan sistem pada membentuk aplikasi yang berkualitas. Metode analisisnya memakai kombinasi pendekatan rekayasa kebutuhan (requirement engineering approach) & pendekatan FAST (Facilitated Application Specification Techniques).

4. KONTRIBUSI PENELITIAN

Menentukan pendekatan rekayasa persyaratan sangat berpengaruh keandalan, reliabilitas & usability berdasarkan sebuah perangkat lunak. Tetapi demikian pula wajib  mempertimbangkan syarat & faktor-faktor lain yang cenderung tak jarang tidak bisa diungkapkan secara realitas ketika komunikasi berlangsung. Memberikan perihal & pemikiran baru bahwa memakai setiap pendekatan yang telah terdapat belum tentu bisa menjamin output analisis sesuai kebutuhan pengguna sistem. Kondisi ini membutuhkan dimensi pemikiran yang cerdas pada menciptakan kembali pola-pola ketika melakukan analisis persyaratan kebutuhan sistem. Analisis ini krusial untuk menghilangkan kesalahpahaman atau ketidak konsisten pada perolehan data & informasi yang diperlukan supaya pada proses pengembangannya bisa sesuai menggunakan planning kerja yang sudah ditetapkan. Penelitian ini mencoba membentuk sebuah pemikiran yang lebih inovatif untuk mencapai keselarasan antara persepsi kebutuhan berdasarkan pengembang & pengguna sistem.

5. HASIL PENELITIAN DAN DISKUSI

Berdasarkan output survei melalui wawancara & pengamatan secara langsung terhadap sejumlah responden yang dipilih untuk maksud & tujuan eksklusif & output kajian berdasarkan beberapa teori atau pendekatan tentang konteks analisis persyaratan kebutuhan sistem, menerangkan bahwa persyaratan sebuah sistem bisa diidentifikasi & ditetapkan. Beberapa pendekatan mempunyai tujuan yang sama, namun langkah pengerjaan analisis persyaratan relatif sedikit berbeda. apabila sebelumnya sudah dilakukan pemahaman terhadap sistem tadi secara spesifik & mempunyai fokus kebutuhan yang detail sebagai akibatnya mudah melakukan penelusuran konflik sistem, hasrat & asa pengguna sistem kini   juga pada ketika yang akan datang. Pemahaman sistem kini   krusial buat mempelajari & pemahaman tempat masalah, kesempatan & peluang untuk peningkatan sistem, lingkup & batasan yg terdapat sistem kini  , proses-proses yang berjalan pada sistem, data yang mengalir & disimpan, serta apa & siapa yang bekerjasama langsung menggunakan sistem.

 Kecenderungan berdasarkan sejumlah pendekatan pada melakukan proses rekayasa kebutuhan sistem lebih menunjuk dalam upaya untuk mencari solusi berdasarkan perseteruan yang dihadapi. Kegiatan analisis persyaratan kebutuhan fokus pada kebutuhan aplikasi yang akan didapatkan tanpa mencoba untuk menelusuri apa sesungguhnya penyebab & dampak berdasarkan akar konflik tadi yang mempengaruhi jalannya sistem. Melalui analisis karena & dampak wajib  sebagai panduan awal waktu mencoba untuk memahami perilaku sebuah sistem. Kenyataannya hal ini memang nir gampang lantaran konduite sistem meliputi banyak entitas, mulai berdasarkan para stakeholder menggunakan gambaran kebutuhan sistem yang bervariasi baik internal juga eksternal, pihak manajemen berdasarkan setiap divisi atau unit fungsi usaha yang saling berinteraksi menggunakan target yang berbeda-beda, kesiapan sumber daya manusianya berdasarkan sisi pengetahuan dan pendidikan dan pengalaman, pencerahan & kesiapan untuk memulai & mau menerima sesuatu yang baru menggunakan resiko penerapannya. Sisi pengembang pula wajib  memiliki pemahaman yang sama sebagai akibatnya solusi yang mereka gambarkan sesuai dengan harapan semua orang. Kesalahpahaman tentang kebutuhan hanya akan berujung dalam bisnis yang sangat sia-sia & mengharuskan pengerjaan ulang tanpa mempunyai nilai-nilai positif yang signifikan. Identifikasi kebutuhan konkret memerlukan suatu proses kebutuhan interaktif & iteratif supaya proses sebagai lebih efektif & mempunyai standarisasi yang jelas & mempunyai sistematika yang detail.

 Selama ini memang kita sadari bahwa banyak dijumpai analisis & perancang sistem gagal pada membentuk software yang benar-benar bisa menjawab pertarungan sistem dalam perusahaan, walaupun telah memakai pendekatan rekayasa kebutuhan & pendekatan FAST. Memang ke 2 pendekatan ini tak jarang dipakai buat menggali sebesar & sedetail mungkin persyaratan kebutuhan sebuah sistem supaya tidak lagi sebagai problem yang cenderung membingungkan pengguna & pengembang sistem. Tetapi buat menspesifikasikan sebuah persyaratan kebutuhan tak jarang terjadi permasalahan bahkan permasalahan kepentingan, lantaran masing-masing terperangkap pada kecerdasan yang membawa dalam perkiraan ketidak sesuaian berdasarkan pengetahuan & pemahaman sosio teknis & dimensi usaha perusahaan. Kondisi ini menyebabkan ketidakpercayaan & kebimbangan yang dalam akhirnya terdapat keengganan buat memakai software tersebut. Kenyataan ini sebagai semakin sulit buat dihindari lantaran adanya ketidak konsistenan pada merepresentasikan persyaratan fungsional & non-fungsional. Hal ini mengakibatkan terjadinya kemenduaan arti yang dalam penerapannya kurang menerima perhatian awal. Jadi memakai pendekatan rekayasa kebutuhan & pendekatan FAST tidak senantiasa bisa mengklaim sebuah software mempunyai validitas, reliabilitas, & usability yang layak & selaras menggunakan hasrat & asa pengguna & pengembang sistem.

 Untuk mencapai kesinambungan antara pengguna & pengembang sistem perlu melakukan aktivitas dekomposisi fase-fase berdasarkan ke 2 pendekatan tersebut & melakukan suatu proses migrasi pendekatan menjadi upaya untuk mengurangi ketidak sesuaian pemahaman tentang masing-masing konduite sistem. Baik pemahaman rekayasa kebutuhan & FAST pertama kali wajib  menerjemahkan target & tujuan sistem ke pada kebutuhan & persyaratan yang diperlukan. Dalam hal ini batasan sistem berdasarkan sebuah software wajib  menerima perhatian utama. Hal-hal yang membatasi fleksibilitas kita pada mendefinisikan sebuah solusi. Pada dasarnya batasan tidak bisa diubah, misalnya tanggal, waktu, anggaran & kebijakan sistem sebagai akibatnya membutuhkan perlakukan spesifik pada mengontrol berdasarkan setiap batasan yang terdapat misalnya biaya, perencanaan, teknologi, & kebijakan.

 Faktor-faktor tersebut wajib  sebagai perhatian yang berfokus menjadi bentuk mengantisipasi kesenjangan pada menemukan & menciptakan sebuah konvensi  berdasarkan fitur masing-masing pendekatan untuk membuat sebuah software yang berkualitas. Melakukan proses diversifikasi sinkron menggunakan kebutuhan memang adalah suatu syarat yang tidak gampang lantaran banyak bermunculan aneka macam anggapan, perkiraan & hipotesis yang keliru. Kenyataan proses migrasi ini akan bisa menghindari pembentukan pemikiran yang hanya menguntungkan beberapa pihak tanpa suatu keselarasan akan pemahaman berdasarkan setiap proses bisnis. Dekomposisi setiap fase menggunakan mengintegrasikan ke 2 pendekatan tadi dilihat menjadi suatu upaya untuk mempermudah & menaikkan taraf keluwesan berdasarkan setiap kepentingan antara stakeholder & pengembang sistem. Hakikatnya sebuah sistem yang telah melakukan proses asimilasi berdasarkan sejumlah kepentingan bisa memperkaya khasanah berdasarkan sebuah kenyataan waktu melakukan penerapan sebuah software. Kualitas sebuah software tidak mampu mengabaikan berdasarkan sebuah struktur & prosedur sistem yang telah terdapat sebelum melakukan pengembangan & rekayasa software. Sejumlah persyaratan kebutuhan hanya mampu & bisa diselesaikan apabila masing-masing pihak yang terlibat mau melakukan knowledge sharing menggunakan tanpa batasan yang mau menang sendiri. Senantiasa melakukan proses brainstorming untuk menemukan berbagai celah yang pada ketikan yang akan tiba dapat sebagai kendala waktu menerapkan software tersebut.

 Indikator berikutnya merupakan harapan pengguna sistem. Harapan & keinginan pengguna diperoleh menurut output wawancara. Hal yang wajib  diperhatikan merupakan apa keinginan pengguna tadi adalah kebutuhan atau hanya menjadi keinginan yang tidak terdapat kaitannya menggunakan kebutuhan pengguna menurut sistem. Selanjutnya proses migrasi meliputi fase-fase berikut ini, yaitu mengidentifikasi stakeholder, menerima pemahaman kebutuhan & harapan berdasarkan pelanggan & pengguna atas suatu sistem bersiklus atau menyampaikan kebutuhan, & mengidentifikasi kebutuhan tersebut. Kemudian memetakan taraf dukungan kebutuhan usaha & fasilitas suatu organisasi untuk mencapainya. Memperjelas & menyatakan pulang kebutuhan, menganalisis kebutuhan, mendefinisikan kebutuhan yang memiliki arti yang sama bagi seluruh stakeholder, memutuskan & memprioritaskan kebutuhan, & memperoleh kebutuhan, melacak kebutuhan melalui pengelolaan kebutuhan, menguji & memverifikasi kebutuhan, & memvalidasi kebutuhan. Kriteria kebutuhan wajib  bisa dilaksanakan, benar, singkat, detail & tidak bersifat ambiguitas, lengkap, konsisten, bisa dibuktikan,  bisa ditelusuri, gampang dialokasikan, tidak terdapat kerangkapan, memakai standarisasi tertentu. Rekayasa kebutuhan wajib  sebagai penengah antara domain pengguna sistem & teknis rekayasa software wajib  menguasai keahlian teknis, kemampuan buat menerima pemahaman domain aplikasi, & keahlian interpersonal untuk membentuk konsensus antara grup stakeholder yang bersifat heterogen.

  Setelah itu, melakukan eksplorasi kebutuhan berdasarkan banyak sekali pandangan masing-masing stakeholder. Kebutuhan yang sama & tidak sama berdasarkan masing-masing stakeholder akan dicatat & disparitas persepsi diluruskan. Mengungkapkan kebutuhan pengguna adalah proses yang tidak gampang dilakukan lantaran batasan sistem tak jarang tidak jelas. Pengguna tidak relatif paham tentang apa yang diperlukan & kebutuhan tak jarang berubah. Aktivitas dilakukan dalam bentuk lanjutan & setiap stakeholder yang diundang diminta untuk menciptakan daftar kebutuhan aplikasi yang disertai penjelasan tentang ciri atau detail berdasarkan kemampuan tersebut. Validasi akan menguji kualitas menurut spesifikasi untuk memastikan bahwa kebutuhan yang dinyatakan dapat diterima/sepaham, konsisten, lengkap & bebas menurut kesalahan. Tiga faktor yang wajib  dipenuhi saat melakukan analisis kebutuhan, yaitu bersifat menyeluruh,terperinci & mempunyai taraf keakuratan yang tinggi. Dalam melakukan analisis kebutuhan yang sesungguhnya di lapangan, akan sering menemukan hal-hal yang kurang diharapkan. Misalnya, pengguna sistem yang membutuhkan aplikasi tetapi tidak mempunyai pengetahuan yang relatif mengenai segala hal yang berkaitan menggunakan rekayasa aplikasi, pemrograman & teknologi informasi. Keadaan ini tentu relatif membuat repot karena akan memerlukan banyak bisnis untuk menggali keinginan mereka yang sesungguhnya & menghindari kondisi terperangkap kedalam domain kecerdasan masing-masing. Masalah ini paling tak jarang dihadapi & adalah aspek validitas yang sangat krusial untuk menyampaikan kebutuhan pengguna sistem.

   Salah satu hal yang perlu diperhatikan adalah menciptakan interaksi yang baik dengan pengguna sistem. Kemampuan seseorang analis dalam membangun interaksi sosial dengan pihak lain, yang dalam situasi ini adalah dengan pengguna, menjadi bantuan yang signifikan. Hubungan sosial yang baik dengan pengguna akan menjadikan komunikasi yang terbuka & lancar. Mengenal lebih dekat dengan pengguna sistem berarti menciptakan komunikasi lebih lancar & tidak terlalu formal sehingga kemungkinan kesalahan dalam berkomunikasi dapat dikurangi. Yang perlu diketahui adalah tentang apa yang dikerjakannya, data apa yang sebagai masukan, & yang dihasilkan. Jangan terlalu terburu-buru dalam menanyakan bagaimana cara mengerjakannya. Bisa mengetahui apa yang sebenarnya didapatkan & apa yang sebagai masukan adalah suatu langkah yang baik untuk memperoleh gambaran yang lebih spesifik mengenai sebuah perangkat lunak. Dalam berkomunikasi dengan pengguna sistem, terutama ketika dalam proses analisis kebutuhan harus memakai bahasa & kata yang gampang untuk dipahami. Menggunakan kata pada bidang teknologi informasi & personal komputer  dapat membuat orang kagum & salut dengan anda, tetapi hal ini bisa menyebabkan kasus serius. Komunikasi bisa menjadi tidak lancar & berpeluang mengakibatkan kesalahpahaman berdasarkan persepsi masing-masing. Senantiasa wajib  mempunyai perilaku yang terbuka & bisa menerima pendapat & masukan pengguna sistem. Harus memakai model nyata yang sanggup dibuktikan & gampang buat dipahami sekalipun orang umum  yang tidak mengerti pada bidang teknologi keterangan & personal komputer . Bisa jadi, model konkret ini dibentuk oleh analis atau berdasarkan apa yang telah dimiliki oleh pengguna, contohnya untuk proses memasukkan data berdasarkan sebuah transaksi perusahaan. Pengguna sistem & analis sama-sama menyaksikan proses memasukkan data tersebut. apabila hanya disampaikan melalui Ilustrasi saja, kemungkinan interpretasi yang keliru relatif terbuka lebar & dapat mengaburkan persyaratan kebutuhan berdasarkan yang seharusnya. 

 

   Sementara melalui kegiatan konkret kinerja berdasarkan sebuah sistem bisa memperkuat & memberi keyakinan positif software yang berkualitas. Kenyataan menunjukkan bahwa faktor kritis sukses untuk berhasilnya analisis persyaratan kebutuhan diantaranya persyaratan tidak boleh ambiguous, wajib  dapat menggambarkan seluruh input & merespon sistem yang mungkin terjadi, bisa dipenuhi dari sumberdaya & batasan yang ada, memenuhi kebutuhan sistem,akurat, mempunyai fungsi & fitur-fitur sistem, & kesesuaian pada pengujian.Memiliki performa sistem berdasarkan software yang dibutuhkan, kesesuaian & kehandalan distribusi informasi, & analisis kebutuhan ini menaruh sistem sebagai lebih fleksibel, reliabel & bisa diperluas. Supaya proses rekayasa kebutuhan ini sebagai lebih adaptif menggunakan perubahan sistem memerlukan penetapan prioritas persyaratan, baik yang bersifat permanen atau wajib  dipenuhi oleh sistem atau hanya berupa persyaratan yang sebagai asa saja. Ketika keliru satu faktor tersebut tidak bisa dipenuhi oleh sebuah persyaratan yang diusulkan, maka kita wajib  melakukan konvensi  menggunakan pengguna sistem menggunakan mengusulkan balik  beberapa cara lain  persyaratan lainnya. Semuanya wajib  mempunyai dokumen persyaratan yang lengkap supaya memudahkan pada pengembangan software selanjutnya. Dimana pada dokumen tadi mempunyai kejelasan persyaratan fungsional & non-fungsional sebagai akibatnya bisa menghilangkan perilaku keragu-raguan, ketidakpastian, kekurangan keyakinan, & kegagalan penerapan software.

6. KESIMPULAN

Hasil penelitian ini memberikan kontribusi konkret, dimana analisis persyaratan kebutuhan sistem adalah fase awal proses rekayasa software yang perlu menerima perhatian serius, karena sebaik apapun pengkodean & perancangan sistem permanen tidak akan bisa memberikan keinginan yang sesungguhnya dengan kondisi yang dihadapi. Hal ini semakin krusial lantaran banyak sekali ditemukan kegagalan demi kegagalan ketika memakai software tersebut. Pemahaman yang konsisten bisa mencerminkan fleksibilitas, reliabilitas, keakuratan & usabilitas yang handal. Penelitian ini memberikan sejumlah kaidah & pertimbangan tentang persyaratan kebutuhan melalui proses migrasi sistem berdasarkan ke 2 pendekatan tersebut supaya analisis persyaratan kebutuhan bisa sinkron menggunakan kondisi konkret. Memiliki kemampuan komunikasi & hubungan yang baik & lancar, kata yang mudah dipahami, bersifat terbuka & fleksibel menerima pendapat & masukan pengguna sistem, memakai model konkret menggambarkan apa yang diperlukan & menghindari perangkap domain kecerdasan berdasarkan para pelaku sistem adalah faktor yang sangat krusial pada menyelaraskan batasan kebutuhan software menggunakan pengguna sistem.

DAFTAR PUSTAKA 

Aybuke Aurum and Claes Wohlin., 2005, Engineering and Managing Software Requirements,          Springer-Verlag Boili Heidelberg.

Pressman, Roger S., 2010, Software Engineering: A Practitioner’s Approach, Seventh Edition, McGraw-Hill, Series in Computer Science. 

Sommerville, Ian., 2011, Software Engineering, Ninth Edition, Addison-Wesley. 

Simarmata, Janner., 2010, Rekayasa Perangkat Lunak, Penerbit Andi Offset Yogyakarta. 

Wahono, Romi Satria., 2003, Analyzing Requirements Engineering Problems, IECI Japan 

Workshop 2003 (IJW-2003), Japan. Zave, Pamela., 1997, Classification of Research Efforts in 

Requirements Engineering, ACM Computing Surveys, 29(4), pp. 315-321.