RPL (REKAYASA PERANGKAT LUNAK)

Pendahuluan

}  Pembuatan program berkualitas yang dapat digunakan pada selang waktu panjang adalah sangat sulit.  

}  Rekayasa PL dimaksudkan untuk memberi landasan sehingga pengembangan PL dilakukan secara sistematis dengan sasaran memperoleh program yang berkualitas.

}  Program berkualitas adalah program yang handal (reliable), efisien, mudah dipahami, dimodifikasi dan dipelihara. 

 

Pengertian Perangkat Lunak

Adalah instruksi (program komputer) yang ketika dijalankan menyediakan fungsi dan tampilan yang diinginkan, struktur data yang memberi kesempatan program untuk memanipulasi informasi dan dokumen yang mendiskripsikan operasi dan penggunaan program.

}  Perangkat lunak merupakan program beserta dokumentasinya.

                Contoh dokumentasi berupa :

◦       Meng-install.

–   Apa spesifikasi perangkat keras ataupun lunak yg. dibutuhkan

–   Prosedur / langkah-langkah yang harus dikerjakan – apa yang boleh dan yang tidak boleh.

–   Apa yang perlu dilakukan sebelum dan sesudah memakai

◦       Mengembangkan.

◦       Apa kebutuhan user.

◦       Apa tujuan sistem

◦       Apa yang telah / belum dicapai

◦       Perawatan

◦       Perubahan yang mungkin ataupun yang tidak mungkin dilakukan.

 

Karakteristik PL

n   PL dikembangkan melalui tahapan perencanaan, analisis, perancangan, penulisan program, pengujian dan pemeliharaan (software life cycle)

n   PL dibangun berdasarkan kebutuhan, tidak hanya dibuat dari komponen yang sudah ada.

n   Tidak akan susut atau aus, tidak ada “suku cadang”, bukan hasil assembling.

}  Rancangan yang buruk berakibat pada peningkatan pemeliharaan perangkat lunak

}  Kegagalan pada perangkat lunak disebabkan oleh kesalahan pada rancangan dan implementasi, BUKAN karena susut atau aus.

 

Ciri Perangkat Lunak Yang Direkayasa Dengan Baik :

}  Mudah dirawat

◦       Tersedianya dokumentasi yang baik

◦       Perubahan dapat dilakukan dengan biaya minimum

}  Dapat diandalkan

}  Saat dijalankan (executed/ run) seperti yang diharapkan

}  Gagal hanya bila keluar dari spesifikasinya

}  Berjalan (execute / run) efisien

◦       Tidak memboroskan sumber daya memory, prosesor, dll.

}  Mempunyai antar muka (interface) yang baik

◦       Dibuat sesuai dengan tingkat kemampuan pemakai

 

3 kelompok yang menilai kualitas PL :

}  Sponsor : pemberi dana untuk pengembanan PL

◦       melihat dari aspek ongkos yang murah, peningkatan produktivitas, fleksibilitas, efisiensi, dan kehandalan.

}  Pemakai : orang yang akan menggunakan PL yang dikembangkan

◦       melihat dari aspek afungsionalitas, kemudahan dipelajari, kemudahan pengingatan, kemudahan penggunaan, efisiensi, dan kehandalan.

}  Pemelihara / pemodifikasi.

◦       melihat dari aspek kesalahan yang minimum, dokumentasi yang bagus, kode yang mudah dipahami / dibaca, rancangan yang bagus, efisiensi dan kehandalan.

 

Ongoing Problems (Masalah yang terus menerus  ada)

◦       Kemajuan perangkat keras melebihi kemampuan membuat software

◦       Kemampuan membangun program baru tidak dapat memenuhi permintaan program-program baru, begitu juga kecepatan membangun program  tidak dapat mnegikuti kebutuhan bisnis dan pasar

◦       Penyebaran penggunaan computer telah membuat kebergantungan masyarakat thdp komputer

◦       Tantangan untuk membangun software dengan reliability & quality yang tinggi

◦       Kemampuan men-support dan meningkatkan program terancam oleh design yang buruk dan keterbatasan sumberdaya

 

Definisi Rekayasa PL

}  RPL adalah sebuah disiplin dimana dalam menghasilkan perangkat lunak bebas dari kesalahan dan sesuai anggaran, tepat waktu serta memuaskan keinginan pemakai.

                à mengacu pada software crisis, yaitu : tepat waktu, sesuai budget, berkualitas, dan sesuai keinginan pemakai.

                à Kepuasan Pemakai = Produk yang memenuhi kebutuhan + kualitas baik + sesuai anggran dan tepat waktu.

Definisi Klasik (1969)

“The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.”

Penerapan prinsip engineering untuk memperoleh software yang ekonomis, reliable dan bekerja efisien pada komputer

Definisi IEEE  (1993)

“Software Engineering:  (1)  The application of a systematic, disciplines, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software.  (2)  The study of approaches as in (1).”

RPL : (1) Penerapan secara sistematis, disiplin, pendekatan terukur pada pengembangan, pengoperasian dan pemeliharaan software. (2) Studi terhadap (1)

}  RPL adalah sebuah studi pendekatan dan aplikasi secara sistematis, disiplin pengembangan operasi dan pemeliharaan perangkat lunak yang kesemuanya itu merupakan aplikasi rekayasa yang berkaitan dengan perangkat lunak. 

 

Perekayasa perangkat lunak harus menguasai :

}  Teknologi komputer

◦       Ilmu dasar komputer     

◦       Pengetahuan perangkat keras

}  Teknologi pengembangan perangkat lunak

◦       Teori, Metodologi, Alat-alat (tools)

}  Manajemen proyek

◦       Pembagian tugas & tanggung jawab di dalam kelompok.

◦       Mengendalikan waktu, biaya dan kualitas.

}  Kemampuan berkomunikasi ( lisan dan tertulis ).

◦       Memahami kesulitan yang dihadapi user ( yang awam dengan teknologi dan metodologi ).

Tujuan :

◦       Untuk membangun software yang benar dan benar sebuah software (right software and software right)

◦       Untuk membangun software yang tepat (correct).

◦       Dikelola dengan baik untuk pemeliharaan kebenarannya (correctness).

 

Komponen Rekayasa Perangkat Lunak.

 

Methods

Metode software engineering memberikan tehnik-tehnik bagaimana membentuk software. Metode ini terdiri dari serangkaian tugas :

}  -->Perencanaan & estimasi proyek

}  -->Analisis kebutuhan sistem dan software

}  -->Desain struktur data

}  -->Arsitektur program dan prosedur algoritma

}  -->Coding

}  -->Testing dan pemeliharaan

 

Tools

Peralatan software engineering memberikan dukungan atau semiautomasi untuk metode. Contohnya :

}  -->CASE (Case Aided Software Engineering), yaitu suatu software yang menggabungkan software, hard­ware, dan database software engineering untuk menghasilkan suatu lingkungan software engineering.

}  -->Database Software Engineering, adalah sebuah struktur data yang berisi informasi penting tentang analisis, desain, kode dan testing.

}  -->Analogi dengan CASE pada hardware adalah : CAD, CAM, CAE

 

Proses Model

Prosedur Software Engineering Terdiri dari : urut-urutan di mana metode tersebut diterapkan

}  -->dokumen

}  -->laporan-laporan

}  -->formulir-formulir yang diperlukan

}  -->mengontrol kualitas software

}  -->mengkoordinasi perubahan yang terjadi pada software

 

Permasalahan yang dihadapi pemakai PL :

}  Kompleksitas permasalahan yang dihadapi meningkat, sejalan dengan perkembangan usaha & oganisasi.

}  Banyaknya alternatif solusi yang ditawarkan kepada pemakai

}  Teknologi sistem komputer yang berkembang dengan cepat, terutama perangkat keras, berakibat masa pakai semangkin singkat.

}  PL aplikasi harus terwujud dalam waktu yang relatif singkat, pemakai tidak dapat menunggu terlalu lama.

}  Pemakai tidak dapat / sukar untuk merumuskan spesifikasi PL yang diperlukan.

}  Isu Yang Perlu diperhatikan :

}  Biaya Pengembangan : Setiap rupiah yang dikeluarkan untuk mengembangkan PL, harus jelas manfaat langsung dan tidak langsung dari perangkat lunak yang dihasilkan.

Produktifitas Pengembangan

}  PL harus dihasilkan dalam waktu yang pendek, karena pengguna memerlukan salusi yang cepat

}  Sangat sukar bagi pemakai dalam menentukan spesifikasi PL aplikasi yang diperlukan.

Kualitas PL

}  Menentukan kehandalan sistem komputer

}  Mempengaruhi unjuk kerja sistem

}  Menentukan apakah PL mudah untuk dipelihara & dikembangkan.

Pemeliharaan PL

}  Fine tuning

}  Memperbaiki, karena ada kesalahn (bugs) pada PL

}  Menyesuaikan dengan perubahan Perangkat keras dan sistem software

}  Penyesuaian terhadap perkembangan dunia usaha dan organisasi.

—  Di dalam pengembangan rekayasa perangkat lunak biasanya dipandu dengan pemodelan dengan Daur Hidup Perangkat Lunak (Software Development Life Cycle).

—  Tak ada standar sehingga bervariasi model proses u/ menggambarkan rekayasa daur hidup p.l. Namun tahap-tahap yang prinsipal terhadap pemetaan model proses kedalam aktifitas pengembangan yang fundamental adalah sbb:

1.       Spesifikikasi Perangkat Lunak à Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan.

2.       Pengembangan (Perancangan dan Implementasi) Perangkat Lunak à Perangkat lunak yang memenuhi spesifikasi harus di produksi

3.       Validasi Perangkat Lunak à Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak bekerja sesuai dengan apa yang diinginkan oleh pelanggan.

4.       Evolusi Perangkat Lunak à Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.

Proses Perangkat Lunak ?

—  Sekumpulan aktifitas untuk mengembangkan perangkat lunak yang berkualitas. Proses PL merupakan aktifitas yang saling terkait untuk menspesifikasikan, merancang / pengembangan, pengujian dan implementasi sistem perangkat lunak.

—  Proses PL merupakan suatu pendekatan terhadap PL yang direkayasa (software is engineered).

               

Model Proses Perangkat Lunak

1. Model Air Terjun (“Waterfall” Model)
2. Model Evolusioner
3. Model Pengembangan Sistem Formal
4. Model Pemakaian Ulang (Re-Usable)
5. Model Iterasi :

—  Incremental

—  Spiral

—  Rapid Application Development

6. Model Prototype

Model Proses Perangkat Lunak

1. Model air terjun (waterfall) à Biasa juga disebut siklus hidup perangkat lunak. Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.

Masalah dengan model waterfall

—  Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses.

—  Hal ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan pengguna (user).

—  Model air terjun harus digunakan hanya ketika persyaratan dipahami dengan baik.

Kekurangan Waterfall Model :

—  Pengguna hanya mendapatkan deskripsi yang panjang, rinci, dan “agak membosankan” untuk dibaca.

—  Alur linier, proses lambat

—  pengguna baru melihat produk setelah akhir tahapan.

—  Personil tidak bekerja optimal, karena ada waktu tunggu sebuah tahapan selesai.

Kelebihan Waterfall Model :

—  lebih disiplin

—  dorongan bahwa dokumentasi selalu tersedia untuk tiap tahapan (dokumen lengkap)

—  dorongan bahwa setiap produk yang dihasilkan selalu dicek.

maintenance mudah, karena dokumen lengkap.

2. Pengembangan Evolusioner à Berdasarkan pada ide untuk mengembangkan implementasi awal, memperlihatkannya kepada user  untuk dikomentari, dan memperbaikinya versi demi versi sampai sistem yang memenuhi persyaratan diperoleh.

           Tidak ada kegiatan spesifikasi, pengembangan, dan validasi yang terpisah. Kegiatan2 ini dilakukan pada saat yang bersamaan dengan umpan balik yang cepat untuk masing2 kegiatan.

3. Model Pengembangan Sistem  Formal

Proses pengembangan Perangkat Lunak didasarkan pada transformasi matematis dari spesifikasi sistem menjadi program yang dapat dijalankan.

4. Model Pengembangan Berorientasi  Pemakaian Ulang (Re-Usable)

Bergantung pada sejumlah besar komponen perangkat lunak yang dapat dipakai ulang, yang bisa didapat, dan berapa kerangka kerja integrasi untuk komponen-komponen ini.

Komponen-komponen ini dapat juga sistem yang disebut COTS (Commercial Off-The-Shelf Systems/Sistem Siap Beli Komersial) yang dapat digunakan untuk memberikan fungsionalitas khusus seperti format teks, perhitungan numerik,dll.

5. ITERASI PROSES

—  Digunakan untuk kebanyakan sistem besar

—  Perlu digunakan berbagai pendekatan untuk berbagai bagian sistem, sehingga harus digunakan model HIBRID à bagian proses diulang, sementara persyaratan sistem berubah.

—  Terdapat 2 model iterasi :

—  Pengembangan Inkremental

—  Pengembangan Spiral

6. Prototyping Model

—  Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output.

—  Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface.

—  Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software.

A.System Engineering and Analysis

Karena software merupakan bagian terbesar dari sistem, maka pekerjaan dimulai dengan cara menerapkan

kebutuhan semua elemen sistem dan mengalokasikan sebagian kebutuhan tersebut ke software.

Pandangan terhadap sistem adalah penting, terutama pada saat software harus berhubungan dengan elemen

lain, seperti :

à Hardware

à Software

à Database

 

B. Analisis kebutuhan software

Suatu proses pengumpulan kebutuhan software untuk mengerti sifat-sifat program yang dibentuk software

engineering, atau analis harus mengerti fungsi software yang diinginkan, performance dan interface

terhadap elemen lainnya. Hasil dari analisis ini didokumentasikan dan direview / dibahas / ditinjau

bersama-sama customer.

 

C. Design

Desain software sesungguhnya adalah proses multi step (proses yang terdiri dari banyak langkah) yang

memfokuskan pada 3 atribut program yang berbeda, yaitu :

à Struktur data

à Arsitektur software

à Rincian prosedur

Proses desain menterjemahkan kebutuhan ke dalam representasi software yang dapat diukur kualitasnya

sebelum mulai coding. Hasil dari desain ini didokumentasikan dan menjadi bagian dari konfigurasi

software.

 

D. Coding

Desain harus diterjemahkan ke dalam bentuk yang dapat dibaca oleh mesin

 

E. Testing

Segera sesudah objek program dihasilkan, pengetesan program dimulai. Proses testing difokuskan pada logika

internal software. Jaminan bahwa semua pernyataan atau statements sudah dites dan lingkungan external

menjamin bahwa definisi input akan menghasilkan output yang diinginkan.

 

F. Maintenance

Software yang sudah dikirim ke customer data berubah karena

à Software mengalami error

à Software harus diadaptasi untuk menyesuaikan dengan lingkungan external, misalnya adanya sistem

operasi baru atau peripheral baru.

à Software yang lebih disempurnakan karena adanya permintaan dari customer.

Masalah yang dihadapi dari model siklus hidup klasik adalah :

à Proyek yang sebenarnya jarang mengikuti aliran sequential yang ditawarkan model ini. Iterasi

(Pengulangan) selalu terjadi dan menimbulkan masalah pda aplikasi yang dibentuk oleh model ini.

à Seringkali pada awalnya customer sulit menentukan semua kebutuhan secara explisit (jelas).

à Customer harus sabar karena versi program yang jalan tidak akan tersedia sampai proyek software selesai

dalam waktu yang lama.

Kebutuhan Software

sistem

 

 

Rekayasa Kebutuhan

  Proses menetapkan layanan yang dibutuhkan konsumen terhadap sistem dan batasan operasi dan pengembangan

  Kebutuhan sendiri adalah diskripsi layanan sistem dan batasan yang dibangkitkan selama proses rekayasa kebutuhan

Apakah Kebutuhan itu?

  Susunan pernyataan abstrak level tinggi dari layanan atau batasan sistem ke dalam spesifikasi fungsional matematis

  Tidak terelakkan bahwa kebutuhan mempunyai dua fungsi

o merupakan dasar untuk penawaran kontrak – sehingga harus terbuka untuk interpretasi

 o merupakan dasar untuk kontrak itu sendiri –sehingga harus didefinisikan dengan detail

o Kedua pernyataan diatas disebut kebutuhan

Tipe-tipe Kebutuhan

Kebutuhan User

o Pernyataan dalam bahasa natural plus diagram layanan yang tersedia dan batasan operasional.

Ditulis oleh konsumen   

Kebutuhan Sistem

o Dokumen terstruktur berisi diskripsi detail dari layanan sistem. Ditulis sebagai kontrak antara

klien dan kontraktor.

Spesifikasi Software

o Diskripsi software detail yang sebagai dasar untuk desain atau implementasi. Ditulis oleh developer

Kebutuhan Fungsional dan nonfungsional

  Kebutuhan fungsional

o Pernyataan layanan sistem yang harus disediakan, bagaimana sistem bereaksi pada input tertentu

dan bagaimana perilaku sistem pada situasi tertentu

  Kebutuhan non-fungsional

o Batasan layanan atau fungsi yang ditawarkan sistem seperti batasan waktu, batasan pengembangan proses, standarisasi dll

  Kebutuhan domain

o Kebutuhan yang datang dari domain aplikasi dari sistem dan yang menyatakan karakteristik dari domain tersebut

Kebutuhan Fungsional

  Menggambarkan fungsionalitas atau layanan sistem   Tergantung pada tipe software, harapan user

dan tipe sistem dimana software digunakan   Kebutuhan fungsional user merupakan

pernyataan level tinggi dari apa yang seharusnya dilakukan sistem tetapi kebutuhan fungsional sistem menggambarkan layanan sistem secara detail

Contoh Kebutuhan Fungsional

Rekayasa Perangkat Lunak 11

Contoh Kebutuhan Fungsional

  User dapat mencari semua kumpulan database inisial atau memilih subset dari database tersebut

  Sistem menyediakan tampilan yang tepat

untuk user yang membaca dokumen dalam penyimpan dokumen   Setiap pesanan dapat dialokasikan sebagai identifier yang unik (ORDER_ID) dimana user dapat meng-copy daerah penyimpan account permanen

Kebutuhan Non-fungsional

  Mendifinisikan properti sistem dan batasan Sistem, seperti kehandalah, waktu respon, kebutuhan penyimpan. Batasan misalnya kapabilitas perangkat I/O, representasi sistem dll

  Kebutuhan proses juga menetapkan penggunaan sistem CASE khusus, bahasa pemrograman atau metode pengembangan

  Kebutuhan non-fungsional lebih kritis daripada kebutuhan fungsional. Jika tidak dapat

bertemu, sistem menjadi tidak berguna

Klasifikasi Non-fungsional

  Kebutuhan Produk

o Kebutuhan yang menetapkan bahwa produk yang dikirim harus berjalan dengan cara tertentu,

contoh kecepatan eksekusi, kehandalan dll

  Kebutuhan Organisasi

o Kebutuhan sebagai akibat dari kebijakan organisas dan prosedur misalnya standar proses yang

digunakan, kebutuhan implementasi dll

  Kebutuhan Eksternal

o Kebutuhan yang muncul dari faktor eksternal sistem dan proses pengembangan misalnya kebutuhan antar operasi, kebutuhan legistatif dll

Tujuan dan Kebutuhan

  Kebutuhan Non-fungsional kemungkinan sangat sulit untuk ditetapkan dan kebutuhan yang

tidak tepat sulit diverifikasi

  Tujuan

o Tujuan umum dari user misalnya kemudahan penggunaan   Kebutuhan non-fungsional yang dapat

diverifikasi

o Pernyataan menggunakan beberapa ukuran yang dapat dites secara obyektif   Tujuan sangat membantu pengembangan sesuai penyampaian maksud user sistem

Contoh

  Tujuan Sistem

o Sistem seharusnya mudah digunakan oleh pengguna dan diorganisasikan sehingga error user

dapat diminimalkan

  Kebutuhan non-fungsional yang dapat diverifikasi

o Pengguna seharusnya dapat menggunakan semua fungsi sistem setelah training selesai. Setelah

training ini, jumlah rata-rata error yang dibuat oleh user yang berpengalaman tidak lebih dari 2

setiap hari

Kebutuhan User

  Menjelaskan kebutuhan fungsional dan nonfungsional sehingga user yang tidak mempunyai

pengetahuan teknis detail dapat mengerti sistem

  Kebutuhan user didefinisikan menggunakan bahasa natural, tabel dan diagram

Permasalahan Kebutuhan

  Kebutuhan database terdiri dari konseptual dan informasi detail

o Menggambarkan konsep fasilitas kontrol konfigurasi

o Terdiri dari detail obyek yang boleh diakses menggunakan nama yang tak lengkap

  Kebutuhan grid menggabungkan 3 kebutuhan yang berbeda

o Kebutuhan konseptual fungsional (kebutuhan untuk grid)

o Kebutuhan non-fungsional (unit grid)

o Kebutuhan antar muka non-fungsional (grid switching)

Ketentuan Penulisan Kebutuhan

·         Menggunakan format standard danmenggunakannya untuk semua kebutuhan

·         Menggunakan bahasa secara konsisten.Penggunaannya untuk kebutuhan utama, untuk kebutuhan yang sangat diperlukan

·         Menggunakan penanda teks untuk identifikasi bagian penting dari kebutuhan

·         Hindari penggunakan jargon komputer

Kebutuhan Sistem

  Spesifikasi yang lebih detail dari kebutuhanuser

  Sebagai dasar mendesain sistem  Biasanya digunakan sebagai bagian dari kontrak sistem

  Kebutuhan sistem diekspresikan menggunakan model sistem

Kebutuhan dan Desain

  Secara prinsip, kebutuhan menyatakan apa yang seharusnya sistem lakukan dan desain menggambarkan bagaimana melakukannya   Prakteknya, kebutuhan dan desain dibedakan

o Arsitektur sistem di desain untuk men-strukturkan kebutuhan

o Sistem dapat beroperasi dengan sistem lain yang membangkitkan kebutuhan desain

o Penggunaan desain tertentu mungkin menjadi kebutuhan domain

Permasalahan dengan Spesifikasi

Bahasa Alami

  Kemenduaan

o Pembaca dan penulis kebutuhan harus menginterpretasikan kata yang sama dg cara yang

sama. Bahasa alami secara natural bersifat mendua sehingga sangat sulit

  Terlalu Fleksibel

o Hal yang sama mungkin dikatakan dengan beberapa cara yang berbeda dalam spesifikasi

  Tidak ada modularitas

o Struktur bahasa alami tidak cukup untuk menstrukturkan kebutuhan sistem

Spesifikasi Bahasa Terstruktur

  Bentuk terbatas dari bahasa alami (Natural Language) dapat digunakan untuk menggambarkan kebutuhan

  Menghilangkan beberapa permasalahan yang menghasilkan kemenduaan dan fleksibilitas dan gangguan level keseragaman pada spesifikasi

  Biasanya menggunakan pendekatan berbasisform

Spesifikasi Berbasis Form

  Definisi fungsi atau entiti

  Menggambarkan input dan dimana berasal

  Menggambarkan output dan dimana berjalan

  Mengindikasikan entiti lain yang dibutuhkan

  Kondisi sebelum dan sesudah (jika diperlukan)

  Efek lain (jika ada)

Spesifikasi Antar Muka

  Sebagian besar sistem harus beroperasi dengan sistem lain dan antar muka operasi harus

ditentukan sebagai bagian kebutuhan

  Tiga tipe antar muka

o Antar muka prosedural

o Struktur data yang dapat ditukar

o Representasi data   Notasi formal adalah teknik efektif untuk spesifikasi antar muka

Dokumen Kebutuhan

  Dokumen kebutuhan adalah pernyataan resmi dari apa yang dibutuhkan oleh developer

sistem

  Terdiri dari definisi dan spesifikasi kebutuhan   BUKAN dokumen desain. Sejauh mungkin,

menentukan APA yang harus dikerjakan sistem

daripada BAGAIMANA mengerjakannya

Summary

  Kebutuhan menentukan apa yang seharusnyadilakukan sistem dan menentukan batasan operasi dan implementasi

  Kebutuhan fungsional menentukan servis sistem yang harus disediakan

  Kebutuhan non-fungsional membatasi pengembangan sistem atau pengembangan

  Kebutuhan user adalah pernyataan level tinggi apa yang sistem harus kerjakan

Kebutuhan sistem dapat ditulis dalam bahasaalami, tabel dan diagram

  Kebutuhan sistem dimaksudkan untuk mengkomunikasikan fungsi yang harus disediakan sistem

  Kebutuhan sistem dapat ditulis dalam bahasa natural terstruktur, PDL atau bahasa formal

  Dokumen kebutuhan software adalah pernyataan persetujuan dari kebutuhan sistem