Analisis Persyaratan Perangkat Lunak dan Spesifikasi

Slides:



Advertisements
Presentasi serupa
©Ayi Purbasari, S.T., /2008 Materi 3 Kuliah IT-505 PSBO ©Ayi Purbasari, S.T., /2008.
Advertisements

Proses-proses Perangkat Lunak
DASAR-DASAR PENGUJIAN PERANGKAT LUNAK
Jaminan Kualitas Perangkat Lunak Software Quality Assurance [SQA]
Siti Mukaromah, S.Kom.  Model yang menggambarkan requirement software dalam bentuk use case - use case  Use case model terdiri dari satu atau beberapa.
Bab 6 PERANCANGAN PERANGKAT LUNAK
Perancangan Perangkat Lunak lanjutan Kuliah - 7
PEMODELAN ANALISIS Kuliah - 5
Software Requirement Specification
BPR – Tahap 1 (Persiapan)
REKAYASA SISTEM.
PENGANTAR REKAYASA PERANGKAT LUNAK I
Manajemen Mutu Perangkat Lunak
Pertemuan 9 Proyek Sistem Informasi Viska Armalina, ST., M.Eng
Requirement.
REKAYASA PERANGKAT LUNAK REQUIREMENTS ANALYSIS FUNDAMENTALS
Perancangan sistem ( berbasis objek )
Konsep & Prinsip Analisis
Analisis Kebutuhan dan Spesifikasi Perangkat Lunak
Prototyping Aplikasi Teknologi Informasi
SIKLUS PENGEMBANGAN SISTEM
PLANNING A SOFTWARE PROJECT Ir. Waniwatining Astuti, M.T.I.
Analisa dan Desain dalam Penelitian
Ir. Waniwatining Astuti, M.T.I Rekayasa Perangkat Lunak
Rekayasa Perangkat Lunak
Spesifikasi Perangkat Lunak
REKAYASA PERANGKAT LUNAK
Analisis Kebutuhan PL dan Spesifikasi PL
A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK.
PENGUJIAN DENGAN SIKLUS HIDUP
A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK.
KONSEP DAN PRINSIP ANALISIS
REKAYASA PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Spesifikasi Perangkat Lunak
Perangkat Lunak 1.
Analisis Sistem Istiqomah, S.Kom.
Rekayasa Perangkat Lunak Model Proses PL
REKAYASA PERANGKAT LUNAK
Pengenalan Rekayasa Perangkat Lunak
Rekayasa Perangkat Lunak
Outline Elemen desain arsitektur. Membuat desain arsitektur.
ANALISA KINERJA SISTEM
MANAJEMEN PROYEK TI PERTEMUAN KE 3 SAFITRI JAYA, S.Kom, M.T.I
SE3414 RPL: Teknik Berorientasi Objek
Pemeliharaan Perangkat Lunak
RPL.
4 Managing Software Requirement Analisis Kebutuhan
ANALISIS KEBUTUHAN PERANGKAT LUNAK
Jaminan Mutu dalam Kebutuhan Rekayasa
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Management Projeck “Fase Inisialisasi dan Reqiurement Analisys”
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Rekayasa Kebutuhan Software
ANALISA KEBUTUHAN PERANGKAT LUNAK
ANALISIS KEBUTUHAN PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Analisa [Kebutuhan] Sistem
Model Waterfall dan Dokumen SKPL
Diagram Konteks & Data Flow Diagram (DFD)
ANALISIS KEBUTUHAN PERANGKAT LUNAK
PENGANTAR REKAYASA PERANGKAT LUNAK
5 Kebutuhan Software By : Andi Latifa Nabone.
Pengembangan Sistem Informasi
JAMINAN KUALITAS PERANGKAT LUNAK (SOFTWARE QUALITY ASSURANCE)
ANALISA KEBUTUHAN PERANGKAT LUNAK
REKAYASA KEBUTUHAN PL.
Pengujian Perangkat Lunak
KONSEP DAN PRINSIP ANALISIS
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
Transcript presentasi:

Analisis Persyaratan Perangkat Lunak dan Spesifikasi Materi 3 Rekayasa Perangkat Lunak Ir. Waniwatining Astuti, M.T.I

Persyaratan Definisi persyaratan : kondisi kemampuan yang dibutuhkan oleh pengguna untuk memecahkan masalah atau mencapai tujuan; Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem ... untuk memenuhi kontrak, standar, spesifikasi, atau dokumen resmi lainnya yang dikenakan "

tujuan dari kegiatan persyaratan untuk menghasilkan Spesifikasi Persyaratan Software / software requirement spesification (SRS) yang menjelaskan apa perangkat lunak yang diusulkan harus melakukan tanpa menggambarkan bagaimana perangkat lunak akan melakukannya.

Dalam bab ini akan dibahas Peran SRS dalam proyek dan nilai sebuah SRS yang baik. Berbagai kegiatan dalam proses untuk membuat SRS yang diinginkan. Karakteristik yang diinginkan dari SRS, struktur dari sebuah dokumen SRS, dan komponen utamanya. Menggunakan pendekatan kasus untuk menganalisis dan menentukan kebutuhan fungsional, dan bagaimana penggunaan dapat dikembangkan. Beberapa pendekatan lain untuk menganalisis persyaratan seperti diagram aliran data. Bagaimana persyaratan divalidasi.

3.1 Value of a Good SRS Tujuan dasar dari SRS adalah untuk menjembatani kesenjangan komunikasi antara klien dan pengembang, sehingga mereka memiliki visi bersama tentang perangkat lunak yang akan dibangun. Oleh karena itu, salah satu keuntungan utama dari SRS yang baik adalah :

1. SRS menetapkan dasar kesepatakan antara Pengguna dan Pengembang Jadi, melalui SRS, klien secara jelas menggambarkan apa yang diharapkan dari pengembang.

2. SRS menyediakan referensi untuk validasi produk akhir SRS membantu klien menentukan apakah perangkat lunak yang memenuhi persyaratan. Tanpa SRS yang tepat, tidak ada cara klien dapat menentukan apakah perangkat lunak yang disampaikan adalah apa yang diperintahkan, dan tidak ada cara pengembang dapat meyakinkan klien bahwa semua persyaratan telah dipenuhi

jika kita ingin hasil akhir berkualitas tinggi yang memiliki beberapa kesalahan, kita harus mulai dengan SRS berkualitas tinggi. Dengan kata lain, kita dapat menyimpulkan bahwa: Sebuah SRS berkualitas tinggi merupakan prasyarat untuk perangkat lunak berkualitas tinggi. Sebuah SRS berkualitas tinggi mengurangi biaya pengembangan

3.2 Kebutuhan Proses Proses persyaratan adalah urutan kegiatan yang perlu dilakukan dalam fase persyaratan dan yang berujung pada menghasilkan dokumen berkualitas tinggi yang berisi SRS. Proses persyaratan biasanya terdiri dari tiga tugas dasar: masalah atau analisis kebutuhan, persyaratan spesifikasi, dan validasi kebutuhan

Analisa masalah Analisa Masalah sering kali dimulai dengan "pernyataan masalah" : analisis domain masalah dan lingkungan yang dimodelkan dalam upaya untuk memahami perilaku sistem., kendala pada sistem, input dan output, dll tujuan dasar kegiatan ini adalah untuk mendapatkan pemahaman yang menyeluruh tentang software apa yang harus disediakan.

Spesifikasi persyaratan Fokus spesifikasi persyaratan adalah pada penetapan persyaratan dalam dokumen. Isu-isu seperti representasi, bahasa spesifikasi, dan alat-alat yang ditujukan pada kegiatan ini. Mengatur dengan benar dan menjelaskan persyaratan adalah tujuan yang penting dari kegiatan ini.

Validasi persyaratan Validasi Persyaratan berfokus untuk memastikan bahwa apa yang telah ditetapkan dalam SRS adalah segala yang berkaitan dengan persyaratan perangkat lunak dan memastikan bahwa SRS berkualitas baik. Proses persyaratan berakhir dengan produksi SRS divalidasi.

Proses kebutuhan

3.3 Spesifikasi persyaratan Suatu SRS harus memiliki sifat tertentu dan harus berisi berbagai jenis kebutuhan. Beberapa karakteristik yang diinginkan dari SRS adalah : Benar Lengkap Jelas Diverifikasi Konsisten Peringkat untuk kepentingan dan / atau stabilitas

Sebuah SRS harus mengidentifikasi dan menentukan semua kendala tersebut. Beberapa contoh ini adalah: Standar Kepatuhan: menetapkan persyaratan standar sistem harus yang harus diikuti. Standar mungkin termasuk format laporan dan prosedur akuntansi. Mungkin ada persyaratan audit yang juga harus dipatuhi.

Keterbatasan hardware: Perangkat lunak mungkin harus beroperasi pada beberapa hardware yang telah ada atau yang telah ditentukan, sehingga memaksakan pembatasan pada desain. Keterbatasan Hardware dapat mencakup jenis mesin yang akan digunakan, sistem operasi yang tersedia pada sistem, bahasa yang didukung, and batasan pada primary dan penyimpanan sekunder. Keandalan dan Toleransi Kegagalan: persyaratan toleransi kegagalan dapat menjadi kendala utama tentang bagaimana sistem harus dirancang, karena mereka membuat sistem yang lebih kompleks dan mahal. persyaratan Pemulihan sering merupakan bagian yang tidak terpisahkan di sini, rincian sistem apa yang harus dilakukan jika terjadi beberapa kegagalan untuk memastikan sistem dapat berjalan kembali dengan baik.

Keamanan: Persyaratan Keamanan menjadi semakin penting. Pembatasan penggunaan perintah tertentu, mengontrol akses ke data, menyediakan jenis different dari persyaratan akses untuk setiap orang, memerlukan penggunaan password and teknik kriptografi, dan memelihara log dari activities dalam sistem. Pengguna juga mungkin membutuhkan penilaian yang tepat dari ancaman keamanan, teknik pemrograman yang benar, dan penggunaan alat untuk mendeteksi kekurangan seperti buffer overflow.

3.4 Persyaratan Fungsional dengan Studi Kasus Persyaratan Fungsional sering merupakan inti dokumen persyaratan. Pendekatan tradisional untuk menentukan fungsi masing-masing adalah untuk menentukan fungsi bahwa sistem harus menyediakan fungsi-fungsi tersebut. Contoh kasus dapat digunakan untuk menjelaskan proses bisnis yang lebih besar, atau hanya bisa menggambarkan perilaku dari sistem perangkat lunak.

Ringkasan / Kesimpulan : Tujuan utama dari proses persyaratan adalah untuk menghasilkan spesifikasi kebutuhan perangkat lunak (SRS) yang menangkap secara akurat kebutuhan klien dan yang membentuk dasar dari pengembangan perangkat lunak dan validasi.

Ada tiga aktivitas dasar dalam proses persyaratan : analisis masalah, spesifikasi, dan validasi. Tujuan analisis adalah untuk memahami aspek-aspek yang berbeda dari masalah, konteksnya, dan bagaimana hal itu cocok dalam organisasi klien. Dalam spesifikasi persyaratan yang ditetapkan masalah mengerti atau tertulis, menghasilkan SRS. Persyaratan validasi dilakukan untuk memastikan bahwa persyaratan yang ditentukan pada SRS memang apa yang diinginkan.

kunci karakteristik yang diinginkan dari SRS adalah: ketepatan, kelengkapan, konsistensi, unambiguousness, Pemastian, dan peringkat untuk penting. SRS yang baik harus menentukan semua fungsi software perlu dukungan, persyaratan kinerja sistem, kendala desain yang ada, dan semua antarmuka eksternal.

menggunakan Kasus pendekatan populer untuk menentukan kebutuhan fungsional. Setiap use case menentukan interaksi sistem dengan aktor utama, yang memulai use case untuk mencapai beberapa tujuan.

Sebuah use case memiliki prasyarat, skenario normal, dan juga banyak skenario yang luar biasa, sehingga memberikan perilaku yang lengkap dari sistem.  Untuk mengembangkan penggunaan kasus, para aktor , tujuan , kondisi kegagalan harus diidentifikasi, dan akhirnya penanganan kegagalan harus ditetapkan.

Dengan data flow diagram, sistem dianalisis dari sudut pandang bagaimana data mengalir melalui sistem. Sebuah DFD terdiri dari proses dan data mengalir melalui proses.