Analisis dan spesifikasi Kebutuhan

pendekatan agile
Minggu 04 - RPLBO
Objectives 1. Memperkenalkan konsep dari user
requirement secara agile
2. Mampu mengembangkan user story

2
Pertanyaan…

Bayangkan Anda sebagai seorang vendor atau

penyedia jasa pembuat buku menu makanan.

Suatu saat, Anda menerima calon pelanggan Anda

yang meminta Anda untuk membuatkan katalog
menu makanan dan minuman di rumah makannya.

Apa yang Anda lakukan?

Mari kita gambarkan blok diagramnya.

Sejarah singkat software requirement Method
Semakin lama kekuatan komputer meningkat
menjadi 10,000 kali lipat.
Kita berubah dengan cepat dari yang hanya simulasi
sederhana sampai benar-benar menerbangkan
pesawat komersial.
Maka konsekuensi kegagalan dan keberhasilan
makin besar.
Untuk mengurangi kegagalan dan hanya
menghasilkan yg diinginkan → metodologi
terstruktur dan terkendali.
Software bukan barang fisik tapi sebuah ide yang
tercermin dalam kode biner. Sehingga fokus metode
ada pada: “managing software requirements.”
Namun, software semakin besar dan metode
terkendali semakin membuat berat. Proses menjadi
lambat, pada hasil yg ingin dicapai:
- deliver higher-value
- higher-quality software
⇒ SDLC mulai berubah ke “agile” dan “leaner”
Software Process
Predictive Process
Requirement pada waterfall menyiratkan bahwa ada
serangkaian persyaratan yang dapat ditentukan
secara wajar "di muka" dan ini kemudian dapat
digunakan sebagai dasar untuk memperkirakan
jadwal dan anggaran proyek.
Pendekatan ini, menurut Thomas (2001),
“Manajemen cakupan yang terkait dengan upaya
praktik waterfall adalah satu-satunya faktor
penyebab kegagalan terbesar.”
Mengapa?????
Iterative dan Incremental: Spiral

● Perkembangan pemahaman yang cepat ● persyaratan masih memiliki placeholder awal

melalui penemuan eksperimental (spiral) yang kuat.
● Pass awal di sekitar spiral dimaksudkan
terutama untuk memahami persyaratan dan
melakukan beberapa validasi persyaratan
sebelum pengembangan yang lebih serius
dimulai
Iterative dan Incremental: RAD
● Pembuatan model, prototipe, dan sistem awal
yang cepat menggunakan alat yang lebih
canggih (RAD)
● Dari perspektif requirement, asumsinya
adalah jika Anda dapat membuatnya cukup
cepat sebelum persyaratan berubah, Anda
akan lebih berhasil.
● Dan jika Anda salah, alatnya cukup mudah
dan ringan sehingga Anda dapat
membangunnya kembali lebih cepat daripada
menggunakan metode penemuan persyaratan
tradisional.
Iterative dan Incremental: RUP
● Pengembangan iteratif dan inkremental dari
sistem yang lebih besar dan lebih kompleks
(RUP)
● kegiatan seperti "Requirement" tidak lagi
diturunkan ke fase tunggal.
● Meskipun kegiatan persyaratan sangat
intensif selama fase awal dan elaborasi awal,
elaborasi persyaratan dan perubahan
persyaratan dianggap sebagai proses
berkelanjutan yang terjadi sepanjang siklus
hidup.
Agile (Adaptif)

● Proses software telah terjadi ledakan model
yang lebih ringan dan lebih adaptif.
● Berbagai metode:
○ Dynamic Systems Development Method
(DSDM),
○ Feature-Driven Development (FDD),
○ Adaptive Software Development,
○ Scrum, Extreme Programming (XP),
○ Open Unified Process (Open UP),
○ Agile RUP,
○ Kanban,
○ Lean,
○ Crystal Methods
○ dll.
● Model-model tersebut berasumsi bahwa,
dengan alat dan praktik pengembangan yang
tepat, akan :
○ lebih hemat biaya untuk menulis kode dengan
cepat,
○ dievaluasi oleh pelanggan dalam penggunaan
sebenarnya,
○ menjadi "salah" (jika perlu), dan dengan cepat
refactoring daripada sebelumnya.
○ untuk mencoba mengantisipasi dan
mendokumentasikan semua persyaratan di
muka.
The Agile Core Beliefs

Kami menemukan cara yang lebih baik untuk mengembangkan perangkat lunak dengan melakukannya dan
membantu orang lain melakukannya. Melalui pekerjaan ini kami telah mencapai nilai:

Individuals and interactions over processes and tools

Customer collaboration over contract negotiation

Working software over comprehensive documentation

Responding to change over following a plan

Artinya, meskipun ada nilai pada item di sebelah kanan, kami lebih menghargai item di sebelah kiri.
The Agile Manifesto
Prinsip inti sebagai kerangka umum untuk semua metode
agile:
1. Prioritas tertinggi kami adalah untuk memuaskan
pelanggan melalui pengiriman perangkat lunak
berharga yang lebih awal dan berkelanjutan.
2. Menyambut perubahan persyaratan, bahkan di akhir
pengembangan. Proses gesit memanfaatkan
perubahan untuk keunggulan kompetitif pelanggan.
3. Perangkat lunak yang berfungsi adalah ukuran
kemajuan utama.
4. Kirimkan perangkat lunak yang berfungsi sesering
mungkin, dari beberapa minggu hingga beberapa
bulan, dengan preferensi pada skala waktu yang lebih
singkat.
5. Pelaku bisnis dan pengembang harus bekerja sama
setiap hari selama proyek berlangsung.
6. Bangun proyek di sekitar individu yang termotivasi.
Beri mereka lingkungan dan dukungan yang mereka
butuhkan, dan percayakan mereka untuk
menyelesaikan pekerjaan.
7. Metode penyampaian informasi yang paling efisien
dan efektif ke dalam tim pengembangan adalah
percakapan tatap muka.
8. Proses tangkas mempromosikan pembangunan
berkelanjutan. Sponsor, pengembang, dan pengguna
harus dapat mempertahankan kecepatan konstan
tanpa batas.
9. Perhatian terus menerus terhadap keunggulan teknis
dan desain yang baik meningkatkan ketangkasan.
10. Kesederhanaan—seni memaksimalkan jumlah
pekerjaan yang belum selesai—sangat penting.
11. Arsitektur, persyaratan, dan desain terbaik muncul dari
tim yang mengatur diri sendiri.
12. Secara berkala, tim merefleksikan bagaimana
menjadi lebih efektif, kemudian menyelaraskan dan
menyesuaikan perilakunya.
Requirements management in agile
Prinsip inti agile terkait requirement:
Manifesto principle #1—Prioritas tertinggi kami
adalah untuk memuaskan pelanggan melalui
pengiriman perangkat lunak berharga yang lebih
awal dan berkelanjutan.
Manifesto principle #2—Menyambut perubahan
requirement, bahkan di akhir pengembangan.
Proses gesit memanfaatkan perubahan untuk
keunggulan kompetitif pelanggan.
Fokus Tim pada:
● delivering early,
● value added stories into an integrated
baseline.
Keuntungan Early delivery:
● menguji requirement dan asumsi arsitektural
● resiko berkurang atas asumsi tersebut
⇒ Stakeholder tidak lagi perlu deg2an menunggu
aplikasi jadi selama berbulan-bulan, berharap tim
membangun hal yang benar.
Requirements management, berubah menjadi:
lebih temporal, interaktif, dan just-in-time.
Goodbye Iron Triangle

Fix quality—deliver a small increment in a timebox—repeat.

The Big Picture
of Agile Requirements
The Big Picture
of Agile Requirements
The Big Picture of Agile Requirements

The Team Level The Portfolio Level

Tim menentukan, membuat dan menguji team user Pekerjaan yang dilakukan adalah pekerjaan yang
stories dalam rangkaian iterasi dan rilis
diperlukan perusahaan untuk mewujudkan strategi
Product owner bertanggung jawab untuk mengelola
backlog dari user stories dan hal lainnya yang harus bisnis.
dilakukan tim. Dalam hal ini tidak hanya Tim IT saja yang
menerapkan agile, tp seluruh perusahaan.
The Program Level
Program Level akan berisi banyak tim untuk
memberikan solusi melalui “Agile Release Train”
(ART). ART adalah standar iterasi dan milestones
dengan tanggal dan kualitas yang diatur, namun scope
bervariasi.
Product manager bertanggungjawab mendefinisikan
fitur
User Story User story ≡ software requirements

objek utama yang membawa kebutuhan

pelanggan melalui aliran nilai—dari analisis
kebutuhan melalui kode dan implementasi

User Story adalah pernyataan niat singkat yang

menggambarkan sesuatu yang perlu dilakukan
sistem untuk beberapa pengguna.

Mengidentifikasi, memelihara, memprioritaskan,

menjadwalkan, mengelaborasi, menerapkan,
menguji, dan menerima user story adalah proses
manajemen requirement utama yang bekerja di
agile.
User Story…
Agile melihat dokumentasi sebagai sesuatu yang:
● Just enough berarti cukup untuk
menggambarkan kebutuhan suatu project.
● Just in time berarti dibuat pada saat last
responsible moment
● Just because berarti dokumen tersebut
dibuat jika diminta atau dibutuhkan.

Agile != mengabaikan dokumentasi

Dalam manifesto Agile:
Working software over comprehensive
documentation
DOKUMENTASI MINIMAL.
Tentukan user value story, implementasikan
dan uji dalam iterasi singkat, demonstrasikan
dan/atau kirimkan ke pengguna, ulangi

selamanya!
Relasi terkait requirement dalam metode Agile
User Story
User Story menjadi jembatan antara developer dan
customer.
User story secara material berbeda dalam sejumlah
cara dalam spesifikasi kebutuhan.
Singkatnya:
- US berfokus pada experience
- Requirement berfokus pada fungsionalitas
● US bukan spesifikasi kebutuhan terperinci
● US singkat, mudah dibaca, dan dapat dipahami
oleh pengembang, pemangku kepentingan, dan
pengguna.
● US mewakili peningkatan kecil dari fungsionalitas
bernilai yang dapat dikembangkan dalam periode
hari hingga minggu.
● US relatif mudah diperkirakan
● US tidak dibawa dalam dokumen besar dan berat
● US tidak rinci pada awal proyek
● US membutuhkan sedikit atau tanpa pemeliharaan
dan dapat dibuang dengan aman setelah
implementasi
● UC dan kode yang dibuat dengan cepat
setelahnya, berfungsi sebagai masukan untuk
dokumentasi, yang kemudian juga dikembangkan
secara bertahap.
Card, Conversation, and Confirmation
Merupakan model yang menangkap komponen user
story
Card
● Berisi informasi yang cukup (tidak kurang dan
tidak lebih) yang dapat dipahami tim untuk
merencanakan dan mengestimasi story.
● Merangkum niat dan mewakili requirement
yang lebih detail, yang detailnya masih harus
ditentukan.
Conversation
● mewakili diskusi antara tim, pelanggan,
product owner, dan stakeholders, yang
diperlukan untuk menentukan perilaku yang
lebih mendetail yang diperlukan untuk
mengimplementasikan maksud tersebut.
● Card mewakili “janji untuk Conversation”
tentang maksud tersebut.
Card, Conversation, and Confirmation

Confirmation ●
● mewakili kondisi satisfaction yang akan
diterapkan untuk menentukan apakah story
memenuhi maksud dan requirement yang
detail
● memunculkan kriteria acceptance untuk
sebuah story berdasarkan conversation
● Kriteria ini akan digunakan untuk
mengevaluasi story saat user story
diimplementasikan
User Story

User story adalah pernyataan singkat yang Stories are maintained in the teams backlog
menjelaskan sesuatu yang perlu dilakukan sistem
untuk pengguna. Hanya ada 1 backlog dalam tim. Semua pekerjaan
harus berasal dari backlog.
Format:
As a <user role>,
I can <activity>
so that <business value>
User Story

As a <user role>, Disebut sebagai bentuk “user voice” dari ekspresi

cerita pengguna dan menganggapnya sebagai
I can <activity> so that <business value>
konstruksi yang sangat berguna, karena
● mencakup ruang masalah (<business value>
● <role> mewakili siapa yang melakukan aksi atau
delivered)
seseorang yang menerima nilai dari aksi
● ruang solusi (<activity> pengguna sistem)
● <activity> mewakili aksi yang akan dilakukan
● memberikan perspektif yang mengutamakan
oleh sistem.
pengguna (<role>)
● <business value> mewakili “nilai” yang dicapai
oleh aktivitas
keeps them focused on business value and solving
real problems for real people.
User Story

Contoh: pengguna dalam home Kita bisa membuat good dan bad user story
energy-management system ingin:

As a Consumer (<role>), I want to be able to see my

Bill Wake menyarankan untuk I.N.V.E.S.T.
daily energy usage (<what I do with the system>) so
that I can lower my energy costs and usage Independent
(<business value I receive>) Negotiable
Valuable
Estimable
Small
Testable
INVEST in good user stories

Independent ● Hindari ketergantungan pada cerita lain

● Menulis cerita untuk membangun fondasi
Negotiable
sistem
Valuable ● Gabungkan cerita untuk satu iterasi
Estimable
Small
setiap cerita dapat berdiri sendiri dan dapat
Testable dikembangkan, diuji, dan di-deliver mandiri.
INVEST - Independent
As an administrator, I can set the consumer’s
password security rules so that users are required to
create and retain secure passwords, keeping the
system secure.
As a consumer, I am required to follow the password
security rules set by the administrator so that I can
maintain high security to my account.
As an administrator, I can set the password
expiration period so that users are forced to change
their passwords periodically.
As an administrator, I can set the password strength
characteristics so that users are required to create
difficult-to-hack passwords.
INVEST in good user stories

Independent user story bukan contract untuk fungsional tertentu,

tp pengganti untuk requirement yang akan dibahas,
Negotiable . . . and Negotiated
dikembangkan, diuji, dan diterima.
Valuable
Estimable user story bersifat real-time and terstruktur dalam
memanfaatkan efektifitas komunikasi dan
Small
kolaborasi langsung
Testable
menangkap esensi kebutuhan user (not too detail)
INVEST in good user stories

Independent Value merupakan atribut yang paling penting. user

story dapat memberikan value atau manfaat kepada
Negotiable
user, customer, atau stakeholder dari produk.
Valuable
Estimable Backlog diprioritaskan berdasarkan value
Small
Meskipun biasanya value berfokus pada interaksi
Testable user dan sistem, terkadang value lebih tepat jika
difokuskan pada customer representative or key
stakeholder.
INVEST - Value
As a consumer, I can see other energy pricing
programs that appeal to me so that I can enroll in a
program that better suits my lifestyle.
As a utility marketing director, I can present users
with new pricing programs so that they are more
likely to continue purchasing energy from me.
Refactor the error logging system.
As a consumer, I can receive a consistent and clear
error message anywhere in the product so that I
know how to address the issue.
OR
As a technical support member, I want the user to
receive a consistent and clear message anywhere in
the application so they can fix the issue without
calling support.
INVEST in good user stories

Independent User Story harus memiliki detail yang cukup agar

tim pengembang dapat memahami dan
Negotiable
memperkirakannya
Valuable
Estimable Estimasi juga berguna untuk menentukan prioritas
Small
Testable
INVEST in good user stories

Independent User Story harus cukup kecil sehingga bisa

diselesaikan dalam 1 iterasi.
Negotiable
Valuable alasan utama: increased throughput dan decreased
Estimable complexity.
Small
Story yang kecil dapat memberikan higher value
Testable through-put dan feedback user dengan lebih cepat

agilist always leans to smaller stories and then

makes them smaller still.
INVEST in good user stories

Independent Kriteria acceptance harus jelas dalam User Story

Negotiable
USer Story tidak boleh dimulai jika belum memiliki
Valuable kriteria yang jelas dan dapat diterima
Estimable
Pelanggan harus jelas tentang apa yang harus dia
Small
uji selama proses review.
Testable
INVEST - Testable
As a consumer, I want to be able to see my daily
energy usage so that I can lower my energy costs
and usage.
Acceptance Criteria:
Read DecaWatt meter data every 10 seconds and
display on portal in 15-minute increments and display
on in-home display every read.
Read KiloWatt meters for new data as available and
display on the portal every hour and on the in-home
display after every read. No multiday trending for
now (another story).
Etc....
Contoh 1 Epic

E.1. Sebagai Nasabah Perbankan, saya ingin

mengakses net banking, sehingga saya dapat
mengakses rekening saya dan melakukan transaksi
Contoh 1 Features

E.1.1. Sebagai Nasabah Perbankan, saya ingin

mengakses rekening Tabungan agar saya dapat
melihat/melakukan transaksi
E.1.2. Sebagai Nasabah Perbankan, saya ingin
mengakses halaman Kartu Kredit, sehingga saya
dapat melihat dan melakukan transaksi
E.1.3. Sebagai Nasabah Perbankan, saya ingin
mengakses halaman Pinjaman sehingga saya dapat
melihat pinjaman saya
E.1.4. Sebagai Nasabah Perbankan, saya ingin
mentransfer dana, sehingga saya dapat memindahkan
dana saya ke rekening yang berbeda di dalam bank
saya dan bank lain
 User Story

Contoh 1 E.1.1.1. Sebagai Nasabah Perbankan, saya ingin

mengakses/melihat ringkasan rekening tabungan saya,
sehingga saya mengetahui saldo saya dan rincian lainnya

E.1.2.1. Sebagai Pelanggan Perbankan, saya ingin Login

ke Net banking sehingga saya dapat melihat detail kartu
kredit

E.1.4.1. Sebagai Nasabah Perbankan, saya ingin

mentransfer dana ke dalam rekening saya sendiri sehingga
saya dapat memindahkan sebagian saldo ke rekening saya

E.1.4.2. Sebagai Nasabah Perbankan, saya ingin

mentransfer dana dari rekening saya ke rekening lain di
bank lain, sehingga saya dapat mengirim uang ke keluarga
dan teman-teman saya yang memiliki rekening di bank lain

E.1.4.3. Sebagai Nasabah Perbankan, saya ingin

menambahkan penerima ke rekening saya, sehingga saya
dapat mentransfer dana ke penerima
 Epic

Contoh 2 E.1. Sebagai Acquisition Gateway User, saya perlu

mengakses platform pemesanan Akuisisi dengan login
yang aman agar saya dapat membeli produk.
 User Story

Contoh 2 E.1.1 Sebagai Acquisition Gateway User, saya perlu

memilih produk Lelang di platform pemesanan Akuisisi agar
saya dapat menawarnya.

E.1.2. Sebagai Acquisition Gateway User, saya perlu

meninjau tawaran saya sebelumnya di platform pemesanan
Akuisisi sehingga saya dapat menghapus tawaran yang
kedaluwarsa.
 Acceptance Criteria

Contoh 2 A.E.1.1 Pastikan Acquisition Gateway User dapat:

● masuk ke Acquisition Gateway

● buka halaman Lelang
● dapat memilih produk untuk ditawar

A.E.1.2. Pastikan Acquisition Gateway User dapat:

● masuk ke Acquisition Gateway

● buka halaman untuk meninjau item yang sebelumnya
ditawar
● pilih satu, atau beberapa, tawaran kedaluwarsa
● menghapus tawaran yang kedaluwarsa
42
Konklusi…

43
Referensi

Leffingwell, D. 2011. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the
Enterprise

44
Quiz

Kerjakan Kuis Mengenai Materi Hari ini pada moodle.

Quiz akan dibuka 1 HARI (Sabtu jam 12.05 - Minggu jam 12.05)

Terdapat 15 SOAL dalam waktu 30 menit

45
46