KELAS : TI-A
UTS RPL
1. Inkremental Development
Kami mengambil model pengembangan ini dikarenakan pembuatan atau
pengupdatetan, kami perlu rencana yaitu, apa saja fitur – fitur yang akan kami
rilis/luncurkan dan pengembangan ini dilakuakn secara bertahap yang mana
pengembangan ini bertujuan untuk menambahkan fungsional terhadap fitur – fitur
yang akan dikembangkan supaya lebih dapat berfungsi lebih baik dan tujuan
utamanya untuk mengelola resiko dengan mendefinisikan dan mengembangkan
sebagian kecil system pada satu waktu.
2.
Unambiguous
Persyaratan ini harus tidak ambigu sehingga tidak ada kebingungan di antara
semua orang (team). Persyaratan ini harus didokumentasikan dan harus dikirim
ke klien untuk ditinjau atau harus disajikan untuk menghilangakan celah dalam
pemahaman.
Complete
Semua kebutuhan-kebutuhan penting sudah tercakup yaiut (fungsionalitas,
performansi, atribut atau antar muka eksternal). Jika ada fitur yang telah
menguraikan kebutuhan eksternal perangkat lunak tersebut, maka fitur
tersebut harus diacu atau dijadikan dasar (bila ada fitur tambahan).
Skenario Fungsi
a) Nomor fungsi: P-01
Nama use-case: Login Deskripsi:
Pengisian Account Aktor : Costumers
Pre-kondisi: Memasukkan username dan password.
Pos-kondisi: Masuk ke menu aplikasi
Skenario:
1. Costumers memasukkan username dan password
2. Login dengan account Costumers tersebut
Consistent
Yang dimaksud ialah bagian dokumen yang mana seluruh dokumen yang telah
dikerjakan harus berhubungan satu sama lain karena jika sudah berbeda dari awal
maka dokumen tersebut dianggap tidak benar karena tidak terkait satu sama lain.
Contohnya :
Latar Belakang di dokumen 1 berbeda dengan dokumen 2.
Implementable
Setiap persyaratan harus dapat diimplementasikan, tidak boleh bersifat hipotetis
sehingga setelah disetujui dan ternyata tidak dapat diterapkan akan menimbulkan
konflik selama penerimaan dan penutupan kontrak
Veriafable
Persyaratan harus sedemikian rupa sehingga dapat diverifikasi setelah
implementasi atau bahkan pada tahap awal desian, jika tidak ada pemgembanga
dan penerimaan akan menjadi sulit dan dapat menyebabkan banyak masalah
kontrak semala pengembangan.
Validatable
Klien harus berada dalam posisi untuk memvalidasi secara obyektif semua yang
dia telah dieja untuk dikembangkan ditangkap dengan tepat jika tidak
subjektivitas dan ambiguitas berlaku dan menyebabkan penundaan selama
pengembangan dan pengiriman produk pekerjaan.
Modifiable
Semua yang dikatakan dan dilakukan, beberapa persyaratan cenderung berubah
selama masa pengembangan, karena semuanya mungkin tidak sepenuhnya dapat
dibekukan pada tahap awal dan beberapa mungkin berkembang kemudian, namun
persyarat ini tidak boleh sedemikian rupa sehingga berdampak besar pada
keseluruhan desain.
Understandable
Persyaratan ini harus mudah untuk dimengerti (tutur bahasa yang mudah
dimengerti) sehingga semua orang yang bersangkutan dapat berkomunikasi
dengan baik.
Testable
Semua yang telah dikembangkan harus di uji terlebih dahulu sehingga nanti jika
ada yang bermasalah akan segera di perbaiki dan aplikasi yang dibuat itu dapat
diterima oleh klien.
Traceable
Proses ini membuat analisis dampak dan manajemen perubahan sangat terkendali.
Property diatas harus dipenuhi sementara persyaratan dirinci dan upaya harus
dilakukan agar tidak ada celah antara harapan dan kiriman oleh klien, jika ini
terjadi kecepatan pengembang jauh lebih cepat, waktu pengiriman minimal dan
kualiatas perangkat lunak akhir akan lebih baik lagi.
3. Tahap ini yaitu tahap pemahaman pada desain dam analisis terhadap fitur-fitur yang
terdapat di dalam apliikasi yang sedang dikembangkan.
Analisis kebutuhan yaitu proses pengembangan kita terhadap aplikasi. Pengguna dalam
aplikasi tersebut agar dapat saling berinterkasi. Aplikasi sebagai perantara antar admin
dan constumers. Constumers dapat manfaat dan kebutuhan pada system yang telah
dibuat. Contohnya :
GPS
History
Menu – menu penampilan tertentu
Login / longout