Persyaratan Software

Persyaratan perangkat lunak adalah deskripsi fitur dan fungsionalitas sistem target. Persyaratan menyampaikan harapan pengguna dari produk perangkat lunak. Persyaratan dapat jelas atau tersembunyi, diketahui atau tidak diketahui, diharapkan atau tidak terduga dari sudut pandang klien.

Rekayasa Kebutuhan

Proses untuk mengumpulkan persyaratan perangkat lunak dari klien, menganalisis dan mendokumentasikannya dikenal sebagai rekayasa persyaratan.

Tujuan dari rekayasa persyaratan adalah untuk mengembangkan dan memelihara dokumen 'Spesifikasi Kebutuhan Sistem' yang canggih dan deskriptif.

Proses Rekayasa Kebutuhan

Ini adalah proses empat langkah, yang meliputi -

Studi kelayakan
Pertemuan Persyaratan
Spesifikasi Kebutuhan Perangkat Lunak
Validasi Kebutuhan Perangkat Lunak

Mari kita lihat prosesnya secara singkat -

Studi kelayakan

Ketika klien mendekati organisasi untuk mengembangkan produk yang diinginkan, muncul gambaran kasar tentang semua fungsi yang harus dilakukan perangkat lunak dan semua fitur yang diharapkan dari perangkat lunak.

Merujuk pada informasi ini, para analis melakukan studi rinci tentang apakah sistem yang diinginkan dan fungsionalitasnya layak untuk dikembangkan.

Studi kelayakan ini difokuskan pada tujuan organisasi. Studi ini menganalisis apakah produk perangkat lunak dapat diwujudkan secara praktis dalam hal implementasi, kontribusi proyek kepada organisasi, kendala biaya dan sesuai dengan nilai dan tujuan organisasi. Ini mengeksplorasi aspek teknis dari proyek dan produk seperti kegunaan, pemeliharaan, produktivitas dan kemampuan integrasi.

Keluaran dari tahap ini harus berupa laporan studi kelayakan yang harus berisi komentar dan rekomendasi yang memadai untuk manajemen tentang apakah proyek harus dilaksanakan atau tidak.

Pertemuan Persyaratan

Jika laporan kelayakan positif terhadap pelaksanaan proyek, tahap selanjutnya dimulai dengan mengumpulkan persyaratan dari pengguna. Analis dan insinyur berkomunikasi dengan klien dan pengguna akhir untuk mengetahui ide-ide mereka tentang apa yang harus disediakan perangkat lunak dan fitur apa yang mereka inginkan untuk disertakan dalam perangkat lunak.

Spesifikasi Kebutuhan Perangkat Lunak

SRS adalah dokumen yang dibuat oleh analis sistem setelah persyaratan dikumpulkan dari berbagai pemangku kepentingan.

SRS mendefinisikan bagaimana perangkat lunak yang dimaksud akan berinteraksi dengan perangkat keras, antarmuka eksternal, kecepatan operasi, waktu respons sistem, portabilitas perangkat lunak di berbagai platform, pemeliharaan, kecepatan pemulihan setelah crash, Keamanan, Kualitas, Batasan, dll.

Persyaratan yang diterima dari klien ditulis dalam bahasa alami. Analis sistem bertanggung jawab untuk mendokumentasikan persyaratan dalam bahasa teknis sehingga dapat dipahami dan berguna oleh tim pengembangan perangkat lunak.

SRS harus hadir dengan fitur-fitur berikut:

Persyaratan Pengguna diekspresikan dalam bahasa alami.
Persyaratan teknis dinyatakan dalam bahasa terstruktur, yang digunakan di dalam organisasi.
Deskripsi desain harus ditulis dalam kode Pseudo.
Format Formulir dan cetakan layar GUI.
Notasi bersyarat dan matematika untuk DFD, dll.

Validasi Kebutuhan Perangkat Lunak

Setelah spesifikasi persyaratan dikembangkan, persyaratan yang disebutkan dalam dokumen ini divalidasi. Pengguna mungkin meminta solusi ilegal dan tidak praktis atau para ahli dapat menafsirkan persyaratan secara tidak benar. Hal ini mengakibatkan peningkatan biaya yang sangat besar jika tidak dihentikan sejak awal. Persyaratan dapat diperiksa terhadap kondisi berikut -

Jika bisa diterapkan secara praktis
Jika mereka valid dan sesuai dengan fungsionalitas dan domain perangkat lunak
Jika ada ambiguitas
Jika sudah lengkap
Jika mereka bisa didemonstrasikan

Proses Kebutuhan Elisitasi

Proses perolehan kebutuhan dapat digambarkan menggunakan diagram berikut:

Requirements gathering - Pengembang berdiskusi dengan klien dan pengguna akhir dan mengetahui harapan mereka dari perangkat lunak.
Organizing Requirements - Pengembang memprioritaskan dan mengatur persyaratan dalam urutan kepentingan, urgensi dan kenyamanan.
Negotiation & discussion - Jika persyaratan tidak jelas atau ada beberapa konflik dalam persyaratan berbagai pemangku kepentingan, jika ada, hal itu kemudian dinegosiasikan dan didiskusikan dengan pemangku kepentingan. Persyaratan kemudian dapat diprioritaskan dan dikompromikan secara wajar.

Persyaratan tersebut datang dari berbagai pemangku kepentingan. Untuk menghilangkan ambiguitas dan konflik, mereka dibahas untuk kejelasan dan kebenaran. Persyaratan yang tidak realistis dikompromikan secara wajar.
Documentation - Semua persyaratan formal & informal, fungsional dan non-fungsional didokumentasikan dan tersedia untuk pemrosesan tahap berikutnya.

Teknik Elisitasi Kebutuhan

Requirements Elicitation adalah proses untuk mengetahui kebutuhan suatu sistem perangkat lunak yang dimaksudkan dengan cara berkomunikasi dengan klien, pengguna akhir, pengguna sistem dan pihak lain yang memiliki andil dalam pengembangan sistem perangkat lunak.

Ada berbagai cara untuk menemukan persyaratan

Wawancara

Wawancara adalah media yang kuat untuk mengumpulkan persyaratan. Organisasi dapat melakukan beberapa jenis wawancara seperti:

Wawancara terstruktur (tertutup), di mana setiap informasi yang dikumpulkan diputuskan sebelumnya, mereka mengikuti pola dan materi diskusi dengan tegas.
Wawancara non-terstruktur (terbuka), di mana informasi yang dikumpulkan tidak diputuskan sebelumnya, lebih fleksibel dan tidak bias.
Wawancara lisan
Wawancara tertulis
Wawancara satu-ke-satu yang diadakan antara dua orang di seberang meja.
Wawancara kelompok yang dilakukan antar kelompok peserta. Mereka membantu mengungkap persyaratan yang hilang karena banyak orang yang terlibat.

Survei

Organisasi dapat melakukan survei di antara berbagai pemangku kepentingan dengan menanyakan tentang harapan dan persyaratan mereka dari sistem yang akan datang.

Kuesioner

Sebuah dokumen dengan serangkaian pertanyaan obyektif yang telah ditentukan sebelumnya dan masing-masing opsi diserahkan kepada semua pemangku kepentingan untuk dijawab, yang dikumpulkan dan dikompilasi.

Kekurangan dari teknik ini adalah, jika opsi untuk beberapa masalah tidak disebutkan dalam kuesioner, masalah tersebut mungkin dibiarkan begitu saja.

Analisis tugas

Tim insinyur dan pengembang dapat menganalisis operasi yang memerlukan sistem baru. Jika klien sudah memiliki beberapa perangkat lunak untuk melakukan operasi tertentu, itu dipelajari dan persyaratan sistem yang diusulkan dikumpulkan.

Analisis Domain

Setiap perangkat lunak termasuk dalam beberapa kategori domain. Orang-orang ahli dalam domain dapat sangat membantu untuk menganalisis persyaratan umum dan khusus.

Brainstorming

Debat informal diadakan di antara berbagai pemangku kepentingan dan semua masukan mereka dicatat untuk analisis persyaratan lebih lanjut.

Pembuatan prototipe

Prototyping adalah membangun antarmuka pengguna tanpa menambahkan fungsionalitas detail bagi pengguna untuk menginterpretasikan fitur produk perangkat lunak yang dimaksudkan. Ini membantu memberikan gagasan yang lebih baik tentang persyaratan. Jika tidak ada perangkat lunak yang diinstal di akhir klien untuk referensi pengembang dan klien tidak mengetahui persyaratannya sendiri, pengembang membuat prototipe berdasarkan persyaratan yang disebutkan di awal. Prototipe ditampilkan kepada klien dan umpan balik dicatat. Umpan balik klien berfungsi sebagai masukan untuk pengumpulan kebutuhan.

Pengamatan

Tim ahli mengunjungi organisasi atau tempat kerja klien. Mereka mengamati kerja sebenarnya dari sistem terpasang yang ada. Mereka mengamati alur kerja di akhir klien dan bagaimana masalah eksekusi ditangani. Tim itu sendiri menarik beberapa kesimpulan yang membantu untuk membentuk persyaratan yang diharapkan dari perangkat lunak.

Karakteristik Kebutuhan Perangkat Lunak

Mengumpulkan persyaratan perangkat lunak adalah dasar dari keseluruhan proyek pengembangan perangkat lunak. Karenanya mereka harus jelas, benar dan terdefinisi dengan baik.

Spesifikasi Kebutuhan Perangkat Lunak yang lengkap harus:

Clear
Correct
Consistent
Coherent
Comprehensible
Modifiable
Verifiable
Prioritized
Unambiguous
Traceable
Sumber yang kredibel

Persyaratan Software

Kita harus mencoba memahami persyaratan seperti apa yang mungkin muncul dalam fase perolehan persyaratan dan jenis persyaratan apa yang diharapkan dari sistem perangkat lunak.

Persyaratan perangkat lunak secara luas harus dikategorikan dalam dua kategori:

Persyaratan Fungsional

Persyaratan yang terkait dengan aspek fungsional perangkat lunak termasuk dalam kategori ini.

Mereka mendefinisikan fungsi dan fungsionalitas di dalam dan dari sistem perangkat lunak.

Contoh -

Opsi pencarian diberikan kepada pengguna untuk mencari dari berbagai faktur.
Pengguna harus dapat mengirimkan laporan apapun ke manajemen.
Pengguna dapat dibagi menjadi beberapa kelompok dan kelompok dapat diberikan hak terpisah.
Harus mematuhi aturan bisnis dan fungsi administratif.
Perangkat lunak dikembangkan dengan menjaga kompatibilitas ke bawah tetap utuh.

Persyaratan Non Fungsional

Persyaratan, yang tidak berhubungan dengan aspek fungsional perangkat lunak, termasuk dalam kategori ini. Mereka adalah karakteristik implisit atau yang diharapkan dari perangkat lunak, yang membuat asumsi pengguna.

Persyaratan non-fungsional meliputi -

Security
Logging
Storage
Configuration
Performance
Cost
Interoperability
Flexibility
Pemulihan bencana
Accessibility

Persyaratan dikategorikan secara logis sebagai

Must Have : Perangkat lunak tidak dapat dikatakan beroperasi tanpanya.
Should have : Meningkatkan fungsionalitas perangkat lunak.
Could have : Perangkat lunak masih dapat berfungsi dengan baik dengan persyaratan ini.
Wish list : Persyaratan ini tidak memetakan ke tujuan perangkat lunak apa pun.

Saat mengembangkan perangkat lunak, 'Harus ada' harus diterapkan, 'Harus ada' adalah masalah perdebatan dengan pemangku kepentingan dan negasi, sedangkan 'dapat memiliki' dan 'daftar keinginan' dapat disimpan untuk pembaruan perangkat lunak.

Persyaratan Antarmuka Pengguna

UI adalah bagian penting dari perangkat lunak atau perangkat keras atau sistem hybrid apa pun. Perangkat lunak diterima secara luas jika -

mudah dioperasikan
cepat dalam merespon
menangani kesalahan operasional secara efektif
menyediakan antarmuka pengguna yang sederhana namun konsisten

Penerimaan pengguna sangat bergantung pada bagaimana pengguna dapat menggunakan perangkat lunak. UI adalah satu-satunya cara bagi pengguna untuk memahami sistem. Sistem perangkat lunak yang berkinerja baik juga harus dilengkapi dengan antarmuka pengguna yang menarik, jelas, konsisten, dan responsif. Jika fungsi sistem perangkat lunak tidak dapat digunakan dengan cara yang nyaman. Suatu sistem dikatakan baik jika menyediakan sarana untuk menggunakannya secara efisien. Persyaratan antarmuka pengguna secara singkat disebutkan di bawah -

Presentasi konten
Navigasi Mudah
Antarmuka yang sederhana
Responsive
Elemen UI yang konsisten
Mekanisme umpan balik
Pengaturan default
Tata letak yang bertujuan
Penggunaan warna dan tekstur secara strategis.
Berikan informasi bantuan
Pendekatan yang berpusat pada pengguna
Pengaturan tampilan berbasis grup.

Analis Sistem Perangkat Lunak

Analis sistem dalam organisasi TI adalah seseorang, yang menganalisis kebutuhan sistem yang diusulkan dan memastikan bahwa persyaratan dipahami dan didokumentasikan dengan baik & benar. Peran seorang analis dimulai selama Fase Analisis Perangkat Lunak SDLC. Merupakan tanggung jawab analis untuk memastikan bahwa perangkat lunak yang dikembangkan memenuhi persyaratan klien.

Analis Sistem memiliki tanggung jawab berikut:

Menganalisis dan memahami persyaratan perangkat lunak yang dimaksudkan
Memahami bagaimana proyek akan berkontribusi dalam tujuan organisasi
Identifikasi sumber kebutuhan
Validasi persyaratan
Kembangkan dan terapkan rencana manajemen persyaratan
Dokumentasi persyaratan bisnis, teknis, proses dan produk
Koordinasi dengan klien untuk memprioritaskan persyaratan dan menghapus serta ambiguitas
Menyelesaikan kriteria penerimaan dengan klien dan pemangku kepentingan lainnya

Metrik dan Ukuran Perangkat Lunak

Pengukuran Perangkat Lunak dapat dipahami sebagai proses mengukur dan melambangkan berbagai atribut dan aspek perangkat lunak.

Metrik Perangkat Lunak memberikan ukuran untuk berbagai aspek proses perangkat lunak dan produk perangkat lunak.

Ukuran perangkat lunak adalah persyaratan mendasar dari rekayasa perangkat lunak. Mereka tidak hanya membantu untuk mengontrol proses pengembangan perangkat lunak tetapi juga membantu menjaga kualitas produk akhir yang sangat baik.

Menurut Tom DeMarco, seorang (Insinyur Perangkat Lunak), "Anda tidak dapat mengontrol apa yang tidak dapat Anda ukur." Dengan ucapannya, sangat jelas betapa pentingnya ukuran perangkat lunak.

Mari kita lihat beberapa metrik perangkat lunak:

Size Metrics - LOC (Lines of Code), sebagian besar dihitung dalam ribuan baris kode sumber yang dikirim, dilambangkan sebagai KLOC.

Hitungan Titik Fungsi adalah ukuran fungsionalitas yang disediakan oleh perangkat lunak. Hitungan Titik Fungsi menentukan ukuran aspek fungsional perangkat lunak.
Complexity Metrics - Kompleksitas Cyclomatic McCabe mengkuantifikasi batas atas jumlah jalur independen dalam sebuah program, yang dianggap sebagai kompleksitas program atau modulnya. Hal tersebut direpresentasikan dalam bentuk konsep teori graph dengan menggunakan control flow graph.
Quality Metrics - Cacat, jenis dan penyebabnya, konsekuensi, intensitas keparahan dan implikasinya menentukan kualitas produk.

Jumlah cacat yang ditemukan dalam proses pengembangan dan jumlah cacat yang dilaporkan oleh klien setelah produk dipasang atau dikirim di akhir klien, menentukan kualitas produk.
Process Metrics - Dalam berbagai fase SDLC, metode dan alat yang digunakan, standar perusahaan dan kinerja pengembangan adalah metrik proses perangkat lunak.
Resource Metrics - Upaya, waktu, dan berbagai sumber daya yang digunakan mewakili metrik untuk pengukuran sumber daya.