kebutuhan software

32
Kebutuhan Software By : Andi Latifa Nabone 5

Upload: rupali

Post on 09-Feb-2016

35 views

Category:

Documents


0 download

DESCRIPTION

5. Kebutuhan Software. By : Andi Latifa Nabone. Proses pembentukan layanan yang pelanggan membutuhkan dari sistem dan batasan di mana ia beroperasi dan dikembangkan. Persyaratan itu sendiri adalah deskripsi dari layanan sistem dan kendala yang dihasilkan selama proses rekayasa persyaratan. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Kebutuhan  Software

Kebutuhan Software

By : Andi Latifa Nabone

5

Page 2: Kebutuhan  Software

Persyaratan rekayasa

o Proses pembentukan layanan yang pelanggan

membutuhkan dari sistem dan batasan di mana ia

beroperasi dan dikembangkan.

o Persyaratan itu sendiri adalah deskripsi dari layanan

sistem dan kendala yang dihasilkan selama proses

rekayasa persyaratan.

Page 3: Kebutuhan  Software

Apa persyaratan?• Hal ini bisa berkisar dari pernyataan abstrak tinggi tingkat pelayanan

atau dari batasan sistem ke dalam spesifikasi fungsional rinci

matematika.

• Hal ini tak terelakkan sebagai persyaratan dapat melayani fungsi ganda

Mungkin dasar untuk penawaran kontrak - karena itu harus terbuka

untuk interpretasi;

Mungkin dasar untuk kontrak itu sendiri - sehingga harus

didefinisikan secara rinci;

Kedua laporan mungkin persyaratan dipanggil.

Page 4: Kebutuhan  Software

Jenis kebutuhan Pengguna persyaratan

Pernyataan dalam bahasa natural plus diagram dari layanan yang

tersedia dan kendala operasional. Ditulis bagi pelanggan.

Persyaratan sistem

Sebuah dokumen terstruktur berisi diskripsi detail dari fungsi

sistem, layanan dan kendala operasional. Mendefinisikan apa yang

harus dilaksanakan sehingga dapat menjadi bagian dari kontrak

antara klien dan kontraktor.

Page 5: Kebutuhan  Software

Persyaratan pembaca

Page 6: Kebutuhan  Software

Fungsional dan kebutuhan non-fungsional

Persyaratan Fungsional

Pernyataan layanan sistem yang harus disediakan, bagaimana sistem harus bereaksi

terhadap input tertentu dan bagaimana sistem harus berperilaku dalam situasi

tertentu.

Non-fungsional persyaratan

Kendala pada layanan atau fungsi yang ditawarkan oleh sistem seperti batasan

waktu, batasan proses pembangunan, standar, dll

Persyaratan Domain

Persyaratan yang berasal dari domain aplikasi sistem dan yang mencerminkan

karakteristik dari domain tersebut.

Page 7: Kebutuhan  Software

Persyaratan Fungsional

Menjelaskan fungsi atau sistem pelayanan.

Tergantung pada jenis perangkat lunak, pengguna diharapkan dan

jenis sistem dimana perangkat lunak digunakan.

Kebutuhan pengguna mungkin fungsional tingkat tinggi laporan

sistem apa yang harus dilakukan, tetapi persyaratan sistem

fungsional harus menjelaskan layanan sistem secara rinci.

Page 8: Kebutuhan  Software

Persyaratan ketidaktepatan

o Masalah muncul ketika persyaratan tidak tepat dinyatakan.

o Persyaratan ambigu dapat ditafsirkan dengan cara yang berbeda

oleh pengembang dan pengguna.

o Pertimbangkan 'pemirsa yang sesuai istilah

Pengguna maksud - tujuan penampil khusus untuk setiap jenis

dokumen yang berbeda;

Interpretasi Developer - Menyediakan penampil teks yang

menunjukkan isi dokumen.

Page 9: Kebutuhan  Software

Persyaratan kelengkapan dan konsistensi

Pada prinsipnya, baik persyaratan harus lengkap dan konsisten.

Lengkap

Mereka harus menyertakan deskripsi dari semua fasilitas yang dibutuhkan.

Konsisten

Seharusnya tidak ada konflik atau kontradiksi dalam deskripsi fasilitas sistem.

Dalam prakteknya, adalah mustahil untuk menghasilkan dokumen persyaratan lengkap

dan konsisten.

Page 10: Kebutuhan  Software

Non-fungsional persyaratan

Ini mendefinisikan sifat sistem dan kendala misalnya kehandalan,

waktu respon dan persyaratan penyimpanan. Kendala adalah

perangkat I / O kemampuan, sistem representasi, dan lain-lain.

Persyaratan proses juga dapat ditentukan mandat sistem KASUS

tertentu, bahasa pemrograman atau metode pembangunan.

Kebutuhan non-fungsional mungkin lebih penting daripada

kebutuhan fungsional. Jika ini tidak terpenuhi, sistem ini tidak

berguna.

Page 11: Kebutuhan  Software

Non-fungsional klasifikasi

Produk persyaratan

Persyaratan yang menetapkan bahwa produk yang diserahkan harus berperilaku

dengan cara tertentu misalnya eksekusi kecepatan, kehandalan, dan lain-lain.

Organisasi persyaratan

Persyaratan yang merupakan akibat dari kebijakan organisasi dan prosedur misalnya

standar proses yang digunakan, persyaratan pelaksanaan, dan lain-lain.

Persyaratan Eksternal

Persyaratan yang timbul dari faktor-faktor yang eksternal ke sistem dan proses

pembangunan misalnya interoperabilitas persyaratan, persyaratan legislatif, dan lain-

lain.

Page 12: Kebutuhan  Software

Tujuan dan persyaratan

• Kebutuhan non-fungsional mungkin sangat sulit untuk negara tepat

dan persyaratan tidak tepat mungkin sulit untuk memverifikasi.

• Tujuan

Sebuah Tujuan umum dari user misalnya kemudahan penggunaan.

• Diverifikasi kebutuhan non-fungsional

Pernyataan menggunakan beberapa ukuran yang dapat diuji secara

objektif.

• Tujuan adalah membantu pengembang karena mereka menyampaikan

maksud dari pengguna sistem.

Page 13: Kebutuhan  Software

Persyaratan interaksi

Konflik antara kebutuhan non-fungsional yang berbeda yang umum dalam sistem yang

kompleks.

Wahana antariksa sistem

Untuk meminimalkan berat, jumlah chip yang terpisah dalam sistem harus

diminimalkan.

Untuk meminimalkan konsumsi daya, chip daya yang lebih rendah harus digunakan.

Namun, dengan menggunakan chip daya rendah dapat berarti bahwa lebih banyak

chip harus digunakan. Yang merupakan kebutuhan yang paling penting?

Page 14: Kebutuhan  Software

Persyaratan Domain Berasal dari domain aplikasi dan menggambarkan karakteristik

sistem dan fitur yang mencerminkan domain.

Domain persyaratan menjadi persyaratan fungsional baru, batasan

persyaratan yang ada atau menentukan perhitungan tertentu.

Jika persyaratan domain tidak terpenuhi, sistem mungkin tidak bisa

dijalankan.

Page 15: Kebutuhan  Software

Domain sistem Perpustakaan persyaratan Terjadi suatu standar antarmuka pengguna untuk semua database

yang harus didasarkan pada standar Z39.50.

Karena pembatasan hak cipta, beberapa dokumen harus dihapus

segera pada saat kedatangan. Tergantung pada kebutuhan

pengguna, baik dokumen-dokumen ini akan dicetak secara lokal

pada sistem server secara manual forwarding untuk user atau

dialihkan ke printer jaringan.

Page 16: Kebutuhan  Software

Domain Persyaratan masalah

• Understandability

Persyaratan disajikan dalam bahasa dari domain aplikasi;

Hal ini sering tidak dimengerti oleh software engineer yang

mengembangkan sistem.

• Implicitness

Spesialis Domain memahami daerah baik sehingga mereka tidak

berpikir untuk membuat persyaratan domain eksplisit.

Page 17: Kebutuhan  Software

Pengguna persyaratan

o Harus menjelaskan kebutuhan fungsional dan non-fungsional

sedemikian rupa sehingga mereka dipahami oleh pengguna sistem

yang tidak memiliki pengetahuan teknis yang rinci.

o Persyaratan pengguna didefinisikan menggunakan bahasa alami,

tabel dan diagram seperti ini dapat dipahami oleh semua pengguna.

Page 18: Kebutuhan  Software

Editor grid persyaratan

Fasilitas Grid Untuk membantu dalam posisi entitas pada

diagram, pengguna dapat mengaktifkan kotak baik dalam sentimeter

atau inci, melalui opsi pada panel kontrol. Awalnya, grid tidak aktif. Grid

mungkin diaktifkan dan dinonaktifkan pada setiap saat selama sesi

editing dan dapat inch dan cm setiap saat. Sebuah pilihan grid

akan disediakan pada tampilan mengurangi-ke-fit tetapi jumlah grid

baris yang ditampilkan akan dikurangi untuk menghindari pengisian

diagram yang lebih kecil dengan garis grid.

Page 19: Kebutuhan  Software

Pedoman untuk menulis persyaratan

Menciptakan format standar dan menggunakannya untuk semua

kebutuhan.

Gunakan bahasa dengan cara yang konsisten. Gunakan harus untuk

kebutuhan wajib, harus untuk kebutuhan yang diinginkan.

Gunakan teks menyoroti untuk mengidentifikasi bagian penting dari

kebutuhan.

Hindari penggunaan jargon komputer.

Page 20: Kebutuhan  Software

Persyaratan sistem Lebih rinci spesifikasi fungsi sistem, layanan dan batasan dari

kebutuhan pengguna.

Mereka dimaksudkan sebagai dasar untuk merancang sistem.

Mereka mungkin dimasukkan ke dalam sistem kontrak.

Persyaratan sistem dapat didefinisikan atau bergambar

menggunakan model sistem dibahas dalam Bab 8.

Page 21: Kebutuhan  Software

Persyaratan dan desain

• Pada prinsipnya, kebutuhan menyatakan apa yang harus dikerjakan

sistem dan desain harus menjelaskan bagaimana melakukan hal ini.

• Dalam praktek, persyaratan dan desain yang tak terpisahkan

• Sebuah arsitektur sistem mungkin dirancang untuk struktur

persyaratan;

• Sistem mungkin antar-beroperasi dengan sistem lain yang

menghasilkan persyaratan desain;

• Penggunaan desain tertentu mungkin menjadi persyaratan domain.

Page 22: Kebutuhan  Software

Masalah dengan spesifikasi NL

• Kemenduaan

Para pembaca dan penulis kebutuhan harus menginterpretasikan

kata yang sama dengan cara yang sama. NL secara alami ambigu

jadi ini sangat sulit.

• Over-fleksibilitas

Hal yang sama dapat dikatakan dalam beberapa cara yang berbeda

dalam spesifikasi.

• Kurangnya modularisation

Struktur NL tidak memadai untuk struktur persyaratan sistem.

Page 23: Kebutuhan  Software

Spesifikasi bahasa terstruktur

o Kebebasan penulis persyaratan dibatasi oleh template standar

untuk persyaratan.

o Semua persyaratan yang ditulis dalam cara yang standar.

o Terminologi yang digunakan dalam deskripsi mungkin terbatas.

o Keuntungannya adalah bahwa sebagian besar ekspresif bahasa alam

dijaga tetapi tingkat keseragaman dikenakan pada spesifikasi.

Page 24: Kebutuhan  Software

Formulir berbasis Spesifikasi

1) Definisi fungsi atau entitas.

2) Deskripsi input dan di mana mereka berasal.

3) Deskripsi output dan mana mereka pergi.

4) Indikasi entitas lain yang dibutuhkan.

5) Pra dan pasca kondisi (jika sesuai).

6) Efek samping (jika ada) fungsi.

Page 25: Kebutuhan  Software

Graphical model

Model grafis yang paling berguna saat Anda harus

menunjukkan perubahan negara bagaimana atau di

mana Anda perlu menggambarkan urutan tindakan.

Model grafis yang berbeda dijelaskan dalam Bab 8.

Page 26: Kebutuhan  Software

Sequence diagram Ini menunjukkan urutan peristiwa yang berlangsung selama

beberapa interaksi pengguna dengan sistem.

Anda membacanya dari atas ke bawah untuk melihat urutan

tindakan yang terjadi.

Penarikan tunai dari ATM

1) Validasi kartu;

2) Menangani permintaan;

3) Menyelesaikan transaksi.

Page 27: Kebutuhan  Software

Sequence diagram penarikan ATM

Page 28: Kebutuhan  Software

Spesifikasi interface Kebanyakan sistem harus beroperasi dengan sistem lain dan

antarmuka operasi harus ditentukan sebagai bagian dari persyaratan.

Tiga jenis antarmuka mungkin harus didefinisikan

1) Interface prosedural;

2) Struktur data yang dipertukarkan;

3) Representasi data.

Notasi formal merupakan teknik efektif untuk spesifikasi interface.

Page 29: Kebutuhan  Software

Persyaratan Dokumen

• Dokumen kebutuhan adalah pernyataan resmi dari apa yang

dibutuhkan oleh pengembang sistem.

• Sebaiknya mencakup definisi kebutuhan pengguna dan

spesifikasi kebutuhan sistem.

• Ini BUKAN dokumen desain. Sejauh mungkin, harus set APA

sistem harus lakukan, bukan BAGAIMANA seharusnya

melakukannya

Page 30: Kebutuhan  Software

Persyaratan standar IEEE

• Mendefinisikan struktur generik untuk dokumen persyaratan

yang harus instantiated untuk setiap sistem yang spesifik.

1) Pendahuluan.

2) Gambaran umum.

3) Persyaratan khusus.

4) Lampiran.

5) Indeks.

Page 31: Kebutuhan  Software

Persyaratan struktur dokumen

a) Kata pengantar

b) Pengantar

c) Glosarium

d) Pengguna persyaratan definisi

e) Arsitektur sistem

f) Persyaratan sistem spesifikasi

g) Sistem model

h) Sistem evolusi

i) Lampiran

j) Indeks

Page 32: Kebutuhan  Software

TERIMA KASIH