SlideShare ist ein Scribd-Unternehmen logo
1 von 45
Downloaden Sie, um offline zu lesen
SOFTWARE
REQUIREMENTS
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 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.
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 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 requirement
process 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 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,
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
            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.
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.
Spesifikasi Requirement
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.
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.
5.1:
   Dokumen 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.
5.2:
Spesifikasi 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.
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 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.
Requirements validation
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.
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:
            Prototyping
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.
6.3:
          Model 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.
6.4:
            Acceptance 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.
Practical Considerations
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.
7.1:
Iterative 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.
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.
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.
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.
7.4:
       Requirements 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.
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.
7.5:
     Measuring 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.

Weitere ähnliche Inhalte

Was ist angesagt?

Pertemuan 5 list view
Pertemuan 5 list viewPertemuan 5 list view
Pertemuan 5 list viewheriakj
 
Perancangan dan Analisa Sistem
Perancangan dan Analisa SistemPerancangan dan Analisa Sistem
Perancangan dan Analisa Sistemguestb7aaaf1e
 
Intermediate code kode antara
Intermediate code   kode antaraIntermediate code   kode antara
Intermediate code kode antaraGunawan Manalu
 
Pertemuan 6 tabview
Pertemuan 6 tabviewPertemuan 6 tabview
Pertemuan 6 tabviewheriakj
 
PERANCANGAN PERANGKAT LUNAK
PERANCANGAN PERANGKAT LUNAKPERANCANGAN PERANGKAT LUNAK
PERANCANGAN PERANGKAT LUNAKDhika The'Lover
 
PENDEKATAN PERANCANGAN TERSTRUKTUR DATA FLOW DIAGRAM
PENDEKATAN PERANCANGAN TERSTRUKTUR DATA FLOW DIAGRAMPENDEKATAN PERANCANGAN TERSTRUKTUR DATA FLOW DIAGRAM
PENDEKATAN PERANCANGAN TERSTRUKTUR DATA FLOW DIAGRAMMuhammad Baihaqi
 
Testing&implementasi 4
Testing&implementasi 4Testing&implementasi 4
Testing&implementasi 4aiiniR
 
Data Base Tiket Pesawat
Data Base Tiket PesawatData Base Tiket Pesawat
Data Base Tiket Pesawatnaufals11
 
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...Uofa_Unsada
 
UML Aplikasi Rental Mobil
UML Aplikasi Rental MobilUML Aplikasi Rental Mobil
UML Aplikasi Rental MobilDwi Mardianti
 
ERD Sistem Informasi Pemesanan Tiket Bioskop Online
ERD Sistem Informasi Pemesanan Tiket Bioskop OnlineERD Sistem Informasi Pemesanan Tiket Bioskop Online
ERD Sistem Informasi Pemesanan Tiket Bioskop OnlineLucha Kamala Putri
 
Analisis ERD Database Rumah Sakit
Analisis ERD Database Rumah SakitAnalisis ERD Database Rumah Sakit
Analisis ERD Database Rumah SakitFitria Nuri
 
Sistem Basis Data(PPT)
Sistem Basis Data(PPT)Sistem Basis Data(PPT)
Sistem Basis Data(PPT)tafrikan
 
Error Handling - P 7 Teknik Kompilasi
Error Handling - P 7 Teknik Kompilasi Error Handling - P 7 Teknik Kompilasi
Error Handling - P 7 Teknik Kompilasi ahmad haidaroh
 

Was ist angesagt? (20)

Pertemuan 5 list view
Pertemuan 5 list viewPertemuan 5 list view
Pertemuan 5 list view
 
Pengujian Perangkat Lunak
Pengujian Perangkat LunakPengujian Perangkat Lunak
Pengujian Perangkat Lunak
 
Perancangan dan Analisa Sistem
Perancangan dan Analisa SistemPerancangan dan Analisa Sistem
Perancangan dan Analisa Sistem
 
Sistem Operasi Komputer
Sistem Operasi KomputerSistem Operasi Komputer
Sistem Operasi Komputer
 
Intermediate code kode antara
Intermediate code   kode antaraIntermediate code   kode antara
Intermediate code kode antara
 
Pertemuan 6 tabview
Pertemuan 6 tabviewPertemuan 6 tabview
Pertemuan 6 tabview
 
Use skenario
Use skenarioUse skenario
Use skenario
 
Use Case Diagram
Use Case DiagramUse Case Diagram
Use Case Diagram
 
PERANCANGAN PERANGKAT LUNAK
PERANCANGAN PERANGKAT LUNAKPERANCANGAN PERANGKAT LUNAK
PERANCANGAN PERANGKAT LUNAK
 
PENDEKATAN PERANCANGAN TERSTRUKTUR DATA FLOW DIAGRAM
PENDEKATAN PERANCANGAN TERSTRUKTUR DATA FLOW DIAGRAMPENDEKATAN PERANCANGAN TERSTRUKTUR DATA FLOW DIAGRAM
PENDEKATAN PERANCANGAN TERSTRUKTUR DATA FLOW DIAGRAM
 
Requirement Engineering
Requirement EngineeringRequirement Engineering
Requirement Engineering
 
Testing&implementasi 4
Testing&implementasi 4Testing&implementasi 4
Testing&implementasi 4
 
Data Base Tiket Pesawat
Data Base Tiket PesawatData Base Tiket Pesawat
Data Base Tiket Pesawat
 
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
LAPORAN TUGAS AKHIR PERANCANGAN APLIKASI KNOWLEDGE BASE SYSTEM UNTUK INSTRUKS...
 
UML Aplikasi Rental Mobil
UML Aplikasi Rental MobilUML Aplikasi Rental Mobil
UML Aplikasi Rental Mobil
 
ERD Sistem Informasi Pemesanan Tiket Bioskop Online
ERD Sistem Informasi Pemesanan Tiket Bioskop OnlineERD Sistem Informasi Pemesanan Tiket Bioskop Online
ERD Sistem Informasi Pemesanan Tiket Bioskop Online
 
Analisis ERD Database Rumah Sakit
Analisis ERD Database Rumah SakitAnalisis ERD Database Rumah Sakit
Analisis ERD Database Rumah Sakit
 
Sistem Basis Data(PPT)
Sistem Basis Data(PPT)Sistem Basis Data(PPT)
Sistem Basis Data(PPT)
 
Error Handling - P 7 Teknik Kompilasi
Error Handling - P 7 Teknik Kompilasi Error Handling - P 7 Teknik Kompilasi
Error Handling - P 7 Teknik Kompilasi
 
Software reuse
Software reuseSoftware reuse
Software reuse
 

Andere mochten auch

Rekayasa Perangkat Lunak software design fundamentals
Rekayasa Perangkat Lunak software design fundamentalsRekayasa Perangkat Lunak software design fundamentals
Rekayasa Perangkat Lunak software design fundamentalsListyowatik (Yanie)
 
REKAYASA PERANGKAT LUNAK (REQUIREMENTS ANALYSIS FUNDAMENTALS)
REKAYASA PERANGKAT LUNAK (REQUIREMENTS ANALYSIS FUNDAMENTALS)REKAYASA PERANGKAT LUNAK (REQUIREMENTS ANALYSIS FUNDAMENTALS)
REKAYASA PERANGKAT LUNAK (REQUIREMENTS ANALYSIS FUNDAMENTALS)Listyowatik (Yanie)
 
Contoh skpl-software-manajemen-sekolah
Contoh skpl-software-manajemen-sekolahContoh skpl-software-manajemen-sekolah
Contoh skpl-software-manajemen-sekolahDinilOctav
 
Kebutuhan fungsional aplikasi simpel
Kebutuhan fungsional aplikasi simpelKebutuhan fungsional aplikasi simpel
Kebutuhan fungsional aplikasi simpelartha69
 
Software Requirements Specification
Software Requirements SpecificationSoftware Requirements Specification
Software Requirements SpecificationAmir Syafrudin
 
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddelCHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddelmohamed khalaf alla mohamedain
 
Penyelesaian sistem persamaan linear dengan metode iterasi gauss seidel
Penyelesaian sistem persamaan linear dengan metode iterasi gauss seidelPenyelesaian sistem persamaan linear dengan metode iterasi gauss seidel
Penyelesaian sistem persamaan linear dengan metode iterasi gauss seidelBAIDILAH Baidilah
 
Penyelesaian sistem persamaan linear dengan metode gauss
Penyelesaian sistem persamaan linear dengan metode gaussPenyelesaian sistem persamaan linear dengan metode gauss
Penyelesaian sistem persamaan linear dengan metode gaussLitami
 

Andere mochten auch (9)

Rekayasa Perangkat Lunak software design fundamentals
Rekayasa Perangkat Lunak software design fundamentalsRekayasa Perangkat Lunak software design fundamentals
Rekayasa Perangkat Lunak software design fundamentals
 
REKAYASA PERANGKAT LUNAK (REQUIREMENTS ANALYSIS FUNDAMENTALS)
REKAYASA PERANGKAT LUNAK (REQUIREMENTS ANALYSIS FUNDAMENTALS)REKAYASA PERANGKAT LUNAK (REQUIREMENTS ANALYSIS FUNDAMENTALS)
REKAYASA PERANGKAT LUNAK (REQUIREMENTS ANALYSIS FUNDAMENTALS)
 
Contoh skpl-software-manajemen-sekolah
Contoh skpl-software-manajemen-sekolahContoh skpl-software-manajemen-sekolah
Contoh skpl-software-manajemen-sekolah
 
Kebutuhan fungsional aplikasi simpel
Kebutuhan fungsional aplikasi simpelKebutuhan fungsional aplikasi simpel
Kebutuhan fungsional aplikasi simpel
 
Software Requirements Specification
Software Requirements SpecificationSoftware Requirements Specification
Software Requirements Specification
 
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddelCHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
CHAPTER 6 REQUIREMENTS MODELING: SCENARIO based Model , Class based moddel
 
Software requirements
Software requirementsSoftware requirements
Software requirements
 
Penyelesaian sistem persamaan linear dengan metode iterasi gauss seidel
Penyelesaian sistem persamaan linear dengan metode iterasi gauss seidelPenyelesaian sistem persamaan linear dengan metode iterasi gauss seidel
Penyelesaian sistem persamaan linear dengan metode iterasi gauss seidel
 
Penyelesaian sistem persamaan linear dengan metode gauss
Penyelesaian sistem persamaan linear dengan metode gaussPenyelesaian sistem persamaan linear dengan metode gauss
Penyelesaian sistem persamaan linear dengan metode gauss
 

Ähnlich wie Software Requirements

Siklus dalam Software Development Life Cycle
Siklus dalam Software Development Life CycleSiklus dalam Software Development Life Cycle
Siklus dalam Software Development Life Cyclehansjenny
 
Pemodelan perangkat lunak
Pemodelan perangkat lunakPemodelan perangkat lunak
Pemodelan perangkat lunakAdityaSaputra83
 
Tugas Kelompok 5 Rekayasa Perangkat Lunak
Tugas Kelompok 5 Rekayasa Perangkat LunakTugas Kelompok 5 Rekayasa Perangkat Lunak
Tugas Kelompok 5 Rekayasa Perangkat LunakIlhamBintang40
 
PRINSIP DAN KONSEP ANALISA (ANALYSIS CONCEPT AND PRINCIPLES)
 PRINSIP DAN KONSEP ANALISA (ANALYSIS CONCEPT AND PRINCIPLES) PRINSIP DAN KONSEP ANALISA (ANALYSIS CONCEPT AND PRINCIPLES)
PRINSIP DAN KONSEP ANALISA (ANALYSIS CONCEPT AND PRINCIPLES)Tinkqi Qtink
 
Rekayasa perangkat lunak (dha3)
Rekayasa perangkat lunak (dha3)Rekayasa perangkat lunak (dha3)
Rekayasa perangkat lunak (dha3)Mawaddah Warahmah
 
Pemodelan perangkat lunak 1
Pemodelan perangkat lunak 1Pemodelan perangkat lunak 1
Pemodelan perangkat lunak 1Kurjum Usman
 
Faulty requirement definition
Faulty requirement definitionFaulty requirement definition
Faulty requirement definitionseyfert130
 
Pert 11 anisah 41812110004
Pert 11 anisah 41812110004Pert 11 anisah 41812110004
Pert 11 anisah 41812110004anisahprasetya
 
Pert 11 anisah 41812110004
Pert 11 anisah 41812110004Pert 11 anisah 41812110004
Pert 11 anisah 41812110004anisahprasetya
 
Model life cycle software
Model life cycle softwareModel life cycle software
Model life cycle softwareHarzalik Meank
 
System Development and Procurement kel 5 (05-01).pptx
System Development and Procurement kel 5 (05-01).pptxSystem Development and Procurement kel 5 (05-01).pptx
System Development and Procurement kel 5 (05-01).pptxrifqiarif6
 
Pemodelan perangkat lunak XI_ Pertemuan 2.pptx
Pemodelan perangkat lunak XI_ Pertemuan 2.pptxPemodelan perangkat lunak XI_ Pertemuan 2.pptx
Pemodelan perangkat lunak XI_ Pertemuan 2.pptxagusnugraha41
 
Analisa Software Quality Factor
Analisa Software Quality FactorAnalisa Software Quality Factor
Analisa Software Quality Factorkamalbaktir
 
Tugas analisa faktor kualitas
Tugas analisa faktor kualitasTugas analisa faktor kualitas
Tugas analisa faktor kualitaskamalbaktir
 
Proses rekayasa perangkat lunak
Proses rekayasa perangkat lunakProses rekayasa perangkat lunak
Proses rekayasa perangkat lunakDavy Arya Atmaja
 
Rpl 2- sw process model
Rpl 2- sw process modelRpl 2- sw process model
Rpl 2- sw process modelf' yagami
 
Tugas sim, rahayu, yananto mihadi putra, pengguna dan pengembang sistem
Tugas sim, rahayu, yananto mihadi putra, pengguna dan pengembang sistemTugas sim, rahayu, yananto mihadi putra, pengguna dan pengembang sistem
Tugas sim, rahayu, yananto mihadi putra, pengguna dan pengembang sistemRahayu Kikan
 

Ähnlich wie Software Requirements (20)

Rekayasa Perangkat Lunak - Model Pengembangan Sistem
Rekayasa Perangkat Lunak - Model Pengembangan SistemRekayasa Perangkat Lunak - Model Pengembangan Sistem
Rekayasa Perangkat Lunak - Model Pengembangan Sistem
 
Meeting 3 metode pengembangan sistem
Meeting 3   metode pengembangan sistemMeeting 3   metode pengembangan sistem
Meeting 3 metode pengembangan sistem
 
Siklus dalam Software Development Life Cycle
Siklus dalam Software Development Life CycleSiklus dalam Software Development Life Cycle
Siklus dalam Software Development Life Cycle
 
Pemodelan perangkat lunak
Pemodelan perangkat lunakPemodelan perangkat lunak
Pemodelan perangkat lunak
 
Tugas Kelompok 5 Rekayasa Perangkat Lunak
Tugas Kelompok 5 Rekayasa Perangkat LunakTugas Kelompok 5 Rekayasa Perangkat Lunak
Tugas Kelompok 5 Rekayasa Perangkat Lunak
 
PRINSIP DAN KONSEP ANALISA (ANALYSIS CONCEPT AND PRINCIPLES)
 PRINSIP DAN KONSEP ANALISA (ANALYSIS CONCEPT AND PRINCIPLES) PRINSIP DAN KONSEP ANALISA (ANALYSIS CONCEPT AND PRINCIPLES)
PRINSIP DAN KONSEP ANALISA (ANALYSIS CONCEPT AND PRINCIPLES)
 
Rekayasa perangkat lunak (dha3)
Rekayasa perangkat lunak (dha3)Rekayasa perangkat lunak (dha3)
Rekayasa perangkat lunak (dha3)
 
Pemodelan perangkat lunak 1
Pemodelan perangkat lunak 1Pemodelan perangkat lunak 1
Pemodelan perangkat lunak 1
 
Faulty requirement definition
Faulty requirement definitionFaulty requirement definition
Faulty requirement definition
 
Pert 11 anisah 41812110004
Pert 11 anisah 41812110004Pert 11 anisah 41812110004
Pert 11 anisah 41812110004
 
Pert 11 anisah 41812110004
Pert 11 anisah 41812110004Pert 11 anisah 41812110004
Pert 11 anisah 41812110004
 
Model life cycle software
Model life cycle softwareModel life cycle software
Model life cycle software
 
System Development and Procurement kel 5 (05-01).pptx
System Development and Procurement kel 5 (05-01).pptxSystem Development and Procurement kel 5 (05-01).pptx
System Development and Procurement kel 5 (05-01).pptx
 
Materi 4.pptx
Materi 4.pptxMateri 4.pptx
Materi 4.pptx
 
Pemodelan perangkat lunak XI_ Pertemuan 2.pptx
Pemodelan perangkat lunak XI_ Pertemuan 2.pptxPemodelan perangkat lunak XI_ Pertemuan 2.pptx
Pemodelan perangkat lunak XI_ Pertemuan 2.pptx
 
Analisa Software Quality Factor
Analisa Software Quality FactorAnalisa Software Quality Factor
Analisa Software Quality Factor
 
Tugas analisa faktor kualitas
Tugas analisa faktor kualitasTugas analisa faktor kualitas
Tugas analisa faktor kualitas
 
Proses rekayasa perangkat lunak
Proses rekayasa perangkat lunakProses rekayasa perangkat lunak
Proses rekayasa perangkat lunak
 
Rpl 2- sw process model
Rpl 2- sw process modelRpl 2- sw process model
Rpl 2- sw process model
 
Tugas sim, rahayu, yananto mihadi putra, pengguna dan pengembang sistem
Tugas sim, rahayu, yananto mihadi putra, pengguna dan pengembang sistemTugas sim, rahayu, yananto mihadi putra, pengguna dan pengembang sistem
Tugas sim, rahayu, yananto mihadi putra, pengguna dan pengembang sistem
 

Kürzlich hochgeladen

Materi pesantren kilat Ramadhan tema puasa.pptx
Materi pesantren kilat Ramadhan  tema puasa.pptxMateri pesantren kilat Ramadhan  tema puasa.pptx
Materi pesantren kilat Ramadhan tema puasa.pptxSuarniSuarni5
 
Aksi Nyata Guru Penggerak Modul 3.3. Program Berdampak Positif pada Murid
Aksi Nyata Guru Penggerak Modul 3.3. Program Berdampak Positif pada MuridAksi Nyata Guru Penggerak Modul 3.3. Program Berdampak Positif pada Murid
Aksi Nyata Guru Penggerak Modul 3.3. Program Berdampak Positif pada MuridDonyAndriSetiawan
 
Implementasi Model pembelajaran STEAM Holistik-Integratif Berbasis Digital Me...
Implementasi Model pembelajaran STEAM Holistik-Integratif Berbasis Digital Me...Implementasi Model pembelajaran STEAM Holistik-Integratif Berbasis Digital Me...
Implementasi Model pembelajaran STEAM Holistik-Integratif Berbasis Digital Me...Shoffan shoffa
 
DSKP KSSM Kurikulum Bersepadu Dini LAM Tingkatan 3
DSKP KSSM Kurikulum Bersepadu Dini LAM Tingkatan 3DSKP KSSM Kurikulum Bersepadu Dini LAM Tingkatan 3
DSKP KSSM Kurikulum Bersepadu Dini LAM Tingkatan 3sekolah9304
 
BMMB 1134 KETERAMPILAN BERBAHASA HALANGAN KOMUNIKASI
BMMB 1134 KETERAMPILAN BERBAHASA HALANGAN KOMUNIKASIBMMB 1134 KETERAMPILAN BERBAHASA HALANGAN KOMUNIKASI
BMMB 1134 KETERAMPILAN BERBAHASA HALANGAN KOMUNIKASIsyedharis59
 
Program Roots Indonesia - Aksi Nyata.pdf
Program Roots Indonesia - Aksi Nyata.pdfProgram Roots Indonesia - Aksi Nyata.pdf
Program Roots Indonesia - Aksi Nyata.pdfrizalrulloh1992
 
power point mengenai akhlak remaja: menghindari tawuran
power point mengenai akhlak remaja: menghindari tawuranpower point mengenai akhlak remaja: menghindari tawuran
power point mengenai akhlak remaja: menghindari tawuranapriandanu
 
Dinamika atmosfer dan Dampaknya terhadap kehidupan.pptx
Dinamika atmosfer dan Dampaknya terhadap kehidupan.pptxDinamika atmosfer dan Dampaknya terhadap kehidupan.pptx
Dinamika atmosfer dan Dampaknya terhadap kehidupan.pptxFritzPieterMichaelNa
 
1.-Materi-Prof.-Bambang-1.ppt PENYEBAB GAGAL GINJAL AKUT
1.-Materi-Prof.-Bambang-1.ppt PENYEBAB GAGAL GINJAL AKUT1.-Materi-Prof.-Bambang-1.ppt PENYEBAB GAGAL GINJAL AKUT
1.-Materi-Prof.-Bambang-1.ppt PENYEBAB GAGAL GINJAL AKUTeric214073
 
573323880-PPT-Nasionalisme-dan-Anti-Korupsi.pptx
573323880-PPT-Nasionalisme-dan-Anti-Korupsi.pptx573323880-PPT-Nasionalisme-dan-Anti-Korupsi.pptx
573323880-PPT-Nasionalisme-dan-Anti-Korupsi.pptxanisakhairoza
 
DOKUMEN PENJAJARAN_KSSR MATEMATIK TAHAP 1_EDISI 3.pdf
DOKUMEN PENJAJARAN_KSSR MATEMATIK TAHAP 1_EDISI 3.pdfDOKUMEN PENJAJARAN_KSSR MATEMATIK TAHAP 1_EDISI 3.pdf
DOKUMEN PENJAJARAN_KSSR MATEMATIK TAHAP 1_EDISI 3.pdfssuserb45274
 
Tanqihul Qoul Bab 14 - Keutamaan Ibadah Fardhu.pptx
Tanqihul Qoul Bab 14  - Keutamaan Ibadah Fardhu.pptxTanqihul Qoul Bab 14  - Keutamaan Ibadah Fardhu.pptx
Tanqihul Qoul Bab 14 - Keutamaan Ibadah Fardhu.pptxMMuminSholih
 
Materi Presentasi PPT Komunitas belajar 2.pptx
Materi Presentasi PPT Komunitas belajar 2.pptxMateri Presentasi PPT Komunitas belajar 2.pptx
Materi Presentasi PPT Komunitas belajar 2.pptxnursamsi40
 
Paparan Model Kompetensi Kepala Sekolah.pptx
Paparan Model Kompetensi Kepala Sekolah.pptxPaparan Model Kompetensi Kepala Sekolah.pptx
Paparan Model Kompetensi Kepala Sekolah.pptxagunk4
 
materi PPT tentang cerita inspiratif kelas 9 smp
materi PPT tentang cerita inspiratif kelas 9 smpmateri PPT tentang cerita inspiratif kelas 9 smp
materi PPT tentang cerita inspiratif kelas 9 smpAanSutrisno
 
Kisi-kisi PTS Kelas 8 semester 2 kurikulum merdeka
Kisi-kisi PTS Kelas 8 semester 2 kurikulum merdekaKisi-kisi PTS Kelas 8 semester 2 kurikulum merdeka
Kisi-kisi PTS Kelas 8 semester 2 kurikulum merdekahellenchanel31
 
PPT GABUNGAN 1 kelas 9 gabungan tabung dengan setengah bola.pptx
PPT GABUNGAN 1 kelas 9 gabungan tabung dengan setengah bola.pptxPPT GABUNGAN 1 kelas 9 gabungan tabung dengan setengah bola.pptx
PPT GABUNGAN 1 kelas 9 gabungan tabung dengan setengah bola.pptxRestiana8
 
Seminar Seri AI Talks - AI dan Media Kristen
Seminar Seri AI Talks - AI dan Media KristenSeminar Seri AI Talks - AI dan Media Kristen
Seminar Seri AI Talks - AI dan Media KristenSABDA
 
Sasaran dan Pengembangan Sikap Profesional Guru.pptx
Sasaran dan Pengembangan Sikap Profesional Guru.pptxSasaran dan Pengembangan Sikap Profesional Guru.pptx
Sasaran dan Pengembangan Sikap Profesional Guru.pptxFidelaNiam
 

Kürzlich hochgeladen (20)

Materi pesantren kilat Ramadhan tema puasa.pptx
Materi pesantren kilat Ramadhan  tema puasa.pptxMateri pesantren kilat Ramadhan  tema puasa.pptx
Materi pesantren kilat Ramadhan tema puasa.pptx
 
Aksi Nyata Guru Penggerak Modul 3.3. Program Berdampak Positif pada Murid
Aksi Nyata Guru Penggerak Modul 3.3. Program Berdampak Positif pada MuridAksi Nyata Guru Penggerak Modul 3.3. Program Berdampak Positif pada Murid
Aksi Nyata Guru Penggerak Modul 3.3. Program Berdampak Positif pada Murid
 
Implementasi Model pembelajaran STEAM Holistik-Integratif Berbasis Digital Me...
Implementasi Model pembelajaran STEAM Holistik-Integratif Berbasis Digital Me...Implementasi Model pembelajaran STEAM Holistik-Integratif Berbasis Digital Me...
Implementasi Model pembelajaran STEAM Holistik-Integratif Berbasis Digital Me...
 
DSKP KSSM Kurikulum Bersepadu Dini LAM Tingkatan 3
DSKP KSSM Kurikulum Bersepadu Dini LAM Tingkatan 3DSKP KSSM Kurikulum Bersepadu Dini LAM Tingkatan 3
DSKP KSSM Kurikulum Bersepadu Dini LAM Tingkatan 3
 
BMMB 1134 KETERAMPILAN BERBAHASA HALANGAN KOMUNIKASI
BMMB 1134 KETERAMPILAN BERBAHASA HALANGAN KOMUNIKASIBMMB 1134 KETERAMPILAN BERBAHASA HALANGAN KOMUNIKASI
BMMB 1134 KETERAMPILAN BERBAHASA HALANGAN KOMUNIKASI
 
Program Roots Indonesia - Aksi Nyata.pdf
Program Roots Indonesia - Aksi Nyata.pdfProgram Roots Indonesia - Aksi Nyata.pdf
Program Roots Indonesia - Aksi Nyata.pdf
 
power point mengenai akhlak remaja: menghindari tawuran
power point mengenai akhlak remaja: menghindari tawuranpower point mengenai akhlak remaja: menghindari tawuran
power point mengenai akhlak remaja: menghindari tawuran
 
Dinamika atmosfer dan Dampaknya terhadap kehidupan.pptx
Dinamika atmosfer dan Dampaknya terhadap kehidupan.pptxDinamika atmosfer dan Dampaknya terhadap kehidupan.pptx
Dinamika atmosfer dan Dampaknya terhadap kehidupan.pptx
 
1.-Materi-Prof.-Bambang-1.ppt PENYEBAB GAGAL GINJAL AKUT
1.-Materi-Prof.-Bambang-1.ppt PENYEBAB GAGAL GINJAL AKUT1.-Materi-Prof.-Bambang-1.ppt PENYEBAB GAGAL GINJAL AKUT
1.-Materi-Prof.-Bambang-1.ppt PENYEBAB GAGAL GINJAL AKUT
 
573323880-PPT-Nasionalisme-dan-Anti-Korupsi.pptx
573323880-PPT-Nasionalisme-dan-Anti-Korupsi.pptx573323880-PPT-Nasionalisme-dan-Anti-Korupsi.pptx
573323880-PPT-Nasionalisme-dan-Anti-Korupsi.pptx
 
DOKUMEN PENJAJARAN_KSSR MATEMATIK TAHAP 1_EDISI 3.pdf
DOKUMEN PENJAJARAN_KSSR MATEMATIK TAHAP 1_EDISI 3.pdfDOKUMEN PENJAJARAN_KSSR MATEMATIK TAHAP 1_EDISI 3.pdf
DOKUMEN PENJAJARAN_KSSR MATEMATIK TAHAP 1_EDISI 3.pdf
 
Tanqihul Qoul Bab 14 - Keutamaan Ibadah Fardhu.pptx
Tanqihul Qoul Bab 14  - Keutamaan Ibadah Fardhu.pptxTanqihul Qoul Bab 14  - Keutamaan Ibadah Fardhu.pptx
Tanqihul Qoul Bab 14 - Keutamaan Ibadah Fardhu.pptx
 
Materi Presentasi PPT Komunitas belajar 2.pptx
Materi Presentasi PPT Komunitas belajar 2.pptxMateri Presentasi PPT Komunitas belajar 2.pptx
Materi Presentasi PPT Komunitas belajar 2.pptx
 
Paparan Model Kompetensi Kepala Sekolah.pptx
Paparan Model Kompetensi Kepala Sekolah.pptxPaparan Model Kompetensi Kepala Sekolah.pptx
Paparan Model Kompetensi Kepala Sekolah.pptx
 
materi PPT tentang cerita inspiratif kelas 9 smp
materi PPT tentang cerita inspiratif kelas 9 smpmateri PPT tentang cerita inspiratif kelas 9 smp
materi PPT tentang cerita inspiratif kelas 9 smp
 
Kisi-kisi PTS Kelas 8 semester 2 kurikulum merdeka
Kisi-kisi PTS Kelas 8 semester 2 kurikulum merdekaKisi-kisi PTS Kelas 8 semester 2 kurikulum merdeka
Kisi-kisi PTS Kelas 8 semester 2 kurikulum merdeka
 
PPT GABUNGAN 1 kelas 9 gabungan tabung dengan setengah bola.pptx
PPT GABUNGAN 1 kelas 9 gabungan tabung dengan setengah bola.pptxPPT GABUNGAN 1 kelas 9 gabungan tabung dengan setengah bola.pptx
PPT GABUNGAN 1 kelas 9 gabungan tabung dengan setengah bola.pptx
 
Seminar Seri AI Talks - AI dan Media Kristen
Seminar Seri AI Talks - AI dan Media KristenSeminar Seri AI Talks - AI dan Media Kristen
Seminar Seri AI Talks - AI dan Media Kristen
 
Sasaran dan Pengembangan Sikap Profesional Guru.pptx
Sasaran dan Pengembangan Sikap Profesional Guru.pptxSasaran dan Pengembangan Sikap Profesional Guru.pptx
Sasaran dan Pengembangan Sikap Profesional Guru.pptx
 
DEFINISI DAN KONTEKS MANAJEMEN ISU DAN KRISIS.pptx
DEFINISI DAN KONTEKS MANAJEMEN ISU DAN KRISIS.pptxDEFINISI DAN KONTEKS MANAJEMEN ISU DAN KRISIS.pptx
DEFINISI DAN KONTEKS MANAJEMEN ISU DAN KRISIS.pptx
 

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/diverifikasi.
  • 4. 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.
  • 5. 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.
  • 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 dari 1*10-8.
  • 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.
  • 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.
  • 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. Seringkali 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.
  • 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, pelacakan 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.
  • 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.1: Dokumen 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.2: Spesifikasi 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.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.
  • 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.
  • 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.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
  • 34. 6.2: Prototyping 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.3: Model 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.4: Acceptance 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.
  • 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.1: Iterative 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.4: Requirements 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.5: Measuring 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.