SRS IEEE

IEEE Std 830-1998 (Revision of IEEE Std 830-1993)

Dokumen Standar IEEE dikembangkan dalam Societies IEEE dan Dewan Standar Koordinasi Komite Asosiasi Standar IEEE ( IEEE – SA ). Anggota komite melayani secara sukarela dan tanpa kompensasi. Mereka belum tentu anggota Institute. Standar dikembangkan dalam IEEE mewakili konsensus keahlian yang luas pada subjek dalam Institut serta kegiatan-kegiatan di luar IEEE yang telah menyatakan minat berpartisipasi dalam pengembangan standar. Penggunaan Standar IEEE sepenuhnya sukarela. Keberadaan sebuah Standar IEEE tidak berarti bahwa tidak ada cara lain untuk memproduksi, menguji, mengukur, pembelian, pasar atau menyediakan barang-barang lain dan layanan yang berkaitan dengan lingkup Standar IEEE.

Selain itu,sudut pandang yang diungkapkan di waktu standar disetujui dan diterbitkan adalah untuk mengubah dibawa melalui perkembangan subjek keadaan seni dan komentar yang diterima dari pengguna standar. Setiap IEEE Standard dikenakan untuk meninjau setidaknya setiap tahun untuk revisi atau reaformation. Ketika dokumen lebih dari berusia tahun dan belum reaformation, masuk akal untuk menyimpulkan bahwa isinya, meskipun masih beberapa nilai, tidak sepenuhnya reflect kondisi sekarang seni. Pengguna diperingatkan untuk memeriksa untuk menentukan bahwa mereka memiliki edisi terbaru dari setiap IEEE Standard.

Standar SKPL IEEE Std 830-1998 ini merupakan salah satu standar dokumentasi SKPL yang direkomendasikan. Hal ini didasarkan bahwa dalam rekayasa kebutuhan perangkat lunak, proses penggalian kebutuhan membutuhkan dokumen yang jelas dan lengkap.

Dokumen ini membantu :

1.     1.   Pengguna software dapat menjelaskan secara akurat apa yang ingin mereka dapatkan

2.     2.   Pemasok software dapat mengerti apa yang pelanggan inginkan

3.     3.   Individu yang ingin menyelesaikan tujuannya :

4.     4.   Membuat Standar Kelengkapan Perangkat Lunak (SKPL) untuk organisasinya

5.     5.   Mendefinisikan format dan konten SKPL tersebut

6.     6.   Membantu pengembangan SKPL itu sendiri

Requirements Engineering in the Rational Unified Process

Rational Unified Process adalah proses rekayasa perangkat lunak iteratif yang terdiri dari kedua kerangka proses dan produk proses. Sebagai produk proses, terdiri dari dokumentasi yang komprehensif berbasis HTML [6, 7], termasuk dukungan bahan seperti daftar periksa atau dokumen template. Awalnya dirilis olehRational Software Corporation, RUP kini dikelola dan didistribusikan oleh IBM sebagai komersial, produk non bebas royalti [6]. Sebagai kerangka proses, menyediakan sebuah pendekatan untuk mengatur dan menetapkan tugas-tugas dalam suatu organisasi. Itu Enam praktik utama ditutupi oleh RUP adalah :

1.     Mengembangkan perangkat lunak iteratif

2.     mengelola persyaratan

3.     Gunakan arsitektur berbasis komponen

4.     Model perangkat lunak Visual

5.     Terus memverifikasi kualitas perangkat lunak

6.     Kontrol perubahan perangkat lunak

Software Requirements Specification J2Lite Software

Software Requirement Specification adalah perangkat lunak yang akan dibuat

          dan sebagai penyembatani komunikasih pembuat dengan pengguna.

          -   Use Case adalah situasi dimana sistem anda digunakan untuk memenuhi

                   satu atau lebih kebut

 Dokumen SRS ini dibagi menjadi tiga bagian utama, yaitu :

1.Bagian pertama berisi penjelasan tentang dokumen SRS yang mencakup tujuan

        pembuatan dokumen ini, lingkup masalah yang diselesaikan oleh perangkat

        lunak yang dikembangkan, definisi, referensi dan deskripsi umum.

2.Bagian kedua berisi penjelasan secara umum mengenai perangkat lunak APB

        yang akan dibangun, meliputi fungsi dari perangkat lunak, karakteristik

        pengguna, batasan dan asumsi yang diambil dalam pembuatan perangkat

        lunak.

3.    Bagian ketiga berisi uraian kebutuhan perangkat lunak secara lebih rinci.

4.Bagian keempat mengenai beberapa persyaratan dan desain kinerja serta

        kendala juga diberikan.

5.Bagian lima berisi memberi beberapa kemungkinan perpanjangan masa depan

        dari sistem.uhan pemakaian anda.

Persyaratan Spesifikasi untuk Maret 2010 Versi 0.1 Disiapkan oleh Software J2Lite – v0.1 Change History Date 24 Mar 2010 Versi 0.1 Deskripsi Initial Draft Diperbarui By J2Lite SoftwareDocument Approvals Name Peran Signature Page 2 dari 7 Persyaratan Spesifikasi 24 Mar 2010

Tabel Perbandingan bagian tiap konten dari IEEE Std 830-1998, the Rational Unified Process & J2Lite Software

HISTORY OF CONTENT			Software Requirement Spesification template			Description
			IEEE	RUP	J2Lite
						IEEE = judul proyek, nama tim nomor, anggota timRUP = setelah judul proyek menyebutkan spesifik untuk subsistem atau fitur tertentu, versi J2Lite = Requirements Specification for <nama proyek >, bulan & tahun pembuatan, versi, dibuat oleh
Table  of contents			X	X	X
Change Management process			X	X	X	J2Lite = terdapat table change history,RUP = Recision history kolomnya ada tanggal, versi, deskripsi, update
Document Approval			X		X	J2Lite = nama, jabatan, tanda tangan
Supporting Information			X
Introduction	Purpose		X	X	X	Semuanya spesifik untuk membahas audience dari dokumen SRS
	Scope		X	X	X	IEEE = nama produk, manfaat dan tujuan produkRUP = deskripsi dari software aplikasi, use case, fitur, grup J2Lite = project boundary, tujuan manfaat dan tujuan, fitur tujuan.
	Definition, Acronyms, Abbreviations		X	X		IEEE = informasi yang bertujuan referensi dokumen lainURP = informasi yang bertujuan referensiglossary
	References		X	X		IEEE & URP = spesifik sumber referensi judul, tanggal, penerbitJ2Lite = referensi sumber luar, dokumen & website
	Overview		X			IEEE = factor umum dari produk dan kebutuhanya meliputiProduct perspective; Product functions; User characteristics; Constraints; Assumptions and dependencies; Apportioning of requirements.RUP = deskripsi konten SRS, bagaimana dokumen dibuat
Overall description	Product Perspective	System interfaces	X	X		IEEE = menyelaraskan deskripsi kebutuhan dan sistemRUP = pada overall description meliputi item berikut :product prespective, product function, user characteristic, constraint, assumptions and dependencies, requirements subsets. J2Lite = umum dijelaskan pada BabSystem Description
		User interfaces	X			IEEE = meliputi a) The logical characteristics of each interface between the software product and its users.b)All the aspects of optimizing the interface with the person who must use the system.
		Hardware interfaces	X			IEEE = Karakter logika meliputi :configuration characteristics (number of ports, instructionsets, etc.)
		Software interfacing	X			IEEE = Software product yang dimiliki meliputi Name; Mnemonic; SpeciÞcation number; Version number;
		Communications interfaces	X			IEEE = variasi antarmuka untuk berkomunikasi, seperti jaringan local dan protocol
		Memory	X			IEEE = Karakter dan batasan dari memory primer dan sekunder
		Operations	X			IEEE = Backup dan recover operasi, fungsi untuk mensuport proses data
		Site adaptation requirement	X			IEEE =
	Product functions		X
	User Characteristic		X
	Constraints		X			Regulatory policies;b) Hardware limitations (e.g., signal timing requirements); c) Interfaces to other applications; d) Parallel operation; e) Audit functions; f) Control functions; g) Higher-order language requirements; h) Signal handshake protocols (e.g., XON-XOFF, ACK-NACK); i) Reliability requirements; j) Criticality of the application; k) Safety and security considerations.
	Assumptions and dependencies		X
	Apportioning of requirement		X			Identifikasi kebutuhan yang ditunda sampai versi kedepannya dari sistem asumsi spesifik OS yang tersedia dengan design hardware dan produk software
Specification requirement	External interface		X	X		IEEE = kebutuhan spesifik dengan karakternya, mennetukan kebutuhan dengan perhatian yang hati – hatiRUP = berisi kebutuhan perangkat lunak, model use case, outline spesifikasi tambahan User interface Hardware interface Software interface Communications interface J2Lite = identifikasi input dan output dari eksternal interface dijelaskan pada Bab 4
	Function		X	X	X	IEEE = harus meliputi Validity checks on the inputs Exact sequence of operations Responses to abnormal situations, including Overflow Communication facilities Error handling and recovery  Effect of parameters Relationship of outputs to inputs, including 1.     Input/output sequences 2.     Formulas for input to output conversion RUP = kebutuhan yang didapat dari gaya bahasa natural, kemampuan dan keamanan. J2Lite = sistem perangkat lunak yang dibuat terdiri dari variasi model untuk design, menmabahkanprocess flow diagram, data flow diagram, flowchart decision table
		System  Feature			X	J2Lite = Spesifikasi level sistem dari fitur yang dibutuhkann product perangkat lunak, setiap kebutuhan adalah unik dan dapat merujuk ke traceability matrixSystem feature 1, system feature 2
	Performance Requirement		X			IEEE = prosentase dari simultan, erminal dan jumlah informasi yang ditangani.
	Logical database requirement		X			IEEE = dapat meliputi :a)Types of information used by various functions; b) Frequency of use; c) Accessing capabilities; d) Data entities and their relationships; e) Integrity constraints; f) Data retention requirements.
	Design constraint		X		X	IEEE = spesifik design dengan standard regulasi meliputia) Report format; b) Data naming; c) Accounting procedures; d) Audit tracing. URP = merepresentasikan keputusan desain  yang akan dibuat meliputi: a) Report format; b) Data naming; c) Accounting procedures; d) Audit tracing. J2Lite =
	Software system attribute	Performance	X	X	X	IEEE = ferifikasi objektif berapa atribut dari software yang spesifik yang dicapaiRUP = spesifikasi respon dari waktu Respon waktu saat transaksi (rata – rata, maksismum) Throughput(transaksi per detik) Kapasitas (jumlah pelanggan atau transaksi sistem yang terakomodasi) Degradasi mode (mode yang dapat diterima dari operasi ketika sistem telah di- degradasi dengan beberapa cara) Sumber perlengkapan seperti memori,disk, kominikasi dll Terdiri dariPerformance Requirement one, Performance Requirement two. J2Lite = contohnya apa yang dibutuhkan untuk merespon waktu
		Reliability	X	X
		Availability	X		X	J2Lite = kebutuhan akan macam – macamdowntime yang diterima
		Security	X		X	J2Lite = Kebutuhan enkripsi data
		Maintainability	X		X
		Supportability		X
		Usability		X	X
		Scalability			X	J2Lite = berapa pengguna sistem setelah beberapa tahun operasi
		Auditing and Logging
	On-line user documentation and help system requirement			X		RUP = kebutuhan yang mendeskripsikan tentang dokumentasi online, sistem bantuan, dan bantuan tentang peringatan
	Purchased component			X		RUP = standar antarmuka dan beberapa asosiasi antara komponen pengadaan yang dibutuhkan sistem
	Licensing Requirement			X		RUP = mendefinisikan lisensi yang dibutuhkan pada saat showing pada software
	Legal, copyright, and other notice			X		Mendiskripsikan jaminan dan perdagangan dan isu logo dari software
	Organizing the specific requirement	System mode	X			IEEE = sistem control bisa jadi berbeda dengan kumpulan dari fungsi yang bergantung pada training, normal or emergency.
		User class	X			IEEE =
		Object	X
		Feature	X
		Stimulus	X
		Responses	X
		Functional hierarchy	X
	Additional comments		X		X	IEEE = jika suatu organisaasi membuat SRS dengan object dan diagram dan cacatan yang akan sangat membuktikan.J2Lite = dengan bab akhir dari SRS ini pada bab 6 dengan judul Open issues, akhir dari elicitasi kebutuhan dengan mendaftar isu – isu yang akan menjadi project resiko setelahnya.
Analysis Modell		Use Case			X	Deskripsi dari usecase dengan table format dengan detail seperti berikut : ID Description Preconditions Alternate Steps Exceptions Business validations/Rules Postconditions
		Entity Relationship Diagram			X
		Data Dictionary			X
Supporting information	Table of contents		X	X		RUP = Pada Bab Supporting Information meliputi Table of contents Index Appendices
	Index			X
	Appendixes		X	X		IEEE = format dari sample masukan dan keluaran, deskripsi dari analisis studi dan hasil dari survey pengguna Latarbelakang dan Informasi pendukung untuk memudahkan pembaca dalam Deskripsi masalah yang akan diselesaikan dengan software Instruksi Pengemasan yang special untuk kode keamanan

Kesimpulan

Berbagai macam dokumen SKPL yang dapat dipakai menjadi standard ataupun contoh dari proyek yang akan kita buta tergantung terhadap kebutuhan, melihat dari berbagai dokumen SRS baik IEEE yang mempunyai 3 bab, RUP mempunyai 4 bab maupun J2Lite yang mempunyai 6 bab dan rata – rata memiliki kesamaan, perbedaannya hanya pada pendefinisian pada bab Requirement specification jika IEEE terdapat mode requirement 1, 2, 3 dst. Jika RUP terdapat non functional requirement yang didefinisikan jelas, kemudian J2Lite lebih dijelaskan detail pada model dan tekhnik usecase diagram dan ERD.