Rekayasa Perangkat Lunak

(1)

RIZKY MAULIDYA AFIFA, S.KOM., M.KOM

POLITEKNIK NEGERI MEDAN

(2)

REQUIREMENT

REQUIREMENT

Suatu kondisi atau kemampuan yang dibutuhkan oleh seorang user untuk menyelesaikan suatu permasalahan atau mencapai sebuah tujuan.

Sebuah spesifikasi kebutuhan adalah bagaimana tujuan harus sesuai dengan sistem yang diusulkan

Deskripsi bagaimana sistem harus berlaku, properti atau atribut sistem, dan karakteristik dan kualitas sistem sehingga dapat memberi nilai atau berguna bagi penggunanya

(3)

REQUIREMENT ENGINEERING

❖ Fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan

❖ Requirement Engineering berkaitan dengan menafsirkan dan memahami tujuan, kebutuhan, dan keyakinan dari pihak yang berkepentingan

❖ Kebanyakan kegagalan pengembangan software disebabkan karena adanya : 1. Ketidakkonsistenan (inconsistent)

2. Ketidaklengkapan (incomplete)

3. Ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan)

❖ Prinsip – prinsip requirement :

1. Clear dan Precise → Kebutuhan harus ditulis dengan jelas dan tanpa ambiguitas

2. Verifiable → Kebutuhan harus dapat diuji untuk memastikan bahwa system memenuhi spesifikasi 3. Consistent → Kebutuhan harus tidak bertentangan satu sama lain

4. Complete → Semua kebutuhan yang relevan harus dicakup

5. Prioritized → Kebutuhan harus diurutkan berdasarkan tingkat kepentingannya

6. Feasible → Kebutuhan harus realistis dan dapat dicapai dalam batasan yang ada

(4)

KENAPA

REQUIREMENT ENGINEERING DIBUTUHKAN ?

(5)

❖ Requirements yang lemah/ tidak lengkap adalah sumber utama dari kegagalan (Standish95)

8000 projects, 350 US companies: 1/3 dari projek tidak pernah selesai dan 50% berhasil hanya Sebagian

❖ Banyaknya masalah yang dirasakan terkait dengan spesifikasi kebutuhan (>50%) – (ESI96) 3800 organisasi di 17 negara eropa

❖ Kebutuhan yang tidak mencukupi, tidak konsisten, tidak lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut (Bell&Tayer76)

❖ Keterlambatan koreksi dari kesalahan meningkatkan biaya sampai 200 kali lebih banyak selama proses requirement engineering (Boehm81)

❖ Jika customer tidak senang dengan perangkat lunak yang dibangun maka software developer membangun perangkat lunak yang salah

(6)

CONTOH USER DAN SYSTEM REQUIREMENT

❖ User Requirement

Pernyataan dalam bentuk bahasa natural ditambah diagram dari layanan sistem dan batasannya, dibuat untuk customer

❖ System Requirement

Dokumen terstruktur yang mengatur detail deskripsi dari layanan system dan kendala operasional, mendefinisikan apa yang harus dilakukan. Dibuat sebagai kontrak antara customer dan software developer

❖ Software Spesification

Deskripsi perangkat lunak yang detail yang menyajikan informasi untuk perancangan atau implementasi sistem. Dibuat untuk software developer.

(7)

REQUIREMENT

❖ User Requirement

Fitur yang harus dimiliki system

Contoh : Kasir menginputkan jualan

Kasir mencetak laporan penjualan harian

❖ System Requirement

Kemampuan yang dimiliki system untuk menyediakan fitur yang dibutuhkan user Contoh : Sistem mampu menyimpan data penjualan yang diinputkan user

Sistem mampu menampilkan data penjualan harian, mingguan, dan periodic sesuai permintaan user

Sistem dapat mencetak laporan penjualan harian

(8)

KATEGORI KEBUTUHAN

❖ Kebutuhan Fungsional

Menunjukkan What the system should do.

Menunjukkan fasilitas apa yang dibutuhkan serta aktivitas apa saja yang terjadi dalam system.

Mencakup bagaimana sistem harus bereaksi pada input tertentu dan bagaimana perilaku sistem pada situasi tertentu

Kebutuhan fungsional mencakup:

* Fungsi deskripsi kebutuhan

* Laporan baik hardcopy maupun softcopy * Updating dan query online

* Penyimpanan data, pencarian kembali dan transfer data Contoh : Dalam system informasi akademik

Mahasiswa dapat melakukan input krs

(9)

KATEGORI KEBUTUHAN

❖ Kebutuhan Non Fungsional

Kebutuhan yang menitikberatkan pada properti prilaku yang dimiliki oleh system Kebutuhan Non Fungsional terdiri dari 4 :

1. Usability → kebutuhan non fungsional terkait dengan kemudahan penggunaan sistem atau perangkat lunak oleh user.

2. Portability → kemudahan dalam pengaksesan sistem khususnya terkait dengan faktor waktu dan Lokasi pengaksesan, serta perangkat atau teknologi yang digunakan untuk

mengakses

3. Reliability → kebutuhan terkait kehandalan sistem atau perangkat lunak termasuk juga faktor keamanan security) sistem.

4. Supportability → kebutuhan terkait dengan dukungan dalam penggunaan sistem atau perangkat lunak

Contoh : Website harus easy to access, easy to use, easy to understand dan menjamin keamanan data member dari orang yang tidak bertanggungjawab

(10)

CONTOH KASUS

Proyek :

Sistem Manajemen Akademik Universitas Kebutuhan Fungsional :

1. Pendaftaran Mahasiswa Baru

Mahasiswa harus dapat mendaftar secara online melalui portal universitas.

Sistem harus memvalidasi data yang dimasukkan dan menyimpan informasi mahasiswa baru.

2. Pengelolaan Kelas

Dosen harus dapat membuat dan mengelola kelas, termasuk jadwal dan materi pengajaran.

Mahasiswa harus dapat melihat dan mendaftar kelas yang ditawarkan.

3. Pengisian KRS

Mahasiswa harus dapat mengisi dan mengubah KRS secara online.

Sistem harus memberikan notifikasi jika ada konflik jadwal.

4. Pengelolaan Nilai

Dosen harus dapat memasukkan dan memperbarui nilai mahasiswa.

Mahasiswa harus dapat melihat nilai mereka secara real-time.

(11)

CONTOH KASUS

Proyek :

Sistem Manajemen Akademik Universitas Kebutuhan Non Fungsional :

1. Kinerja

Sistem harus mampu menangani 5000 pengguna secara bersamaan tanpa penurunan kinerja.

Waktu respon untuk permintaan harus kurang dari 3 detik 2. Keamanan

Sistem harus melindungi data pribadi mahasiswa dan dosen dengan enkripsi.

Autentikasi harus menggunakan dua faktor untuk akses ke portal akademik.

3. Usability (Keterpakaian)

Antarmuka pengguna harus mudah digunakan oleh mahasiswa dan dosen.

Sistem harus menyediakan panduan dan bantuan online.

4. Ketersediaan

Sistem harus tersedia 99,5% selama tahun ajaran, dengan pemeliharaan terjadwal di luar jam kuliah

(12)

Problems in Requirement

Engineering

(13)

(14)

PROSES – PROSES REQUIREMENT ENGINEERING

1. Penggalian dan analisis kebutuhan (software requirement elicitation and analysis) 2. Spesifikasi kebutuhan (software requirement specification)

3. Validasi & verifikasi kebutuhan (software requirement validation and verification) 4. Manajemen kebutuhan (software requirement management)

(15)

PROSES – PROSES REQUIREMENT ENGINEERING

Elisitasi dan Analisis

❖ Developer harus memahami domain permasalahan

❖ Developer dan stakeholder menggali domain aplikasi, layanan-layanan sistem yang harus disediakan, unjuk kerja sistem yang diperlukan, batasan-batasan perangkat keras dan sejenisnya

❖ Fokus pada APA (WHAT) dan BUKAN bagaimana (HOW)

❖ Komunikasi yang baik dengan stakeholder adalah faktor penting dalam RE

(16)

PROSES – PROSES REQUIREMENT ENGINEERING

Inception

❖ Dalam tahapan ini pengembang menanyakan pertanyaan yang berkaitan dengan : 1. Pemahaman dasar tentang domain masalah

2. Pengguna yang menginginkan solusi 3. Sifat solusi yang diinginkan

4. Tata cara komunikasi dan kolaborasi antara pengembang dan calon pengguna

❖ Tujuan dalam tahapan ini :

1. Mengidentifikasi stakeholder (persona)

2. Mengenali berbagai macam sudut pandang

3. Mengawali kolaborasi antara pengembang dan pengguna 4. Mengawali proses komunikasi

(17)

PROSES – PROSES REQUIREMENT ENGINEERING

Elicitation

❖ Tahap elisitasi termasuk tahap yang sulit dalam spesifikasi perangkat lunak

❖ Ada beberapa permasalahan yang ada pada tahapan elisitasi, yaitu : 1. Permasalahan terhadap cakupan system

2. Pemahaman masalah, apa yang diinginkan, domain permasalahan, bagaimana system digunakan, lingkungan system

3. Ketidakpastian, karena kebutuhan selalu berubah Elisitasi terdiri dari 2 (dua) kegiatan :

❖ Collaborative requirements gathering :

Meeting, brainstorming, observasi, kuesioner dll

❖ Quality function deployment

Validasi → Memastikan bahwa kebutuhan yang dikumpulkan akurat dan dapat dipahami Kategorisasi → Mengelompokkan kebutuhan berdasarkan jenis atau fungsinya (misalnya,

kebutuhan fungsional dan non-fungsional)

Prioritas → Menentukan mana kebutuhan yang paling penting dan harus dipenuhi terlebih dahulu

(18)

PROSES – PROSES REQUIREMENT ENGINEERING

Elaboration

➢ Informasi dari proses Inception dan Elicitation dianalisa (diperluas dan diperbaiki)

➢ Elaborasi fokus pada pembuatan model teknis tentang fungsi, fitur dan batasan-batasan system

➢ Analisis model meliputi : 1. Use case

2. Class dasar

3. Daur hidup object

➢ Pada tahap ini akan terbentuk gambaran tentang fungsi, informasi dan perilaku dari system

➢ Element berbasis scenario :

▪ Use Case dan Activity Diagram

➢ Element berbasis kelas :

▪ Class Diagram

➢ Element berbasis perilaku:

▪ State Transition Diagram

➢ Element berbasis aliran (Flow-oriented Elements) :

▪ Data Flow Diagram

(19)

PROSES – PROSES REQUIREMENT ENGINEERING

Negotiation

❖ Proses negosiasi dalam rangka meredam konflik antara pengguna dan pengembang dalam hal apa yang diinginkan oleh pengguna dan apa yang bisa dicapai oleh pengembang (dengan keterbatasan sumber daya)

❖ Perankingan daftar kebutuhan (prioritization) oleh stakeholder

❖ Resiko yang ada pada setiap kebutuhan diidentifikasi dan dianalisis

❖ Dengan proses iteratif, kebutuhan dihilangkan, digabung atau dimodifikasi sehingga stakeholder dapat mencapai kesepakatan Bersama

Langkah – Langkah Negosiasi Requirement : 1. Persiapan Sebelum Negosiasi

▪ Identifikasi Pemangku Kepentingan → Kenali semua pihak yang terlibat dan kepentingan mereka.

▪ Kumpulkan Data Kebutuhan → Siapkan dokumentasi kebutuhan yang jelas dan terperinci.

▪ Tentukan Tujuan → Definisikan apa yang ingin dicapai dalam negosiasi, termasuk kebutuhan yang harus dipenuhi dan batasan yang ada.

(20)

PROSES – PROSES REQUIREMENT ENGINEERING

2. Komunikasi yang efektif

▪ Dengarkan dengan Aktif → Berikan kesempatan bagi semua pihak untuk menyampaikan pandangan dan kebutuhan mereka.

▪ Jelaskan Kebutuhan Anda → Sampaikan alasan di balik kebutuhan yang diajukan dengan jelas dan logis.

3. Analisis dan Prioritaskan Kebutuhan

▪ Klasifikasikan Kebutuhan → Kategorikan kebutuhan menjadi wajib, bisa ditunda, atau dihilangkan

▪ Diskusikan Prioritas → Bicarakan prioritas setiap kebutuhan dan bagaimana mereka berkontribusi pada tujuan proyek.

4. Mencari Kompromi

▪ Tawarkan Alternatif → Jika ada kebutuhan yang sulit dipenuhi, tawarkan solusi alternatif atau kompromi yang masih memenuhi tujuan.

▪ Fokus pada Solusi Win-Win → Cari jalan tengah yang menguntungkan semua pihak untuk membangun hubungan yang baik.

(21)

PROSES – PROSES REQUIREMENT ENGINEERING

5. Dokumentasikan Kesepakatan

▪ Catat Hasil Negosiasi → Dokumentasikan semua kesepakatan dan perubahan yang disetujui

▪ Konfirmasi dengan Semua Pihak → Pastikan semua pemangku kepentingan menyetujui dan memahami hasil negosiasi

6. Dokumentasikan Kesepakatan

▪ Tindak Lanjut Kesepakatan → Pastikan bahwa kesepakatan dilaksanakan sesuai dengan rencana.

▪ Evaluasi dan Umpan Balik → Setelah implementasi, evaluasi apakah kebutuhan yang dinegosiasikan memenuhi harapan dan berikan umpan balik untuk perbaikan di masa depan 7. Bersikap Fleksibel

▪ Kesiapan untuk Beradaptasi → Terkadang, kebutuhan dapat berubah selama proses negosiasi. Bersikaplah fleksibel dan terbuka untuk perubahan yang diperlukan.

(22)

TEKNIK-TEKNIK ELISITASI (PENGUMPULAN) KEBUTUHAN

➢ Teknik Tradisional

• Wawancara

• Kuesioner

• Observasi

• Sampling

• Analisis Dokumen

➢ Teknik Elisitasi Berkelompok

• Brainstorming

• Teknik JAD (Join Application Design)

• Prototyping

➢ Scenario based methods → berdasarkan urutan pekerjaan

➢ Derivation from the existing system → studi banding dari beberapa sistem

(23)

CONTOH HASIL ELISITASI DAN ANALISIS

➢ Perangkat lunak harus mampu menyediakan sarana untuk menampilkan dan mengakses file- file

➢ Pengguna harus dapat mencari buku/dokumen/literatur di perpustakaan dengan memasukkan sebuah kata kunci.

➢ Sistem tidak boleh dioperasikan oleh pengguna yang tidak memiliki otoritas.

➢ Sistem harus menyediakan GUI sehingga dapat digunakan secara mudah oleh pengguna yang belum berpengalaman.

➢ Sistem harus bisa memanfaatkan database yang sudah ada.

➢ Sistem harus diimplementasikan dengan bahasa Java.

(24)

PROSES – PROSES REQUIREMENT ENGINEERING

❑ Specification

➢ Proses untuk menjelaskan kebutuhan Perangkat Lunak yang telah didefinisikan sebelumnya secara lebih detil, tepat, dan terukur yang akan menjadi dasar bagi perancangan dan implementasi

➢ Spesifikasi adalah proses final dalam Requirement Engineering yang menghasilkan dokumen SRS (Software Requirement Specification)

❑ Validation dan Verification

➢ Proses pengecekan untuk menjamin bahwa pernyataan kebutuhan yang telah didefinisikan dan dispesifikasikan adalah benar, akurat dan lengkap

➢ Sangat penting dilakukan karena kesalahan di dalam menentukan kebutuhan akan berdampak pada keseluruhan proses yang mengikutinya

➢ Teknik:

1. Review → Software Specification Review (SSR)

2. Prototyping → executable model of the system/software

(25)

PROSES – PROSES REQUIREMENT ENGINEERING

Validation

Do we make the right product?

Apakah kita membuat produk yang benar?

Verification

Do we make the product right?

Apakah kita membuat produk dengan

benar?

(26)

PROSES – PROSES REQUIREMENT ENGINEERING

❑ Validation dan Verification

➢ Proses validasi terhadap produk dari spesifikasi kebutuhan (SRS) dimana seluruh daftar kebutuhan diperiksa untuk dapat diyakinkan (valid dan verified)

1. Parameter validasi:

Validity: does the system provide the functions which best support the customer’s needs ?

Consistency: are there any requirements conflicts ?

Comprehensibility: are all functions required by the customer included ? 2. Parameter verifikasi:

Readability, Testability, Completeness, Identifiability, Ambiguity

➢ Pada umumnya dilakukan oleh stakeholder, bagaimana jika dilakukan oleh mesin (komputer)? Mungkinkah?

(27)

PROSES – PROSES REQUIREMENT ENGINEERING

❑ Requirement Management

➢ Aktivitas untuk melakukan pengendalian terhadap kebutuhan yang sedang maupun telah didefinisikan dan dispesifikasikan, meliputi:

1. Identifikasi: bagaimana setiap kebutuhan dapat diidentifikasi dengan mudah 2. Manajemen perubahan: bagaimana mekanisme untuk menangani perubahan

kebutuhan yang terjadi

3. Dokumentasi: SRS, IRS, ECP, PCR

4. Tracking: penelusuran informasi yang berhubungan dengan sebuah kebutuhan (sumber/asal, alokasi ke perancangan)

SRS: Software Requirement Specification, IRS: Interface Requirement Specification, ECP: Engineering Change Proposal, PCR: Program Change Request

(28)

CARA MELAKUKAN VALIDASI REQUIREMENT ENGINEERING

1. Review Kebutuhan

Melakukan tinjauan terhadap dokumen kebutuhan dengan tim proyek dan pemangku kepentingan.

Memastikan bahwa setiap kebutuhan terdokumentasi dengan jelas dan dapat dipahami.

2. Konsultasi dengan Pemangku Kepentingan

Berkomunikasi dengan pemangku kepentingan untuk mengonfirmasi bahwa kebutuhan yang diidentifikasi mencerminkan harapan dan kebutuhan mereka.

Mengadakan sesi wawancara atau diskusi kelompok untuk mendapatkan umpan balik.

3. Prototyping

Mengembangkan prototipe atau model fungsional dari sistem yang dapat digunakan untuk mendemonstrasikan dan menguji kebutuhan.

Mengumpulkan umpan balik dari pengguna tentang prototipe untuk mengidentifikasi kekurangan.

4. Analisis Keterkaitan

Memeriksa hubungan antara kebutuhan untuk memastikan tidak ada konflik dan redundansi.

Menggunakan diagram atau alat pemodelan untuk visualisasi keterkaitan.

(29)

CARA MELAKUKAN VALIDASI REQUIREMENT ENGINEERING

5. Pengujian Kebutuhan

Mengembangkan skenario pengujian untuk memverifikasi bahwa setiap kebutuhan dapat diuji.

Melakukan pengujian untuk memastikan bahwa sistem memenuhi semua kebutuhan yang telah ditentukan.

6. Dokumentasi yang Jelas

Memastikan bahwa semua kebutuhan terdokumentasi dengan baik dan mudah diakses oleh semua anggota tim.

Menggunakan format standar untuk mendokumentasikan kebutuhan, seperti User Stories atau Use Cases.

7. Revisi dan Pembaruan

Secara berkala melakukan revisi terhadap kebutuhan berdasarkan perubahan yang terjadi dalam proyek atau umpan balik dari pengguna.

Memastikan bahwa setiap perubahan didokumentasikan dan dikomunikasikan kepada semua pemangku kepentingan.

8. Persetujuan Formal

Mendapatkan persetujuan formal dari pemangku kepentingan utama atas kebutuhan yang telah divalidasi.

Menyimpan catatan persetujuan sebagai bagian dari dokumentasi proyek.

(30)

SOFTWARE REQUIREMENT SPESIFICATION (SRS)

➢ SRS → sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak

➢ SRS → mencantumkan deskripsi dengan lingkungannya, mencakup antarmuka untuk perangkat keras, perangkat lunak, komunikasi dan pemakai

➢ SRS terdiri dari banyak dokumentasi yang saling melengkapi 1. menguraikan definisi masalah

2. menguraikan masalah dengan tepat dengan cara yang tepat pula

➢ Objektif SRS

1. Persetujuan kerja dengan pelanggan

2. daftar kebutuhkan teknis yang harus dipenuhi oleh perangkat lunak

➢ Syarat pembentukan SRS 1. Mudah diidentifikasi

2. Diuraikan dengan jelas, simple, tidak ambigu

3. Bisa divalidasi dan bisa dites (test reliable, tes accessable) 4. Mampu untuk ditelusuri kembali (tracebility)

5. Bisa dibedaan antara bagian what (bagian spesifikasi) dan how (bagian yang menjelaskan what)

(31)

SOFTWARE REQUIREMENT SPESIFICATION (SRS)

➢ Hal – hal yang harus dihindari saat pembentukan SRS :

1. Over specification (penjelasan berlebih dan berulang-ulang sehingga menjadi tidak jelas 2. Tindakan unconcistency

3. Ambigu dalam kata atau kalimat

4. Menuliskan hal-hal yang tidak bisa dilakukan

➢ Ada 2 aspek yang harus bisa dilihat dalam dokumen SRS :

1. Fungsi → menjelaskan fungsi dari perangkat lunak (digunakan untuk apa, keperluan apa), sifat perangkat lunak dan datanya

2. Non Fungsi

1. Dependability (reliability, maintainability, security, integrity) 2. Perfomance

3. Constraint

(32)

SOFTWARE REQUIREMENT SPESIFICATION (SRS)

➢ Beberapa orang yang terlibat dalam pembuatan dokumen SRS :

1. Pemakai (user) → yang mengoperasikan atau menggunakan perangkat lunak 2. Client → orang atau Perusahaan yang mau membuat system (yang menentukan)

3. System analis / system engineer → yang melakukan kontak Teknik pertama degan client, bertugas menganalisis persoalan, menerima dan menulis requirement

4. Software engineer → yang bekerja setelah kebutuhkan perangkat lunak dibuat, bekerja sama dengan system engineer

5. Programmer → menerima spesifikasi perancangan perangkat lunak, membuat kode dalam bentuk modul, menguji dan memeriksa modul

6. Test Integration Group → Kumpulan orang yang melakukan tes dan mengintegrasikan modul 7. Maintenance group → memantau dan merawat perfomansi system perangkat lunak

8. Technical support → orang-orang yang mengelola (manage) perangkat lunak, termasuk konsultan atau orang yang mempunyai kepandaian lebih tinggi

9. Staff dan Clerical Work → bertugas mengetik, emmasukkan data dan membuat dokumen

(33)

CONTOH TEMPLATE DOKUMEN SRS

(34)

(35)

REFRENSI

❖ Pressman, R. S. (2014). Software Engineering: A Practitioner’s Approach (9th ed.). McGraw- Hill.

❖ Sommerville, I. (2011). Software Engineering. 9th edition. Addison-Wesley.

❖ Ian Sommerville. (2016). Requirements Engineering: Concepts and Techniques. 2nd edition.

Springer.

❖ Romi Satria Wahono, “Menyegarkan Kembali Pemahaman tentang Requirement Engineering”, http://romisatriawahono.net/2006/04/29/menyegarkan-kembali-pemahaman-tentang-

requirement-engineering/

❖ Siahaan, Daniel., 2012, “Analisa Kebutuhan Dalam Rekayasa Perangkat Lunak”, ANDI, Yogyakarta

(36)

TERIMA KASIH

[email protected] POLITEKNIK NEGERI MEDAN

0813 – 7520 - 9761