4. kebutuhan software

1

Rekayasa Perangkat Lunak

1

Kebutuhan Software

Deskripsi dan Spesifikasi Sistem

Arna Fariza

Rekayasa Perangkat Lunak 2

TujuanMemperkenalkan konsep kebutuhan user dansistemMenggambarkan kebutuhan fungsional dan non-fungsionalMenjelaskan dua teknik menggambarkankebutuhan sistemMenjelaskan bagaimana kebutuhan software diorganisasikan dalam dokumen kebutuhan

2


MateriKebutuhan fungsional dan non-fungsionalKebutuhan userKebutuhan sistemDokumen kebutuhan software


Rekayasa KebutuhanProses menetapkan layanan yang dibutuhkankonsumen terhadap sistem dan batasan operasidan pengembanganKebutuhan sendiri adalah diskripsi layanansistem dan batasan yang dibangkitkan selamaproses rekayasa kebutuhan

3


Apakah Kebutuhan itu?Susunan pernyataan abstrak level tinggi darilayanan atau batasan sistem ke dalamspesifikasi fungsional matematisTidak terelakkan bahwa kebutuhan mempunyaidua fungsio merupakan dasar untuk penawaran kontrak –

sehingga harus terbuka untuk interpretasio merupakan dasar untuk kontrak itu sendiri –

sehingga harus didefinisikan dengan detailo Kedua pernyataan diatas disebut kebutuhan


Abstraksi Kebutuhan (Davis)

“Jika sebuah perusahaan akan mengadakan kontrak untuk proyek pengembangan software besar, harusdidefinisikan kebutuhan yang cukup dimana solusi belum terdefinisi. Kebutuhan harus ditulis sehinggabeberapa kontraktor dapat menawarkan kontrak, penawaran, kemungkinan, secara berbeda dengankebutuhan organisasi client. Bila kontrak sudah diserahkan, kontraktor harus menulis definisi sistem untukclient secara lebih detail sehingga client mengerti dan dapat mem-validasi software yang akan dikerjakan.Kedua dokumen ini disebut dokumen kebutuhan untuk sistem”

4


Tipe-tipe KebutuhanKebutuhan Usero Pernyataan dalam bahasa natural plus diagram

layanan yang tersedia dan batasan operasional. Ditulis oleh konsumen

Kebutuhan Sistemo Dokumen terstruktur berisi diskripsi detail dari

layanan sistem. Ditulis sebagai kontrak antaraklien dan kontraktor.

Spesifikasi Softwareo Diskripsi software detail yang sebagai dasar untuk

desain atau implementasi. Ditulis oleh developer


Definisi dan Spesifikasi

1.1.

Definisi Kebutuhan

Software harus menyediakan ketentuan menampilkan dan mengakses file yang dibuat oleh tool lain

Spesifikasi Kebutuhan

1.1 User diberikan fasilitas untuk mendefinisikan tipe file eksternal

1.2 Setiap tipe file eksternal mempunyai alat untuk dihubungkan yang dapat diaplikasikan ke file

1.3 Setiap tipe file eksternal direpresentasikan sebagai icon tertentu padatampilan user

1.4 Fasilitas disediakan untuk icon yang merepresentasikan tipe file eksternal yang didefinisikan oleh user

1.5 Jika user memilih icon untuk merepresentasikan file eksternal, efekpemilihan mengaplikasikan alat yang menghubungkan antara tipe file eksternal ke file yang direpresentasikan oleh icon terpilih

5


Pengguna Kebutuhan

Kebutuhan user

Kebutuhan sistem

Spesifikasidesain software

Manajer clientEnd-user sistemEngineer clientManager kontraktorArsitek sistem

End-user sistemEngineer clientArsitek sistemDeveloper software

Engineer client (mungkin)Arsitek sistemDeveloper software


Kebutuhan Fungsional dan non-fungsional

Kebutuhan fungsionalo Pernyataan layanan sistem yang harus disediakan,

bagaimana sistem bereaksi pada input tertentudan bagaimana perilaku sistem pada situasitertentu

Kebutuhan non-fungsionalo Batasan layanan atau fungsi yang ditawarkan

sistem seperti batasan waktu, batasanpengembangan proses, standarisasi dll

Kebutuhan domaino Kebutuhan yang datang dari domain aplikasi dari

sistem dan yang menyatakan karakteristik daridomain tersebut

6


Kebutuhan Fungsional

Menggambarkan fungsionalitas atau layanansistemTergantung pada tipe software, harapan user dan tipe sistem dimana software digunakanKebutuhan fungsional user merupakanpernyataan level tinggi dari apa yang seharusnya dilakukan sistem tetapi kebutuhanfungsional sistem menggambarkan layanansistem secara detail


Contoh Kebutuhan Fungsional

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

Sistem menyediakan tampilan yang tepatuntuk user yang membaca dokumen dalampenyimpan dokumen

Setiap pesanan dapat dialokasikan sebagaiidentifier yang unik (ORDER_ID) dimana user dapat meng-copy daerah penyimpan account permanen

7


Ketidaktepatan Kebutuhan

Permasalahan timbul jika kebutuhan tidakditetapkan dengan jelasKebutuhan yang sama mungkindiinterprestasikan dengan cara yang berbedaoleh developer dan userViewer yang tepato Kemauan user – viewer tujuan khusus untuk tipe

dokumen yang berbedao Interpretasi developer – menyediakan text viewer

yang menunjukkan isi dokumen


Konsistensi dan Kelengkapan Kebutuhan

Kebutuhan prinsip harus lengkap dan konsistenLengkapo Harus mendiskripsikan semua fasilitas yang

dibutuhkan

Konsisteno Seharusnya tidak ada konflik atau kontradiksi

dalam diskripsi fasilitas sistem

Dalam prakteknya, mungkin untukmemproduksi dokumen kebutuhan yang lengkap dan konsisten

8


Kebutuhan Non-fungsionalMendifinisikan properti sistem dan batasansistem, seperti kehandalah, waktu respon, kebutuhan penyimpan. Batasan misalnyakapabilitas perangkat I/O, representasi sistemdllKebutuhan proses juga menetapkanpenggunaan sistem CASE khusus, bahasapemrograman atau metode pengembanganKebutuhan non-fungsional lebih kritis daripadakebutuhan fungsional. Jika tidak dapatbertemu, sistem menjadi tidak berguna


Klasifikasi Non-fungsionalKebutuhan Produko Kebutuhan yang menetapkan bahwa produk yang

dikirim harus berjalan dengan cara tertentu, contoh kecepatan eksekusi, kehandalan dll

Kebutuhan Organisasio Kebutuhan sebagai akibat dari kebijakan organisasi

dan prosedur misalnya standar proses yang digunakan, kebutuhan implementasi dll

Kebutuhan Eksternalo Kebutuhan yang muncul dari faktor eksternal

sistem dan proses pengembangan misalnyakebutuhan antar operasi, kebutuhan legistatif dll

9


Tipe Kebutuhan Non-fungsionalKebutuhan

non-fungsional

Kebutuhanproduk

Kebutuhanorganisasi

Kebutuhaneksternal

Kebutuhanefisiensi

Kebutuhankehandalan

Kebutuhanportabilitas

Kebutuhaninteroperasi

Kebutuhanethical

Kebutuhankemampuanpenggunaan

Kebutuhanpenyerahan

Kebutuhanimplementasi

Kebutuhanstandar

Kebutuhankeselamatan

Kebutuhanprivacy

Kebutuhanlegislatif

Kebutuhanperformansi

Kebutuhanruang


Contoh Kebutuhan Non-fungsional

Kebutuhan Produko 4.C.8 Dimungkinan untuk semua komunikasi yang

diperlukan antara APSE dan user diekspresikandalam karakter Ada standar

Kebutuhan Organisasio 9.3.2 Proses pengembangan sistem dan

penyerahan dokumen seharusnya sesuai denganproses dan penyerahan yanga didefinisikan dalamXYZCo-SP-STAN-95

Kebutuhan Eksternalo 7.6.5 Sistem seharusnya tidak tertutup untuk

segala informasi personal tentang konsumen lepasdari nama dan nomor referensi ke operator sistem

10


Tujuan dan Kebutuhan

Kebutuhan Non-fungsional kemungkinan sangatsulit untuk ditetapkan dan kebutuhan yang tidak tepat sulit diverifikasiTujuano Tujuan umum dari user misalnya kemudahan

penggunaanKebutuhan non-fungsional yang dapatdiverifikasio Pernyataan menggunakan beberapa ukuran yang

dapat dites secara obyektifTujuan sangat membantu pengembangansesuai penyampaian maksud user sistem


Contoh

Tujuan Sistemo Sistem seharusnya mudah digunakan oleh

pengguna dan diorganisasikan sehingga error user dapat diminimalkan

Kebutuhan non-fungsional yang dapatdiverifikasio Pengguna seharusnya dapat menggunakan semua

fungsi sistem setelah training selesai. Setelahtraining ini, jumlah rata-rata error yang dibuatoleh user yang berpengalaman tidak lebih dari 2 setiap hari

11


Ukuran Kebutuhan

Transaksi proses/detikWaktu respon user/eventWaktu refresh screen

Kecepatan

Waktu trainingJumlah frame bantuan

Kemudahan penggunaan

K byteJumlah chip RAM

Ukuran

Persentase pernyataan ketergantungan targetJumlah sistem target

Portabilitas

Waktu restart setelah kegagalanPersentase event yang menyebabkan kegagalanKemungkinan korupsi data pada saat kegagalan

Kekuatan

Rata-rata waktu kegagalanKemungkinan ketidak tersediaanRata-rata kejadian kegagalanKetersediaan

Kehandalan

UkuranProperti


Interaksi Kebutuhan

Konflik antara kebutuhan non-fungsionalbersifat umum dalam sistem yang kompleksSistem kendaraan luar angkasao Untuk meminimalkan berat, jumlah chip yang

terpisah pada sistem harus diminimalkano Untuk meminimalkan konsumsi listrik, listrik chip

lebih rendah harus digunakano Sehingga, menggunakan chip listrik rendah berarti

lebih banyak chip yang harus digunakan. Manayang merupakan kebutuhan kritis?

12


Kebutuhan Domain

Diperoleh dari domain aplikasi danmenggambarkan karakteristik sistem dan fituryang merefleksikan domainBerupa kebutuhan fungsional baru, batasanpada kebutuhan yang sudah ada ataumendefinisikan komputasi tertentuJika kebutuhan domain tidak terpenuhi, sistemmungkin tidak dapat bekerja


Kebutuhan Domain sistemPerpustakaan

Terdapat antar muka standar user untuk semuadatabase berdasarkan standar X39.50

Karena pembatasan copyright, beberapadokumen harus dihapus segera setelah datang. Tergantung kebutuhan user, dokumen tersebutdapat dicetak secara lokal pada server sistemuntuk dikirim secara manual ke user ataudilewatkan ke network printer

13


Sistem Proteksi Kereta Api

Perlambatan kereta dapat dihitung sbb:o Dtrain = Dcontrol + Dgradient

dimana Dgradient sebesar 9.81ms2 * ganti_rugigradient/alpha dan dimana nilai 9.81ms2

/alpha diketahui dari tipe kereta api yang berbeda


Permasalahan Kebutuhan Domain

Kemampuan untuk dimengertio Kebutuhan dinyatakan dalam bahasa domain

aplikasio Biasanya tidak dimengerti oleh software engineer

yang mengembangkan sistem

Ketidaklengkapano Domain spesialis mengerti area dengan baik

sehingga mereka tidak berfikir untuk membuatkebutuhan domain secara eksplisit

14


Kebutuhan User

Menjelaskan kebutuhan fungsional dan non-fungsional sehingga user yang tidak mempunyaipengetahuan teknis detail dapat mengertisistemKebutuhan user didefinisikan menggunakanbahasa natural, tabel dan diagram


Permasalahan dengan BahasaAlami

Ketidakjelasano Kecermatan sulit diwujutkan tanpa membuat

dokumen yang sulit dibaca

Kebutuhan yang membingungkano Kebutuhan fungsional dan non-fungsional

cenderung dicampur aduk

Penggabungan kebutuhano Beberapa kebutuhan yang berbeda dinyatakan

bersama-sama

15


Kebutuhan Database

4.A.5 Database harus mendukung pembangkitan dan kontrol darikonfigurasi obyek; sehingga obyek terkelompok sendiri dalam database.Fasilitas kontrol konfigurasi mengijinkan akses ke obyek menggunakannama yang tidak lengkap


Kebutuhan Editor grid

2.6 Fasilitas Grid untuk membantu meletakkan entiti pada diagram,user harus mengubah grid dalam cm atau inch, melalui pilihanpada control panel. Semula, grid off. Grid diubah on dan off selamawaktu editing dan dapat diubah inch dan cm sepanjang waktu.Pilihan grid akan disediakan pilihan penurunan tetapi jumlah garisgrid yang ditampilkan akan diturunkan untuk menghindari mengisidiagram lebih kecil dengan garis grid.

16


Permasalahan Kebutuhan

Kebutuhan database terdiri dari konseptualdan informasi detailo Menggambarkan konsep fasilitas kontrol

konfigurasio Terdiri dari detail obyek yang boleh diakses

menggunakan nama yang tak lengkap

Kebutuhan grid menggabungkan 3 kebutuhanyang berbedao Kebutuhan konseptual fungsional (kebutuhan

untuk grid)o Kebutuhan non-fungsional (unit grid)o Kebutuhan antar muka non-fungsional (grid

switching)


Presentasi Terstruktur

2.6 Fasilitas Grid

2.6.1 Editor menyediakan fasilitas grid dimana matriks barishorisontal dan vertikal merupakan background window editor.Grid ini merupakan passive grid dimana ukuran entitas adalahtanggung jawab user

Alasan: grid membantu user membuat diagram teratur denganentitas teratur. Meskipun grid aktif, dimana entitas garis grid dapatberguna, posisi tidak teliti. User adalah orang yang tepat untukmenentukan dimana entitas seharusnya diletakkan

17


Kebutuhan User Detail

3.5.1 Penambahan node ke desain

3.5.1.1 Editor menyediakan fasilitas untuk user menambahnode untuk tipe tertentu pada desain

3.5.1.2 Urutan akse untuk menambah node sebagai berikut:

1. User memilih tipe node yang ditambahkan

2. User memindahkan kursor ke posisi node yang tepat padadiagran dan mengindikasikan bahwa simboh node ditambahkanpada titik tersebut

3. User menarik simbol node ke posisi akhir

Alasan: user adalah orang terbaik untuk memutuskan dimana posisinode pada diagram. Pendekatan ini memberikan kontrollangsung user ke semua pemilihan dan memosisikan tipe node

Spesifikasi: BCLIPSB/WS/Tools/DB/FS.Section 3.5.1


Ketentuan Penulisan Kebutuhan

Menggunakan format standard danmenggunakannya untuk semua kebutuhanMenggunakan bahasa secara konsisten. Penggunaannya untuk kebutuhan utama, untukkebutuhan yang sangat diperlukanMenggunakan penanda teks untuk identifikasibagian penting dari kebutuhanHindari penggunakan jargon komputer

18


Kebutuhan Sistem

Spesifikasi yang lebih detail dari kebutuhanuserSebagai dasar mendesain sistemBiasanya digunakan sebagai bagian darikontrak sistemKebutuhan sistem diekspresikan menggunakanmodel sistem


Kebutuhan dan Desain

Secara prinsip, kebutuhan menyatakan apayang seharusnya sistem lakukan dan desainmenggambarkan bagaimana melakukannyaPrakteknya, kebutuhan dan desain dibedakano Arsitektur sistem di desain untuk men-strukturkan

kebutuhano Sistem dapat beroperasi dengan sistem lain yang

membangkitkan kebutuhan desaino Penggunaan desain tertentu mungkin menjadi

kebutuhan domain

19


Permasalahan dengan SpesifikasiBahasa Alami

Kemenduaano Pembaca dan penulis kebutuhan harus

menginterpretasikan kata yang sama dg cara yang sama. Bahasa alami secara natural bersifatmendua sehingga sangat sulit

Terlalu Fleksibelo Hal yang sama mungkin dikatakan dengan

beberapa cara yang berbeda dalam spesifikasi

Tidak ada modularitaso Struktur bahasa alami tidak cukup untuk men-

strukturkan kebutuhan sistem


Alternatif Spesifikasi Bahasa Alami

Notasi DeskripsiBahasa Pendekatan ini tergantung definisi bentuk standard atau template untuknatural terstruktur menggambarkan spesifikasi kebutuhanBahasa deskripsi Pendekatan ini menggunakan bahasa seperti bahasa pemrogramandesain tetapi lebih banyak fitur abstrak untuk menentukan kebutuhan

dengan mendefinisikan model operasi dari sistemNotasi grafis bahasa grafis, ditambahkan dengan text digunakan untuk mendefinisikan

kebutuhan fungsional untuk sistemContohnya sebelumnya bahasa grafis SADT (Ross, 1977; Schomanand Ross, 1977), saat ini digunakan deskripsi use case (Jacobsen,Christerson et al.,1993)

Spesifikasi Ada beberapa notasi berbasis konsep matematis sepertiMatematis mesin finite-state atau himpunan. Spesifikasi yang ganda dapat

mengurangi argumen antara konsumen dan kontraktor tentangfungsional sistem. Sebaliknya, sebagian besar konsumen tidak mengertispesifikasi formal dan enggan menerimanya sebagai kontrak sistem

20


Spesifikasi Bahasa TerstrukturBentuk terbatas dari bahasa alami (Natural Language) dapat digunakan untukmenggambarkan kebutuhanMenghilangkan beberapa permasalahan yang menghasilkan kemenduaan dan fleksibilitasdan gangguan level keseragaman padaspesifikasiBiasanya menggunakan pendekatan berbasisform


Spesifikasi Berbasis FormDefinisi fungsi atau entitiMenggambarkan input dan dimana berasalMenggambarkan output dan dimana berjalanMengindikasikan entiti lain yang dibutuhkanKondisi sebelum dan sesudah (jika diperlukan)Efek lain (jika ada)

21


Spesifikasi node Berbasis FormBCLIPSB/Workstation/Tools/DB/3.5.1

Function Tambah node

Deskripsi Menambah node ke desain yang sudah ada. User memilih tipe node dan posisi bila ditambahkan ke desain, node menjadi pilihan saat ini. User memilih posisinode dan memindahkan kursor ke area dimana node ditambahkan

Input Tipe node, posisi node, identifier desain

Source Tipe node dan posisi node diinputkan oleh user, identifier desain daridatabase

Output Identifier desain

Tujuan Desain database. Desain membuat database menyelesaikan operasi

Kebutuhan Desain graph akar dari identifier desain input

Pre-kondisi Desain terbuka dan ditampilkan pada layar user

Post-kondisi Desain tidak berubah terpisah dari tambahan node tipe tertentu padaposisi yang diberikan

Efek lain TIdak ada


Definisi Kebutuhan BerbasisBahasa Pemrograman (PDL)

Kebutuhan dapat didefinisikan secara operasionalmenggunakan bahasa seperti bahasa pemrogramantetapi lebih fleksibel dalam ekspresiCocok untuk 2 situasi yaituo Dimana operasi ditentukan sebagai deretan aksi dan urutan

sangat pentingo Dimana antar muka hardware dan software harus

dispesifikasi

Kelemahannyao PDL tidak cukup ekspresif untuk mendefinisikan konsep

domaino Spesifikasi akan dianggap sebagai desain daripada spesifikasi

22


Bagian dari spesifikasi ATM

class ATM {// declarations herepublic static void main (String args[]) throws InvalidCard {

try {thisCard.read () ; // may throw InvalidCard exceptionpin = KeyPad.readPin () ; attempts = 1 ;while ( !thisCard.pin.equals (pin) & attempts < 4 )

{ pin = KeyPad.readPin () ; attempts = attempts + 1 ;}if (!thisCard.pin.equals (pin))

throw new InvalidCard ("Bad PIN");thisBalance = thisCard.getBalance () ;do { Screen.prompt (" Please select a service ") ;

service = Screen.touchKey () ;switch (service) {

case Services.withdrawalWithReceipt:receiptRequired = true ;


Kelemahan PDL

PDL tidak cukup ekspresif untuk menyatakanfungsional sistem yang dapat dimengertiNotasi hanya dapat dimengerti oleh orang yang mempunyai pengetahuan bahasa pemrogramanKebutuhan dianggap sebagai spesifikasi desaindaripada model untuk membantu mengertisistem

23


Spesifikasi Antar Muka

Sebagian besar sistem harus beroperasi dengansistem lain dan antar muka operasi harusditentukan sebagai bagian kebutuhanTiga tipe antar mukao Antar muka proseduralo Struktur data yang dapat ditukaro Representasi data

Notasi formal adalah teknik efektif untukspesifikasi antar muka


Deskripsi Antar Muka PDL

interface PrintServer {

// defines an abstract printer server// requires: interface Printer, interface PrintDoc// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;void print ( Printer p, PrintDoc d ) ;void displayPrintQueue ( Printer p ) ;void cancelPrintJob (Printer p, PrintDoc d) ;void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;

} //PrintServer

24


Dokumen KebutuhanDokumen kebutuhan adalah pernyataan resmidari apa yang dibutuhkan oleh developer sistemTerdiri dari definisi dan spesifikasi kebutuhanBUKAN dokumen desain. Sejauh mungkin, menentukan APA yang harus dikerjakan sistemdaripada BAGAIMANA mengerjakannya


User dari dokumenkebutuhan

Konsumen sistem

Manager

Engineer sistem

Engineer testing sistem

Engineer maintenance

sistem

Spesifikasi kebutuhan danmembacanya untuk memeriksa

apakah sesuai kebutuhankonsumen. Konsumenmenentukan perubahan

kebutuhan

Menggunakan dokumenkebutuhan untuk perencanaan

sistem dan merencanakanproses pengembangan sistem

Menggunakan kebutuhanuntuk mengerti sistem apa

yang dikembangkan

Menggunakan kebutuhanuntuk mengembangkan

tes validasi sistem

Menggunakan kebutuhanuntuk membantu mengertisistem dan hubungan antar

bagian

25


Kebutuhan Dokumen KebutuhanMenentukan perilaku sistem eksternalMenentukan batasan implementasiMudah diubahBerlaku sebagai alat referensi untukmaintenanceMenyimpan siklus hidup sistem, misalnyamemprediksi perubahanMenentukan karakter respon untuk even yang tak diharapkan


Standard IEEE untuk KebutuhanPendahuluanDeskripsi UmumKebutuhan spesifikLampiranIndeksMerupakan struktur generik yang harusdisesuaikan sistem spesifik

26


Struktur Dokumen Kebutuhan

PendahuluanDaftar IstilahDefinisi Kebutuhan UserArsitektur SistemSpesifikasi kebutuhan sistemModel sistemEvolusi sistemLampiranIndeks


SummaryKebutuhan menentukan apa yang seharusnyadilakukan sistem dan menentukan batasanoperasi dan implementasiKebutuhan fungsional menentukan servissistem yang harus disediakanKebutuhan non-fungsional membatasipengembangan sistem atau pengembanganprosesKebutuhan user adalah pernyataan level tinggiapa yang sistem harus kerjakan

27


SummaryKebutuhan sistem dapat ditulis dalam bahasaalami, tabel dan diagramKebutuhan sistem dimaksudkan untukmengkomunikasikan fungsi yang harusdisediakan sistemKebutuhan sistem dapat ditulis dalam bahasanatural terstruktur, PDL atau bahasa formalDokumen kebutuhan software adalahpernyataan persetujuan dari kebutuhan sistem

4. kebutuhan software

Documents