Anda di halaman 1dari 12

Nama = Dzhia Ussafa Alqausar

NIM = 421921076

Mata Kuliah = Rekayasa Perangkat Lunak

Tugas ke 4
Software Requirements
Specification.
Table of Contents
1. Pendahuluan 1
1.1 Tujuan Penulisan Dokumen 1
1.2 Audien yang Dituju dan Pembaca yang Disarankan 1
1.3 Batasan Produk 1
1.4 Definisi dan Istilah 1
1.5 Refrensi 1
2. Deskripsi Keseluruhan 2
2.1 Deskripsi Produk 2
2.2 Fungsi Produk 2
2.3 Penggolongan Karakterik Pengguna 2
2.4 Lingkungan Operasi 2
2.5 Batasan Desain dan Implementasi 2
2.6 Dokumentasi Pengguna 3
3. Kebutuhan Antarmuka Eksternal 4
3.1 User Interfaces 4
3.2 Hardware Interface 4
3.3 Software Interface 4
3.4 Communication Interface 4
4. Functional Requirement5
4.1 Use Case Diagram 5
4.2 Nama Use Case 1 5
4.3 Nama Use Case 2 5
4.4 Class Diagram 6
5. Non Functional Requirements 7
Revision History
Name Date Reason For Changes Version
Sistem Penjualan 10 13/10/2020 9.0
Sederhana
Software Electronic 11 14/10/2020 8.0
Developpers
Software Database 12 16/10/2020 1.0
Environtment
1. Pendahuluan
1.1 Tujuan Penulisan Dokumen
<Tujuan dokumentasi, ini adalah untuk bisa mengetahu tentang bagaimana cara,
mengembangkan sebuah Program, maupun membangun proyek-proyek program, yang akan
dihasilkan suatu saat nanti….. Dan juga bisa dapat menjadi sebagai panduan untuk buat
mengembangkan ataupun membangun sebuah proyek-proyek program tertentu…… >

1.2 Audien yang Dituju dan Pembaca yang Disarankan


<Jelaskan berbagai jenis pembaca bahwa dokumen ini ditujukan untuk, seperti pengembang,
manajer proyek, staf pemasaran, pengguna, penguji, dan lainnya>

1.3 Batasan Produk


<Berikan penjelasan singkat dari perangkat lunak yang ditentukan dan tujuannya, termasuk
manfaat yang relevan, tujuan, dan sasaran. Hubungkan perangkat lunak untuk tujuan perusahaan
atau strategi bisnis>

1.4 Definisi dan Istilah


<tulis istilah dan definisikan jika ada>

o SRS : Software Requirements Specification, atau


Spesifikasi Kebutuhan Perangkat Lunak (SKPL)

o IEEE : Institute of Electrical and Electronics Engineering


Standar internasional untuk pengembangan dan perancangan produk.
2. Deskripsi Keseluruhan
2.1 Deskripsi Produk
<Deskripsi ini membahas tentang bagaimana cara membuat atau membangun sebuah Perangkat
Lunak (Software), dan akan dibuatkan pada Langkah-langkah yang diperlukan untuk dapat
membangu Software, dan juga buat Program Kasir, yang membutuhkan Uang Transaksi
Penjualan harian, dan itu juga harus dimanipulasi lebih lanjut, terhadap pengembangan Perangkat
Lunak (Software ), tersebut. >

2.2 Fungsi Produk


<Berisi hanya rangkuman fungsi utama produk, produk harus melakukan apa atau memungkinkan
pengguna melakukan apa. Hanya ringkasan tingkat tinggi (seperti bullet list) yang dibutuhkan di
sini.>

2.3 Penggolongan Karakterik Pengguna


<Identifikasi berbagai golongan pengguna yang terkait dengan produk yang dikembangkan>

Tabel 1 Karakteristik Pengguna


Kategori Tugas Hak Akses ke aplikasi Kemampuan yang
Pengguna harus dimiliki
Kasir Mencatat transaksi Insert Data Entry Data Transaksi
(example) penjualan harian Penjualan
Supervisor Memanipulasi Data Insert, Update, Delete Data Memanipulasi Data
(Example) jika ada kesalahan Transaksi Penjualan
entry dari kasir

2.4 Lingkungan Operasi


<Jelaskan lingkungan di mana perangkat lunak akan beroperasi, termasuk platform, perangkat
keras, sistem operasi dan versi, dan komponen perangkat lunak lain atau aplikasi yang
berdampingan>

2.5 Batasan Desain dan Implementasi


<Jelaskan setiap item atau masalah yang akan membatasi pilihan yang tersedia untuk para
pengembang / developer. Ini mungkin termasuk: kebijakan perusahaan atau peraturan;
keterbatasan hardware (persyaratan memori); teknologi tertentu, alat, dan database yang akan
digunakan; persyaratan bahasa; protokol komunikasi; pertimbangan keamanan; atau standar
pemprograman>
2.6 Dokumentasi Pengguna
<Daftar komponen dokumentasi pengguna (seperti user manual, on-line help, dan tutorial) yang
akan disampaikan bersama dengan perangkat lunak yang akan dikirim>
3. Kebutuhan Antarmuka Eksternal
3.1 User Interfaces
<Jelaskan karakteristik Logis, dari setiap antarmuka, antara produk perangkat lunak dan juga
pengguna. Ini mungkin, yang termasuk contoh gambar layer, standar GUI (Graphics User
Interface), ataupun juga panduan gaya keluarga produk-produk, yang telah dikembangkannya,
meskipun ini harus diikuti, Batasan, tata letak, layar, tombol, dan juga fungsi-fungsi standar,
(misalnya, bantuan), yang akan memunculkan di setiap layar, pintasan, seperti contoh misalnya,
pada keyboard standar, tampilan pesan kesalahan, yang lain, dan juga seterusnya. Tentukan
komponen-komponen, perangkat lunak, yang selalu memerlukan antarmuka pengguna. Dan juga
ada rincian gambar/desain, yang telah dibuatnya, serta antarmuka, harus bisa didokumentasikan
dalam spesifikasi-spesifikasi, antarmuka pengguna yang juga terpisah.. >

3.2 Hardware Interface


<Jelaskan, karakteristik logis, dan juga fisi-fisik, yang dimiliki dari setiap antarmuka antara produk
perangkat lunak, dan juga komponen-komponen perangkat keras yang ada di sistem ini.. Ini
mungkin termasuk jenis-jenis, perangkat yang didukung, sifat, data, dan juga interaksi control,
antara perangkat lunak, dan juga perangkat keras, termasuk juga pada protocol-protokol,
komunikasi, yang harus selalu digunakan sebagai mana mestinya… .>

3.3 Software Interface


<Jelaskan, hubungan antara produk-produk, ini dan juga beserta dengan perangkat lunak, dan
juga spesifikasnya, yang lainnya, yang harus termasuk (Nama/Versi), itu juga harus ada sistem
basis data (Database), yang telah ada pada sistem operasi, juga alat-alat, dan juga komponen-
komponen, yang lebih sangat komersial, yang selalu lebih terintegrasi… .>

3.4 Communication Interface

<Jelaskan, persyaratan yang terkait, dengan fungsi-fungsi, komunikasi, maupun yang diperlukan
oleh produk-produk ini, termasuk juga Email, Browser, Aplikasi-Website, Protokol, Komunikasi
Server, Jaringan, Formulir Elektronik, dan juga lain sebagainya… Dan juga harus menentukan apa
dari pemformatan, pesan yang terkait… Termasuk juga pengidentifikasiannya, standar, komunikasi,
yang lainnya… Seperti yang telah digunakan pada FTP, atau HTTP… Dan juga harus menentukan
yang paling terutama ada masalah keamanan ataupun enkripsi komunikasi, juga kecepatan transfer
data, dan juga terhadap mekanisme sinkronisasi… .>
4. Functional Requirement
<Area ini menggambarkan pengorganisasian persyaratan fungsional untuk produk dengan fitur
sistem, layanan utama yang disediakan oleh produk>

<Tulis Kebutuhan Fungsional / Functional Requirement disini>


Diawali dengan membuat daftar kebutuhan fungsional P/L, lengkap dengan ID dan penjelasan jika perlu.
Bisa dibuat dalam bentuk tabel.

ID Kebutuhan Fungsional Penjelasan


00001 Memeriksa Keuangan Saldo Selalu harus rutin memeriksa Saldo
00002 Menarik Keuangan Saldo Perlu melakukan Transaksi Saldo
00003 Menstransfer Keuangan Saldo Rutin menstransfer keuangan salso
00004 Melakukan Pembayaran Perlu melakukan pembayaran
Transaksi
00005 Melakukan Penabungan Saldo Harus melakukan penabungan saldo
00006 Memeriksa Sisa Keuangan Saldo Perlu memeriksa sisa keuangan
saldo transaksi pembayaran
00007 Memantau Transaksi Selalu memantau kesalahan
transaksi pembayaran
00008 Memeriksa Pembelian Barang Perlu memeriksa pembelian barang
00009 Melakukan Peninjauan Transaksi Barang Harus melakukan peninjauan
transaksi barang
00010 Melakukan Peninjauan Kesalahan Transaksi Rutin pemeriksaan/peninjauan
kesalahan transaksi
00011 Memeriksa Kesalahan Transaksi Rutin memeriksa kesalahan
Pembayaran
00012 Pemberian Label Nama Keuangan Transaksi Perlu diberikan Label Nama,
Saldo keuangan transaksi pembayaran
saldo
4.1 Use Case Diagram
<Gambarkan use case diagramnya dari functional requirement yang didapatkan>

4.2
N
a
m
a

Bagan 1Gambar 1. Sistem Penjualan Sederhana

Use Case 1
4.1.1 Deskripsi Use Case
<Diagram use case, atau case diagram, yang dapat menyajikan interaksi, antara use
case, dan actor. Dimana actor, itu bisa berupa orang, peralatan, yang sistem lain,
yang saling berinteraksi dengan sistem yang sedang dibangun, antara lain, adalah:>

Adapun Use Case dari sistem ini, adalah:

1. Pengguna yang mengumpulkan data barang


2. Pengguna yang mengumpulkan data pelanggan
3. Pengguna input, data supplier
4. Pengguna input, data-data, penjualan barang
5. Pengguna input, data-data, pembelian/pemasukan barang
6. Sistem, akan mencetak laporan pelanggan
7. Sistem, akan mencetak laporan data dari supplier
8. Sistem, akan mencetak laporan persediaan barang
9. Sistem, akan mencetak laporan data supplier
10. Sistem, akan mencetak laporan penjualan barang
11. Sistem, akan mencetak laporan pemasukan/pembelian barang

4.1.2 Stimulus and Respon:


<menyediakan daftar aksi yang dilakukan oleh user dan respon dari sistem.>
Action by user Response from system
1. Pengguna yang sering
mengubah kegagalan sistem tidak
terduga
2. Kesalahan sistem sehingga sulit
diproses oleh sistem hingga tidak
terduga.
3. Kegagalan sistem yang
diinterupsi sulit diproses oleh
sistem, hingga tidak terduga.
4 ..Kesalahan sistem yang mudah
dirubah

4.3 Nama Use Case 2

1. Pengguna yang mengumpulkan data barang


2. Pengguna yang mengumpulkan data pelanggan
3. Pengguna input, data supplier
4. Pengguna input, data-data, penjualan barang
5. Pengguna input, data-data, pembelian/pemasukan barang
6. Sistem, akan mencetak laporan pelanggan
7. Sistem, akan mencetak laporan data dari supplier
8. Sistem, akan mencetak laporan persediaan barang
9. Sistem, akan mencetak laporan data supplier
10. Sistem, akan mencetak laporan penjualan barang
11. Sistem, akan mencetak laporan pemasukan/pembelian barang

4.4 Analysis Class Diagram


<Analisis use case, ini adalah sebuah rancangan Teknik yang digunakan untuk mengidentifikasi
persyaratan sistem, (biasanya, terkait dengan perangkat lunak/proses pendesaian,), dan juga
informasi yang digunakan untuk menentukan proses yang digunakan dan kelas, (yang merupakan
kumpulan-kumpulan, actor, dan juga proses), yang akan digunakan lebih baik, dalam diagram use
case, dan secara keseluruhan use case, dalam pengembangan atau desain ulang sistem atau program,
perangkat lunak. Analisi, use case, adalah pada fondasi, yang dimana sistem akan dikembangan
lebih sangat baik….. >

5. Non Functional Requirements


<Uraikan dengan ringkas kebutuhan non fungsional dalam tabel sebagai berikut. Isilah Kolom
Kebutuhan dengan kalimat yang jelas dan kelak dapat ditest untuk dipenuhi. ID adalah nomor
kebutuhan yang harus ditelusuri pada saat test. Tuliskan N/A bila Not Applicable>
ID Parameter Kebutuhan
000001 Availability Perawatan, mesin/peralatan, pemeriksaan perangkat.
000002 Reliability Kehandalan sistem atau perangkat lunak, optimalisasi.
000003 Ergonomy Kenyamanan pemakaian bagi pengguna.
000004 Portability Perangkat lunak, yang dapat ditransfer, pada (Software ).
000005 Memory Kapasitas lebih kecil agar bisa dijadikan Chips
000006 Response time Waktu, yang harus dipenuhi oleh sistem/perangkat
000007 Safety N/A
000008 Security Keamanan paling utama harus dipenuhi oleh sistem/perangkat.
000009
000010 Others 1: Bahasa Misalnya : semua tanya jawab harus dalam bahasa Indonesia.
komunikasi
000011 Productivity Setiap layar harus mengandung logo PT Pos Indonesia.

Catatan :
Availability : ketersediaan aplikasi, misalnya harus terus menerus beroperasi 7 hari perminggu, 24
jam per hari tanpa gagal.
Reliability : keandalan, misalnya tidak pernah boleh gagal(atau kegagalan yang ditolerir adalah …
%) sehingga harus dipikirkan fault tolerant architecture. Biasanya hanya perlu untuk Critical
Application yang jika gagal akan berakibat fatal.
Ergonomy : kenyamanan pakai bagi pengguna
Portability : kemudahan untuk dibawa dan dioperasikan ke mesin/sistem operasi/platform yang
lain
Memory : jika perhitungan kapasitas memori internal kritis (misalnya untuk SW yang harus
dijadikan CHIPS dan ukurannya harus kecil
Response time : Batasan waktu yang harus dipenuhi. Sangat penting untuk aplikasi Real Time.
Contoh: “Aaplikasi harus mampu menampilkan hasil dalam 4 detik”, atau “ATM harus menarik
kembali kartu yang tidak diambil dalam waktu 3 menit”
Safety: yang menyangkut keselamatan manusia, misalnya untuk SW yang dipakai pada sistem
kontrol di pabrik
Security : aspek keamanan yang harus dipenuhi

Anda mungkin juga menyukai