SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

SISTEM INFORMASI PERSEDIAAN BARANG

DISTRO

untuk:

TWILIGHT STORE

Dipersiapkan oleh:

PUTU ADE ANDIKA NUGARAHA

STMIK STIKOM Bali2014

Logo STIKOM

SISTEM INFORMASI

STMIK STIKOM Bali

Nomor Dokumen Halaman

<x: id proyek>SKPL-xxx <#>/<jml #

Revisi <nomor revisi> Tgl: <isi tanggal>

DAFTAR PERUBAHANRevisi Deskripsi

A

B

C

D

E

F

G

INDEX - A B C D E F GTGL

Ditulis oleh

Diperiksa oleh

Disetujui oleh

Daftar Halaman Perubahan

Halaman Revisi Halaman Revisi

Daftar Isi

1. Pendahuluan................................................................................................................................................. 61.1 Tujuan Penulisan Dokumen...............................................................................................................61.2 Lingkup Masalah............................................................................................................................... 61.3 Definisi, Istilah, dan Akronim...........................................................................................................61.4 Aturan Penomoran dan Penamaan.....................................................................................................6

1.4.1 Aturan Penomoran dan Penamaan Spesifikasi Kebutuhan..........................................................61.4.2 Aturan Penomoran dan Penamaan Tabel....................................................................................71.4.3 Aturan Penomoran dan Penamaan Fungsi / Proses.....................................................................7

1.5 Referensi........................................................................................................................................... 71.6 Deskripsi Umum Dokumen............................................................................................................... 7

2 Deskripsi Umum Perangkat Lunak............................................................................................................82.1 Deskripsi Umum Sistem.................................................................................................................... 82.2 Fungsi Produk................................................................................................................................... 82.3 Karakteristik Pengguna..................................................................................................................... 82.4 Batasan-batasan................................................................................................................................. 82.5 Lingkungan Operasi.......................................................................................................................... 8

3 Deskripsi Umum Kebutuhan..................................................................................................................... 83.1 Kebutuhan antarmuka eksternal......................................................................................................... 8

3.1.1 Antarmuka pemakai................................................................................................................... 83.1.2 Antarmuka perangkat keras........................................................................................................93.1.3 Antarmuka perangkat lunak.......................................................................................................93.1.4 Antarmuka komunikasi..............................................................................................................9

3.2 Kebutuhan Fungsional....................................................................................................................... 93.2.1 DFD Level 1.............................................................................................................................. 93.2.2 DFD Level 2 dan seterusnya......................................................................................................9

3.3 Data Requirement............................................................................................................................. 93.3.1 ER Diagram............................................................................................................................... 9

3.4 Deskripsi Kebutuhan Non Fungsional................................................................................................93.5 Batasan Perancangan....................................................................................................................... 103.6 Kerunutan (traceability)................................................................................................................... 10

3.6.1 Data Store vs ER Diagram.......................................................................................................103.7 Ringkasan Kebutuhan...................................................................................................................... 11

3.7.1 Ringkasan Kebutuhan Fungsional............................................................................................113.7.2 Ringkasan Kebutuhan Non Fungsional.....................................................................................11

Lampiran.................................................................................................................................................... 11Lampiran lain yang dianggap perlu......................................................................................................... 11

Daftar GambarHanya dicantumkan dan diisi jika ada gambar pada badan dokumen

Daftar TabelHanya dicantumkan dan diisi jika ada tabel pada badan dokumen

Daftar LampiranHanya dicantumkan dan diisi jika ada lampiran setelah badan dokumen

1. Pendahuluan

1.1 Tujuan Penulisan DokumenProyek perangkat lunak  “Sistem Informasi Persediaan Barang Distro” ini dimaksudkan :

1. Menghasilkan perangkat lunak untuk aplikasi Sistem Informasi Persediaan Barang Distro yang memiliki fitur-fitur standar seperti menambah barang, menghapus barang, menampilkan inventarisasi barang dari clothingan yang menitipkan barangnya di distro tersebut.

2. Memudahkan pekerjaan administrator, karena bisa mendapatkan informasi barang secara cepat dan akurat.

3. Memudahkan pekerjaan up-date barang, karena ada penambahan barang baru  dan pengurangan barang akibat laku terjual maupun hilang.  

1.2 Lingkup MasalahSistem Informasi Persediaan Barang Online digunakan untuk mengatasi masalah dalam membuat persediaan barang distro karena banyaknya barang dari berbagai clothing yang menitipkan barangnya.

1.3 Definisi, Istilah, dan AkronimKata Kunci atau frase Definisi dan atau akronimTOR Term of Reference

Dokumen yang berisi gambaran umum mengenai perangkat lunak yang diminta.

SDP Software Development PlanRPPL Rencana Pengembangan Perangkat Lunak

Dokumen yang berisi rencana pengembangan perangkat lunak dalam suatu proyek, yang mencakup gambaran umum proyek, gambaran manajerial proyek, dan gambaran teknik proyek.

SRS Software Requirement Specification SKPL Spesifikasi Kebutuhan Perangkat Lunak

Dokumen hasil analisis yang berisi spesifikasi kebutuhan user

RPL Rekayasa Perangkat LunakKegiatan pengembangan perangkat lunak

IEEE Institute of Electrical and Electronics EngineersStandar internasional untuk pengembangan dan rancangan produk

ANSI American Standard InstituteLembaga standardisasi Amerika

Tabel 2. Daftar IstilahIstilah DefinisiDistroClothingAdministratorUp-date

1.4 Aturan Penomoran dan Penamaan

1.4.1 Aturan Penomoran dan Penamaan Spesifikasi KebutuhanSetiap kebutuhan perangkat lunak dalam dokumen ini akan diberi penomoran dengan format : SKPL-JK-XX.Y <nama proyek>, dengan : JK adalah jenis kebutuhan. JK dapat diisi dengan :

F untuk jenis kebutuhan fungsional NF untuk jenis kebutuhan non fungsional

XX adalah nomor kebutuhan fungsi (dua digit) dimulai dari 00, 01, 02, … Y adalah nomor fungsi rinci, yang diturunkan dari kebutuhan nomor XX. Jika suatu

kebutuhan bukan turunan maka nilai Y diisi 0.

1.4.2 Aturan Penomoran dan Penamaan TabelTabel diberi nama awalan huruf T kapital, diikuti dengan nama entitas tabel tersebut. Tiap karakter awal kata dalam nama entitas tabel, dimulai dengan huruf kapital, tanpa adanya spasi antar kata bila nama entitas lebih dari satu kata. Penomoran tabel mengikuti format TAB-X, dengan X menyatakan nomor urut tabel.Contoh :TAB-1 TDosenTAB-2 TStandarKredit

1.4.3 Aturan Penomoran dan Penamaan Fungsi / ProsesPenomoran fungsi menurut format FS-X, FS-X.Y, FS-X.Y.Z, dan seterusnya, dengan X,Y,Z menyatakan tingkatan level fungsi/proses pada Data Flow Diagram (DFD) sesuai dengan kedalaman fungsi. Setiap fungsi diberi nama sesuai dengan deskripsinya.Contoh :FS-1.1 Validasi PenggunaFS-1.3.1 Pemilihan Menu

1.5 ReferensiDokumentasi PL yang dirujuk oleh dokumen ini.Buku, Panduan, Dokumentasi lain yang dipakai dalam pengembangan PL ini.

Dokumen ini merujuk pada hasil wawancara dan observasi pada pengguna tentang kebutuhan yang

diperlukannya dan penulisan dokumen berdasarkan pada :

1. IEEE Std 830-1993, IEEE Recommended Practice for Software Requirement Specifications.

2. Panduan Penggunaan dan Pengisian Spesifikasi Kebutuhan Perangkat Lunak (SKPL). Jurusan

Sistem Informasi , STMIK STIKOM Bali, 2014.

3. Pressman, R.S., "Software Engineering, a Practitioner's Approach" Fourth Edition, McGraw Hill,

1997.

1.6 Deskripsi Umum Dokumen Dokumen Spesifikasi Kebutuhan Perangkat Lunak ini terdiri dari tiga bab yang terdiri dari :

BAB I Pendahuluan.

Deskripsikan isinya

BAB II Deskripsi Global Perangkat Lunak

Deskripsikan isinya

BAB III Deskripsi Rinci Kebutuhan

Deskripsikan isinya

2 Deskripsi Umum Perangkat Lunak

2.1 Deskripsi Umum SistemTuliskan System Overview, dalam bentuk gambar dan narasi yang dapat memberikan gambaran tentang aplikasi dan konteksnya (gambar yang mirip dengan Context diagram, tetapi dengan logo yang lebih gampang dimengerti awam).

2.2 Fungsi ProdukMemuat fungsi-fungsi sistem yang utama dan diberikan langsung ke pengguna, kira-kira sama dengan

DFD level 1, tapi dengan kata-kata Boleh juga disertai dengan diagram semacam yang telah dibuat

dengan judul diagram keterkaitan antar modul

1. (SKPL-F-01) Dapat mengelola data dosen2. (SKPL-F-02) Dapat mengelola data mahasiswa

2.3 Karakteristik PenggunaMinimal sebuah tabel dengan Kolom: Pengguna, Pekerjaan, Hak Akses. Kolom Hak Akses

dihubungkan dengan Fungsi utama yang muncul pada Fungsi Produk

Tabel 1. Karakteristik pengguna

Kategori Pengguna AktivitasNasabah Melakukan transaksi Petugas Bank

2.4 Batasan-batasanBatasan (jika ada), ketergantungan SW terhadap SW/HW sistem lain

Batasan yang harus dipakai. Misalnya :

- harus memakai file data dari Sistem lain (sebutkan),

- harus memakai format data yang sama dengan sistem lain

- harus berfungsi multi platform (di Windows dan linux)

2.5 Lingkungan OperasiOperating system, DBMS, ...

Aplikasi Client server ini akan berfungsi dengan spesifikasi:Server: ???Client: ????OS:DBMS:

3 Deskripsi Umum Kebutuhan

3.1 Kebutuhan antarmuka eksternal

3.1.1 Antarmuka pemakaiUser interface untuk mengoperasikan Perangkat Lunak : keyboard, mouse

3.1.2 Antarmuka perangkat kerasHanya diisi jika perlu perangkat keras khusus, misalnya CARD XXX, CABLE XYZ

3.1.3 Antarmuka perangkat lunakHanya diisi jika PL memakai interface (berupa PL), misalnya API (Application Programming

Interface) Windows.

3.1.4 Antarmuka komunikasiHanya diisi jika PL beroperasi di jaringan dan membutuhkan alat komunikasi khusus, misalnya

RS232.

3.2 Kebutuhan Fungsional

3.2.1 DFD Level 1Termasuk di dalamnya deskripsi dari proses yang ada di dalam DFD, contoh:

Proses Data Masuk Data Keluar Deskripsi Proses

3.2.2 DFD Level 2 dan seterusnya

3.3 Data Requirement

3.3.1 ER DiagramGambar E-R diagram yang benar-benar konseptual, dengan VISIO. Minimal ada nama Entity, Relasi dan Key (Skema relasi). Sudah dijelaskan apa bedanya E-R konseptual dengan Conceptual Data Model pada Case Tools, karena E-R diagram ini tidak mungkin digambar dengan Case Tools. Keterbatasan CASE Tools biasanya adalah:- tidak mungkin mempunyai relasi dengan atribut non-key- tidak mungkin mempunyai relasi bukan biner (terner, dan lebih tinggi)sehingga akibatnya, relasi dijadikan “entity”. Kenapa E-R konseptual disarankan untuk digambar, adalah karena E-R ini sebenarnya lebih mencerminkan abstraksi perancang

3.4 Deskripsi Kebutuhan Non Fungsional

Uraikan dengan ringkas kebutuhan non fungsional dalam tabel sebagai berikut. Isilah Kolom Kebutuhan dengan kalimat yang jelas dan kelak dapat ditest untuk dipenuhi. SRS-Id adalah nomor requirement yang harus ditelusuri pada saat test. Tuliskan N/A bila Not Applicable..Catatan:Availability: ketersediaan aplikasi, misalnya harus terus menerus beroperasi 7 hari perminggu, 24 jam per haritanpa gagalReliability: 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 lainMemory: jika perhitungan kapasitas memori internal kritis (misalnya untuk SW yang harus dijadikan CHIPS dan ukurannya harus kecilResponse time: Batasan waktu yang harus dipenuhi. Sangat penting untuk aplikasi Real Time. Contoh: “Aplikasi harus mampu menampilkan hasil dalam 4 detik”, atau “ATM harus menarik kembali kartu yang tidak diambil dalam waktu 30 detik”Safety: yang menyangkut keselamatan manusia, misalnya untuk SW yang dipakai pada sistem kontrol di pabrikSecurity: aspek keamanan yang harus dipenuhi.

Tabel 3-1 Non Functional Requirement

No. SKPL Parameter Kebutuhan(SKPL-NF-01.0) Response Time Pengguna menerima indikasi reaksi

terhadap aksinya maksimal 3 detik setelah aksi dilakukan

(SKPL-NF-02.0) Availability Perangkat lunak berjalan selama jam kerja Departemen ......., yaitu dari hari Senin sampai Jumat, pukul 07.00 sampai pukul 17.00

(SKPL-NF-03.0) Portability Perangkat lunak dapat diinstall pada computer yang diminta pelanggan, asalkan memenuhi batasan lingkungan operasi yang diperlukan perangkat lunak

(SKPL-NF-05.0) Ergonomy Tampilan antarmuka menggunakan Graphical User Interface (GUI)

(SKPL-NF-06.0) Ergonomy Perangkat lunak menggunakan format menu seperti pada perangkat lunak yang biasa terdapat pada sistem operasi Windows 9x

(SKPL-NF-07.0) Ergonomy Perangkat lunak menggunakan bahasa Indonesia untuk antarmuka dan komunikasi dengan pengguna

(SKPL-NF-08.0) Ergonomy Perangkat lunak akan menampilkan logo Departemen Teknik Informatika di setiap layar antarmuka

3.5 Batasan PerancanganPenjelasan tentang batasan dari perancangan yang di buat .Seperti : Sistem Pemanfaatan Teknologi Aplikasi kampus akan diimplementasikan pada Sistem Operasi berbasis WINDOWS, menggunakan bahasa pemrograman PHP dengan database Microsoft SQL Server 2000.

Contoh : harus memakai library yang ada, harus memakai sepotong kode yang sudah pernah dikembangkan, harus memperhatikan hal-hal tertentu

3.6 Kerunutan (traceability)Diisi dengan tabel yang berisi traceability dari hasil analisis. Gunanya untuk menilai apakah hasil analisis “runut” dan lojik. Untuik sementara, baru didefinisikan Data-store versus E-R.

No SKPL Nama ProsesSKPL-F1 Menampilkan halaman utamaSKPL-F2 Koneksi ke database

3.6.1 Data Store vs ER DiagramData Store Entitas RelasiPegawai tb_Pegawai Dinamis / StatisPotongan tb_potongan Mempunyai potongan ... ???Data Masuk ??? ???

3.7 Ringkasan KebutuhanBab ini berisi ringkasan semua “Requirement item”. Requirement item ini mencerminkan semua hal yang harus dipenuhi, dan nantinya akan menjadi arahan untuk tahapan testing, karena pada dasarnya, semua requirement harus dapat ditest supaya dapat dibuktikan dipenuhi. Dibagi menjadi dua bagian: functional dan non functional

3.7.1 Ringkasan Kebutuhan FungsionalNomor Kebutuhan Fungsional(SKPL-F-01.1) Mengubah data dosen(SKPL-F-01.2) Menghapus data dosenSKPL-F-02.0 Data MahasiswaSKPL-F-02.1 Melihat Data MahasiswaSKPL-F-02.2 Menghapus Data MahasiswaSKPL-F-02.3 Mengubah Data Mahasiswa

3.7.2 Ringkasan Kebutuhan Non FungsionalNomor Kebutuhan Non FungsionalSKPL-NF-01.0 Pengguna menerima indikasi reaksi terhadap aksinya

maksimal 3 detik setelah aksi dilakukanSKPL-NF-02.0 Perangkat lunak berjalan selama jam kerja

Departemen ......., yaitu dari hari Senin sampai Jumat, pukul 07.00 sampai pukul 17.00

Lampiran

Lampiran lain yang dianggap perluJika ada lampiran lain yang perlu disertakan, dan berhubungan dengan Analisis dan Perancangan