Nama: Dyandra Paramitha Widyadhana

NRP: 05111940000119

Kelas: RK-D

Evaluasi Tengah Semester: Pegadaian Digital

Requirements Analysis (No. 1)

Kelas: RK-D

Kelompok: 

Andika Nugrahanto                 05111940000031

Dyandra Paramitha W.           051119400000119

 Nama: Dyandra Paramitha Widyadhana

NRP: 05111940000119

Kelas: RK-D

Deskripsi Aplikasi

Airbnb adalah sebuah marketplace online  yang memungkinkan pengguna untuk mendaftarkan atau menyewa properti atau akomodasi untuk digunakan dalam jangka pendek. Aplikasi Airbnb ini memungkinkan penyewa properti/akomodasi dan pengguna properti/akomodasi untuk berinteraksi dan melakukan transaksi penyewaan dengan mudah. 

Business Requirements

Kebutuhan bisnis dari Airbnb yaitu: 

1. Menyediakan platform untuk pemilik properti dan yang menyewa properti untuk melakukan transaksi dan penyewaan akomodasi dengan mudah, terarah, dan minimum risk. 

2. Menyediakan platform untuk pengguna aplikasi khususnya wisatawan dalam membeli layanan tur atau aktivitas-aktivitas lain. 

3. Mendapatkan profit sebagai perantara antara pemilik properti dan penyewa. 

Stakeholder Identification & User Requirements

1. Rental Hosts

Rental hosts adalah pemilik properti/akomodasi yang menyewakan properti mereka untuk dijadikan tempat lodging secara jangka pendek. Rental hosts dapat melakukan listing properti mereka pada aplikasi. 

User requirements: 

Experience Hosts adalah penyedia kegiatan-kegiatan pada aplikasi Airbnb. Penyedia kegiatan ini menawarkan aktivitas-aktivitas menarik kepada wisatawan yang dilakukan oleh mereka sendiri, seperti contoh tour guide. 

User requirements: 

1. Melakukan listing kegiatan yang ditawarkan untuk customer

2. Melihat dan mengatur jadwal booking yang telah dilakukan oleh customer

3. Melakukan komunikasi customer

4. Melakukan transaksi dengan customer

5. Mengatur jumlah tamu untuk kegiatan 

6. Melihat statistik dari penawaran kegiatan yang dilakukan

7. Melihat review-review yang dikirimkan oleh penyewa properti

8. Mendapatkan income/profit dari listing kegiatan yang telah dilakukan

3. Tourism Partners

Tourism partners adalah hosts yang juga menawarkan kegiatan yang bisa dilakukan akan tetapi merupakan jasa legal/resmi dari pemerintah maupun perusahaan dalam industri wisata yang besar. Tourism partners dapat bekerja sama dengan Airbnb untuk mempromosikan kegiatan-kegiatan yang lebih professional, resmi, dan juga besar kepada pengguna aplikasi Airbnb lainnya. 

User requirements:

1. Melakukan listing kegiatan yang ditawarkan

2. Melakukan komunikasi dengan pihak Airbnb untuk memasarkan kegiatan

3. Melakukan transaksi dengan customer

4. Melihat statistik dari penawaran kegiatam yang dilakukan

5. Mendapatkan profit dari listing kegiatan yang dilakukan

4. Guests/Penyewa/Pelaku Booking 

Guests/penyewa/pelaku booking adalah pengguna aplikasi yang melakukan penyewaan akomodasi atau melakukan booking kegiatan yang ditawarkan oleh Tourism Partners atau Experience Hosts. 

User requirements: 

1. Melihat listing akomodasi dan kegiatan yang ditawarkan pada aplikasi Airbnb

2. Mendapatkan listing yang paling sesuai dengan lokasi dan harga yang diinginkan

3. Melakukan komunikasi dengan hosts

4. Melakukan transaksi penyewaan/penjadwalan kegiatan dengan aman

5. Memberikan review kepada hosts

6. Melihat history sewa/jadwal kegiatan yang telah dilakukan

Nama: Dyandra Paramitha Widyadhana

NRP: 05111940000119

Kelas: RK-D

Pada tugas kali ini, perangkat lunak yang akan saya elisitasi adalah aplikasi perpustakaan digital. Aplikasi perpustakaan digital adalah sistem informasi perpustakaan yang dapat diakses oleh administrator dan juga pengunjung perpustakaan untuk mengakses buku secara online. Dengan adanya perpustakaan digital, masyarakat umum dapat mengakses bacaan dan referensi secara mudah, dengan harapan dapat meningkatkan tingkat literasi masyarakat dan minat untuk membaca kembali. 

Elisitasi kebutuhan adalah proses mengidentifikasi dan menemukan persyaratan dari berbagai sumber melalui wawancara, workshops, kelompok fokus, observasi, analisis dokumen dan mekanisme lainnya.

Pada proses elisitasi kebutuhan perangkat lunak, terdapat beberapa langkah yang harus dilakukan agar elisitasi berjalan dengan baik. Langkah-langkahnya terdiri atas: 

1. Mengidentifikasi stakeholder 

2. Mengidentifikasi kebutuhan-kebutuhan pengguna

3. Mengidentifikasi kebutuhan fungsional, non fungsional dan sistem 

Untuk melakukan elisitasi kebutuhan, terdapat beberapa metode yang dapat dilakukan yaitu melakukan interview, survey, observasi, joint application development, ataupun menganalisis dokumen.

Metode Elisitasi Kebutuhan

Pada tugas kali ini, saya menggunakan metode berupa interview dan observasi. Ada pula di bawah yaitu list pertanyaan yang dapat digunakan untuk melakukan elisitasi. List pertanyaan ini difokuskan untuk menggali proses bisnis, kebutuhan, dan juga ekspektasi yang dimiliki oleh stakeholder terhadap sistem. 

List Pertanyaan: 

1. Pertanyaan general seperti nama, dan job title

2. Apakah tanggung jawab yang harus dilakukan sesuai dengan pekerjaanmu?

3. Apakah terdapat hambatan yang menghalangi mengerjakan tanggung jawabmu?

4.  Apakah terdapat existing system sebelumnya atau tidak? 

5. Apabila terdapat existing system, apakah terdapat kendala dalam menggunakan existing system dan apakah menurut Anda yang harus diimprove? 

6. Masalah apa yang ingin diselesaikan dengan adanya perangkat lunak baru ini? 

7. Apa yang Anda sebagai pengguna butuhkan dengan adanya perangkat lunak baru ini? Apakah kebutuhan-kebutuhan yang dibutuhkan?

8. Fitur apa yang dibutuhkan untuk menunjang tanggung jawab anda dan jalannya perangkat lunak baru ini? 

Dari observasi yang dilakukan, maka terdapat beberapa stakeholder yaitu:

1. Pemilik perpustakaan

Pemilik perpustakaan bertanggung jawab atas kelancaran dari perpustakaan itu sendiri, dan dapat melihat laporan pengelolaan dari administrator. 

2. Administrator perpustakaan

Administrator perpustakaan bertanggung jawab untuk mengelola sistem secara penuh, yaitu mengelola informasi pengunjung, member dan data-data mengenai buku yang dimiliki di perpustakaan. 

3. Masyarakat umum

Masyarakat umum dapat melihat dan mengakses judul-judul yang dimiliki pada sistem informasi sebagai member. Masyarakat umum dapat terdiri atas pelajar dari segala kalangan, orang tua dari pelajar, organisasi-organisasi kesastraan, dll. 

4. Donatur Buku

Donatur buku adalah mereka yang mendukung jalannya perpustakaan dengan cara mendonasikan buku-buku kepada perpustakaan. Perpustakaan bertanggung jawab untuk memastikan buku dari donatur terdata dengan baik. 

5. Penerbit Buku

Perpustakaan digital dan penerbit buku bekerja sama untuk menghadirkan buku-buku fisik dan juga digital secara legal. 

6. Team developer

Team developer adalah stakeholder yang bertanggung jawab untuk mengembangkan perangkat lunak. Team developer perangkat lunak ini terdiri atas: 

• Project Manager
• Front End Developer
• Back End Developer
• System Analyst
• Quality Assurance
• UI/UX Designer 

Pada bagian elisitasi kebutuhan ini, team developer yang beranggung jawab yaitu system analyst dan Project Manager. 

Dari list pertanyaan tersebut, sebagai team developer, kita dapat menyimpulkan goals yang ingin didapatkan. Goals yang ingin didapatkan dari pembuatan perpustakaan digital ini yaitu untuk memudahkan pengelolaan data-data buku dan pengunjung oleh administrator dan memudahkan pengaksesan sumber buku oleh pengunjung/masyarakat umum.  

Mengidentifikasi Kebutuhan

Kebutuhan fungsional: 

1. Pengunjung dapat melakukan registrasi member 

2. Pengunjung dapat melihat katalog buku perpustakaan 

3. Pengunjung dapat mengakses buku pada perangkat lunak

4. Pengunjung dapat melakukan request peminjaman buku untuk diambil secara offline

5. Pengunjung dapat melakukan request penambahan katalog 

6. Pengunjung dapat menjadwalkan peminjaman perpustakaan untuk organisasinya

7. Administrator dapat mengelola data katalog buku

8. Administrator dapat melihat hasil request penambahan katalog 

Kebutuhan non fungsional: 

1. Operasional

1. Sistem harus terintegrasi dengan sistem informasi sebelumnya

2. Sistem harus dapat diakses dari browser manapun. 

3. Sistem mewajibkan user untuk melakukan login terlebih dahulu sebelum dapat mengakses penuh sistem. 

4. Sistem harus dapat diakses dari device manapun. 

2. Performance

1. Halaman website dapat diakses 24x7 jam tanpa perlu adanya admin yang menjalankan. 

3. Keamanan

1. Sistem harus terlindung dari virus dan bahaya lainnya.

2. Data member hanya dapat diakses oleh administrator. 

3. Konten yang ditampilkan menyesuaikan jenis akses ke perpustakaan.

4. Cultural

1. Sistem menggunakan Bahasa Indonesia.

Nama: Dyandra Paramitha Widyadhana

NRP: 05111940000119

Kelas: RK-D

Pada tugas kali ini, kami diminta untuk menonton documentary Downfall: A Case Against Boeing yang merupakan documentary yang menjelakan mengenai kecelakaan pesawat jatuh yang terjadi pada pesawat Lion Air JT610 dan Ethiopia ET-302. Yang mengakibatkan kecelakaan tersebut adalah Maneuvering Characteristics Augmentation System (MCAS) yaitu control system baru yang diimplementasikan oleh Boeing pada pesawat Boeing 737 Max mereka, yang dirahasiakan untuk mempercepat penggunaan pesawat.

Maneuvering Characteristics Augmentation System (MCAS) adalah sistem otomatis yang mengkompensasi gerakan pitch (dongakan hidung pesawat), untuk membantu pilot menurunkan hidung pesawat, saat angle of attack terlalu besar dalam terbang manual. Angle of attack yang terlalu besar dapat membuat hidung pesawat menjadi terlalu ke atas, dan berisiko membuat pesawat kehilangan daya angkat. MCAS bekerja dengan cara memutar horizontal stabilizer (sayap kecil di belakang), sehingga hidung pesawat menjadi turun. 

Identifikasi Requirements: 

Functional Requirements: 

- Dapat menurunkan hidung pesawat untuk mereduksi risiko stalling (Stalling adalah pengurangan gaya angkat yang dialami oleh pesawat terbang. Itu terjadi ketika Angle of Attack naik terlalu banyak)

- Dapat menerima data dari sensor Angle of Attack pada pesawat

- Dapat menggerakan horizontal stabilizer ke atas 

- Dapat teraktivasi secara otomatis apabila identifikasi angle of attack besar, flap (sirip tambahan di sayap) tidak menjulur keluar, dan berbelok terlalu tajam (miring). 

- Dapat melakukan deaktivasi saat dioverride oleh pilot dengan manual trim, atau apabila angle of attack mengecil

Non-Functional Requirements: 

- Reliability : Critical failure time dari MCAS harus sangat minim, dan operasi dari penggunaan MCAS harus stabil. 

- Usability: Pilot harus bisa memahami dan menavigasi sistem control MCAS dengan mudah, dan dapat melakukan prediksi terhadap cara penggunaan fitur apabila masih belum memahami secara penuh. 

- Availability : MCAS harus tersedia selama 24/7 selama pesawat sedang dalam pengoperasian, dan dapat teraktivasi secara otomatis apabila dibutuhkan. 

- Training & Documentation: Awak kapal terutama pilot yang akan mengoperasikan pesawat harus memiliki training seperti tutorials yang diajarkan kepada mereka untuk dapat menggunakan pesawat. 

- Policy and Regulatory: Control system MCAS harus sesuai dengan regulatory dari FAA (Federal Aviation Administration) 

Analisis Problema MCAS pada Kecelakaan Boeing ET 302 dan JT 610.

Dari film yang sudah ditonton, beberapa faktor yang menyebabkan terjadinya kegagalan pada sistem kontrol MCAS yaitu dikarenakan:

1. Dokumentasi dan training yang buruk. 

Salah satu alasan kenapa control system MCAS membuat pesawat jatuh yaitu dikarenakan tidak adanya dokumentasi dan training dari pihak Boeing untuk para kru pesawat, terutama kepada pilot. Dokumentasi dan training merupakan contoh dari non functional requirements yang seharusnya dipenuhi oleh Boeing dikarenakan sudah merupakan kewajiban dari Boeing untuk menjelaskan mengenai sebuah fitur baru kepada pilot sebelum lepas landas mengenai pesawat. 

2. Desain MCAS yang buruk

Salah satu kebutuhan fungsional dari sistem MCAS yaitu dapat melakukan aktivasi sistem secara otomatis apabila terdapat identifikasi kondisi-kondisi tertentu. 

Sensor angle-of-attack (AOA), seperti yang diketahui, mengirimkan data ke sistem perangkat lunak 737 Max yang mendorong hidung pesawat ke bawah jika mendeteksi stalling yang akan segera terjadi. Software tersebut, yang dipicu oleh false data dari sensor AOA, diyakini berperan dalam kecelakaan pesawat Lion Air dan Ethiopian Airlines, sehingga menyebabkan stalling. 

Desain yang terdapat pada pesawat, dimana seharusnya terdapat 2 AoA (Angle of Attack) sensor, MCAS hanya menggunakan satu, sehingga tidak ada switch otomatis ke sensor lainnya, sehingga MCAS terus bekerja dengan data sensor yang salah. Seharusnya sejak awal desain dari Boeing mengimplementasikan fail safe design pada kedua sensor tersebut. Hal ini agar MCAS menerima data dari kedua sensor untuk menghasilkan akurasi yang lebih tinggi dan meminimalisir adanya risiko kesalahan data dan false warning, seperti yang terjadi pada pesawat Lion Air JT610. Dengan menggunakan dua sensor, MCAS hanya akan aktif apabila keduanya menghasilkan data AoA yang sama.  

Selain itu, dimana seharusnya MCAS dapat mematikan dirinya sendiri apabila dioverride oleh pilot saat dilakukan manual trim, sistem MCAS sangat susah untuk dilakukan override dikarenakan teraktivasi secara otomatis berkali-kali, dan kru pesawat akhirnya kesulitan untuk mematikan MCAS yang berkontribusi kepada 2 kecelakaan yang terjadi pada tahun 2018 itu.  

Desain MCAS yang buruk seharusnya tidak terjadi apabila proses requirements engineering seperti elisitasi dan validasi dilakukan dengan benar, dikarenakan saat pembuatan sistem, engineer harus sudah memperhatikan beberapa scenario yang dapat muncul, dan juga sudah melakukan elisitasi pada kebutuhan sistem sendiri (seperti pesawat Max sebenarnya memiliki 2 AoA sensor, akan tetapi MCAS tidak menggunakan keduanya)

3. Testing 

Walaupun sudah bukan bagian dari requirements engineering sendiri, akan tetapi faktor lain yang menyebabkan MCAS gagal yaitu testing yang tidak dilakukan dengan benar. Seperti yang diberitahukan pada documentary, bahwa testing yang dilakukan pada pesawat Boeing 737 Max dilakukan dengan cepat dan dipenuhi dorongan dari managers untuk mempercepat proses analisis dan membatasi satefy testing. Selain itu, laporan yang Boeing berikan kepada FAA untuk divalidasi tidak menyantumkan beberapa kekurangan dari sistem yang telah dilaporkan oleh engineer. 

Selain itu, error yang dilaporkan oleh beberapa engineer yang bekerja pada desain MCAS kepada pihak atas diabaikan dan tidak ditindaklanjuti dikarenakan ingin perubahan yang minimal untuk mereduksi harga produksi. 

Referensi: 

https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Augmentation_System

https://www.researchgate.net/publication/343474935_Evaluation_of_MCAS_System 

Q&A: What led to Boeing’s 737 MAX crisis | The Seattle Times

What is the Boeing 737 Max Maneuvering Characteristics Augmentation System? - The Air Current

Boeing relied on single sensor for 737 Max that had been flagged 216 times to FAA - CNN

Tugas 2: Proses Rekayasa Kebutuhan

Pada tugas kali ini, SRS yang telah didapatkan merupakan salah satu deliverables atau output yang didapatkan dari proses rekayasa kebutuhan. Dari proses rekayasa kebutuhan tersebut, terdapat 5 inputan yang harus diperhatikan yaitu existing systems information, stakeholder needs, organisational standards, regulations, dan domain information.