Rekayasa Perangkat Lunak

Software Engineering (Basic)

+ SW Design
Presented by: HER
 Latar Belakang
• Apakah Costumer/Pelanggan Tau Apa yang mereka butuhkan?

• Apakah end User memiliki pemahaman yang cukup baik tentang fitur-
fitur dan fungsi-fungsi yang akan memberikan mereka keuntungan-
keuntungan berkaitan dengan Penggunaan Sistem/PL yang
dikembangkan?

• Jawabannya TIDAK

• Berikut ini Bukan merupakan Solusi Permasalahan yang selalu Benar,

Meski Demikian, Hal-Hal Berikut ini memberikan suatu Pendekatan yang
solid untuk menyelesaikan Permasalahan diatas
Roger Pressman
Mismatch
 Requirement Engineering
Bagian Paling berat pada Software Development adalah memutuskan
apa yang akan kita kembangkan
Fred Brooks
Segala sesuatunya akan segera menjadi jelas saat mereka melakukan pekerjaan
Pengembangan Software, bahwa para Penyandang dana Proyek dan orang-
orang yang berkepentingan akan dapat memahami kebutuhan mereka setelah
mereka memeriksa hasil dari pengembangan perangkat lunak pada iterasi-
iterasi awal, bahwa segala sesuatunya bisa saja berubah dengan cepat sehingga
upaya-upaya untuk memahami kebutuhan secara rinci merupakan sebuah hal
yang menghabiskan waktu, bahwa yang paling penting bagi mereka adalah
menghasilkan program-program yang berjalan dengan baik dan hal-hal lainnya
merupakan tambahan saja.

Ada Benarnya untuk Sistem yang kecil

 Requirement Engineering
Sejumlah Pekerjaan dan Teknik yang dapat dilakukan
untuk lebih memahami kebutuhan-kebutuhan disebut
dengan Requirement Engineering/Rekayasa Kebutuhan.
 Requirement Engineering
Requirement Engineering pada dasarnya menyediakan bagi kita

1. Mekanisme-mekanisme yang cocok untuk memahami apa yang para

pelanggan butuhkan,
2. Menyediakan bagi kita mekanisme-mekanisme yang cocok untuk
melakukan analisis kebutuhan,
3. Mekanisme-mekanisme untuk melakukan penilaian kelayakannya,
4. Mekanisme-mekanisme untuk menegosiasikan solusi atas
permasalahan-permasalahan yang memiliki alasan yang kuat,
5. Mekanisme-mekanisme untuk menspesifikasikan solusi-solusi
permasalahan sehingga tidak menimbulkan penafsiran ganda,
6. Mekanisme-mekanisme untuk validasi spesifikasi-spesifikasi kebutuhan,
7. Mekanisme-mekanisme yang cocok untuk mengelola kebutuhan-
kebutuhan saat ditransformasikan kedalam sebuah Sistem/Software
 Requirement Engineering
• Inception—Pertanyaan yang muncul adalah
– Pemahaman Dasar dari Permasalahan
– Pihak yang membutuhkan Solusi
– Sifat-Sifat dari Solusi yang diinginkan
– Efektivitas dari komunikasi awal dan kolaborasi antara Costumer dan
Developer
Saat ini Kebanyakan Proyek Software dimulai saat Kebutuhan Bisnis telah
teridentifikasi dengan baik, Saat pasar baru yang sifatnya potensial dikenali, dan
layanan-layanan baru ditemukan
• Elicitation—memperoleh kebutuhan dari semua Stakeholder
• Elaboration—membuat model analisis yang mengidentifikasi data,
fungsional dan perilaku/Behaviour dari Spesifikasi Kebutuhan
• Negotiation—Persetujuan pada Deliverable sistem yang realistis
untuk Developer dan Costumer
 Requirement Engineering
• Specification—can be any one (or more) of the following:
– A written document
– A set of models
– A formal mathematical
– A collection of user scenarios (use-cases)
– A prototype
• Validation—a review mechanism that looks for
– errors in content or interpretation
– areas where clarification may be required
– missing information
– inconsistencies (a major problem when large products or systems are
engineered)
– conflicting or unrealistic (unachievable) requirements.
• Requirements management
Sebuah Aktivitas yang akan membantu tim proyek Software untuk
mengidentifikasi, mengendalikan, dan melacak kebutuhan dan melacak juga
Perubahan kebutuhan setiap saat
 Inception
• Identify stakeholders
– “who else do you think I should talk to?”
• Recognize multiple points of view
• Work toward collaboration
• The first questions
– Who is behind the request for this work?
– Who will use the solution?
– What will be the economic benefit of a successful
solution
– Is there another source for the solution that you need?
 Eliciting Requirements
• Pertemuan-Pertemuan dipimpin dan diikuti oleh
Software Engineer maupun Stakeholder
• Aturan-Aturan untuk persiapan dan partisipasi
ditetapkan
• Agenda dibuat dengan bentuk yang cukup santai
sehingga aliran ide-ide bisa berjalan seacara bebas
• Seorang Fasilitator bisa ditunjuk untuk mengendalikan
pertemuan
• Mekanisme Pendefinisian (dapat berupa Kertas-Kertas,
Forum diskusi, Forum Maya, dll) dapat digunakan
 Conduc t FAST
m e e tings

Ma ke lis ts of
func tions , c la s s e s

Ma ke lis ts of
c ons tra ints , e tc .

form a l prioritiz a tion?

Elic it re q u ire m e n t s
ye s no

Us e QFD to inform a lly de fine a c tors

prioritiz e prioritiz e
re quire m e nts re quire m e nts

dra w us e -c a s e
write s c e na rio
dia gra m

Cre a te Us e -c a s e s
c om ple te te m pla te
Quality Function Deployment (QFD)
 Elicitation Work Products
• Pernyataan tentang Kebutuhan-Kebutuhan Sistem dan Kelayakannya
• Pernyataan lengkap tentang lingkup system dan Produk
• Daftar para pelanggan, Pengguna, Orang-Orang Lain yang berkepentingan,
yang berpartisipasi dalam pengenalan requirements elicitation
• Deskripsi berkaitan dengan lingkungan Teknis yang dimiliki system
• Daftar Requirement (sebaiknya diorganisir berdasarkan Fungsi) dan
batasan-batasan yang dapat diterapkan pada masing-masing Requirement
• Skenario-Skenario Penggunaan yang menyediakan wawasan yang
berkaitan dengan penggunaan system atau produk saat system atau
produk dieksekusi dibawah berbagai kondisi operasi yang berbeda
• Terdapat Prototipe yang dikembangkan untuk dapat mendefenisikan
Requirement Sistem dengan cara yang lebih baik
 Building the Analysis Model
• Elements of the analysis model
– Scenario-based elements
• Functional—processing narratives for software functions
• Use-case—descriptions of the interaction between an
“actor” and the system
– Class-based elements
• Implied by scenarios
– Behavioral elements
• State diagram
– Flow-oriented elements
• Data flow diagram
 Use Case
• A collection of user scenarios that describe the thread of usage of a system
• Each scenario is described from the point-of-view of an “actor”—a person or
device that interacts with the software in some way
• Each scenario answers the following questions:
• Who is the primary actor, the secondary actor (s)?
• What are the actor’s goals?
• What preconditions should exist before the story begins?
• What main tasks or functions are performed by the actor?
• What extensions might be considered as the story is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?
Use Case Diagram
Arms / dis arms
s ys tem

Acces s es s ys t em s ens ors

via Int ernet

homeowner

Res ponds t o
alarm event

Encount ers an
error condit ion

s ys tem Reconfigures s ens ors

adminis t rat or and relat ed
s ys t em features
 Class Diagram
From the SafeHome system …

Sensor

name/id
type
location
area
characteristics

identify()
enable()
disable()
reconfigure ()
 State Diagram
Reading
Commands
State name
System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables

Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities
 Negotiating Requirements
• Identify the key stakeholders
– These are the people who will be involved in the
negotiation
• Determine each of the stakeholders “win
conditions”
– Win conditions are not always obvious
• Negotiate
– Work toward a set of requirements that lead to
“win-win”
Validating Requirements
Validating Requirements
 Tambahan:
Software Architecture Microwave Oven
Example 1(cont.): Microwave Sample Sequence Diagram
 Latihan
Buatlah Usecase Scenario:

Login pada sipp.del.ac.id dan cis.del.ac.id

 Referensi
• Adopted from ART slide
• These slides are designed to accompany
Software Engineering: A Practitioner’s
Approach, 8/e (McGraw-Hill, 2015). Slides
copyright 2015 by Roger Pressman.