SOFTWARE REQUIREMENTS

1
SOFTWARE REQUIREMENTS
2
Dasar Dasar Software Requirements
3
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/diverifik
  asi.

4
Product and Process requirement

• Parameter produk adalah requirement pada software
  untuk dikembangkan (Contohnya Software harus
  memeriksa prasyarat mata kuliah yang diambil
  mahasiswa)
• Parameter 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.

5
Requirement fungsional dan nonfungsional

• Requirments 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.

6
Emergent Properties

• Beberapa requirement merupakan perwakilan dari
  emergent properties yaitu requirement yang tidak
  bisa ditangani oleh satu komponen saja.
  Keberhasilan dalam menanganinya juga bergantung
  pada interoperasi dari berbagai komponen yang
  ada. Emergent properties amat bergantung pada
  arsitektur sistem.

7
Quantifiable Requirements

• Software requirement harus bisa dinyatakan dengan
  jelas, tidak ambigu dan pada beberapa bagiannya
  yang sesuai, kuantitatif.
• Contoh requirement yang memenuhi syarat Sebuah
  perangkat lunak dari suatu call central harus
  meningkatkan throughput sebanyak 20 dan
  sistemnya hanya menghasilkan kesalahan fatal
  dengan peluang kurang.

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.

9
Requirement Process
10
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.

11
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.

12
Process Quality and Improvement

• Membahas penilaian kualitas dan peningkatan dari
  suatu requirement process. Tujuannya adalah untuk
  menekankan peran kunci requirement process dari
  segi biaya dan masa berlaku suatu produk software
  dan kepuasan pelanggan.

13
Requirements Elicitation
14
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.

15
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. Seringakali suatu
  software dibuat untuk menunjang proses bisnis.
  Karenanya perlu diperhatikan struktur, budaya
  kerja dan situasi politik dari organisasi yang
  bersangkutan.

16
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.

17
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.

18
Requirement Analysis
19
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.

20
Conceptual Modelling

• Pemodelan dari permaslahan riil adalah kunci dari
  analisa software requirements.
• Tujuannya untuk membantu memahami permasalahan.
  Model konseptual terdiri dari model entitas
  entitas dari domain permasalahan yang disusun
  untuk mewakili relasi riil dan ketergantungan
  riil.
• Ada beberapa model yang bisa dikembangkan. Antara
  lain aliran data dan kontrol, model keadaan,
  pelackan even, interaksi pengguna, model obyek,
  model data dan lain lain.

21
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.

22
Desain Arsitektural dan Alokasi Requirement

• Desain arsitektural adalah suatu tahap di mana
  requirement process dilakukan bersamaan dengan
  desain sistem atau software. Karenanya sulit
  memisahkan dua aktivitas tersebut.
• Desain arsitektural sangat berhubungan dengan
  pemodelan konseptual. Pemetaan domain entitas
  dunia nyata menjadi komponen software tidak
  selalu jelas, sehingga desain arsitektural
  dianggap sebagai topik terpisah. Requirement
  untuk notasi dan metode secara umum sama pada
  pemodelan konseptual dan desain arsitektural.

23
Negosiasi Requirement

• Topik ini disebut juga sebagai penyelesaian
  konflik. Topik ini membahas penanganan masalah
  requirement di mana timbul konflik antara dua
  pihak yang sama sama berkepentingan, antara
  requirement dengan sumber daya atau requirement
  fungsional dan non fungsional. Dalam kebanyakan
  kasus, keputusan yang diambil secara unilateral
  bukanlah sikap bijaksana. Karenanya penting untuk
  mencapai konsensus dengan pihak yang
  berkepentingan.

24
Spesifikasi Requirement
25
Spesifikasi Requirement

• Pada kebanyakan profesi perekayasaan, istilah
  spesifikasi merujuk pada kegiatan memberikan
  nilai numerik atau batas pada tujuan produk
  akhir.
• Tetapi definisi ini tidak bisa dipakai pada
  rekayasa perangkat lunak mengingat banyaknya
  requirement yang ada dan kompleksitas
  interaksinya.
• Karenanya pada rekayasa perangkat lunak istilah
  spesifikasi requirement software mengacu pada
  pembuatan dokumen baik fisik maupun elektronis.

26

• Pada sistem yang kompleks, terutama yang
  melibatkan banyak kompone non software, ada 3
  jenis dokumen yang dibuat yaitu definisi sistem,
  requirement sistem dan requirement perangkat
  lunak.
• Pada produk software yang sederhana hanya satu
  dari 3 jenis dokumen itu yang perlu dibuat.
• Semua tiga jenis dokumen itu akan dijelaskan di
  sini.

27
5.1Dokumen Definisi Sistem

• Dokumen ini menyimpan requirement sebuah sistem.
• Dokumen ini mendaftar semua requirement beserta
  keterangan latar belakang tujuan keseluruhan
  sebuah sistem, lingkungan yang menjadi sasaran
  dan pernyataan batasan, asumsi dan requirement
  non-fungsional.
• Mungkin juga di dalamnya terdapat model
  konseptual yang didesain untuk memberikan
  gambaran tentang konteks sistem, skenario
  pemakaian dan entitas - entitas domain yang
  penting, termasuk juga data, informasi dan aliran
  kerja.

28
5.2Spesifikasi Requirement Sistem.

• Para pengembang dari sebuah sistem berkomponen
  software dan non-software yang cukup banyak,
  seringkali memisahkan deskripsi dari requirement
  sistem dari deskripsi requirement software.
• Dengan cara ini, requirement sistem
  dispesifikasikan, requirement software didapat
  dari requirement sistem dan requirement untuk
  komponen sosftware dispesifikasikan .
• Karena merupakan bidang rekayasa sistem, dokumen
  jenis ini tidak akan dibahas terperinci di sini.

29
5.3Spesifikasi Requirement Software

• Dokumen jenis ini mendirikan 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.

30

• Dokumen ini memungkinkan penilaian mendalam
  tentang requirement sebelum desain dimulai
  sehingga mengurangi keharusan desain ulang.
• Dokumen ini juga memberikan dasar dasar
  realistis untuk memperkirakan biaya, risiko dan
  jadwal produksi.

31
Requirements validation
32
Requirements validation

• Kebutuhan dokumen difokuskan pada prosedur
  validasi dan verifikasi.
• Kebutuhan akan validasi untuk meyakinkan bahwa
  software engineer telah mengerti tentang
  requirement yang diperlukan, dan juga sangat
  penting untuk membuktikan bahwa requirements
  document dapat disesuaikan dengan kebutuhan
  standard suatu perusahaan, dan juga dapat mudah
  dipahami, konsisten, dan lengkap.

33
6.1Requirements 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

34
6.2Prototyping

• Prototyping secara umum berarti untuk melakukan
  validasi, interpretasi software engineer mengenai
  software requirements, sama seperti memperoleh
  requirement baru.
• Keuntungan dari prototype adalah akan memudahkan
  software engineer menginterpretasikan asumsinya
  dan juga berguna untuk mengetahui kembali jika
  terdapat kesalahan.

35
6.3Model Validation

• Merupakan suatu hal yang dibutuhkan untuk
  mengesahkan kualitas suatu model yang sedang
  dianalisis.
• Sebagai contoh, dalam objek model sangat berguna
  untuk melakukan static anlisis untuk menguji
  bahwa jalur komunikasi antara objek itu ada,
  dimana dalam daerah stakeholders, terjadi
  pertukaran data.
• Jika formal specification notations digunakan,
  sangat memungkinkan untuk menggunakan formal
  reasoning untuk membuktikan spesifikasi
  properties.

36
6.4Acceptance Tests

• Property yang diperlukan dari sebuah software
  requirement adalah bahwa sangat mungkin untuk
  mengesahkan produk yang telah selesai dapat
  memenuhinya.
• Requirements yang tidak dapat divalidasi
  merupakan hanya sebuah keinginan.
• Sebuah tugas yang penting adalah merencanakan
  bagaimana menguji masing-masing requirement.
• Dalam berbagai kasus, desain acceptance tests
  yang melakukannya.
• Mengidentifikasi dan mendesain acceptance tests
  mungkin sangat sulit untuk non-functional
  requirement.
• Agar bisa divalidasi, pertama harus dianalisis
  pada poin dimana dapat ditunjukkan secara
  kuantitatif.

37
Practical Considerations
38
Practical Considerations

• Tidak semua organisasi mempunyai kebiasaan
  mendokumentasikan dan mengatur requirement.
• Bagaimanapun, sebagai perusahaan yang
  berkembang, pelanggan mereka bertumbuh, dan
  produk mulai berkembang, mereka menemukan bahwa
  mereka perlu untuk memulihkan keperluan
  keperluan yang mendukung fitur produk agar dapat
  menaksir gangguan dari perubahan tujuan.
• Oleh sebab itu, requirements documentation dan
  pengubahan management adalah kunci sukses dari
  requirements process.

39
7.1Iterative Nature of Requirements Process

• Kebanyakan proyek didesak oleh lingkungannya,
  dan banyak perubahan, atau revisi, dari software
  yang ada.
• Sehingga, selalu tidak bisa dijalankan untuk
  implementasi requirement process sebagai sebuah
  linear, dan penanganan lebih pada tim software
  development.

40

• Pada beberapa proyek, hal ini bisa saja
  menghasilkan/berdampak dalam kebutuhan yang
  digariskan sebelum semua propertinya benar-benar
  dipahami.
• Point yang paling penting dalam mengerti
  requirement engineering adalah proporsi yang
  signifikan dari requirement yang akan berubah.
• Kadang- kadang dikarenakan error pada analisa,
  tapi ini sering akibat perubahan lingkungan yang
  tak dapat dihindarkan. Contohnya, operasi
  pelanggan atau lingkungan bisnis, atau pasar
  dimana software harus dijual.

41
7.2 Change management

• Change management adalah pusat untuk mengatur
  requirement.
• Topik ini menggambarkan peran dari change
  management, prosedur yang diperlukan, dan analisa
  yang seharusnya digunakan untuk usulan
  pengubahan.
• Ini telah memperkuat hubungan Software
  Configuration Management Knowledge Area.

42
7.3 Requirements Attributes

• Requirement sebaiknya tidak hanya terdiri dari
  perincian dari apa yang dibutuhkan, tapi juga
  dari informasi tambahan yang mana membantu
  mengatur dan menafsirkan requirement tersebut.
• Mungkin juga memasukkan informasi tambahan
  seperti kesimpulan dari masing- masing
  requirement, sumber daya dari masing- masing
  requirement, dan perubahan sejarah.
• Requirement attribute yang paling penting adalah
  sebuah pengenal yang mana memperbolehkan
  requirement tersebut unik dan jelas.

43
7.4Requirements Tracing

• Requirements Tracing diperhatikan dengan
  pemulihan sumber daya requirement dan
  memprediksikan efek dari requirement.
• Tracing adalah pokok untuk melakukan analisa
  ketika requirement berubah.
• Sebuah requirement sebaiknya dapat di- trace ke
  belakang. Contoh, dari software requirement
  kembali ke system requirement.

44

• Sebaliknya, requirement sebaiknya dapat di-
  trace ke depan. Contoh, dari system requirement
  ke software requirement yang telah diuraikan, dan
  ke kode modul yang mengimplementasikannya.
• Requirement Tracing untuk proyek yang khusus
  akan membentuk DAG ( Directed Acyclic Graph) yang
  kompleks dari requirement.

45
7.5Measuring Requirement

• Sebagai sebuah bentuk yang praktis, biasanya
  digunakan untuk mempunyai beberapa konsep
  volume requirement untuk produk software.
• Jumlah ini digunakan dalam mengevaluasi ukuran
  pada perubahan dalam requirement, dalam estimasi
  harga development atau tugas maintenance, atau
  menyerderhanakan penggunaan sebagai denominator
  pada pengukur lain.
• FSM ( Functional Size Measurement ) adalah
  sebuah teknik untuk mengevaluasi ukuran badan
  dari fungsi requirement.
• IEEE Std 14143.1 mendefinisikan konsep dari
  FSM.
• Informasi tambahan ukuran dan standard akan
  ditemukan di Software Engineering Process
  Knowledge Area.