Dokumen tersebut membahas persyaratan perangkat lunak, termasuk persyaratan fungsional, non-fungsional, dan domain. Dokumen tersebut juga membedakan antara persyaratan pengguna, persyaratan sistem, dan spesifikasi desain."

1. ST. MAWADDATANWWARAHMAH
PERT 4
Dhawarahmah 1

2. PERSYARATAN PERANGKAT LUNAK
Dhawarahmah 2

3. 4. 1 PERSYARATAN FUNGSIONAL & NON
FUNGSIONAL
4.2 PERSYARATAN USER
4.3 PERSYARATAN SISTEM
4.4 DOKUMEN PERSYARATAN
PERANGKAT LUNAK
Dhawarahmah 3

4. Deskripsi layanan dan batasan merupakan
persyaratan bagi sistem, dan proses menemukan,
menganalisis, mendokumentasikan , dan memeriksa
layanan dan batasan tersebut yang dinamakan
rekayasa persyaratan.
Dhawarahmah 4

5. Lanjutan
 Istilah persyaratan tidak dipakai di seluruh industri
perangkat lunak secara konsisten.
 Pada beberapa kasus, persyaratan dipandang sebagai
persyaratan tingkat tinggi dan abstrak mengenai
layanan harus diberikan sistem atau mengenai
batasan sistem.
Dhawarahmah 5

6. Beberapa masalah yang muncul pada saat proses
rekayasa persyaratan merupakan akibat dari kegagalan
membuat pemisahan yang jelas antara tingkat-tingkat
deskripsi yang berbeda ini. Dalam hal ini menggunakan
istilah persyaratan user, persyaratan sistem dan spesifikasi
perancangan perangkat lunak.
Dhawarahmah 6

7. Persyaratan user, persyaratan sistem, dan spesifikasi
perangkat lunak dapat didefinisikan sebagai berikut:
- Persyaratan user merupakan pernyataan dalam bahasa
natural ditambah diagram, mengenai apa yang kita
harapkan disediakan oleh sistem dan batasan
operasinya.
Dhawarahmah 7

8. - Persyaratan sistem menentukan layanan dan batasan
sistem secara rinci. Dokumen ini berlaku sebagai
kontrak antara pembeli sistem dan pengembang
perangkat lunak.
- Spesifikasi perancangan sistem merupakan deskripsi
abstrak dari perancangan perangkat lunak yang
merupakan dasar bagi perancangan yang lebih rinci dan
implementasi.
Dhawarahmah 8

9. Definisi Persyaratan user
1. Perangkat lunak memberikan bantuan dalam merepresentasikan dan
mengakses file-file eksternal yang dibuat dengan alat bantu (tool) lain.
Spesifikasi Persyaratan Sistem
1.1 user harus diberi fasilitas untuk mendefinisikan jenis file eksternal
1.2 setiap file eksternal bisa memiliki alat bantu relevan yang bisa diterapkan pada
file tersebut
1.3 setiap file eksternal bisa direpresentasikan sebagai ikon yang spesifik pada
display user
1.4 fasilitas harus disediakan untuk ikon yang merepresentasikan suatu jenis file
eksternal yang akan didefinisikan oleh user
1.5 ketika user memilih sebuah ikon yang merepresentasikan file eksternal, efek
pemilihan itu adalah penerapan alat bantu yang berhubungan dengan jenis file
eksternal ke file yang direpresentasikan oleh ikon yang dipilih.
Gambar 5.1
GAMBAR 5.1 PERSYARATAN USER & SISTEM
Dhawarahmah 9

10.  Gambar 5.1 mengilustrasikan Perbedaan antara
persyaratan user dan persyaratan sistem. Gambar
tersebut menunjukkan bagaimana persyaratan user
dapat diperluas menjadi beberapa persyaratan sistem.
Dhawarahmah 10

11. Gambar 5.2
pembaca dengan jenis spesifikasi yang berbeda
Dhawarahmah 11

12. - Persyaratan user harus ditulis untuk klien dan manajer
kontraktor yang tidak memilki pengetahuan teknis rinci
mengenain sistem.
- Spesifikasi persyaratan sistem harus ditujukan bagi staf
teknis senior dan manajer proyek.
- Spesifikasi perancangan perangkat lunak merupakan
dokumen yang berorientasi pada implementasi.
Dhawarahmah 12

13.  Persyaratan fungsional. Ini merupakan pernyataan
layanan harus diberikan sistem, bagaimana sistem
harus bereaksi terhadap input tertentu, dan bagaimana
sistem berlaku pada situasi-situasi tertentu.
 Persyaratan non-fungsional. Ini merupakan batasan
layanan atau fungsi yang diberikan sistem.
 Persyaratan domain. Ini merupakan persyaratan yang
datang dari domain aplikasi sistem dan merefleksikan
karakteristik domain tersebut.
Dhawarahmah 13

14.  Persyaratan fungsional untuk sistem mendeskripsikan
fungsionalitas atau layanan yang diharapkan akan
diberikan oleh sistem.
 Persyaratan ini bergantung pada jenis perangkat lunak
yang sedang dikembangkan, user yang diharapkan
menggunakan perangkat lunak tersebut dan jenis sistem
yang sedang dikembangkan.
Dhawarahmah 14

15.  Persyaratan fungsional untuk sistem perpustakaan
universitas (Kotonya dan Sommerville, 1998) untuk
memesan buku dari perpustakaan lain.
1. User dapat mencari semua data atau set awal database
atau memilih subset darinya.
2. Sistem akan menyediakan viewer yang sesuai bagi user
untuk membaca dokumen pada penyimpanan (store)
dokumen.
3. Semua pemesanan akan diberi identifier yang unik
(ORDER_ID) yang dapat dikopi user ke area
penyimpanan permanen untuk account tersebut.
Dhawarahmah 15

16.  Persyaratan non-fungsional, dilihat dari namanya
merupakan persyaratan yang tidak langsung
berhubungan dengan fungsi spesifik yang disediakan
oleh sistem.
 Persyaratan ini berhubungan dengan properti sistem,
seperti keandalan, waktu tanggap, dan penempatan
pada media penyimpanan
Dhawarahmah 16

17. - Jika sebuah sistem pesawat udara tidak memenuhi
persyaratan keandalannya, sistem tersebut tidak akan
disertifikasi aman untuk beroperasi.
- Jika sebuah sistem kontrol real-time gagal memenuhi
persyaratan kinerjanya, fungsi kontrol tidak akan
beroperasi dengan benar.
Dhawarahmah 17

18. Gambar 5.3
Jenis Persyaratan Dhawarahmah
Non-fungsional 18

19.  Persyaratan produk, ini merupakan persyaratan
yang menspesifikasi perilaku produk.
 Persyaratan organisasi. Persyaratan ini berasal dari
kebijakan dan prosedur pada organisasi pelanggan
dan pengembang.
 Persyaratan eksternal. Nama yang luas ini
mencakup semua persyaratan yang berasal dari
faktor eksternal terhadap sistem dan proses
pengembangannya.
Dhawarahmah 19

20. Persyaratn Produk
4.C.8 Semua komunikasi yang diperlukan antara APSE dan user harus mungkin
diekspersikan dalam set karakter ada.
Persyaratan organisasi
9.3.2 Proses pengembangan sistem dan dokumen yang telah selesai akan mengikuti
proses dan hasil yang diharapkan, yang didefinisikan pada XYZCo-SP-STAN-95
Persyaratan eksternal
7.6.5 Sistem tidak akan mengungkapkan informasi pribadi pelanggan, selain nama dan
nomor referensi mereka kepada operator sistem.
Gambar 5.4
contoh persyaratan non-fungsional
Dhawarahmah 20

21. Tujuan sistem
Sistem harus dapat digunakan dengan mudah oleh kontroller yang berpengalaman dan
harus diatur sedemikian rupa sehingga error diminimasi.
Persyaratan non-fungsional yang dapat diverifikasi
Kontroller yang berpengalaman akan dapat menggunakan semua fungsi sistem setelah
total dua jam pelatihan. Setelah pelatihan ini, jumlah rata-rata error yang dibuat oleh
user yang berpengalaman tidak akan melebihi dua per hari.
Gambar 5.5
Tujuan sistem dan persyaratan yang dapat
diverifikasi
Dhawarahmah 21

22. Properti Pengukuran
Kecepatan Transaksi yang diproses/ detik waktu tanggap user/evet waktu
refresh layar
Ukuran K byte
Jumlah chip RAM
Kemudahan penggunaan Waktu pelatihan
Jumlah frame help
Keandalan Waktu rata-rata kegagalan
Probabilitas ketidaksediaan
Kecepatan terjadinya kegagalan
Ketersediaan
Ketahanan Waktu start ulang setelah kegagalan
Persentase event yang menyebabkan kegagalan Probabilitas
korupsi data pada kegagalan
Portabilitas Persentase pernyataan yang bergantung target jumlah sistem
target.
Gambar 5.6
Ukuran untuk spesifikasi persyaratan non-fungsional
Dhawarahmah 22

23.  Persyaratan domain berasal dari domain aplikasi dan
bukan dari kebutuhan user sistem yang spesifik.
 Persyaratan ini bisa berupa persyaratan fungsional yang
baru, membatasi persyaratan fungsional yang ada atau
menentukan bagaimana komputasi tertentu harus
dilakukan
 Jika persyaratan ini tidak dipenuhi, tidak menutup
kemungkinan membuat sistem bekerja dengan tidak
memuaskan
Dhawarahmah 23

24. 1. Akan ada interface user standar bagi semua database
yang akan didasarkan pada standar Z39.50
2. Karena adanya batasan hak cipta, beberapa dokumen
harus dihapus dengan segera pada saat berakhir.
Bergantung pada persyaratan user, dokumen-
dokumen ini akan dicetak lokal pada server sistem
untuk kemudian diteruskan secara manual kepada
user, atau di-routekan ke printer jaringan.
Dhawarahmah 24

25.  Persyaratan user untuk sistem harus mendeskripsikan
persyaratan fungsional dan non-fungsional sehingga
dapat dipahami oleh user sistem yang tidak memilki
pengetahuan teknik yang rinci.
 Persyaratan user tidak boleh didefinisikan dengan
memakai model implementasi.
 Persyaratan user harus ditulis dengan memakai bahasa
natural, format, dan diagram intuitif yang sederhana
Dhawarahmah 25

26. 1. Tidak adanya kejelasan. Kadang-kadang sulit
menggunakan bahasa dengan cara yang tepat dan tidak
mendua artinya tanpa membuat dokumen menjadi
panjang dan sulit dibaca
2. Kesimpang-siuran persyaratan. Persyaratan fungsional,
persyaratan non-fungsional, tujuan sistem dan informasi
perancangan mungkin tidak dibedakan dengan jelas.
3. Penggabungan persyaratan. Beberapa persyaratan yang
berbeda dapat dinyatakan bersama dalam satu
persyaratan
Dhawarahmah 26

27. 4.A.5 Database ini akan mendukung pembuatan dan
kontrol objek konfigurasi, yaitu objek yang
merupakan pengelompokan objek lainnya pada
database. Fasilitas kontrol konfigurasi akan
memungkinkan akses terhadap objek pada
kelompok versi dengan menggunakan nama yang
tidak lengkap
Gambar 5.7
persyaratan bagi database
untuk lingkungan pemrograman
Dhawarahmah 27

28. Fasilitas Grid
Fasilitas grid ini digunakan untuk membantu penempatan entitas
pada diagram, user bisa membuat grid dalam ukuran centimeter
atau inci, melalui plihan pada panel kontrol. Pada awalnya, grid
ini tidak ada. Grid dapat ditampilkan dan dihilangkan kapan saja
selama waktu pengeditan dan dapat diganti-ganti antara inci dan
centimeter pada setiap saat. Pilihan grid akan disediakan pada
tampilan reduce-to-fit (dikecilkan agar sesuai) tetapi jumlah garis
grid yang ditampilkan akan diperkecil untuk menghindari
memenuhi diagram yang kecil dengan garis-garis grid.
Gambar 5.8
persyaratan user untuk grid editor
Dhawarahmah 28

29.  Persyaratan konseptual dan fungsional yang
menyatakan bahwa sistem edit harus menyediakan
grid.
 Persyaratan non-fungsional yang memberikan
informasi rinci mengenai satuan grid (centimeter
atau inci)
 Persyratan interface user non-fungsional yang
mendefinisikan bagaimana grid tersebut
ditampilkan atau dihilangkan oleh user
Dhawarahmah 29

30. 1. Buat format standar dan pastikan bahwa semua definisi
persyaratan mengikuti format tersebut.
2. Gunakan bahasa secara konsisten. Terutama bedakan
antara persyaratan yang diperintahkan dan yang
diinginkan.
3. Gunakan bahasa teks (tebal dna miring) untuk
menemukan bagian kunci pada persyaratan tersebut.
4. Hindari semaksimal mungkin penggunaan istilah
komputer
Dhawarahmah 30

31.  Persyaratan sistem merupakan deskripsi yang
lebih rinci dari pernyataan user.
 Persyaratan ini berfungsi sebagai dasar kontrak
untuk implementasi sistem.
 Merupakan spesifikasi yang lengkap dan
konsisten dari sistem secara keseluruhan.
 Pada prinsipnya, persyaratan sistem harus
menyatakan apa yang harus dilakukan sistem
dan bukan bagaimana sistem tersebut harus
diimplementasi.
Dhawarahmah 31

32.  Pemahaman bahasa natural bergantung pada
pembaca dan penulis spesifikasi dalam menggunakan
kata yang sama untuk konsep yang sama.
 Spesifikasi persyaratan bahasa natural terlalu
fleksibel. Artinya bisa mengatakan hal yang sama
dengan cara yang berbeda.
 Tidak ada cara yang mudah untuk memodularisasi
persyaratan bahasa natural. Bisa jadi kita sangat sulit
menemukan semua persyaratan yang berhubungan.
Dhawarahmah 32

33. Notasi Keterangan
Bahasa Natural Pendekatan ini bergantung pada pendefinisian format atau
Terstruktur template standar untuk menyatakan spesifikasi persyaratan
Bahasa deskripsi desain Pendekatan ini menggunakan bahasa seperti bahasa
pemrograman tetapi lebih banyak fitur abstrak untuk
menspesifikasi persyaratan dengan cara mendefinisikan
model operasional sistem
Notasi grafis Bahasa grafis, dilengkapi dengan anotasi teks, yang
digunakan untuk mendefinisikan persyaratan fungsional
sistem. Contoh awal bahasa grafis: SADT (Ross,1977)
Spesifikasi matematis Ada notasi yang berdasarkan pada konsep matematis
seperti finite-state machine atau set. Spesifikasi jenis ini
mengurangi argumen antara pelanggan dan kontraktor
mengenai fungsionalitas sistem
Gambar 5.9
Notasi untuk spesifikasi persyaratan
Dhawarahmah 33

34.  Bahasa natural terstruktur merupakan bentuk yang
terbatas dari bahasa natural untuk menulis
persyaratan sistem
 Keuntungan pendekatan ini ialah bahwa pendekatan
ini mempertahankan tidak hanya keekspresifan dan
kekomprehensifan bahasa natural tetapi juga
menjamin diterapkannya suatu tingkat keseragaman
pada spesifikasi.
 Bahasa ini memakai bentuk kontrol yang berasal dari
bahasa pemrograman dan penonjolan grafis untuk
mempartisi spesifikasi
Dhawarahmah 34

35.  Proyek yang memakai bahasa natural terstruktur untuk
spesifikasi persyaratan sistem dideskripsikan oleh
Heninger (1980).
 form-form khusus dirancang untuk mendeskripsikan
input, output, dan fungsi sistem perangkat lunak.
Dhawarahmah 35

36. ECLIPSE/Workstation/Tools/DE/FS/3.5.1
Fungsi Menambahkan titik (node)
Deskripsi Menambahkan sebuah titik kepada desain yang sudah ada. User memilki jenis
titik dan posisinya.
Input Jensi titik, posisi titik, identifier desain
Sumber Jenis titik dan posisi titik diinputkan oleh user, identifier desain dari database
Output Identifier desain
Tujuan Database desain diperuntukkan bagi database pada saat tuntasnya operasi
Membutuhkan Graf desain yang berakar pada identifier desain input
Pra-kondisi Desain terbuka dan ditampilkan pada layar user
Pasca-kondisi Desain tidak berubah terlepas dari adanya penambahan titik dengan jenis tertentu
pada posisi tertentu
Efek samping Tidak ada
Definisi : ECLIPSE/Workstation/Tools/DE/RD/3.5.1
Gambar 5.10
Spesifikasi persyaratan sistem dengan menggunakan form
standar
Dhawarahmah 36

37. 1. Deskripsi fungsi atau entitas yang dispesifikasi
2. Deskripsi inputnya dan dari mana asalnya
3. Deskripsi outputnya dan kemana perginya
4. Indikasi untuk apa entitas lainnya digunakan (bagian
membutuhkan/requires)
5. Jika digunakan pendekatan fungsional, suatu pra-
kondisi mengenai apa yang harus sebelum fungsi
dipanggil dan pasca-kondisi yang menspesifikasi apa
yang benar setelah fungsi dipanggil.
6. Deskripsi efek samping operasi (jika ada)
Dhawarahmah 37

38.  Persyaratan dapat dideskripsikan secara operasional
dengan memakai bahasa deskripsi program PDL(Program
Description Language).
 PDL adalah bahasa yang berasal dari bahasa pemrograman
seperti java.
 Keuntungan penggunaan PDL ialah bahwa bahasa ini
dapat diperiksa secara sintaksis dan semantik dengan alat
bantu perangkat lunak.
Dhawarahmah 38

39. 1. Ketika suatu operasi dispesifikasi sebagai serangkaian
aksi yang lebih mudah dan urutan eksekusi menjadi
penting.
2. Ketika interface perangkat keras dan perangkat lunak
harus dispesifikasi. Pada banyak kasus, interface
antara subsistem-subsistem didefinisikan pada
spesifikasi persyaratan sistem.
Dhawarahmah 39

40.  Bahasa yang digunakan untuk menulis spesifikasi
mungkin tidak cukup ekspresif untuk
mendeskripsikan fungsionalitas sistem
 Notasinya hanya dapat dipahami oleh orang yang
memiliki cukup pengetahuan mengenai bahasa
pemrograman.
 Persyaratan bisa diambil sebagai perancangan
spesifikasi desain dibanding sebagai model untuk
membantu user memahami sistem
Dhawarahmah 40

41.  Mayoritas sistem perangkat lunak harus beroperasi dengan
sistem lain yang telah diimplementasi dan diinstal pada
suatu lingkungan.
 Jika sistem yang baru dan sistem yang sudah ada harus
bekerja sama, interface sistem yang ada harus dispesifikasi
dengan tepat.
Dhawarahmah 41

42. 1. Interface prosedural di mana subsistem yang ada
memberikan berbagai layanan yang diakses dengan
memanggil prosedur interface.
2. Struktur data yang dioperkan dari satu subsistem ke
yang lainnya. Dalam hal ini bisa menggunakan
PDL, ddengan berbasis java.
3. Representasi data (seperti pengurutan bit) yang
telah ditetapkan untuk subsistem yang ada.
Dhawarahmah 42

43. Interface Printserver{
// mendefinisikan server printer abstrak
// mempersyaratkan : interface printer, interface PrintDoc
/* menyediakan : 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
Gambar 5.11
Deskripsi PDL java dari interface print server
GAMBAR: DESKRIPSI PDL JAVA DARI INTERFACE PRINT
Dhawarahmah
SERVER. 43

44.  Interface tersebut menangani antrian permintaan
pencetakan file pada berbagai printer yang berbeda.
 User dapat memeriksa antrian yang berhubungan
dengan suatu printer dan dapat mengambil
pencetakan mereka dari antrian tersebut.
 User juga dapat beralih dari satu printer ke printer
yang lainnya.
 Spesifikasi pada gambar 5.11 merupakan model
abstrak dari print server tanpa menyingkap rincian
interface
Dhawarahmah 44

45.  Dokumen persyaratan perangkat lunak juga disebut
spesifikasi persyaratan perangkat lunak atau SRS /
software requirements specification merupakan
pernyataan resmi mengenai apa yang dibutuhkan dari
pengembang sistem.
 Dokumen persyaratan mempunyai berbagai macam set
user yang berkisar dari manajemen organisasi yang
membayar sistem, sampai perekayasa yang
bertanggung jawab terhadap pengembangan perangkat
lunak.
Dhawarahmah 45

46. Gambar 5.12
Dokumen Persyaratan User
Dhawarahmah 46

47.  Dokumen tersebut harus menspesifikasi perilaku sistem
eksternal
 Dokumen tersebut harus menspesifikasi batasan-batasan
implementasi
 Dokumen tersebut harus mudah diubah
 Dokumen tersebut harus berfungsi sebagai alat bantu
referensi bagi pemelihara sistem
 Dokumen tersebut harus mencatat prakiraan mengenai
siklus sistem
 Dokumen tersebut harus mencirikan tanggapan yang
dapat diterima terhadap event-event yang tidak
diinginkan
Dhawarahmah 47

48. 1. Pendahuluan
1.1 Tujuan dokumen persyaratan
1.2 Cakupan produk
1.3 Definisi, akronim, dan singkatan
1.4 Referensi
1.5 Tinjauan bagian dokumen berikutnya
2. Deskripsi umum
2.1 Perspektif Produk
2.2 Fungsi produk
2.3 karakteristik user
2.4 Batasan-batasan umum
2.5 Asumsi dan ketergantungan
Dhawarahmah 48

49. 3. Persyaratan khusus yang mencakup persyaratan
fungsional, non-fungsional dan interface.
4. Lampiran
5. Indeks
Dhawarahmah 49

50. Dhawarahmah 50