5 Kebutuhan Software By : Andi Latifa Nabone.

Slides:



Advertisements
Presentasi serupa
REKAYASA PERANGKAT LUNAK
Advertisements

Proses-proses Perangkat Lunak
Functional Requirements (FR) dan Non-Functional Requirements (NFR)
Perancangan Perangkat Lunak lanjutan Kuliah - 7
PEMODELAN ANALISIS Kuliah - 5
Software Requirement Specification
Sasaran Menjelaskan apa yang dimaksud model proses
PENGANTAR REKAYASA PERANGKAT LUNAK I
BAB 5 SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Requirement.
Analisis Model.
Konsep & Prinsip Analisis
Prototyping Aplikasi Teknologi Informasi
Desain Berorientasi Obyek dan UML
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
Analisa dan Desain dalam Penelitian
Analisis Kebutuhan PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK.
A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK.
Rekayasa Perangkat Lunak Spesifikasi Formal 9 By : Andi Latifa Nabone.
REKAYASA PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
KONSEP & DEFINISI KEBUTUHAN PL
10 documentation.
Pengantar UML.
Spesifikasi Perangkat Lunak
Materi Sesi ke 2 Konsep Sistem dan Informasi
Analisis Model.
PriNciples That Guide Practice
Impact Analysis.
Rekayasa Perangkat Lunak Model Proses PL
REKAYASA PERANGKAT LUNAK
Professional documents
PERANCANGAN PERANGKAT LUNAK ( PL )
PERANCANGAN INTERFACE USER
DESAIN SISTEM Muhammad Taqiyyuddin Alawiy, ST., MT TEKNIK ELEKTRO
Building the Requirements Model
Persyaratan Perangkat Lunak
Membangun Model Kebutuhan
PEMODELAN KEBUTUHAN DENGAN USE CASE
Jaminan Mutu dalam Kebutuhan Rekayasa
PEMODELAN KEBUTUHAN DENGAN USE CASE
Persyaratan Rekayasa Proses
SISTEM PENDUKUNG KEPUTUSAN
Penyusunan Spesifikasi Perangkat Lunak
Requirement Conclusion.
Rekayasa Kebutuhan Software
REKAYASA PERANGKAT LUNAK
PERTEMUAN 2 Proses Pengembangan Perangkat Lunak
REKAYASA PERANGKAT LUNAK
PEMODELAN KEBUTUHAN DENGAN USE CASE
10 Perancangan Arsitektural
Building the Requirements Model
REKAYASA PERANGKAT LUNAK
Rekayasa Kebutuhan.
Analisa [Kebutuhan] Sistem
Model Waterfall dan Dokumen SKPL
Analisis Model.
Pertemuan 8 Rekayasa Kebutuhan
PENGANTAR REKAYASA PERANGKAT LUNAK
Interaksi Manusia dan Komputer
Building the Requirements Model
Building the Requirements Model
Rekayasa Perangkat Lunak
Kebutuhan dan Pemodelan Analisis
Proses Rekayasa Kebutuhan
Analisis dan Desain Sistem
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
Transcript presentasi:

5 Kebutuhan Software By : Andi Latifa Nabone

Persyaratan rekayasa 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.

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.

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.

Persyaratan pembaca

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.

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.

Persyaratan ketidaktepatan Masalah muncul ketika persyaratan tidak tepat dinyatakan. Persyaratan ambigu dapat ditafsirkan dengan cara yang berbeda oleh pengembang dan pengguna. 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.

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.

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.

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.

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.

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?

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.

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.

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.

Pengguna persyaratan Harus menjelaskan kebutuhan fungsional dan non-fungsional sedemikian rupa sehingga mereka dipahami oleh pengguna sistem yang tidak memiliki pengetahuan teknis yang rinci. Persyaratan pengguna didefinisikan menggunakan bahasa alami, tabel dan diagram seperti ini dapat dipahami oleh semua pengguna.

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.

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.

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.

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.

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.

Spesifikasi bahasa terstruktur Kebebasan penulis persyaratan dibatasi oleh template standar untuk persyaratan. Semua persyaratan yang ditulis dalam cara yang standar. Terminologi yang digunakan dalam deskripsi mungkin terbatas. Keuntungannya adalah bahwa sebagian besar ekspresif bahasa alam dijaga tetapi tingkat keseragaman dikenakan pada spesifikasi.

Formulir berbasis Spesifikasi Definisi fungsi atau entitas. Deskripsi input dan di mana mereka berasal. Deskripsi output dan mana mereka pergi. Indikasi entitas lain yang dibutuhkan. Pra dan pasca kondisi (jika sesuai). Efek samping (jika ada) fungsi.

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.

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 Validasi kartu; Menangani permintaan; Menyelesaikan transaksi.

Sequence diagram penarikan ATM

Spesifikasi interface Kebanyakan sistem harus beroperasi dengan sistem lain dan antarmuka operasi harus ditentukan sebagai bagian dari persyaratan. Tiga jenis antarmuka mungkin harus didefinisikan Interface prosedural; Struktur data yang dipertukarkan; Representasi data. Notasi formal merupakan teknik efektif untuk spesifikasi interface.

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

Persyaratan standar IEEE Mendefinisikan struktur generik untuk dokumen persyaratan yang harus instantiated untuk setiap sistem yang spesifik. Pendahuluan. Gambaran umum. Persyaratan khusus. Lampiran. Indeks.

Persyaratan struktur dokumen Kata pengantar Pengantar Glosarium Pengguna persyaratan definisi Arsitektur sistem Persyaratan sistem spesifikasi Sistem model Sistem evolusi Lampiran Indeks

TERIMA KASIH