Analisis Kebutuhan Perangkat Lunak dengan Contoh
Charles Moore
⚡ Ringkasan Cerdas
Analisis kebutuhan perangkat lunak memecah kebutuhan pemangku kepentingan menjadi pernyataan fungsional dan non-fungsional, memberi peringkat pada tingkat bisnis, arsitektur, dan sistem, kemudian memeriksa setiap pernyataan terhadap atribut kualitas untuk menjamin perangkat lunak yang dapat diuji, tracSpesifikasi yang dapat diandalkan dan diprioritaskan.
Persyaratan perangkat lunak adalah kebutuhan fungsional atau non-fungsional yang harus diimplementasikan dalam sistem. Fungsional berarti menyediakan layanan tertentu kepada pengguna.
Sebagai contoh, dalam konteks aplikasi perbankan, persyaratan fungsionalnya adalah ketika pelanggan memilih "Lihat Saldo", mereka harus dapat melihat saldo rekening terbaru mereka.
Persyaratan perangkat lunak juga dapat bersifat non-fungsional, seperti persyaratan kinerja. Misalnya, persyaratan non-fungsional mungkin menyatakan bahwa setiap halaman sistem harus dimuat untuk pengguna dalam waktu 5 detik.
Pada dasarnya kebutuhan perangkat lunak adalah a
- Fungsional atau
- Tidak berfungsi
perlu yang harus diimplementasikan ke dalam sistem. Persyaratan perangkat lunak biasanya dinyatakan dalam bentuk pernyataan.
Jenis Persyaratan
Persyaratan bisnisIni adalah persyaratan tingkat tinggi yang diambil dari studi kelayakan proyek. Misalnya, sistem layanan perbankan seluler menyediakan layanan perbankan untuk Asia Tenggara. Persyaratan bisnis yang ditetapkan untuk India adalah ringkasan rekening dan transfer dana, sedangkan untuk Tiongkok adalah ringkasan rekening dan pembayaran tagihan.
| Negara | Perusahaan yang menyediakan Fungsi atau layanan Perbankan |
|---|---|
| India | Ringkasan Rekening dan Transfer Dana |
| Tiongkok | Ringkasan Rekening dan Bill Pembayaran |
Archipersyaratan tekstur dan DesainPersyaratan ini lebih rinci daripada persyaratan bisnis dan mendorong arsitektur solusi. Persyaratan ini menentukan desain keseluruhan yang diperlukan untuk mengimplementasikan persyaratan bisnis. Untuk organisasi pendidikan, contoh kasus penggunaan arsitektur dan desain yang umum meliputi login, detail kursus, dan pendaftaran. Persyaratan tersebut akan seperti yang ditunjukkan di bawah ini.
| Kasus penggunaan perbankan | Kebutuhan |
|---|---|
| Bill Pembayaran | Kasus penggunaan ini menjelaskan bagaimana pelanggan dapat login ke net banking dan menggunakan Bill Fasilitas Pembayaran. Pelanggan dapat melihat dasbor tagihan yang belum dibayar untuk penagih terdaftar. Pelanggan dapat menambahkan, mengubah, dan menghapus detail penagih. Pelanggan dapat mengkonfigurasi peringatan SMS dan email untuk berbagai tindakan penagihan. Pelanggan dapat melihat riwayat tagihan yang telah dibayar sebelumnya. Aktor yang memulai kasus penggunaan ini adalah pelanggan bank atau personel dukungan. |
Persyaratan Sistem dan IntegrasiPada level terendah, kita memiliki persyaratan sistem dan integrasi. Ini memberikan deskripsi rinci tentang setiap persyaratan. Persyaratan ini dapat diwujudkan sebagai user story yang ditulis dalam bahasa bisnis sehari-hari. Persyaratan tersebut berisi detail yang melimpah sehingga pengembang dapat mulai melakukan pengkodean. Bill Contoh modul pembayaran di bawah ini menunjukkan persyaratan untuk menambahkan penagih.
| Bill Pembayaran | Persyaratan |
|---|---|
| Add Billers | Nama Penyedia Layanan Utilitas, Nomor Pelanggan, Pembayaran Otomatis – Ya/Tidak, Bayar Seluruhnya Bill – Ya/Tidak, Batas Pembayaran Otomatis – Jangan bayar jika Bill melebihi jumlah yang ditentukan |
Terkadang untuk suatu proyek, Anda mungkin tidak menerima persyaratan atau dokumen apa pun untuk dikerjakan. Meskipun demikian, ada sumber informasi persyaratan lain yang dapat Anda andalkan untuk mendasarkan desain perangkat lunak atau pengujian Anda. Sumber persyaratan lain yang dapat Anda andalkan tercantum di bawah ini.
Sumber Persyaratan Lainnya
- Transfer pengetahuan dari kolega atau karyawan yang sudah mengerjakan proyek tersebut
- Diskusikan proyek tersebut dengan Analis Bisnis, manajer produk, pemimpin proyek, dan pengembang.
- Analisis versi sistem sebelumnya yang telah diimplementasikan.
- Analisis dokumen persyaratan lama dari proyek tersebut.
- RevLihat laporan bug sebelumnya; beberapa laporan bug diubah menjadi permintaan peningkatan yang mungkin diimplementasikan dalam versi saat ini.
- Periksa panduan instalasi, jika tersedia, untuk melihat instalasi apa saja yang diperlukan.
- Analisis pengetahuan domain atau industri yang coba diterapkan oleh tim.
Apa pun sumber persyaratan yang Anda gunakan, dokumentasikan dalam format yang sama dan mintalah anggota tim yang berpengalaman untuk meninjaunya.
Bagaimana Menganalisis Persyaratan
Pertimbangkan contoh sistem perangkat lunak pendidikan di mana seorang siswa dapat mendaftar untuk berbagai kursus.
Mari kita pelajari cara menganalisis persyaratan. Setiap persyaratan harus memenuhi serangkaian atribut kualitas standar, yang meliputi hal-hal berikut:
- Atomic
- Diidentifikasi secara unik
- Menyelesaikan
- Konsisten dan tidak ambigu
- Tracmampu
- Diprioritaskan
- Dapat diuji
Tabel berikut mengilustrasikan setiap atribut dengan tiga kolom:
- Kolom pertama menunjukkan- “kualitas persyaratan”
- Kolom kedua menunjukkan- “persyaratan buruk dengan beberapa masalah”
- Kolom ketiga menunjukkan persyaratan yang sama “yang diubah menjadi persyaratan yang baik”.
| Kualitas Persyaratan | Contoh persyaratan yang buruk | Contoh persyaratan yang baik |
|---|---|---|
| Atomic | Siswa akan dapat mendaftar ke program sarjana dan pascasarjana | Mahasiswa akan dapat mendaftar ke program sarjana. Mahasiswa akan dapat mendaftar ke program pascasarjana. |
| Diidentifikasi secara unik | 1- Mahasiswa akan dapat mendaftar ke program sarjana. 1- Mahasiswa akan dapat mendaftar ke program pascasarjana. | Pendaftaran Kursus. Mahasiswa dapat mendaftar ke kursus sarjana. Mahasiswa dapat mendaftar ke kursus pascasarjana. |
| Menyelesaikan | Seorang pengguna profesor akan masuk ke sistem dengan memberikan nama pengguna, kata sandi, dan informasi relevan lainnya | Seorang pengguna profesor akan login ke sistem dengan memberikan nama pengguna, kata sandi, dan kode departemennya |
| Konsisten dan tidak ambigu | Seorang siswa akan memiliki program sarjana atau program pascasarjana tetapi tidak keduanya. Beberapa program studi akan terbuka untuk program sarjana dan pasca sarjana | Seorang siswa akan memiliki gelar sarjana atau pasca sarjana tetapi tidak keduanya |
| Tracmampu | Menjaga informasi siswa terpetakan ke kebutuhan BRD? | Menyimpan informasi siswa-Dipetakan ke BRD req ID 4.1 |
| Diprioritaskan | Mahasiswa terdaftar - Prioritas 1. Mengelola Informasi Pengguna - Prioritas 1. Mendaftar kursus - Prioritas 1. Melihat Kartu Laporan - Prioritas 1. | Mendaftarkan Siswa - Prioritas 1. Mengelola Informasi Pengguna - Prioritas 2. Mendaftarkan Mata Kuliah - Prioritas 1. Melihat Laporan Nilai - Prioritas 3. |
| Dapat diuji | Setiap halaman sistem akan dimuat dalam jangka waktu yang dapat diterima | Halaman daftar siswa dan daftar kursus sistem akan dimuat dalam 5 detik |
Mari kita pahami masing-masing atribut ini secara lebih rinci, dimulai dengan Atomic
Atomic
Setiap persyaratan harus bersifat atomik, artinya harus berada pada tingkat detail terendah dan tidak dapat dipecah lebih lanjut menjadi komponen-komponen. Contoh-contoh berikut membandingkan persyaratan atomik dan non-atomik.
Melanjutkan contoh sistem domain pendidikan: Di sini, persyaratan yang buruk adalah “Mahasiswa akan dapat mendaftar ke program sarjana dan pascasarjana”. Ini adalah persyaratan yang buruk karena tidak atomik — persyaratan ini mencampuradukkan dua entitas yang berbeda, program sarjana dan pascasarjana. Persyaratan yang baik memisahkannya menjadi dua persyaratan. Satu persyaratan mencakup pendaftaran di program sarjana, dan yang lainnya mencakup pendaftaran di program pascasarjana.
Diidentifikasi Secara Unik
Atribut kualitas selanjutnya adalah identifikasi unik. Dalam contoh yang buruk, dua persyaratan terpisah memiliki ID#1 yang sama. Jika sebuah tim merujuk pada suatu persyaratan berdasarkan ID-nya, akan menjadi tidak jelas mana dari keduanya yang dimaksud. Persyaratan yang baik mengelompokkannya kembali di bawah Bagian 1 — Pendaftaran Kursus, dengan sub-persyaratan 1.1 (pendaftaran ke kursus sarjana) dan 1.2 (pendaftaran ke kursus pascasarjana).
Menyelesaikan
Setiap persyaratan harus lengkap. Misalnya, di sini persyaratan yang buruk menyatakan bahwa "pengguna profesor akan masuk ke sistem dengan memberikan nama pengguna, kata sandi, dan informasi relevan lainnya". "Informasi relevan lainnya" bersifat ambigu. Persyaratan yang lengkap mencantumkan bidang-bidang yang tepat, seperti kode departemen, yang harus diberikan oleh profesor.
Konsisten dan Tidak Ambigu
Setiap persyaratan harus konsisten dan tidak ambigu. Dalam contoh yang buruk, satu persyaratan menyatakan “Seorang mahasiswa akan mengambil mata kuliah sarjana atau pascasarjana, tetapi tidak keduanya”, sementara persyaratan lain menyatakan “Beberapa mata kuliah akan terbuka untuk mahasiswa sarjana dan pascasarjana”.
Persyaratan pertama menyiratkan bahwa mata kuliah dibagi menjadi dua kategori eksklusif, tetapi persyaratan kedua bertentangan dengan hal itu karena membuka beberapa mata kuliah untuk kedua kelompok tersebut.
Persyaratan yang baik ini menyelesaikan konflik dengan menyatakan secara jelas bahwa setiap mata kuliah ditandai sebagai program sarjana atau pascasarjana, dan seorang mahasiswa hanya dapat mendaftar di mata kuliah dari satu kategori saja.
Tracmampu
Setiap persyaratan harus tracHal ini dimungkinkan karena persyaratan ada di berbagai tingkatan: bisnis, arsitektur dan desain, serta sistem dan integrasi.
Saat Anda mengubah persyaratan bisnis menjadi persyaratan arsitektur dan desain, atau persyaratan arsitektur dan desain menjadi persyaratan sistem dan integrasi, tracKemudahan akses harus dijaga. Setiap persyaratan bisnis harus dipetakan ke satu atau lebih persyaratan arsitektur dan desain. Dalam contoh yang buruk "Kelola informasi siswa – dipetakan ke ID persyaratan BRD?", ID persyaratannya hilang.
Persyaratan yang baik mencatat pernyataan yang sama tetapi secara eksplisit memetakan ke ID persyaratan BRD 4.1. Setiap persyaratan harus memuat tracpeta kelayakanpingPersyaratan sistem dan integrasi juga harus dipetakan ke kode yang mengimplementasikannya dan ke kasus uji yang memverifikasinya.
TracOleh karena itu, eabilitas berjalan menyeluruh di seluruh proyek.
Diprioritaskan
Setiap persyaratan harus diprioritaskan agar tim tahu apa yang harus diimplementasikan terlebih dahulu dan apa yang bisa menunggu. Dalam contoh yang buruk, Pendaftaran Siswa, Pengelolaan Informasi Pengguna, Pendaftaran Kursus, dan Melihat Laporan Nilai semuanya ditetapkan sebagai Prioritas 1. Tidak semuanya bisa menjadi Prioritas 1, jadi persyaratan harus diberi peringkat secara realistis. Contoh yang baik memberikan Pendaftaran Siswa dan Pendaftaran Kursus Prioritas 1 tertinggi, Pengelolaan Informasi Pengguna Prioritas 2, dan Melihat Laporan Nilai Prioritas 3.
Dapat diuji
Setiap persyaratan harus dapat diuji. Contoh yang buruk, “setiap halaman sistem akan dimuat dalam jangka waktu yang dapat diterima”, tidak dapat diuji karena dua alasan. Pertama, “setiap halaman” dapat berarti puluhan halaman, yang memperbesar upaya pengujian. Kedua, “jangka waktu yang dapat diterima” tidak didefinisikan — dapat diterima oleh siapa, dan berdasarkan tolok ukur apa? Persyaratan yang baik memperbaiki kedua masalah tersebut dengan menyebutkan halaman-halaman spesifik (“halaman pendaftaran mahasiswa dan pendaftaran kursus”) dan menetapkan target terukur yaitu 5 detik.
