Ringkasan dokumen tersebut adalah: 1. Requirements engineering merupakan fase awal dalam proses pengembangan perangkat lunak dimana kebutuhan pengguna dikumpulkan dan ditetapkan. 2. Terdapat beberapa tahapan dalam requirements engineering seperti elicitation, specification, validation, dan pelacakan perubahan kebutuhan. 3. Kebutuhan tersebut kemudian didokumentasikan untuk memastikan konsistensi dan kelengkapan spesifikasi kebutuhan.

1. REQUIREMENT
ENGINEERING
Febryci Legirian 1211044
Bangkit Kristianus P. 1211048
Gerry Martinus 1211010
M. Fadhil Fadlan 1211054

2. Requirements Engineering
Berdasarkan standart IEEE 1220-1998 yang merupakan
standart aplikasi dan manajemen dari proses
engineering sistem adalah:
”Statement that identifies a product or process
operational, functional, or design characteristic or
constraint, which is unambiguous, teastable or measurable, and
necessary for product or process acceptability (by consumers or
internal quality assurance guidelines)”
"Pernyataan yang mengidentifikasi produk atau proses
operasional, fungsional, atau karakteristik desain atau
kendala untuk memperjelas dan memperkirakan apa
saja yang diperlukan untuk sebuah produk atau proses
penerimaan (oleh konsumen atau pedoman
penjaminan mutu internal)"

3. Requirements Engineering
menurut Pamela Zave dalam bukunya yang berjudul
Classification of Research Efforts in Requirements
Engineering, definisi Requiement Engineering adalah
cabang dari software engineering yang mengurusi masalah
yang berhubungan dengan: tujuan (dunia
nyata), fungsi, dan batasan-batasan pada sistem
software. Termasuk hubungan faktor-faktor tersebut
dalam menetapkan spesifikasi yang tepat dari suatu
software, proses evolusinya baik berhubungan dengan
masalah waktu maupun dengan software lain (dalam
satu keluarga).

4. Requirements Engineering
O Requirements engineering merupakan fase terdepan
dari proses rekayasa perangkat lunak (software
engineering), dimana software requirements
(kebutuhan) dari user (pengguna) dan customer
(pelanggan) dikumpulkan, dipahami dan ditetapkan.
Fase ini sangat penting, sebagaimana disepakati oleh
para pakar software engineering karena Fakta
membuktikan bahwa kebanyakan kegagalan
pengembangan software disebabkan karena adaya
ketidakkonsistenan (inconsistent), ketidaklengkapan
(incomplete), maupun ketidakbenaran (incorrect) dari
requirements specification (spesifikasi kebutuhan).

5. Requirement Engineering dalam V model
Requirement
Engineering

6. Tiga Dimensi Requirements Engineering

7. Requirement Elicitation
O Requirement Elicitation adalah proses mengumpulkan
dan memahami requirements dari user.
O Permasalahan yang muncul adalah perbedaan disiplin
ilmu yang dimiliki oleh pengembang software dengan
pihak customer.
O Customer biasanya lebih tahu tentang proses bisnis
atau domein dari software yang ingin dikembangkan.
O Sedangkan pengembang yang mempunyai tugas salah
satunya adalah requirement analyst terkadang buta
sama sekali terhadap domain atau proses bisnis
tersebut.

8. Requirement Specification
O Requirements Specification adalah sebuah tahap
pendokumentasian requieremnt elicitation.
O Dokumen ini berisi tentang fitur dan fungsi yang
diinginkan oleh customer.
O IEEE mengeluarkan standard untuk dokumen spesifikasi
requirements yang terkenal dengan nama IEEE
Recommended Practice for Software Requirements
Specifications [IEEE-830].
O Dokumen spesifikasi requirements bisa berisi functional
requirements, performance requirements, external
interface requirements, design constraints, maupun
quality requirements.

9. Gambar Contoh Form Requirement Catalogue
Std. IEEE

10. Requirement Validation and Verifications
O Requirement Validation adalah proses untuk
memastikan bahwa requirements yang benar sudah
ditulis.
O Verification (verifikasi), yaitu proses untuk memastikan
bahwa requirements sudah ditulis dengan benar.
O Proses validasi dan verifikasi ini melibatkan customer
(user) sebagai pihak yang menilai dan memberi
feedback berhubungan dengan requirements.

11. Kegiatan Tahapan Requirement Engineering
1. Vision Statement
2. Requirements Slicitation and Prioritization
3. Pengetahuan Akuisisi dan Pengelolaan
4. Studi Kelayakan atau Analisis Risiko
5. Kebutuhan fungsional dan non-fungsional
6. Keselamatan dan Kebutuhan keamanan
7. Dokumentasi Kebutuhan
8. Penerimaan, Validasi dan Persetujuan Kebutuhan
9. Pelacakan Kebutuhan dan Perubahan kendali

12. Vision Statement
O Visi dari sistem yang akan dibangun merupakan hal baik
untuk memulai proses kebutuhan.
O Visi dituangkan dalam bentuk dokumen yang
menguraikan keseluruhan tujuan yang harus dicapai
dan disetujui oleh stakeholders, terutama di tingkat
manajemen.
O Jika dalam proses ternyata visi tidak dapat
dicapai, pernyataan visi harus direvisi dan dibahas
kembali.

13. Requirements Slicitation and Prioritization
O Kebutuhan harus dikumpulkan dari sumber yang dapat
berkontribusi.
O Kontribusi terutama dari calon pelanggan dan
pengguna.

14. Pengetahuan Akuisisi dan Pengelolaan
O Customer adalah expert pada domain yang softwarenya
ingin dikembangkan (domain specialist), dilain pihak
sang pengembang (requirements analyst) adakalanya
sama sekali buta terhadap knowledge domain
tersebut, meskipun tentu memahami dengan benar
bagaimana sebuah software harus dikembangkan.
O biasa dimodelkan menjadi beberapa teknik dan
metodologi diantaranya adalah
interviewing, brainstorming, prototyping, use
case, dsb.
Studi Kelayakan atau Analisis Risiko
O Untuk sistem yang lebih besar, studi kelayakan perlu
dilakukan sebelum kebutuhan secara resmi diterima.

15. Kebutuhan fungsional dan non-fungsional
O Kebutuhan fungsional
• Adalah suatu kebutuhan yang menyatakan prilaku yang
harus ada pada sistem. Sebagai contoh jika seorang
pengusaha membeli mobil untuk membawa barang dari
gudang ke toko, maka kebutuhan fungsional dari mobil
tersebut adalah mobil harus dapat membawa barang
dari gudang ke toko.
O Kebutuhan non fungsional
• Sederhananya adalah batasan yang harus ada pada
sistem dan bagaimana dalam membentuk sistem
tersebut.

16. Keselamatan dan Kebutuhan keamanan
O Bentuk kebutuhan non-fungsional menyangkut
keselamatan dan keamanan sistem.
O Resiko keselamatan dapat menimbulkan bahaya untuk
pengguna individu, kelompok, atau masyarakat luas.
O Keselamatan adalah penting, terutama jika komputer
mengendalikan peralatan fisik atau pabrik, seperti rem
mobil, pesawat, atau stasiun tenaga nuklir.
O Keamanan menjadi isu penting jika data yang
disimpan, data harus dilindungi terhadap
penyalahgunaan, serta terhadap serangan berbahaya
oleh pesaing.

17. Dokumentasi Kebutuhan
O Setelah kebutuhan terkumpul dan dianalisa, selanjutnya
didokumentasikan dengan jelas dan baik dan tidak
ambigu.
O Penulisan dokumentasi kebutuhan merupakan aspek
yang “critical” sehingga memungkinkan suatu iterasi
yang melibatkan seluruh „stakesholders‟ sangatlah
mungkin terjadi.

18. Penerimaan, Validasi dan Persetujuan
Kebutuhan
O Keberhasilan setiap proyek pembangunan terutama
tergantung pada penerimaan dari produk akhir yang
diinginkan oleh pengguna. User harus menerima
kebutuhan, yakni mempertimbangkan kebutuhan
sebagai milik mereka.
O Setelah didapat suatu kebutuhan yang teranalisa maka
team rekayasa kebutuhan dan para stakeholdes
memvalidasi kembali dan meperbaiki apa yang menjadi
kekurangan.
O Meliputi proses identifikasi, menyakinkan
kembali, menanggapi dan memperbaiki masalah dari
requirements, dan menyatakan bahwa requirement telah
dapat diterima.

19. Pelacakan Kebutuhan dan Perubahan kendali
O Untuk sistem yang besar, perlu dipastikan bahwa tidak
ada kebutuhan dokumentasi yang terlupakan.
O Kebutuhan dapat berubah, selama kehidupan sebuah
proyek, baik sebelum atau setelah pengiriman.
O Oleh karena itu, diperlukan untuk membuat perubahan
kendali prosedur guna kebutuhan.