04 software requirement.pdf
TRANSCRIPT
1
Rekayasa Perangkat Lunak
1
Software Requirement
(Persyaratan PL)
Arna Fariza
Rekayasa Perangkat Lunak 2
Tujuan
� Memperkenalkan konsep persyaratan user dan
sistem
� Menjelaskan persyaratan fungsional dan non-
fungsional
� Menjelaskan bagaimana persyaratan PL dapat
ditulis dalam dokumen persyaratan
2
Rekayasa Perangkat Lunak 3
Materi
� Persyaratan fungsional dan non-fungsional
� Persyaratan user
� Persyaratan sistem
� Spesifikasi antar muka
� Dokumen persyaratan PL
Rekayasa Perangkat Lunak 4
Rekayasa Persyaratan
� Proses menetapkan layanan yang dibutuhkan
konsumen terhadap sistem dan batasan operasi
dan pengembangan.
� Persyaratan itu sendiri adalah diskripsi layanan
sistem dan batasan yang dihasilkan selama
proses rekayasa persyaratan.
3
Rekayasa Perangkat Lunak 5
Apakah Persyaratan itu?
� Pernyataan abstrak level tinggi dari layanan
atau batasan sistem ke dalam spesifikasi
fungsional matematis
� Tidak terelakkan bahwa persyaratan
mempunyai dua fungsi
o merupakan dasar untuk penawaran kontrak –
sehingga harus terbuka untuk interpretasi
o merupakan dasar untuk kontrak itu sendiri –
sehingga harus didefinisikan secara detail
o Kedua pernyataan diatas disebut persyaratan
Rekayasa Perangkat Lunak 6
Abstraksi Persyaratan (Davis)
“Jika sebuah perusahaan akan mengadakan kontrak untuk proyek pengembangan software besar, harus didefinisikan persyaratan
yang cukup dimana solusi belum terdefinisi. Persyaratan harus ditulis sehingga beberapa kontraktor dapat menawarkan kontrak, penawaran, kemungkinan, secara berbeda dengan persyaratan
organisasi client. Bila kontrak sudah diserahkan, kontraktor harus menulis definisi sistem untuk client secara lebih detail sehingga client mengerti dan dapat mem-validasi software yang akan
dikerjakan. Kedua dokumen ini disebut dokumen persyaratan
untuk sistem”
4
Rekayasa Perangkat Lunak 7
Tipe-tipe Persyaratan
� Persyaratan User
o Laporan dalam bahasa natural plus diagram
layanan yang tersedia dan batasan operasional.
Ditulis oleh konsumen
� Persyaratan Sistem
o Dokumen terstruktur yang berisi diskripsi detail
dari fungsi sistem, layanan dan batasan
operasional. Mendefinisikan apa yang harus
dilaksanakan sehingga dapat menjadi bagian dari
kontrak antara konsumen dan developer.
Rekayasa Perangkat Lunak 8
Definisi dan Spesifikasi
1 .
1 .
Definisi Persyaratan
Software harus menyediakan ketentuan menampilkan dan mengakses file yang dibuat
oleh tool lain
Spesifikasi Persyaratan
1.1 User diberikan fasilitas untuk mendefinisikan tipe file eksternal
1.2 Setiap tipe file eksternal mempunyai alat untuk dihubungkan yang dapat
diaplikasikan ke file
1.3 Setiap tipe file eksternal direpresentasikan sebagai icon tertentu pada tampilan
user
1.4 Fasilitas disediakan untuk icon yang merepresentasikan tipe file eksternal yang
didefinisikan oleh user
1.5 Jika user memilih icon untuk merepresentasikan file eksternal, efek pemilihan
mengaplikasikan alat yang menghubungkan antara tipe file eksternal ke file yang
direpresentasikan oleh icon terpilih
5
Rekayasa Perangkat Lunak 9
Pengguna Persyaratan
Persyaratan user
Persyaratan sistem
Spesifikasi desain
software
Manajer client
End-user sistem
Engineer client
Manager kontraktor
Arsitek sistem
End-user sistem
Engineer client
Arsitek sistem
Developer software
Engineer client (kemungkinan)
Arsitek sistem
Developer software
Rekayasa Perangkat Lunak 10
Persyaratan Fungsional dan non-fungsional
� Persyaratan fungsional
o Pernyataan layanan sistem yang harus disediakan, bagaimana
sistem bereaksi pada input tertentu dan bagaimana perilaku
sistem pada situasi tertentu
� Persyaratan non-fungsional
o Batasan layanan atau fungsi yang ditawarkan sistem seperti
batasan waktu, batasan pengembangan proses, standarisasi
dll
� Persyaratan domain
o Persyaratan yang datang dari domain aplikasi sistem dan
yang menyatakan karakteristik dari domain tersebut
6
Rekayasa Perangkat Lunak 11
Persyaratan Fungsional
� Menggambarkan fungsionalitas atau layanan
sistem
� Tergantung pada jenis PL, harapan user dan
jenis sistem dimana PL digunakan
� Perysaratan fungsional user merupakan
pernyataan level tinggi dari apa yang
seharusnya dilakukan sistem tetapi persyaratan
fungsional sistem harus menggambarkan
layanan sistem secara rinci
Contoh Kasus : System LIBSYS
�Sebuah sistem perpustakaan yang menyediakan
antarmuka tunggal untuk sejumlah database
dari artikel di perpustakaan yang berbeda.
�Pengguna dapat mencari, mengunduh dan
mencetak artikel secara pribadi.
7
Contoh Peryaratan Fungsional
� User seharusnya dapat melakukan pencarian melalui
database atau subsetnya.
� Sistem menyediakan tampilan yang tepat bagi user
untuk membaca dokumen dalam penyimpan dokumen.
� Setiap order akan dialokasikan identifikasi unik
(ORDER_ID) dimana pengguna dapat menyalin ke
penyimpanan sekunder.
Rekayasa Perangkat Lunak 14
Ketidaktepatan Peryaratan
� Permasalahan timbul jika persyaratan tidak
ditetapkan dengan jelas
� Persyaratan yang sama mungkin
diinterprestasikan dengan cara yang berbeda
oleh developer dan user
� Pertimbangkan ‘Viewer yang tepat’
o Keinginan user – tampilan khusus untuk tipe
dokumen yang berbeda
o Interpretasi developer – menyediakan tampilan
teks yang menunjukkan isi dokumen
8
Rekayasa Perangkat Lunak 15
Konsistensi dan Kelengkapan Persyaratan
� Secara prinsip, persyaratan harus lengkap dan
konsisten
� Lengkap
o Harus mendiskripsikan semua fasilitas yang dibutuhkan
� Konsisten
o Tidak terdapat konflik atau kontradiksi dalam
mendiskripsikan fasilitas sistem
� Dalam prakteknya, tidak mungkin menghasilkan
dokumen persyaratan yang lengkap dan konsisten
Rekayasa Perangkat Lunak 16
Peryaratan Non-fungsional
� Mendifinisikan sifat sistem dan batasan sistem, seperti
kehandalan, waktu respon, kebutuhan penyimpan.
Batasan lain misalnya kapabilitas perangkat I/O,
representasi sistem dll
� Persyaratan proses juga dapat ditentukan dari sistem
CASE khusus, bahasa pemrograman atau metode
pengembangan
� Persyaratan non-fungsional mungkin lebih penting
kritis daripada persyaratan fungsional. Jika tidak
terpenuhi, sistem menjadi tidak berguna
9
Rekayasa Perangkat Lunak 17
Klasifikasi Non-fungsional
� Persyaratan Produk
o persyaratan yang menetapkan bahwa produk yang
dikirim harus berjalan dengan cara tertentu,
contoh kecepatan eksekusi, kehandalan dll
� Persyaratan Organisasi
o persyaratan sebagai akibat dari kebijakan
organisasi dan prosedur misalnya standar proses
yang digunakan, persyaratan implementasi dll
� Persyaratan Eksternal
o persyaratan yang muncul dari faktor eksternal
sistem dan proses pengembangan misalnya
persyaratan antar operasi, persyaratan legistatif
dll
Rekayasa Perangkat Lunak 18
Tipe Persyaratan Non-fungsional
Persyaratan non-
fungsional
Persyaratan
produk
Persyaratan
organisasi
Persyaratan
eksternal
Persyaratan
efisiensi
Persyaratan
kehandalan
Persyaratan
portabilitas
Persyaratan
interoperasi
Persyaratan
ethical
Persyaratan
kemampuan
penggunaan
Persyaratan
penyerahan
Persyaratan
implementasi
Persyaratan
standar
Persyaratan
keselamatan
Persyaratan
privacy
Persyaratan
legislatif
Persyaratan
performansi
Persyaratan
ruang
10
Rekayasa Perangkat Lunak 19
Contoh Persyaratan Non-fungsional
� Persyaratan Produk
o 8.1 User interface untuk LIBSYS harus diimplementasikan
sebagai HTML sederhana tanpa frame atau Java applet.
� Persyaratan Organisasi
o 9.3.2 Proses pengembangan sistem dan penyerahan dokumen
harus sesuai dengan proses dan penyerahan yang
didefinisikan dalam XYZCo-SP-STAN-95.
� Persyaratan Eksternal
o 7.6.5 Sistem seharusnya tidak mengungkapkan informasi
pribadi apapun tentang konsumen selain nama dan nomor
referensi ke operator sistem.
Rekayasa Perangkat Lunak 20
Persyaratan Domain
� Berasal dari domain aplikasi dan
menggambarkan karakteristik sistem dan fitur
yang mencerminkan domain.
� Domain persyaratan menjadi persyaratan
fungsional baru, batasan pada peryaratan yang
ada atau mendefinisikan komputasi tertentu.
� Jika persyaratan domain tidak terpenuhi,
sistem mungkin tidak dapat dijalankan.
11
Rekayasa Perangkat Lunak 21
Persyaratan Domain pada LIBSYS
� Harus ada user interface standar untuk semua
database yang harus didasarkan pada standar Z39.50.
� Karena pembatasan hak cipta, beberapa dokumen
harus dihapus segera setelah tiba. Tergantung
persyaratan user, dokumen tersebut dapat dicetak
secara lokal pada server sistem untuk dikirim secara
manual ke user atau dilewatkan ke network printer.
Rekayasa Perangkat Lunak 22
Permasalahan Persyaratan Domain
� Kemampuan untuk dimengerti
o Persyaratan dinyatakan dalam bahasa domain
aplikasi
o Hal ini sering tidak dipahami oleh software
engineer yang mengembangkan sistem
� Ketidaklengkapan
o Domain khusus sudah mengerti area dengan baik
sehingga mereka tidak berfikir untuk membuat
persyaratan domain secara eksplisit
12
Rekayasa Perangkat Lunak 23
Persyaratan User
� Menjelaskan persyaratan fungsional dan non-
fungsional sedemikian rupa sehingga
dimengerti oleh user yang tidak mempunyai
pengetahuan teknis yang rinci.
� Persyaratan user didefinisikan menggunakan
bahasa alami, tabel dan diagram yang dapat
dipahami oleh semua user.
Rekayasa Perangkat Lunak 24
Permasalahan dengan Bahasa Alami
� Ketidakjelasan
o Sulit untuk presisi tanpa membuat dokumen yang
sulit dibaca.
� Persyaratan yang membingungkan
o Persyaratan fungsional dan non-fungsional
cenderung dicampur aduk
� Penggabungan persyaratan
o Beberapa persyaratan yang berbeda dinyatakan
bersama-sama
13
Rekayasa Perangkat Lunak 25
Persyaratan LIBSYS
4 .. 5 LIBSYS wajib menyediakan sistem akuntansi keuangan yang
menyimpan catatan dari semua pembayaran yang dilakukan oleh user
sistem. Manajer sistem dapat mengkonfigurasi sistem ini sehingga user
biasa mungkin menerima potongan harga
Rekayasa Perangkat Lunak 26
Permasalahan Persyaratan
� Persyaratan database terdiri dari informasi baik
konseptual maupun rinci
o Menjelaskan konsep sistem akuntansi keuangan yang akan
dimasukkan dalam LIBSYS;
o Namun, juga mencakup hal detail mengenai konfigurasi
sistem yang dapat dilakukan manajer dapat mengkonfigurasi
sistem ini - hal ini tidak diperlukan pada tingkat ini.
14
Rekayasa Perangkat Lunak 27
Ketentuan Penulisan Persyaratan
� Menciptakan format standard dan
menggunakannya untuk semua persyaratan.
� Menggunakan bahasa secara konsisten.
� Menggunakan penanda teks untuk identifikasi
bagian penting dari persyaratan
� Hindari penggunakan jargon komputer
Rekayasa Perangkat Lunak 28
Persyaratan Sistem
� Spesifikasi fungsi sistem yang lebih rinci,
layanan dan batasan persyaratan user
� Sebagai dasar merancang sistem
� Biasanya digunakan sebagai bagian dari
kontrak sistem
15
Rekayasa Perangkat Lunak 29
Persyaratan dan Desain
� Secara prinsip, persyaratan menyatakan apa
yang seharusnya sistem lakukan dan desain
menjelaskan bagaimana melakukannya
� Prakteknya, persyaratan dan desain dibedakan
o Arsitektur sistem dirancang untuk men-strukturkan
persyaratan
o Sistem dapat beroperasi dengan sistem lain yang
menghasilkan persyaratan desain
o Penggunaan desain tertentu mungkin menjadi
persyaratan domain
Rekayasa Perangkat Lunak 30
Permasalahan dengan Spesifikasi
Bahasa Alami
� Kemenduaan
o Pembaca dan penulis persyaratan harus menginterpretasikan
kata yang sama dg cara yang sama. Bahasa alami secara
natural bersifat mendua sehingga hal ini sangat sulit
� Terlalu Fleksibel
o Hal yang sama mungkin dikatakan dengan beberapa cara
yang berbeda dalam spesifikasi
� Tidak ada modularitas
o Struktur bahasa alami tidak cukup untuk men-strukturkan
persyaratan sistem
16
Rekayasa Perangkat Lunak 31
Alternatif Spesifikasi dalam Bahasa Alami
Notasi Deskripsi
Bahasa Pendekatan ini tergantung definisi bentuk standard atau template untuk
natural terstruktur menggambarkan spesifikasi persyaratan
Bahasa deskripsi Pendekatan ini menggunakan bahasa seperti bahasa pemrograman
desain tetapi lebih banyak fitur abstrak untuk menentukan persyaratan
dengan mendefinisikan model operasi dari sistem
Notasi grafis bahasa grafis, ditambahkan dengan text digunakan untuk mendefinisikan
persyaratan fungsional untuk sistem
Contohnya sebelumnya bahasa grafis SADT (Ross, 1977; Schoman
and Ross, 1977), saat ini digunakan deskripsi use case (Jacobsen,
Christerson et al.,1993)
Spesifikasi Ada beberapa notasi berbasis konsep matematis seperti
Matematis mesin finite-state atau himpunan. Spesifikasi yang ganda dapat
mengurangi argumen antara konsumen dan kontraktor tentang
fungsional sistem. Sebaliknya, sebagian besar konsumen tidak mengerti
spesifikasi formal dan enggan menerimanya sebagai kontrak sistem
Rekayasa Perangkat Lunak 32
Spesifikasi dg Bahasa Terstruktur
� Kebebasan penulisan persyaratan dibatasi oleh
template standar untuk persyaratan.
� Semua persyaratan ditulis dengan cara yang
standar.
� Terminologi yang digunakan dalam deskripsi
mungkin terbatas.
� Keuntungannya adalah bahwa sebagian besar
ekspresi dari bahasa alami dipertahankan
dengan penyeragaman pada spesifikasi.
17
Rekayasa Perangkat Lunak 33
Spesifikasi Berbasis Form
� Definisi fungsi atau entiti
� Menggambarkan input dan darimana berasal
� Menggambarkan output dan dimana berjalan
� Mengindikasikan entiti lain yang diperlukan
� Kondisi sebelum dan sesudah (jika diperlukan)
� Efek lain (jika ada) dari fungsi
Rekayasa Perangkat Lunak 34
Spesifikasi node Berbasis Form BCLIPSB/Workstation/Tools/DB/3.5.1
Function Tambah node
Deskripsi Menambah node ke desain yang sudah ada. User memilih tipe node
dan posisi bila ditambahkan ke desain, node menjadi pilihan saat ini. User memilih posisi
node dan memindahkan kursor ke area dimana node ditambahkan
Input Tipe node, posisi node, identifier desain
Source Tipe node dan posisi node diinputkan oleh user, identifier desain dari
database
Output Identifier desain
Tujuan Desain database. Desain membuat database menyelesaikan operasi
Persyaratan Desain graph akar dari identifier desain input
Pre-kondisi Desain terbuka dan ditampilkan pada layar user
Post-kondisi Desain tidak berubah terpisah dari tambahan node tipe tertentu pada
posisi yang diberikan
Efek lain TIdak ada
18
Diagram Sequence
�Menunjukkan urutan peristiwa yang terjadi selama beberapa user berinteraksi dengan sistem.
�Dibaca dari atas ke bawah untuk melihat urutan tindakan yang terjadi.
�Penarikan dari ATM o Validasi Kartu;
o Menangani permintaan;
o Transaksi selesai.
Diagram Sequence pada Penarikan ATM
19
Rekayasa Perangkat Lunak 37
Spesifikasi Antar Muka
� Sebagian besar sistem harus beroperasi dengan
sistem lain dan antar muka operasi harus
ditentukan sebagai bagian persyaratan
� Tiga tipe antar muka
o Antar muka prosedural
o Struktur data yang dapat ditukar
o Representasi data
� Notasi formal adalah teknik efektif untuk
spesifikasi antar muka
Rekayasa Perangkat Lunak 38
Deskripsi Antar Muka PDL
interface PrintServer {
// defines an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter
void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;} //PrintServer
20
Rekayasa Perangkat Lunak 39
Dokumen Persyaratan
� Dokumen persyaratan adalah pernyataan resmi
dari apa yang dibutuhkan oleh developer
sistem
� Harus mencakup persyaratan pengguna dan
spesifikasi persyaratan sistem.
� BUKAN dokumen desain. Sejauh mungkin,
menentukan APA yang harus dikerjakan sistem
daripada BAGAIMANA mengerjakannya
Rekayasa Perangkat Lunak 40
User dari dokumen
persyaratan
Konsumen sistem
Manager
Engineer sistem
Engineer testing
sistem
Engineer
maintenance
sistem
Spesifikasi persyaratan dan
membacanya untuk memeriksa apakah
sesuai persyaratan konsumen.
Konsumen menentukan perubahan
persyaratan
Menggunakan dokumen persyaratan
untuk perencanaan sistem dan
merencanakan proses
pengembangan sistem
Menggunakan persyaratan untuk
mengerti sistem apa yang
dikembangkan
Menggunakan persyaratan
untuk mengembangkan tes
validasi sistem
Menggunakan persyaratan
untuk membantu mengerti
sistem dan hubungan antar
bagian
21
Rekayasa Perangkat Lunak 41
Standard IEEE untuk Persyaratan
�Menentukan struktur umum untuk dokumen
persyaratan yang harus ditulis untuk setiap
sistem
o Pendahuluan
o Deskripsi Umum
o Persyaratan khusus
o Lampiran
o Indeks
Rekayasa Perangkat Lunak 42
Struktur Dokumen Persyaratan
� Pendahuluan
� Daftar Istilah
� Definisi Persyaratan User
� Arsitektur Sistem
� Spesifikasi persyaratan sistem
� Model sistem
� Evolusi sistem
� Lampiran
� Indeks
22
Rekayasa Perangkat Lunak 43
Key Point
� Persyaratan menentukan apa yang seharusnya
dilakukan sistem dan menentukan batasan operasi dan
implementasi
� Persyaratan fungsional menentukan layanan sistem
yang harus disediakan
� Persyaratan non-fungsional membatasi pengembangan
sistem atau pengembangan proses
� Persyaratan user adalah pernyataan level tinggi apa
yang sistem harus kerjakan. Persyaratan user
sebaiknya ditulis menggunakan bahasa alami, tabel
dan diagram
Rekayasa Perangkat Lunak 44
Key Point
� Persyaratan sistem dimaksudkan untuk
mengkomunikasikan fungsi yang harus
disediakan sistem
� Dokumen persyaratan software adalah
pernyataan persetujuan dari persyaratan
sistem
� Standart IEEE digunakan untuk mendefinisikan
persyaratan khusus lebih rinci sesuai standart.