Your SlideShare is downloading. ×
0
Rekayasa Kebutuhan Perangkat Lunak
Sherly Christina, S.Kom., M.Kom
Materi
• Pengertian Rekayasa Kebutuhan PL
• Mengapa perlu Rekayasa Kebutuhan PL
• Stakeholder
• Tipe Kebutuhan Perangkat L...
Pengertian
• Requirements are a specification of what
should be implemented. (Sommerville and
Sawyer, 1997)
Pengertian
• Investigating and describing the problem
domain and requirements and designing and
documenting the characteri...
Pengertian
• Investigasi dan identifikasi
• Komunikasi dan dokumentasi
– Atribut/Properti/Karakteristik, Kapabilitas,
Kual...
Mengapa perlu Rekayasa Kebutuhan PL
Stakeholder
• Stakeholder adalah setiap pihak yang memiliki
kepentingan terhadap sesuatu.
• Sesuatu dalam konteks perangka...
Permasalahan Dalam Rekayasa
Kebutuhan Perangkat Lunak
• Stakeholder sering tidak mengetahui apa yang
diinginkan dan mengun...
Permasalahan Dalam Rekayasa
Kebutuhan Perangkat Lunak
Permasalahan Dalam Rekayasa
Kebutuhan Perangkat Lunak
Tipe Kebutuhan
Kebutuhan dapat dibedakan menjadi:
• Kebutuhan fungsional, yang mendeskripsikan
layanan‐layanan atau fungsi...
Tingkatan dalam Kebutuhan
Kebutuhan Bisnis
• Tujuan tingkat tinggi dari organisasi
• Biasanya berasal dari penyandang dana atau
pemilik sistem
• Men...
Kebutuhan Pengguna
• Goal atau tugas pengguna yang harus dapat
dilaksanakan menggunakan produk
bersangkutan.
–Contoh:FRS‐O...
Kebutuhan Fungsional
• Fungsionalitas perangkat lunak
• Kebutuhan perilaku
• Gunakan kata “akan” (shall)
–Contoh:FRS‐Onlin...
Kebutuhan Sistem
• Kebutuhan tingkat atas dari sebuah sistem
yang terdiri dari sub sistem ganda
• Sistem terdiri dari: : H...
Aturan Bisnis/Constraint
• Termasuk:
– Corporate policies
– Government regulations
– Industry standards
– Accounting pract...
Atribut Kualitas
• Termasuk goal dan deskripsi dari kinerja
Contoh:
– Usability: “The system is equipped with user manual....
Tujuan Dokumen Spesifikasi
• Menyediakan umpan balik kepada konsumen.
• Memecah permasalahan ke dalam
komponen‐komponen ya...
Outline SKPL-IEEE 830-1998
Studi Kasus
• Website Perpustakaan
• Game Belajar Berhitung
Buat komponen SKPL berikut:
1. Deskripsi Umum produk
2. Fungsi...
Upcoming SlideShare
Loading in...5
×

Rekayasa Kebutuhan Perangkat Lunak

2,341

Published on

Rekayasa Kebutuhan Perangkat Lunak

Published in: Engineering
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,341
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
114
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Rekayasa Kebutuhan Perangkat Lunak"

  1. 1. Rekayasa Kebutuhan Perangkat Lunak Sherly Christina, S.Kom., M.Kom
  2. 2. Materi • Pengertian Rekayasa Kebutuhan PL • Mengapa perlu Rekayasa Kebutuhan PL • Stakeholder • Tipe Kebutuhan Perangkat Lunak • Outline SKPL-IEEE 830-1998 • Studi Kasus
  3. 3. Pengertian • Requirements are a specification of what should be implemented. (Sommerville and Sawyer, 1997)
  4. 4. Pengertian • Investigating and describing the problem domain and requirements and designing and documenting the characteristics for a solution system that will meet those requirements (Ian K. Bray, An Introduction to Requirements Engineering, 2002)
  5. 5. Pengertian • Investigasi dan identifikasi • Komunikasi dan dokumentasi – Atribut/Properti/Karakteristik, Kapabilitas, Kualitas, dan Batasan‐batasan yang Penting. – Agar memiliki nilai dan kegunaan bagi pengguna (user)
  6. 6. Mengapa perlu Rekayasa Kebutuhan PL
  7. 7. Stakeholder • Stakeholder adalah setiap pihak yang memiliki kepentingan terhadap sesuatu. • Sesuatu dalam konteks perangkat lunak adalah proyek pengembangan perangkat lunak itu sendiri –Yang termasuk stakeholder : Pelanggan, Regulator, Penyelia, Pengembang
  8. 8. Permasalahan Dalam Rekayasa Kebutuhan Perangkat Lunak • Stakeholder sering tidak mengetahui apa yang diinginkan dan mengungkapkan keinginannya dalam kalimat yang umum. • Stakeholder mengungkapkan permintaan dalam istilah bidang pekerjaannya, sehingga perekayasa kebutuhan yang tidak memiliki pengalaman di bidang kerja pemesan harus memahami permintaan tersebut. • Beberapa stakeholder memiliki permintaan yang berbeda‐beda yang dinyatakan dalam cara yang berbeda pula. • Faktor politik dapat mempengaruhi kebutuhan sistem. • Lingkungan bisnis dan ekonomi bersifat dinamis.
  9. 9. Permasalahan Dalam Rekayasa Kebutuhan Perangkat Lunak
  10. 10. Permasalahan Dalam Rekayasa Kebutuhan Perangkat Lunak
  11. 11. Tipe Kebutuhan Kebutuhan dapat dibedakan menjadi: • Kebutuhan fungsional, yang mendeskripsikan layanan‐layanan atau fungsi‐fungsi dari sistem • Kebutuhan non‐fungsional, yang merupakan batasan‐batasan pada sistem atau pada proses pengembangan sistem
  12. 12. Tingkatan dalam Kebutuhan
  13. 13. Kebutuhan Bisnis • Tujuan tingkat tinggi dari organisasi • Biasanya berasal dari penyandang dana atau pemilik sistem • Mendeskripsikan Mengapa organisasi menginginkan pengimplementasian sistem bersangkutan. – Contoh:Universitas: Meningkatkan efisiensi selama proses registrasi kuliah. – Perusahaan: Mengurangi biaya tak perlu, memonitor kinerja setiap waktu.
  14. 14. Kebutuhan Pengguna • Goal atau tugas pengguna yang harus dapat dilaksanakan menggunakan produk bersangkutan. –Contoh:FRS‐Online: memilih mata kuliah, mengajukan persetujuan, menampilkan latar belakang mahasiswa. – Online Ticketing: memesan tiket, mengecek jadwal, memesan tempat duduk.
  15. 15. Kebutuhan Fungsional • Fungsionalitas perangkat lunak • Kebutuhan perilaku • Gunakan kata “akan” (shall) –Contoh:FRS‐Online: “The system shall view a confirmation to the student.” – Online Ticketing: “The system shall provide a link to download an softcopy ticket.”
  16. 16. Kebutuhan Sistem • Kebutuhan tingkat atas dari sebuah sistem yang terdiri dari sub sistem ganda • Sistem terdiri dari: : Hardware + Software + Brainware
  17. 17. Aturan Bisnis/Constraint • Termasuk: – Corporate policies – Government regulations – Industry standards – Accounting practices – Computational algorithm • Ada di luar sistem • Fungsi:Membatasi siapa dan bagaimana melakukan suatu use cases tertentu • Mendikte fungsionalitas yang harus dimiliki suatu sistem agar comply dengan aturan‐aturan yang sudah berlaku • Gunakan sebagai atribut kualitas. – Contohs:Sistem perbankan: Semua kartu kredit harus menggunakan smart card.” – SIAK: Suatu kartu ID harus sesuai dengan KepMen No. 80/2005.”
  18. 18. Atribut Kualitas • Termasuk goal dan deskripsi dari kinerja Contoh: – Usability: “The system is equipped with user manual.” – Portability: “The system shall work in Microsoft‐OSs and Unix‐OS.” – Integrity: “The system shall restrict access for un‐authorized user.” – Efficiency: “The system shall work with maximum 200VA/hour.” – Robustness: “The system shall withstand 5.1 atmoshpere pressure.”
  19. 19. Tujuan Dokumen Spesifikasi • Menyediakan umpan balik kepada konsumen. • Memecah permasalahan ke dalam komponen‐komponen yang lebih kecil. • Merupakan masukan untuk tahap spesifikasi rancangan. • Bisa melakukan pengecekan validasi produk.
  20. 20. Outline SKPL-IEEE 830-1998
  21. 21. Studi Kasus • Website Perpustakaan • Game Belajar Berhitung Buat komponen SKPL berikut: 1. Deskripsi Umum produk 2. Fungsi Produk 3. Karakteristik Pengguna
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×