32
Panduan Penulisan Spesifikasi Kebutuhan Perangkat Lunak (SKPL) 1. Pendahuluan Dokumen ini akan berisi penjelasan pemakaian dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement Specification (SRS). Untuk penamaan dokumen ini selanjutnya akan digunakan istilah SKPL. Isi dari dokumen ini sebagian besar adalah terjemahan dari dokumen IEEE Std 830-1993. 1.1 Lingkup Persoalan Dokumen ini digunakan untuk acuan dalam menulis SKPL. Akan diberikan juga beberapa outline dari SKPL. Dokumen ini dibuat untuk membantu membuat spesifikasi perangkat lunak yang akan dikembangkan. 2. Referensi IEEE Std 830-1993, IEEE Recommended Practice for Software Requirement Specifications. IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology (ANSI). 3. Definisi Definisi dari istilah yang akan digunakan pada dokumen ini dibuat berdasarkan hasil terjemahan dari IEEE Std 610.12-1990. 3.1 Kontrak Adalah suatu dokumen legal yang disetujui oleh pelanggan dan pengembang. Dalam kontrak akan disertai dengan kebutuhan teknis, organisasi, biaya dan jadwal pengerjaan produk. Kontrak dapat berisi informasi yang berguna, misalnya komitmen dan harapan dari organisasi yang terlibat. 3.2 Pelanggan Adalah orang atau organisasi yang membayar produk, dan biasanya (tidak harus) ia yang akan memutuskan kebutuhannya. Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 1

aturan skpl

Embed Size (px)

DESCRIPTION

aturan skpl

Citation preview

Page 1: aturan skpl

Panduan Penulisan

Spesifikasi Kebutuhan Perangkat Lunak (SKPL) 1. Pendahuluan

Dokumen ini akan berisi penjelasan pemakaian dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement Specification (SRS). Untuk penamaan dokumen ini selanjutnya akan digunakan istilah SKPL. Isi dari dokumen ini sebagian besar adalah terjemahan dari dokumen IEEE Std 830-1993.

1.1 Lingkup PersoalanDokumen ini digunakan untuk acuan dalam menulis SKPL. Akan diberikan juga beberapa

outline dari SKPL.

Dokumen ini dibuat untuk membantu membuat spesifikasi perangkat lunak yang akan dikembangkan.

2. Referensi

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

IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology (ANSI).

3. Definisi

Definisi dari istilah yang akan digunakan pada dokumen ini dibuat berdasarkan hasil terjemahan dari IEEE Std 610.12-1990.

3.1 Kontrak Adalah suatu dokumen legal yang disetujui oleh pelanggan dan pengembang. Dalam kontrak akan disertai dengan kebutuhan teknis, organisasi, biaya dan jadwal pengerjaan produk. Kontrak dapat berisi informasi yang berguna, misalnya komitmen dan harapan dari organisasi yang terlibat.

3.2 PelangganAdalah orang atau organisasi yang membayar produk, dan biasanya (tidak harus) ia yang akan memutuskan kebutuhannya.

3.3 PengembangAdalah orang yang menghasilkan produk untuk pelanggan.

3.4 PenggunaAdalah orang yang akan langsung menjalankan atau menggunakan produk. Pengguna dan pelanggan umumnya adalah orang yang sama.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 1

Page 2: aturan skpl

4. Pertimbangan Pembuatan SKPL yang Baik

Beberapa hal yang harus diperhatikan dalam pembuatan SKPL adalah:

1. Sifat dari SKPL2. Lingkungan SKPL3. Karakteristik SKPL yang baik4. Persiapan SKPL5. Evolusi SKPL6. Prototipe SKPL7. Pemasukan Rancangan pada SKPL8. Pemasukan kebutuhan proyek pada SKPL

4.1 Sifat dari SKPLSKPL adalah spesifikasi dari suatu produk/program yang melakukan suatu fungsi tertentu

pada lingkungan tertentu. SKPL dapat dibuat oleh wakil dari pengembang atau wakil dari pelanggan. Sebaiknya SKPL dibuat bersama-sama oleh pengembang dan pelanggan.

Penulis SKPL harus memperhatikan hal-hal berikut:

1. Fungsionalitas - Untuk apa suatu perangkat lunak dibuat.2. Antar muka eksternal (External Interface) - Bagaimana perangkat lunak berinteraksi dengan

pengguna, perangkat keras sistem, perangkat keras di luar sistem dan perangkat lunak lain. 3. Performansi - Bagaimana kecepatannya, ketersediaannya (availability), waktu tanggap

(response time), waktu recovery dari berbagai fungsi perangkat lunak.4. Atribut - Bagaimana tingkat portabilitas, tingkat kebenaran (correctness), tingkat

pemeliharaan (maintainability), keamanannya.5. Batasan perancangan - Apakah diperlukan suatu standar, bahasa yang khusus, kebijaksanaan

integritas basisdata, batasan sumberdaya, lingkungan operasi, dan lain-lain.

Penulis SKPL harus menghindari kebutuhan perancangan atau kebutuhan proyek dalam SKPL.

4.2 Lingkungan SKPLKarena SKPL akan memainkan peranan penting dalam proses pengembangan perangkat lunak, penulis SKPL harus secara berhati-hati dalam memainkan peranannya. Jadi suatu dokumen SKPL harus memenui syarat-syarat berikut:

1. Mendefinisikan kebutuhan perangkat lunak dengan benar. Kebutuhan perangkat lunak muncul karena ada pekerjaan yang harus diselesaikan atau karena ada karakteristik khusus dari projek.

2. Tidak menjelaskan rancangan atau implementasi dengan rinci. Penjelasan tersebut tidak diperlukan karena bagi pengguna hal tersebut lebih teknis dan tidak perlu.

3. Tidak memaksakan penambahan suatu batasan dari perangkat lunak.

4.3 Karakteristik SKPL yang baikKarakterisitk SKPL yang baik adalah sebagai berikut:

1. BenarPanduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 2

Page 3: aturan skpl

2. Tidak ambigu3. Lengkap4. Konsisten5. Terurut berdasarkan kepentingannya atau kestabilannya6. Dapat diverifikasi7. Dapat dimodifikasi8. Dapat ditelusuri (traceable)

4.3.1 Benar

SKPL dianggap benar jika dan hanya jika setiap kebutuhan yang telah ditetapkan telah tercantum dalam dokumen. Tidak ada alat (tool) atau prosedur yang dapat digunakan untuk menjamin kebenaran.

4.3.2 Tidak ambigu

SKPL tidak ambigu jika dan hanya jika setiap kebutuhan yang ditetapkan hanya memiliki satu interpretasi. Minimum kebutuhan dari setiap karakteristik produk akhir dijelaskan dalam satu istilah yang unik. Jika istilah tersebut memiliki banyak arti, pada harus diberikan penjelasan. Jadi SKPL tidak boleh membingungkan baik bagi pembuat ataupun yang akan menggunakannya.

4.3.2.1 Kelemahan Bahasa Manusia

Kebutuhan sering ditulis dalam bahasa manusia (misalnya bahasa Indonesia atau bahasa Inggris). Bahasa manusia ini sering tidak jelas (ambigu). Bahasa yang digunakan dalam SKPL harus didiskusikan oleh pihak lain yang independen untuk mengindentifikasi ketidakjelasan dalam pemakaian bahasa.

4.3.2.2 Bahasa Spesifikasi Kebutuhan

Salah satu cara untuk menghilangkan keraguan dalam penulisan bahasa ini, adalah dengan menuliskan SKPL dengan suatu bahasa spesifikasi kebutuhan yang khusus. Pemroses bahasanya akan dapat mendeteksi kesalahan leksikal, sintaks atau semantik.

Kelemahan dalam menggunakan bahasa tersebut adalah waktu yang panjang untuk mempelajarinya. Juga banyak pengguna non teknis akan kesulitan. Bahasa spesifikasi kebutuhan ini cenderung akan lebih dapat digunakan pada kebutuhan khusus, dan sistem tertentu.

4.3.2.3 Alat Presentasi

Secara umum, kebutuhan metode dan bahasa serta alat pendukungnya, akan dibagi menjadi tiga kategori, yaitu objek, proses dan perilaku (behaviour).

Pendekatan berbasis objek akan mengorganisasikan kebutuhan dalam bentuk objek-objek dengan atribut dan pelayanan (fungsi) yang dimiliki dari setiap objek.

Pendekatan berbasis proses akan mengatur kebutuhan menjadi fungsi-fungsi hirarki yang saling berkomunikasi melalui suatu jalur aliran data.

Pendekatan berbasis perilaku menjelaskan perilaku eksternal dari sistem dalam suatu pendekatan abstrak (dengan predikat kalkulus), fungsi matematika atau mesin status.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 3

Page 4: aturan skpl

Tingkat kebergunaan dalam pemakaian suatu tools dan metode mungkin berguna dalam menyiapkan SKPL tergantung pada ukuran dan kompleksitas dari program. Dalam menggunakan berbagai pendekatan ini akan lebih baik untuk membentuk deskripsi bahasa alami, dengan demikian pelanggan yang tidak biasa dengan notasi tersebut akan tetap dapat mengerti SKPL.

4.3.3 Lengkap

SKPL adalah lengkap jika dan hanya jika sudah melibatkan elemen-elemen berikut:

1. Semua kebutuhan-kebutuhan penting sudah tercakup (fungsionalitas, performansi, batasan perancangan, atribut atau antar muka eksternal).

2. Semua definisi masukan pada berbagai kondisi sudah terpenuhi3. Referensi yang lengkap dari setiap gambar, tabel dan diagram pada SKPL, dan disertai

dengan semua istilah yang digunakan dan unit yang digunakan sebagai pengukuran (bila ada).

Penggunaan istilah ‘TBD’ atau ‘To Be Defined’ atau ‘Sedang dalam pengembangan’ menunjukkan SKPL yang tidak lengkap. Tetapi bagaimana pun istilah tersebut sering harus digunakan. Pada kasus tersebut harus disertai dengan penjelasan yang menyertai pernyataan tersebut (misalnya kenapa suatu jawaban belum ditemukan), sehingga situasi tersebut akan dapat diselesaikan. Selain itu perlu didefinisikan cara menghilangkan pernyataan tersebut, dengan memberikan juga siapa yang bertanggung jawab, dan kapan harus sudah dihilangkan.

4.3.4 Konsisten

Dalam hal ini konsisten berhubungan dengan konsistensi internal. Jika suatu SKPL tidak mengacu ke dokumen lain yang sifatnya memiliki tingkat lebih tinggi, maka SKPL tersebut tidak benar.

4.3.4.1 Konsistensi Internal

Suatu dokumen tidak konsisten secara internal jika dan hanya jika tidak ada kebutuhan yang konflik. Ada tiga tipe yang dapat menyebabkan konflik dalam SKPL:

1. Karakteristik yang ditentukan pada objek nyata mungkin konflik. Misalnya:1.1. Suatu kebutuhan format laporan keluaran mungkin dijelaskan sebagai tabel, tetapi

pada pada kebutuhan lain berbentuk tekstual.1.2. Suatu kebutuhan mungkin menyatakan suatu hal yang bertentangan dengan

pernyataan lain2. Kemungkinan ada konflik logika antara dua aksi, misalnya:

2.1. Suatu kebutuhan mungkin menetapkan bahwa program harus menjumlah dua masukan dan kebutuhan lain mungkin menentukan harus dikali.

2.2. Suatu kebutuhan menyatakan bahwa suatu status A akan mengikuti status B, tetapi pernyataan lain menyatakan status B yang akan mengikuti A.

3. Dua atau lebih kebutuhan mungkin dapat dijelaskan dengan objek dunia nyata yang sama, tetapi karena kebutuhannya berbeda, sebaiknya menggunakan istilah yang berbeda. Misalnya suatu program yang meminta masukan dari pengguna mungkin disebut sebagai prompt, tetapi pada kebutuhan lain mungkin disebut membaca masukan dari pengguna.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 4

Page 5: aturan skpl

4.3.5 Pengurutan berdasarkan kepentingannya/kestabilannya

Suatu SKPL diurutkan berdasarkan tingkat kepentingan/kestabilan dari setiap kebutuhannya. Hal tersebut dapat diberikan suatu tanda untuk menunjukkan kepentingan atau kestabilannya. Umumnya semua kebutuhan yang berhubungan dengan produk perangkat lunak tidak memiliki kepentingan yang sama. Beberapa kebutuhan mungkin bersifat harus, khususnya untuk aplikasi yang kritis, sementara yang lain bersifat sebaiknya.

Setiap kebutuhan dalam SKPL harus diidentifikasi agar perbedaan ini jelas dan eksplisit. Pengenalan kebutuhan yang ada dengan cara berikut mungkin akan dapat membantu:

1. Pelanggan harus memberikan pemikiran yang rinci terhadap kebutuhannya, yang sering akan memperjelas setiap asumsi yang sebelumnya tersembunyi.

2. Pengembang harus melakukan perancangan yang benar dan bersungguh-sungguh melakukan usaha yang sesuai dengan levelnya pada bagian yang berbeda dari perangkat lunak.

4.3.5.1 Tingkat Kestabilan

Suatu metode untuk mengenali kebutuhan adalah dengan menggunakan dimensi kestabilan. Kestabilan dapat dinyatakan dalam jumlah perubahan yang diharapkan pada setiap kebutuhan yang berdasarkan pada pengalaman atau pengetahuan akan kejadian yang akan datang yang mungkin dapat berakibat pada organisasi, fungsi , orang yang didukung oleh sistem perangkat lunak.

4.3.5.2 Tingkat Keperluan (Degree of Necessity)

Cara lain untuk mengurutkan kebutuhan adalah dengan membedakan kelas kebutuhan sebagai bersifat perlu, kondisional dan opsional.

1. Sifat Perlu menunjukkan bahwa perangkat lunak tidak akan diterima jika kebutuhan-kebutuhan tidak disetujui secara tidak jelas

2. Sifat Kondisional menunjukkan bahwa kebutuhan-kebutuhan ini akan memperbaiki produk perangkat lunak, dan tidak akan diterima jika tidak ada.

3. Sifat Opsional menunjukkan kelompok fungsi yang mungkin berguna atau mungkin tidak. Pengembang akan mendapat kesempatan untuk mengajukan sesuatu yang melebihi SKPL.

4.3.6 Dapat diverifikasi

Suatu SKPL disebut dapat diverfikasi, jika dan hanya jika setiap kebutuhan sudah terverifikasi. Suatu kebutuhan dapat diverifikasi jika dan hanya jika ada suatu proses yang efektif untuk mmeriksa apakah suatu produk perangkat lunak sudah memenuhi kebutuhan. Jadi secara umum, kebutuhan yang ambigu tidak dapat diverifikasi.

Kebutuhan yang tidak dapat diverifikasi termasuk pernyataan seperti “bekerja dengan baik”, “interaksi manusia yang baik” atau “biasanya terjadi”. Kebutuhan-kebutuhan ini tidak dapat diverikasi karena hampir tidak mungkin mendefinisikan istilah baik, atau biasanya. Pernyataan “program jangan pernah masuk ke pengulangan yanag tidak terbatas” juga tidak dapat diverifikasi, karena pengujian kualitas ini secara teori tidak mungkin.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 5

Page 6: aturan skpl

Contoh pernyataan yang dapat diverifikasi: “Keluaran program harus diproduksi dalam 20 detik dan harus diproduksi lagi selama 30 detik”. Statement tersebut dapat diverifikasi kaena penggunaan istilah dan kuantitas yang terukur.

4.3.7 Dapat dimodifikasi

SKPL dapat dimodifikasi, jika dan hanya jika strukturnya memungkinkan setiap perubahan terhadap kebutuhan dapat dibuat dibuat secara mudah, lengkap dan konsisten, dengan tetap mempertahankan struktur. Kemampuan dapat dimodifikasi umumnya menghendaki SKPL yang,

1. memiliki organisasi yang mudah digunakan dengan daftar isi, indeks dan cross-reference.2. tidak ada duplikasi yang tidak perlu. Jadi suatu kebutuhan tidak perlu muncul lebih dari satu

tempat di SKPL3. Setiap kebutuhan sebaiknya dinyatakan secara terpisah.

Duplikasi sendiri bukanlah suatu kesalahan, tetapi adalah sumber terjadinya kesalahan. Duplikasi dapat membantu membuat SKPL menjadi lebih mudah dibaca, tetapi masalah muncul jika ada proses terhadap duplikasi dokumen. Misalnya jika suatu kebutuhan diubah hanya pada satu dokumen, akan menyebabkan tidak konsisten. Jika memang diperlukan duplikasi, SKPL harus menyertakan cross-reference yang membuatnya dapat dimodifikasi.

4.3.8 Dapat ditelusuri (traceable)

SKPL dapat ditelusuri jika asal dari kebutuhan sudah jelas dan memberikan fasilitas untu mereferensi setiap kebutuhan dalam pengembangan masa depan dan perbaikan dokumen. Dua tipe kemampuan penelusuran dibutuhkan.

1. Dapat ditelusuri ke belakang (Backward Traceability) atau ke tahapan sebelumnya. Hal ini tergantung pada setiap kebutuhan yang mereferensi ke sumber pada dokumen sebelumnya.

2. Dapat ditelusuri ke depan (Forward Traceability) atau semua dokumen yang dihasilkan setelah SKPL. Hal ini tergantung pada setiap kebutuhan dalam SKL memiliki nomor yang khas (nomor referensi).

Penelusuran ke depan dari SKPL akan sangat penting ketika produk perangkat lunak memasuki fase operasi dan perawatan. Saat dokumen perancangan dan kode program di modifikasi, adalah penting untuk memastikan bahwa semua kebutuhan akan terkait dengan modifikasi tersebut.

4.4 Persiapan Bersama SKPLDalam proses pengembangan perangkat lunak mula-mula harus disepakati perjanjian

antara pengembang dan pelanggan tentang apa yang harus dilakukan oleh perangkat lunak. Perjanjian ini, dalam bentuk SKPL, harus dipersiapkan bersama. Hal ini penting karena biasanya baik pelanggan ataupun pengembang itdak dapat menulis SKPL sendiri.

1. Pelanggan biasanya tidak mengerti proses perancangan dan pengembangan yang cukup untuk menulis SKPL

2. Pengembang biasanya tidak mengerti masalah pelanggan untuk menentukan setiap kebutuhan.

Karena itu pelanggan dan pengembang harus bekerja sama mengembangkan SKPL.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 6

Page 7: aturan skpl

Situasi khusus mungkin terjadi jika sistem dan perangkat lunak dibuat secara bersama. Maka fungsioalitas, antar muka, performansi dan batasan lain dari perangkat lunak tidak terdefinisi sebelumnya, tetapi terdefinisi secra bersama-sama, dan biasanya ini adalah memerlukan negosiasi. Kasus ini akan lebih sulit, tapi tetap harus memperhatikan hal-hal yang sudah dituliskan di 4.3. Jadi secara khusus, SKPL yang tidak sesuai dengan kebutuhan adalah SKPL yang tidak benar.

4.5 Evolusi SKPLSKPL dapat berevolusi seperti juga pada pengembangan perangkat lunak. Karena

mungkin tidak mungkin untuk men-spesifikasi-kan secara rinci pada saat proyek dimulai. Perubahan-perubahan tambahan diperlukan untuk efisiensi, menutupi kelemahan-kelemahan atau ketidakakuratan pada SKPL. Dua pemikiran dalam proses ini adalah sebagai berikut:

1. Kebutuhan harus dispesifikasikan secara lengkap. Bila belum lengkap harus dicatat.2. Proses perubahan formal dapat dimulai untuk mengidentifikasi, mengendalikan, menelusuri

dan melaporkan setiap perubahan.

4.6 Prototipe SKPLPrototipe sering digunakan selama fase kebutuhan dalam proyek. Banyak tool yang sudah

tersedia untuk membuat prototipe, yang hanya menampilkan beberapa aspek karakteristik dari sistem. Prototipe ini biasanya dibuat dengan sangat cepat dan mudah. Prototipe akan berguna karena tiga alasan:

1. pelanggan biasanya lebi mudah melihat prototipe daripada membaca SKPL. Jadi kadang-kadang prototipe dapat memberikan masukan dengan cepat

2. Prototipe menampilkan aspek yang tidak terantisipasi dalam melihat perilaku sistem. Jadi kadang-kadang tidak hanya memberikan jawaban tetapi juga menimbulkan pertanyaan baru. Hal ini akan membantu pelengkapan SKPL

3. SKPL yang menggunakan teknik prototipe akan cenderung mengalami perubahan sealma pengembangan, sehingga mengurangi waktu pengembangan.

4.7 Pemasukan Rancangan pada SKPLSuatu kebutuhan mendefinisikan fungsi yang terlihat dari sistem. Suatu rancangan

menjelaskan tentang subkomponen dari sistem atau antarmukanya dengan komponen lain. Penulis SKPL harus secara jelas membedakan antara pengenalan batasan rancangan. Jadi setiap kebutuhan dalam SKPL akan membatasi setiap alternatif perencanaan. Tetapi hal ini bukan berarti setiap kebutuhan sudah dirancang.

SKPL harus menentukan fungsi-fungsi yang akan dilakukan terhadap suatu data untuk memberikan suatu hasil pada seseorang. SKPL harus memfokuskan pada layanan yang dilakukan. SKPL seharusnya tidak menspesifikasikan item rancangan sebagai berikut:

1. Pembagian perangkat lunak menjadi modul-modul2. Pengalokasian suatu fungsi dari modul-modul3. Penjelasan aliran informasi antar bagian dari program4. Pemilihan struktur data

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 7

Page 8: aturan skpl

Pada kasus khusus, beberapa kebutuhan akan membatasi rancangan secara tegas. Misalnya kebutuhan akan keamanan atau keselamatan mungkin dapat dirancang secara langsung ke perancangan untuk memenuhi kebutuhan:

1. Pemisahan fungsi dan modul2. Hanya mengijinkan komunikasi antar area dalam program3. Pemeriksaan integritas data untuk variabel kritis

Contoh batasan perancangan yang baik adalah kebutuhan fisik, kebutuhan performansi, standard pengembangan perangkat lunak dan standard jaminan kualitas perangkat lunak.

Jadi kebutuhan harus dinyatakan dari sudut pandang eksternal. Jika menggunakan model ini untuk mengilustrasikan kebutuhan, ingat bahwa model hanya menyatakan perilaku eksternal, dan tidak menspesifikasikan perancangan.

4.8 Pemasukan kebutuhan proyek pada SKPLSKPL seharusnya menyelesaikan persoalan hasil jadi perangkat lunak, bukan proses

untuk menghasilkannya. Kebutuhan proyek mewakili pengertian antara pelanggan dan pengembang tentang masalah kontrak yang berhubungan dengan produksi perangkat lunak dan sebaiknya tidak diikut sertakan dalam SKPL. Hal-hal yang diperahtikan antara lain:

1. Biaya2. Jadwal penyerahan3. Aturan pelaporan4. Metode Pengembangan Perangkat Lunak5. Jaminan Kualitas6. Kriteria Validasi dan Verifikasi7. Aturan penerimaan (acceptance procedure).

Kebutuhan proyek akan ditentukan pada dokumen lain, umumnya dalam dokumen perencanaan pengembangan perangkat lunak, perencanaan jaminan kualitas atau statement of work.

5. Bagian-bagian SKPL

Bagian-bagian penting dari SKPL adalah sebagai berikut:

Daftar Isi1. Pendahuluan

1.1 Tujuan1.2 Lingkup Masalah1.3 Definisi, Akronim dan Singkatan1.4 Referensi1.5 Deskripsi umum (Overview)

2. Deskripsi Keseluruhan2.1 Perspektif produk2.2 Fungsi Produk2.3 Karakteristik Pengguna2.4 Batasan-batasan

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 8

Page 9: aturan skpl

2.5 Asumsi dan Ketergantungan

3. Kebutuhan khusus (penjelasan ada di lampiran A)

LampiranIndeks

5.1 PendahuluanPendahuluan dari SKPL harus memberikan gambaran umum dari seluruh SKPL. Dan harus berisi bagian-bagian berikut:

1.1 Tujuan1.2 Lingkup Masalah1.3 Definisi, Akronim dan Singkatan1.4 Referensi1.5 Deskripsi umum (Overview)

5.1.1 Tujuan

Bagian ini harus menunjukkan tujuan SKPL, dan juga menentukan siapa yang akan menggunakan SKPL ini.

5.1.2 Lingkup Masalah

Bagian ini harus:

1. Mengidentifikasi produk perangkat lunak berdasarkan nama (misalnya DBMS yang digunakan, Report Generator, dan lain-lain).

2. Menjelaskan apa yang akan dilakukan dan tidak dilakukan (bila perlu) oleh perangkat lunak 3. Penjelasan aplikasi yang ditentukan termasukan keuntungan, dan tujuan4. Konsisten dengan spesifikasi sistem yang diberikan (jika ada)

5.1.3 Definisi, akronim dan singkatan

Harus memberikan penjelasan terhadap semua definisi, akronim dan singkat yang digunakan untuk menginterpretasikan SKPL. Informasi ini dibagi dengan mereferensikan satu atau lebih lampiran dalam SKPL atau referensi ke dokumen lain.

5.1.4 Referensi

Bagian ini harus memberikan:

1. Daftar lengkap dari dokumen yang direferensikan 2. Identifikasi dari setiap dokumen berdasarkan judul, nomor laporan, tanggal dan penerbit3. sumber-sumber referensi yang didapat

5.1.5 Deskripsi Umum

Bagian ini menjelaskan apa isi SKPL, dan bagaimana organisasi SKPL.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 9

Page 10: aturan skpl

5.2 Deskripsi UmumBagian ini menjelaskan faktor-faktor umum yang berakibat pada produk dan kebutuhannya. Bagian ini tidak memberikan kebutuhan rinci, hanya latar belakang dari kebutuhan tersebut yang akan dibuat lebih rinci di bagian 3. Dengan organisasi ini diharapkan hasilnya lebih mudah dimengerti. Bagian ini terdiri dari

2.1 Perspektif produk2.2 Fungsi Produk2.3 Karakteristik Pengguna2.4 Batasan-batasan2.5 Asumsi dan Ketergantungan

5.2.1 Perspektif produk

Bagian ini akan memberikan penjelasan perspektif produk dengan produk yang terkait. Jika produk tidak tergantung maka harus juga dinyatakan di sini. Jika SKPL mendefinisikan produk sebagai komponen sistem yang lebih besar (hal ini sering terjadi), maka bagian ini harus menghubungkan dengan kebutuhan dari sistem yang lebih besar ini hingga fungsionalitas dari perangkat lunak dan harus mengindentifikasikan antarmuka antara sistem dan perangkat lunak.

Suatu diagram blok dapat menunjukkan komponen utama dari sistem yang lebih besar, interkoneksi dan antarmuka eksternal.

Bagian ini harus menjelaskan bagaimana perangkat lunak akan beroperasi dalam berbagai batasan. Bagian ini biasanya melibatkan:

1. Antarmuka Sistem2. Antarmuka Pemakai3. Antarmuka Perangkat Keras4. Antarmuka Perangkat Lunak5. Antarmuka Komunikasi6. Batasan Memori7. Operasi8. Kebutuhan adaptasi lokasi

5.2.1.1 Antarmuka Sistem

Bagian in akan menampilkan antaramuka sistem dan mengidentifikasi fungsionalitas dari perangkat lunak untuk mencapai kebutuhan sistem dan deskripsi antarmuka untuk mencocokkan sistem.

5.2.1.2 Antarmuka Pemakai

Bagian ini akan berisi hal-hal berikut:

1. Karakteristik logis dari setiap antarmuka antara produk perangkat lunak dan penggunanya. Hal ini akan melibatkan karakteristik konfigurasi (misalnya format layar yang diperlukan, tataletak window, isi laporan/menu atau ketersediaan kunci khusus) untuk memenuhi kebutuhan sistem.

2. Semua aspek optimisasi antarmuka dengan orang yang akan menggunakan sistem. Bagian ini mungkin hanya berisi daftar yang harus dan tidak akan dilakukan oleh sistem bagi sudut

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 10

Page 11: aturan skpl

pandang pengguna. Misalnya kebutuhan untuk pemilihan pesan yang singkat atau panjang. Seperti kebutuhan lain, kebutuhan ini harus dapat di verifikasi. Misalnya kalimat “seorang pegawai berpengalaman dapat melakukan X dalam Z menit setelah 1 jam training” akan lebih baik daripada hanya mendefinisikan “Seorang pegawai berpengalaman dapat melakukan X”.

5.2.1.3 Antarmuka Perangkat Keras

Bagian ini akan menjelaskan karakteristik logis dari setiap antarmuka antara produk perangkat lunak dan komponen perangkat keras dari sistem. Bagian ini akan melibatkan karakteristik konfigurasi (jumlah port, jumlah instruksi, dll). Antarmuka ini juga melibatkan hal-hal seperti perangkat pendukung, dan bagaimana peralatan tersebut menjadi pendukung, dan protokol.

5.2.1.4 Antarmuka Perangkat Lunak

Bagian ini menspesifikasikan penggunaan produk perangkat lunak lain (misalnya sistem manajemen basisdata, sistem operasi atau paket matematik) dan antarmuka dengan sistem aplikasi lain (sebagai contoh hubungan antara sistem account receivable dan sistem General Ledger). Untuk setiap perangkat lunak yang dibutuhkan, harus disertai dengan:

1. Nama2. Mnemonic3. Nomor spesifikasi4. Nomor Versi5. Sumber

Untuk setiap antarmuka, harus disertai dengan hal-hal berikut:

1. Diskusi dari kegunaan antarmuka perangkat lunak dan hubungannya dengan produk perangkat lunak

2. Definisi dari antarmuka dalam bentuk isi pesan dan formatnya. Adalah tidak perlu untuk merinci antarmuka yang sudah terdokumentasi dengan baik, jadi sebaiknya yang dilakukan adalah dengan melakukan referensi terhadap dokumennya.

5.2.1.5 Antarmuka Komunikasi

Bagian ini harus menspesifikasikan berbagai antarmuka untuk komunikasi, seperti protokol jaringan lokal, dll

5.2.1.6 Batasan Memori

Bagian ini menspesifikasikan setiap karakteristik dan batasan memori primer dan sekunder

5.2.1.7 Operasi

Bagian ini menentukan operasi normal dan operasi khusus yang dibutuhkan oleh pengguna seperti misalnya:

1. Berbagai variasi mode operasi dalam organisasi pengguna, misalnya operasi yang bersifat user-initiated (inisiatif dari pengguna)

2. Periode operasi interaktif dan periode operasi yang tidak diinginkan

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 11

Page 12: aturan skpl

3. Fungsi pendukung pemrosesan data4. Operasi backup dan recovery

5.2.1.8 Kebutuhan adaptasi lokasi

Bagian ini dapat berisi:

1. Pendefinisian kebutuhan untuk setiap data atau urutan inisialisasi yang tergantung pada lokasi yang diberikan, misi atau mode operasi (misalnya batasan keselamatan, dll).

2. Menspesifikasikan lokasi atau ciri yang berhubungan dengan misi yang harus dimodifikasi untuk mengadaptasi perangkat lunak terhadap suatu instalasi yang khusus.

5.2.2 Fungsi Produk

Pada bagian ini SKPL akan memberikan kesimpulan dari fungsi yang umum yang akan dilakukan oleh perangkat lunak. Sebagai contoh SKPL untuk program akuntansi dapat menggunakan bagian ini untuk menjelaskan perawatan akunting dari pengguna, pernyataan pengguna dan persiapan invoice tanpa menyebutkan rincian dari fungsi yang membutuhkan.

Kadang-kadang kesimpulan dari fungsi yang diperlukan untuk bagian ini dapat diambil secara langsung dari bagian spesifikasi yang lebih tinggi (jika ada) yang akan mengalokasikan fungsi khusus dari produk perangkat lunak. Perhatikan bahwa untuk alasan kejelasan:

1. Fungsi harus diorganisasikan dengan suatu cara sehingga daftar fungsi dapat dimengerti oleh pengguna atau orang lain yang membaca dokumen pertama kali

2. Metode tekstual dan grafik dapat digunakan untuk menunjukkan fungsi yang berbeda dan keterhubungannya. Diagram ini tidak ditujukan untuk menunjukkan perancangan produk tetapi juga menunjukkan hubungan logik antar variabel.

5.2.3 Karakteristik Pengguna

Bagian ini akan menjelaskan karakteristik umum yang diinginkan terhadap pengguna produk termasuk tingkat pendidikan, pengalaman dan keahlian teknis tertentu. Bagian ini sebaiknya tidak digunakan untuk menyatakan kebutuhan yang spesifik tetapi lebih kepada alasan mengapa kebutuhan tersebut diperlukan.

5.2.4 Batasan-batasan

Bagian SPKL ini berisi deskripsi umum dari item lain yang akan membatasi pilihan pengembangan. Hal-hal tersebut antara lain:

1. Kebijaksanaan umum2. Keterbatasan perangkat keras3. Antar muka ke aplikasi lain4. Operasi paralel5. Fungsi audit6. Fungsi kendali7. Kebutuhan bahasa tingkat tinggi8. Protokol sinyal komunikasi (misalnya XON-XOFF, ACK, NACK).9. Kebutuhan keandalan10. Tingkat kritis dari aplikasiPanduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 12

Page 13: aturan skpl

11. Masalah keamanan dan keselamatan

5.2.5 Asumsi dan Ketergantungan

Bagian ini akan menampilkan daftar faktor yang akan berakibat pada kebutuhan yang telah ditentukan oleh SKPL. Faktor-faktor ini bukan pembatasan perancangan perangkat lunak, tetapi lebih kepada perubahan-perubahan yang dapat berakibat pada kebutuhan dari SKPL. Sebagai contoh asumsi bahwa suatu sistem operasi akan tersedia pada suatu perangkat keras dari produk perangkat lunak. Jika sistem operasi tidak ada maka SKPL harus diubah karena hal tersebut.

5.2.6 Pembagian Kebutuhan

Bagian dari SKPL ini akan mengidentifikasi kebutuhan yang ditunda hingga versi berikutnya dari sistem.

5.3 Kebutuhan KhususBagian SKPL ini harus berisi semua kebutuhan perangkat lunak hingga pada tingkat rinci

yang memungkin pengembang untuk merancang sistem, untuk memenuhi kebutuhan-kebutuhan itu dan juga bagi penguji untuk menguji sistem terhadap kebutuhan. Pada bagian ini, setiap kebutuhan yang telah ditetapkan harus menyadari secara eksternal oleh pengguna, opoerator atau sistem eksternal lain. Kebutuhan ini harus melibatkan deskripsi minimum dari setiap masukan ke sistem, setiap keluaran dari sistem dan semua fungsi yang dilakukan oleh sistem untuk merespons terhadap masukan (stimulus) dan keluaran (respon) dari sistem dan semua fungsi dilakukan oleh sistem sebagai respon terhadap masukan/keluaran. Karena bagian ini merupakan bagian yang paling besar dan bagian penting dari SKPL. Prinsip-prinsip yang digunakan:

1. Kebutuhan khusus harus dinyatakan sesuai dengan karakteristiknya2. Kebutuhan khusus harus di-cross-reference-kan dengan dokumen sebelumnya yang

berhubungan3. Semua kebutuhan harus dapat diidentifikasi secara unik.4. Perhatian lebih harus diberikan untuk mengorganisasikan kebutuhan hingga memaksimalkan

readability.

Sebelum melihat cara mengatur kebutuhan yang akan beguna untuk mengerit item-item yang ada pada kebutuhan

5.3.1 Antar muka eksternal

Bagian ini akan memberikan penjelasan rinci terhadap semua masukan dan keluaran dari sistem perangkat lunak. Bagian ini akan mendukung deskripsi antarmuka di 5.2, dan jangan melakukan pengulangan informasi disini.

Akan juga dilibatkan isi dan format sebagai berikut:

1. Nama item2. Deskripsi penggunaan3. sumber masukan atau tujuan keluaran4. Jangkauan yang diterima, kebenaran atau toleransi.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 13

Page 14: aturan skpl

5. Unit pengukuran6. Pewaktuan (timing)7. Keterhubungan dengan masukan/keluaran lain8. format/organisasi layar9. format/organisasi window10. format data11. format perintah12. Pesan-pesan akhir

5.3.2 Fungsi-fungsi

Kebutuhan fungsional harus mendefinisikan aksi dasar yang harus diambil oleh perangkat lunak untuk menerima dan memproses masukan dan menghasilkan keluaran. Hal ini umumnya dinyatakan dengan kata ‘akan’. Misalnya, sistem akan...

Bagian yang terlibat

1. Validasir masukan2. Urutan operasi yang pasti3. Respon terhadap situasi abnormal termasuk kejadian overflow, fasilitas komunikasi atau

penanganan kesalahan dan recovery.4. Efek pada parameter5. Keterhubungan dari keluaran ke masukan, termasuk urutan masukan/keluaran, atau formula

untuk konversi masukan ke keluaran.

Dapat dilakukan juga pembagian kebutuhan fungsional menjadi sub fungsional aau sub proses. Hal ini tidak berarti bahwa perancangan perangkat lunak akan dibagi dengan cara seperti itu.

5.3.3 Kebutuhan perfomansi

Bagian ini harus menspesifikasikan baik kebutuhan numerik statik/dinamik yang terletak pada interaksi perangkat lunak atau pada interaksi manusia dengan perangkat lunak secara keseluruhan. Kebutuhan numerik statis mungkin melibatkan:

1. Jumlah terminal yang didukung2. Jumlah pengguna simultan yang didukung3. Jumlah dan tipe informasi yang ditangani

Kebutuhan numerik statik sering diidentifikasi pada bagian terpisah ayng disebut kapasitas.

Kebutuhan numerik dinamik mungkin dapat melibatkan, sebagai contoh, jumlah transaksi dan tugas dan jumlah hdata yang akan diproses selama jangka waktu tertentu, baik kondisi normal atau kondisi beban puncak.

Semua kebutuhan ini harus dinyatakan dalam istilah yang dapat diukur. Contohnya, kalimat “95 % transaksi harus diproses dalam 1 detik”, akan lebih baik daripada kalimat “operator mungkin tidak harus menunggu transaksi akan selesai.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 14

Page 15: aturan skpl

5.3.4 Kebutuhan Basisdata logik

Kebutuhan ini harus menspesifikasi kebutuhan logis untuk setiap informasi yang diletakkan ke basisdata, antara lain:

1. Tipe informasi yang digunakan oleh berbagai fungsi2. Frekuensi pemakaian3. Kemampuan pengaksesan4. Entitas data dan keterhubungannya5. Batasan integritas6. kebutuhan pemakaian data

5.3.5 Batasan perancangan

Bagian ini akan menspesifikasikan batasan perancangan yang akan dihasilkan oleh standar lain, keterbatasan perangkat keras, dan lain-lain

5.3.5.1 Pemenuhan Standard

Bagian ini akan menspesifikasikan kebutuhan yang diturunkan dari standar yang ada atau aturan, antara lain:

1. Format laporan2. Penamaan data3. Aturan akunting4. Penelusuran audit

Sebagai contoh, bagian in dapat menentukan kebutuhan perangkat lunak untuk menelusuri aktivitas pemrosesan. Penelusuran ini diperlukan untuk suatu aplikasi agar sesuai dengan peraturan minimum dan standar keuangan. Kebutuhan penelusuran audit, sebagai contoh, menyatakan bahwa semua perubahan harus dicatat pada suatu file khusus untuk penelusuran dengan isi sebelum dan sesudah dilakukan.

5.3.6 Aturan sistem perangkat Lunak

Ada sejumlah atribut perangkat lunak yang dapat ditampilkan sebagai kebutuhan. Adalah penting bahwa atribut yang diinginkan harus dispesifikasi sehingga hasilnya dapat diverifikasi. Item-item berikut akan memberikan contoh kecil.

5.3.6.1 Keandalan

Bagian ini akan menspesifikasi faktor yang dibutuhkan untuk membentuk keandalan sistem pada saat diterimakan.

5.3.6.2 Ketersediaan.

Bagian ini akan berisi faktor untuk menjamin tingkat ketersediaan seluruh sistem seperti checkpoint, recovery dan restart.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 15

Page 16: aturan skpl

5.3.6.3 Keamanan

Bagian ini berisi faktor untuk memproteksi perangkat lunak dari akses yang mendadak atau akses yang merusak, mengubah, dll. Kebutuhan yang spesifik termasuk hal-hal berikut:

1. Penggunakan teknik kriptografi2. Menyimpan data log/history3. Memberikan suatu fungsi ke modul-modul yang berbeda4. Membatasi komunikasi antara suatu area dalam program5. Memeriksa integritas data untuk nilai-nilai kritis

5.3.6.4 Tingkat perawatan (Maintainability)

Bagian ini akan menentukan atribut dari perangkat lunak yang berhubungan dengan kemudahan perawatan dari perangkat lunak tersebut. Ada beberapa kebutuhan untuk modularitas, antar muak, kompleksitas, dan lain-lain.

5.3.6.5 Portabilitas

Atribut dari perangkat lunak yang berhubungan dengan kemudahan porting perangkat lunak ke mesin lain/perangkat operasi lain. Hal-hal yang harus diperhatikan:

1. Persentase komponen yang berisi kode yang independent2. Persentase komponen yang tergantung pada host3. Penggunaan bahasa yang portabilitasnya terbukti4. Penggunaan suatu kompilator/bahasa5. Penggunan suatu sistem operasi

5.3.7 Pengorganisasian kebutuhan khusus

Untuk setiap sistem (kecuali yang sangat sederhana) kebutuhan rinci cenderung menjadi luas. Untuk alasan ini, direkomendasikan cara-cara yang hati-hati dalam mengorganisasikan agar mudah dimengerti. Umumnya tidak ada organisasi yang optimal pada seluruh sistem. Perbedaan kelompok sistem cendreung akan melibatkan mereka ke organisasi kebutuhan yang berbda dengan baigan 3 dari SKPL. Beberapa dari organisasi ini dijelaskan sebagai berikut:

5.3.7.1 Mode sistem

Beberapa sistem berlakuk agak berbeda tergantung pada mode operasi. Sebagai contoh sistem kendali mungkin memiliki sekumpulan fungsi yang berbeda tergantung modenya (training, normal atau berbahaya). Dengan mengorganisasikan bagian ini dengan mode, gunakan outline seperti di lampiran. Pemilihan bergantung pada apakah antar muka dan performansi tergantung pada model.

5.3.7.2 Kelompok pengguna

Beberapa sistem membuthkan fungsi yang berbeda terhadap kelompok yang berbda dari pengguna. Sebagai contoh sistem elevator melibatkan umum (pengguna elevator), pekerjan maintenance dan pemadam kebakaran. Jika menggunakan bagian ini sebagai kelas gunakan lampian A.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 16

Page 17: aturan skpl

5.3.7.3 Objek

Objek adalah entitas dunia yang memiliki hubungan dnegan sistem. Sebagai contoh sistem monitoring pasien, objek termasuk pasien, perawat, sensor, runang, doketr, obat, dll. Pada seitap obejk memiliki atribut dan fungsi.

5.3.7.4 Feature

Suatu feature adalah pelayanan yang dinginkan secara eksternal oleh sistem yang membutuhkan serangkaian masukan yang memberi efek terhadap hasil. Sebagai contoh pada sistem telpon, feature-nya adalah hubungan lokal, call forwarding dan conference call. Setiap feature umumnya dijelaskan dalam pasangan stimulus-response. Jika digunakan bagian ini, gunakan outline di bagian 5 dari lampiran A.

5.3.7.5 Stimulus

Beberapa sistem akan lebih baik diorganisasikan berdasarkan stimulus. Misalnya fungsi0fungsi sistem pendaratan pesawat udar mungkin diorganisasikan menjadi bagian loss of power, wind shear, sudden change in roll, vertical velocity excessive, dll. Jika diorganisasikan sebagai stimulus, gunakan outline di lampiran A bagian 6.

5.3.7.6 Respons

Beberapa sistem dapat diorganisasikan dengan menejlaskan semua fungsi dalam mendukung pembangkitan respons. Misalnya fungsi sistem personil dapat diorganisasikan menjadi bagian-bagian yang berhubungan dengan semua fungsi yang diasosiasikan dengan pembangkitan cek pembayaran, fungsi-fungsi yang berhubungan daftar pegawai, dll. Gunakan A.6 di lampiran.

5.3.7.7 Hirarki fungsional

Jika tidak ada skema di atas yang terbukti berguna, fungsionalitas keseluruhan dapat diorganisasikan menjadi fungsi hirarki dengan masukan, keluaran dan akses data internal. DFD dan kamus data dapat digunakan untuk menunjukkan keterhubungan antara fungsi dan data. Gunakan A.7 di lampiran A.

5.3.8 Komentar Tambahan

Pada SKPL yang menggunakan lebih dari satu teknik organisasi dapat menggunakan teknik di 5.3.7.7. pada kasus tersebut dengan mengorganisasikan kebutuhan spesifik untuk hirarki ganda, dihubungkan dengan kebutuhan spesifik dari sistem. Bagian A.8 dari lampiran A digunakan organisasi dengan mengkombinasikan user class dan feature. Kebutuhan tambahan dapat diletakan dalam bagian yang berbeda dalam SKPL.

Banyak notas, metode dan dukungan alat yang otomatis untuk membantu dokumentasi kebutuhan. Umumnya kegunaannya adalah fungsi dari organisasi. Sebagai contoh, jika diorganisasikan dengan mode, finite state machine, atau stat chart mungkin dapat berguna. Jika diorganisasikan sebagai objek, OOA mungkin dapat membatnu. Jika diorganisasikan sebagia feature, urutan stimulus-respones mungkin akan berguna. Ketika mengorganisasikan hirarki fungsional, dfd dan kamus data sudah terbukti dapat membantu. Bagian kebutuhan fungsionalitas dari lampiran A, bagian A1 s/d A8 dapat dijelaskan dalam suatu bahasa kalimat, pseudo code, dll.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 17

Page 18: aturan skpl

5.4 Informasi tambahanDukungan informasi yang membuat SKPL mudah digunakan, antara lain:

1. Daftar isi2. Index3. Lampiran

5.4.1 Daftar isi dan Index

Daftar isi dan index adalah cukup penting dan harus mengikuti standard yang ada.

5.4.2 Lampiran-lampiran

Lampiran tidak selalu menjadi bagian dari spesifikasi kebutuhan aktual dan tidak harus perlu. Lampiran dapat berisi:

1. contoh format masukan/keluaran, deskripsi analisa biaya, hasil survey2. dukungan informasi yang membantu SKPL.3. Deskripsi dari masalah yang dipecahkanoleh perangkat lunak.4. Instruksi khusus, dan media yang cocok untuk pengamatan, dan kebutuhan lain.

Jika disertakan lampiran, SKPL harus secara eksplisit menegaskan apakah lampiran ini adalah bagian dari kebutuhan.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 18

Page 19: aturan skpl

Lampiran AA.1 Template SKPL bagian 3 diorganisasikan oleh mode : Versi 1

3. Kebutuhan Khusus3.1. Kebutuhan antarmuka eksternal

3.1.1. Antarmuka pemakai3.1.2. Antarmuka perangkat keras3.1.3. Antarmuka perangkat lunak3.1.4. Antarmuka komunikasi

3.2. Kebutuhan fungsional3.2.1. Mode 1

3.2.1.1. Kebutuhan fungsionlitas 11.13.2.1.2. ...3.2.1.3. ...3.2.1.4. kebutuhan fungsionlitas 1.n

3.2.2. Mode 23.2.2.1. Kebutuhan fungsionlitas 11.13.2.2.2. ...3.2.2.3. ...3.2.2.4. kebutuhan fungsionlitas 1.n

3.2.3. Mode ...3.2.4. Mode m3.2.5. ..

3.3. Kebutuhan performansi3.4. Batasan perancangan3.5. Atribut sistem perangkat lunak 3.6. Kebutuhan lain

A.2 Template SKPL bagian 3 diorganisasikan oleh mode : Versi 2

3. Kebutuhan Khusus3.1. Kebutuhan fungsional

3.1.1. Mode 13.1.1.1. Antarmuka eksternal

3.1.1.1.1. Antarmuka pemakai3.1.1.1.2. Antarmuka perangkat keras3.1.1.1.3. Antarmuka perangkat lunak3.1.1.1.4. Antarmuka komunikasi

3.1.1.2. Kebutuhan fungsionlitas 1.13.1.1.2.1. Kebutuhan fungsionalitas 13.1.1.2.2. ....3.1.1.2.3. ....3.1.1.2.4. kebutuhan fungsionlitas n

3.1.1.3. Performansi3.1.2. Mode 23.1.3. .....

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 19

Page 20: aturan skpl

3.1.4. ....3.1.5. Mode n

3.2. Batasan perancangan3.3. Atribut sistem perangkat lunak3.4. Kebutuhan lain

A.3 Template SKPL bagian 3 diorganisasikan dengan kelas pengguna

3. Kebutuhan Khusus3.1. Kebutuhan antarmuka eksternal

3.1.1. Antarmuka pemakai3.1.2. Antarmuka perangkat keras3.1.3. Antarmuka perangkat lunak3.1.4. Antarmuka komunikasi

3.2. Kebutuhan fungsional3.2.1. User class 1

3.2.1.1. Kebutuhan fungsionlitas 11.13.2.1.2. ...3.2.1.3. ...3.2.1.4. kebutuhan fungsionlitas 1.n

3.2.2. User class 23.2.2.1. Kebutuhan fungsionlitas 11.13.2.2.2. ...3.2.2.3. ...3.2.2.4. kebutuhan fungsionlitas 1.n

3.2.3. User class....3.2.4. User class n

3.3. Kebutuhan performansi3.4. Batasan perancangan3.5. Atribut sistem perangkat lunak 3.6. Kebutuhan lain

A.4 Template SKPL bagian 3 diorganisasikan sebagai objek.

3. Kebutuhan Khusus3.1. Kebutuhan antarmuka eksternal

3.1.1. Antarmuka pemakai3.1.2. Antarmuka perangkat keras3.1.3. Antarmuka perangkat lunak3.1.4. Antarmuka komunikasi

3.2. Kelas/objek3.2.1. kelas/objek 1

3.2.1.1. atribut (langsung/tidak langsung)3.2.1.1.1. atribut 13.2.1.1.2. atribut 23.2.1.1.3. ....

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 20

Page 21: aturan skpl

3.2.1.1.4. ...3.2.1.1.5. atribut n

3.2.1.2. fungsi-fungsi (service, metode, langsung /tidak langsung)3.2.1.2.1. kebutuhan fungsional 1.13.2.1.2.2. kebutuhan fungsional 1.23.2.1.2.3. ...3.2.1.2.4. kebutuhan fungsional 1.m

3.2.1.3. Pesan (komunikasi yang diterima/dikirim)3.2.2. class objek 23.2.3. .....3.2.4. class objek p

3.3. Kebutuhan performansi3.4. Batasan perancangan3.5. Atribut sistem perangkat lunak 3.6. Kebutuhan lain

A.5 Template SKPL bagian 3 diorganisasikan sebagai feature3. Kebutuhan Khusus

3.1. Kebutuhan antarmuka eksternal3.1.1. Antarmuka pemakai3.1.2. Antarmuka perangkat keras3.1.3. Antarmuka perangkat lunak3.1.4. Antarmuka komunikasi

3.2. Feature System3.2.1. Sistem feature 1

3.2.1.1. Pendahuluan / guna dari purpose3.2.1.2. urutan stimulus/response3.2.1.3. kebutuhan fungsional yang berhubungan

3.2.1.3.1. Kebutuhan fungsional 13.2.1.3.2. .....3.2.1.3.3. ...3.2.1.3.4. Kebutuhan fungsional n

3.2.1.4. Pesan (komunikasi yang diterima/dikirim)3.2.2. Sistem feature 23.2.3.3.2.4. Sistem feature m

3.3. Kebutuhan performansi3.4. Batasan perancangan3.5. Atribut sistem perangkat lunak 3.6. Kebutuhan lain

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 21

Page 22: aturan skpl

A.6 Template SKPL bagian 3 diorganisasikan sebagai stimulus3. Kebutuhan Khusus

3.1. Kebutuhan antarmuka eksternal3.1.1. Antarmuka pemakai3.1.2. Antarmuka perangkat keras3.1.3. Antarmuka perangkat lunak3.1.4. Antarmuka komunikasi

3.2. Kebutuhan fungsionalitas3.2.1. stimulus 1

3.2.1.1. Kebutuhan fungsional 1.13.2.1.2. ....3.2.1.3. ....3.2.1.4. Kebutuhan fungsional 1.1

3.2.2. stimulus 23.2.3. ....3.2.4. ...3.2.5. stimulus m

3.3. Kebutuhan performansi3.4. Batasan perancangan3.5. Atribut sistem perangkat lunak 3.6. Kebutuhan lain

A.7 Template SKPL bagian 3 diorganisasikan sebagai hirarki fungsional3. Kebutuhan Khusus

3.1. Kebutuhan antarmuka eksternal3.1.1. Antarmuka pemakai3.1.2. Antarmuka perangkat keras3.1.3. Antarmuka perangkat lunak3.1.4. Antarmuka komunikasi

3.2. Kebutuhan fungsionalitas3.2.1. aliran informasi

3.2.1.1. DFD 13.2.1.1.1. Entitas data3.2.1.1.2. proses 3.2.1.1.3. topologi

3.2.1.2. DFD 23.2.1.2.1. Entitas data3.2.1.2.2. proses 3.2.1.2.3. topologi

3.2.1.3. ....3.2.1.4. DFD n

3.2.2. Deskripsi proses3.2.2.1. Proses 1

3.2.2.1.1. Entitas data masukan3.2.2.1.2. Algoritma atau Formula dari proses

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 22

Page 23: aturan skpl

3.2.2.1.3. entitas data terlibat3.2.2.2. Proses 2

3.2.2.2.1. ...3.2.2.2.2. ...

3.2.2.3. ....3.2.2.4. Proses n

3.2.3. Spesifikasi konstruksi data3.2.3.1. Konstruksi 1

3.2.3.1.1. Tipe record3.2.3.1.2. field-field

3.2.3.2. ...3.2.3.3. Konstruksi n

3.2.4. Kamus data3.2.4.1. Elemen data 1

3.2.4.1.1. Nama3.2.4.1.2. Representasi3.2.4.1.3. Unit/format3.2.4.1.4. presisi /keakuratan3.2.4.1.5. Range

3.2.4.2. elemen data 23.2.4.3. .....3.2.4.4. elemen data n

3.3. Kebutuhan performansi3.4. Batasan perancangan3.5. Atribut sistem perangkat lunak 3.6. Kebutuhan lain

A.8 Template SKPL bagian 3 diorganisasikan untuk organisasi ganda3. Kebutuhan Khusus

3.1. Kebutuhan antarmuka eksternal3.1.1. Antarmuka pemakai3.1.2. Antarmuka perangkat keras3.1.3. Antarmuka perangkat lunak3.1.4. Antarmuka komunikasi

3.2. Kebutuhan fungsionalitas3.2.1. User class 1

3.2.1.1. Feature 1.13.2.1.1.1. Introduksi dan pengenalan feature3.2.1.1.2. Urutan stimulus/response 3.2.1.1.3. kebutuhan fungsionalias yang terhubung

3.2.1.2. feature 1.23.2.1.3. ....3.2.1.4. ....

3.2.2. User class 23.2.3. ...

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 23

Page 24: aturan skpl

3.2.4. ....3.2.5. User c.lass n

3.3. Kebutuhan performansi3.4. Batasan perancangan3.5. Atribut sistem perangkat lunak 3.6. Kebutuhan lain

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 24