• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Software Requirements
 

Software Requirements

on

  • 1,594 views

 

Statistics

Views

Total Views
1,594
Views on SlideShare
1,588
Embed Views
6

Actions

Likes
1
Downloads
35
Comments
0

1 Embed 6

http://berkasindekssequensial.blogspot.com 6

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Software Requirements Software Requirements Presentation Transcript

    • SOFTWAREREQUIREMENTS
    • Dasar – Dasar Software Requirements
    • Definisi software requirement adalah sebuah properti yang harus diperlihatkan /ditunjukkan oleh software untuk menyelesaikan suatu permasalahan yang ada di dunia nyata / bersifat riil. merupakan kombinasi rumit dari kebutuhan berbagai orang di bermacam – macam tingkat organisasi dan lingkungan di mana perangkat lunak akan dioperasikan. properti yang esensial dari semua software requirement adalah harus mampu diperiksa/diverifikasi.
    • Product and Process requirement Kebutuhan produk adalah requirement pada software untuk dikembangkan (Contohnya “Software harus memeriksa prasyarat mata kuliah yang diambil mahasiswa”) Kebutuhan proses adalah batasan – batasan dalam mengembangkan software. Contohnya pilihan teknik verifikasi. Process requirement juga bisa ditetapkan oleh organisasi pengembang, pelanggan atau pihak ketiga seperti badan regulator.
    • Requirement fungsional dan nonfungsional Requirements fungsional menjabarkan fungsi – fungsi yang akan dilaksanakan software. Contohnya memformat teks. Kadang – kadang disebut juga sebagai kapabilitas. Requirements non-fungsional memberikan batasan terhadap solusi yang akan dihasilkan. Disebut juga sebagai quality requirement. Requirement jenis ini masih bisa dibagi lagi menjadi performance requirements, maintainability requirements, safety requirements, reliability requirements atau salah satu software requirements lainnya.
    • Emergent PropertiesBeberapa requirement merupakanperwakilan dari emergent properties yaiturequirement yang tidak bisa ditangani olehsatu komponen saja. Keberhasilan dalammenanganinya juga bergantung padainteroperasi dari berbagai komponen yangada. Emergent properties amat bergantungpada arsitektur sistem.
    • Quantifiable RequirementsSoftware requirement harus bisa dinyatakandengan jelas, tidak ambigu dan padabeberapa bagiannya yang sesuai,kuantitatif.Contoh requirement yang memenuhi syarat:Sebuah perangkat lunak dari suatu callcentral harus meningkatkan throughputsebanyak 20% dan sistemnya hanyamenghasilkan kesalahan fatal denganpeluang kurang dari 1*10-8.
    • System Requirements dan Software Requirements Dalam topik ini sistem berarti kombinasi dari elemen – elemen yang berinteraksi untuk mencapai suatu tujuan yang terdefinisikan. Ini termasuk hardware, software, firmware, manusia, informasi, tehnik, fasilitas, layanan dan berbagai elemen pendukung lainnya System requirement adalah requirement untuk sistem secara keseluruhan. Dalam sebuah sistem yang mengandung komponen software, software requirement diperoleh dari system requirement.
    • Requirement Process
    • Process Models Bukan kegiatan berawal – berakhir secara diskrit tetapi dimulai dari awal suatu proyek dan terus diperhalus selama siklus hidup software. Mengidentifikasi software requirement sebagai konfigurasi item – item dan mengaturnya dengan praktik – praktik manajemen konfigurasi software yang sama dengan produk – produk lain dari proses – proses siklus hidup software tersebut. Perlu diadaptasikan sesuai dengan konteks organisasi dan proyek.
    • Process Actors Pengguna : kelompok yang kelak akan mengoperasikan software. Pelanggan : Kelompok inilah yang akan memberlakukan suatu software ke dalam suatu organisasi. Analis Pasar : Analis pasar diperlukan untuk mengetahui kebutuhan pasar. Regulator : Banyak bidang di mana aplikasi terkena regulasi misalnya perbankan dan transportasi umum. Karenanya software yang dioperasikan pada bidang – bidang semacam ini harus sesuai dengan ketentuan dari badan regulator yang berwenang. Perekayasa software : Kelompok ini memiliki hak yang sah untuk mengambil keuntungan dari pengembangan suatu software, termasuk menggunakan ulang beberapa komponennya untuk produk lain.
    • Process Quality and Improvement Membahas penilaian kualitas dan peningkatan dari suatu requirement process. Tujuannya adalah untuk menekankan peran kunci requirementprocess dari segi biaya dan masa berlaku suatu produk software dan kepuasan pelanggan.
    • Requirements Elicitation
    • Sumber – Sumber Requirements Tujuan. Tujuan bisa memberi motivasi bagi pembuatan software tetapi sayangnya sering diformulasikan secara samar. Karenanya perlu dinilai biaya dan nilainya secara jelas. Pengetahuan akan domain. Seseorang perekayasa software harus mengetahui domain dari aplikasi yang dikerjakannya. Pihak yang berkepentingan. Banyak software yang tidak memuaskan karena terlalu condong pada kepentingan pihak tertentu saja dan mengorbankan pihak lain. Hendaknya dipahami dan dicapai keseimbangan dari sudut pandang tiap pihak.
    • Sumber – Sumber Requirements Lingkungan operasional. Requirement akan disusun dari lingkungan di mana software akan bekerja. Misalnya batasan timing untuk real – time software atau kemampuan interoperasional Lingkungan organisasional. Seringkali suatu software dibuat untuk menunjang proses bisnis. Karenanya perlu diperhatikan struktur, budaya kerja dan situasi politik dari organisasi yang bersangkutan.
    • Elicitation Techniques Wawancara. Merupakan tehnik yang paling tradisional. Perlu diketahui batasan dan tata caranya. Skenario. Tehnik ini mampu memberikan konteks untuk menyusun requirement bagi pengguna. Memberikan kerangka kerja bagi perekayasa software dengan membolehkan pertanyaan seperti “Bagaimana jika…” atau “Bagaimana ini dikerjakan”. Prototipe. Tehnik ini bisa memberi kejelasan pada requirement yang masih kabur. Tehnik ini bertindak mirip dengan skenario karena bisa memberikan konteks di mana pengguna bisa tahu informasi apa yang harus diberikan.
    • Elicitation Techniques Pertemuan terfasilitasi. Tehnik ini baik untuk menghimpun pandangan berbagai pihak yang berkepentingan. Bisa pula timbul – saran atau ide yang membantu. Selain itu juga bisa mengenali konflik antar requirement. Tetapi pertemuan sebaiknya menggunakan jasa seorang fasilitator untuk mencegah / mengendalikan kemungkinan dominasi pihak tertentu. Observasi. Tehnik ini relatif mahal tapi wajib karena mungkin saja proses bisnis terlau kompleks dan canggih untuk dijelaskan secara lisan. Perekayasa software harus masuk ke dalam lingkungan kerja pengguna dan mengamati interaksi pengguna dengan software dan sesama pengguna lain.
    • Requirement Analysis
    • Klasifikasi Requirements Fungsional dan non fungsional Apakah suatu requirement didapat dari satu atau lebih requirement yang berlevel lebih tinggi atau merupakan emergent propety (sub bagian 1.4) atau ditetapkan oleh pihak yang berkepentingan atau sumber lain. Apakah requirement ada pada produk atau proses. Prioritas. Secara umum, semakin tinggi prioritas suatu requirement semakin mendesak pula untuk dipenuhi dalam produk akhir. Cakupan dari requirement. . Hal ini sangat berpengaruh pada arsitektur software dan desain komponen. Stabilitas. Requirement kadang berubah dalam suatu siklus hidup software bahkan mungkin dalam proses pengembangannya.
    • Conceptual ModellingPemodelan dari permaslahan riil adalah kunci darianalisa software requirements.Tujuannya untuk membantu memahamipermasalahan. Model konseptual terdiri dari modelentitas – entitas dari domain permasalahan yangdisusun untuk mewakili relasi riil danketergantungan riil.Ada beberapa model yang bisa dikembangkan.Antara lain aliran data dan kontrol, model keadaan,pelacakan even, interaksi pengguna, model obyek,model data dan lain – lain.
    • Conceptual Modelling Faktor yang mempengaruhi pemilihan pemodelan: Sifat dari permasalahan. Beberapa tipe software menuntut agar aspek tertentu dianalisa secara menyeluruh Keahlian perekayasa software. Lebih baik menggunakan notasi atau metode permodelan yang sudah familier. Process requierement dari pelanggan. Mungkin pelangan ingin menetapkan notasi atau metode pemodelan tertentu Ketersediaan metode dan alat. Meskipun cocok namun jika tidak ditunjang dengan keahlian dan alat yang baik, suatu notasi atau metode tidak bisa dipakai.
    • Desain Arsitektural dan Alokasi RequirementDesain arsitektural adalah suatu tahap di manarequirement process dilakukan bersamaan dengandesain sistem atau software. Karenanya sulitmemisahkan dua aktivitas tersebut.Desain arsitektural sangat berhubungan denganpemodelan konseptual. Pemetaan domain entitasdunia nyata menjadi komponen software tidak selalujelas, sehingga desain arsitektural dianggap sebagaitopik terpisah. Requirement untuk notasi dan metodesecara umum sama pada pemodelan konseptual dandesain arsitektural.
    • Negosiasi RequirementTopik ini disebut juga sebagai “penyelesaiankonflik”. Topik ini membahas penanganan masalahrequirement di mana timbul konflik antara dua pihakyang sama – sama berkepentingan, antararequirement dengan sumber daya atau requirementfungsional dan non fungsional. Dalam kebanyakankasus, keputusan yang diambil secara unilateralbukanlah sikap bijaksana. Karenanya penting untukmencapai konsensus dengan pihak yangberkepentingan.
    • Spesifikasi Requirement
    • Spesifikasi RequirementPada kebanyakan profesi perekayasaan, istilahspesifikasi merujuk pada kegiatan memberikannilai numerik atau batas pada tujuan produkakhir.Tetapi definisi ini tidak bisa dipakai padarekayasa perangkat lunak mengingatbanyaknya requirement yang ada dankompleksitas interaksinya.Karenanya pada rekayasa perangkat lunakistilah “spesifikasi requirement software”mengacu pada pembuatan dokumen baik fisikmaupun elektronis.
    • Pada sistem yang kompleks, terutamayang melibatkan banyak kompone nonsoftware, ada 3 jenis dokumen yangdibuat yaitu definisi sistem,requirement sistem dan requirementperangkat lunak.Pada produk software yang sederhanahanya satu dari 3 jenis dokumen itu yangperlu dibuat.Semua tiga jenis dokumen itu akandijelaskan di sini.
    • 5.1: Dokumen Definisi SistemDokumen ini menyimpan requirement sebuahsistem.Dokumen ini mendaftar semua requirementbeserta keterangan latar belakang tujuankeseluruhan sebuah sistem, lingkungan yangmenjadi sasaran dan pernyataan batasan, asumsidan requirement non-fungsional.Mungkin juga di dalamnya terdapat modelkonseptual yang didesain untuk memberikangambaran tentang konteks sistem, skenariopemakaian dan entitas - entitas domain yangpenting, termasuk juga data, informasi dan alirankerja.
    • 5.2:Spesifikasi Requirement Sistem.Para pengembang dari sebuah sistemberkomponen software dan non-software yangcukup banyak, seringkali memisahkan deskripsidari requirement sistem dari deskripsirequirement software.Dengan cara ini, requirement sistemdispesifikasikan, requirement software didapatdari requirement sistem dan requirement untukkomponen sosftware dispesifikasikan .Karena merupakan bidang rekayasa sistem,dokumen jenis ini tidak akan dibahas terperinci disini.
    • 5.3:Spesifikasi Requirement Software Dokumen jenis ini menjadi dasar untuk sebuah perjanjian antara pelanggan dan kontraktor atau penyuplai tentang apa yang seharusnya dan tidak seharusnya dikerjakan oleh produk software. Untuk pembaca yang kurang paham hal – hal yang sifanya teknis, dokumen jenis ini juga didampingi oleh dokumen definisi requirement software.
    • Dokumen ini memungkinkan penilaianmendalam tentang requirement sebelumdesain dimulai sehingga mengurangikeharusan desain ulang.Dokumen ini juga memberikan dasar –dasar realistis untuk memperkirakanbiaya, risiko dan jadwal produksi.
    • Requirements validation
    • Requirements validationKebutuhan dokumen difokuskan pada prosedurvalidasi dan verifikasi.Kebutuhan akan validasi untuk meyakinkanbahwa software engineer telah mengerti tentangrequirement yang diperlukan, dan juga sangatpenting untuk membuktikan bahwa requirementsdocument dapat disesuaikan dengan kebutuhanstandard suatu perusahaan, dan juga dapatmudah dipahami, konsisten, dan lengkap.
    • 6.1: Requirements Reviews Arti umum validation adalah memeriksaan (inspection) atau review (meninjau) requirements document. Reviewer bertugas mencari error (look for errors), asumsi yang salah (mistaken assumptions), hal-halyang kurang jelas (lack of clarity), dan penyimpangan standar (deviation from standard practice). Hal ini sangat penting dan munkin membantu memberikan petunjuk apa yang dicari dalam tabel checklists. Review terdapat pada : penyelesaian dari system definition document system specification document software requirements specification document baseline specification for a new release atau pada langkah lain dalam suatu proses
    • 6.2: PrototypingPrototyping secara umum berarti untukmelakukan validasi, interpretasi softwareengineer mengenai softwarerequirements, sama seperti memperolehrequirement baru.Keuntungan dari prototype adalah akanmemudahkan software engineermenginterpretasikan asumsinya dan jugaberguna untuk mengetahui kembali jikaterdapat kesalahan.
    • 6.3: Model ValidationMerupakan suatu hal yang dibutuhkan untukmengesahkan kualitas suatu model yang sedangdianalisis.Sebagai contoh, dalam objek model sangatberguna untuk melakukan static anlisis untukmenguji bahwa jalur komunikasi antara objek ituada, dimana dalam daerah stakeholders, terjadipertukaran data.Jika formal specification notations digunakan,sangat memungkinkan untuk menggunakanformal reasoning untuk membuktikan spesifikasiproperties.
    • 6.4: Acceptance TestsProperty yang diperlukan dari sebuah software requirementadalah bahwa sangat mungkin untuk mengesahkan produk yangtelah selesai dapat memenuhinya.Requirements yang tidak dapat divalidasi merupakan hanyasebuah ‘keinginan’.Sebuah tugas yang penting adalah merencanakan bagaimanamenguji masing-masing requirement.Dalam berbagai kasus, desain acceptance tests yangmelakukannya.Mengidentifikasi dan mendesain acceptance tests mungkin sangatsulit untuk non-functional requirement. Agar bisa divalidasi, pertama harus dianalisis pada poin dimanadapat ditunjukkan secara kuantitatif.
    • Practical Considerations
    • Practical ConsiderationsTidak semua organisasi mempunyai kebiasaanmendokumentasikan dan mengatur requirement.Bagaimanapun, sebagai perusahaan yangberkembang, pelanggan mereka bertumbuh, danproduk mulai berkembang, mereka menemukanbahwa mereka perlu untuk memulihkankeperluan – keperluan yang mendukung fiturproduk agar dapat menaksir gangguan dariperubahan tujuan.Oleh sebab itu, requirements documentation danpengubahan management adalah kunci suksesdari requirements process.
    • 7.1:Iterative Nature of Requirements ProcessKebanyakan proyek didesak olehlingkungannya, dan banyak perubahan,atau revisi, dari software yang ada.Sehingga, selalu tidak bisa dijalankanuntuk implementasi requirement processsebagai sebuah linear, dan penangananlebih pada tim software development.
    • Pada beberapa proyek, hal ini bisa sajamenghasilkan/berdampak dalamkebutuhan yang digariskan sebelumsemua propertinya benar-benar dipahami.Point yang paling penting dalam mengertirequirement engineering adalah proporsiyang signifikan dari requirement yangakan berubah.Kadang- kadang dikarenakan error padaanalisa, tapi ini sering akibat perubahanlingkungan yang tak dapat dihindarkan.Contohnya, operasi pelanggan ataulingkungan bisnis, atau pasar dimanasoftware harus dijual.
    • 7.2: Change managementChange management adalah pusat untukmengatur requirement.Topik ini menggambarkan peran darichange management, prosedur yangdiperlukan, dan analisa yang seharusnyadigunakan untuk usulan pengubahan.Ini telah memperkuat hubungan SoftwareConfiguration Management KnowledgeArea.
    • 7.3: Requirements AttributesRequirement sebaiknya tidak hanya terdiri dariperincian dari apa yang dibutuhkan, tapi juga dariinformasi tambahan yang mana membantumengatur dan menafsirkan requirement tersebut.Mungkin juga memasukkan informasi tambahanseperti kesimpulan dari masing- masingrequirement, sumber daya dari masing- masingrequirement, dan perubahan sejarah.Requirement attribute yang paling penting adalahsebuah pengenal yang mana memperbolehkanrequirement tersebut unik dan jelas.
    • 7.4: Requirements TracingRequirements Tracing diperhatikan denganpemulihan sumber daya requirement danmemprediksikan efek dari requirement.Tracing adalah pokok untuk melakukan analisaketika requirement berubah.Sebuah requirement sebaiknya dapat di- trace kebelakang. Contoh, dari software requirementkembali ke system requirement.
    • Sebaliknya, requirement sebaiknya dapatdi- trace ke depan. Contoh, dari systemrequirement ke software requirement yangtelah diuraikan, dan ke kode modul yangmengimplementasikannya.Requirement Tracing untuk proyek yangkhusus akan membentuk DAG ( DirectedAcyclic Graph) yang kompleks darirequirement.
    • 7.5: Measuring RequirementSebagai sebuah bentuk yang praktis, biasanya digunakanuntuk mempunyai beberapa konsep ‘volume’ requirementuntuk produk software.Jumlah ini digunakan dalam mengevaluasi ukuran padaperubahan dalam requirement, dalam estimasi hargadevelopment atau tugas maintenance, ataumenyerderhanakan penggunaan sebagai denominator padapengukur lain.FSM ( Functional Size Measurement ) adalah sebuah teknikuntuk mengevaluasi ukuran badan dari fungsi requirement.IEEE Std 14143.1 mendefinisikan konsep dari FSM.Informasi tambahan ukuran dan standard akan ditemukandi Software Engineering Process Knowledge Area.