Keperluan/ Capturing the Requirements BAB 4 Keperluan/ Capturing the Requirements

Bagaimana keperluan dinyatakan? Keperluan biasanya dispesifikasikan dalam bahasa yang boleh difahami oleh pengguna Masalah: Semua pihak mesti ada interpretasi yang sama Keperluan biasanya susah dipisahkan mengikut elemen sistem Oleh sebab itu jurutera perisian akan cuba banyak cara untuk definisikan keperluan

Tiada cara yang ideal Tidak ada teknik yang ideal untuk menyatakan keperluan Ada beberapa teknik yang menggunakan gabungan beberapa teknik yang lain untuk menyatakan keperluan Dengan cara ini model sistem dapat diperbanyakkan dan diperkayakan (Sommerville)

Ciri-ciri yang diperlukan untuk memilih notasi menyatakan keperluan perisian (Sommerville) Kesesuaian dengan tahap pemahaman pengguna Ketepatan definasi notasi Bantuan memformulasikan keperluan Definasi dunia luar Skop untuk perubahan Skop untuk mengintegrasikan dengan pendekatan/ cara2 lain Skop untuk komunikasi Sokongan peralatan (Sommerville)

Teknik-teknik menyatakan keperluan Antara teknik-teknik yang digunakan: Deskripsi Static Deskripsi Dinamik Data Flow diagram Spesifikasi Berorientasikan Objek

Deskripsi Statik Senaraikan semua entiti, objek sistem, atribut dan perhubungan setiap satu Tidak terangkan bagaimana perhubungan berubah dengan masa Teknik: Indirect reference Recurrence relations Axiomatic Definition Expression as a Language Data abstraction

Deskripsi Dinamik Terangkan bagaimana sistem bertindakbalas terhadap perubahan sistem Teknik: Jadual Keputusan(‘decision table’) Deskripsi fungsian dan rajah transisi (functional description and transition diagram) Jadual peristiwa (‘event table’) ‘Petri Nets’

Notasi Keperluan Beberapa kaedah yang membantu di dalam mengorganisasi dan juga mempiawaikan spesifikasi keperluan: Rajah Aliran Data (“Data Flow Diagram “) Analisa Berstruktur dan Teknik Rekabentuk (“Structured Analysis and Design Technique”) Metodologi Kejuruteraan Keperluan Perisian (“Software Requirements Engineering Methodology”) Z Teknik Hierarki

Lain-lain model untuk menyatakan Keperluan Model Hubungan (“Relational Models”) Model Komposisi (“Compositional”) Model Klasifikasi (“Classification”) Model tindakbalas-stimulus (“stimulus- response”) Model Proses Model Semantik

Perbincangan Kuliah: Rajah Aliran Data Analisis Berstruktur Model Hubungan Model Semantik Spesifikasi Berorientasikan Objek

Rajah Aliran Data Rajah menunjukkan bagaimana data mengalir ke dalam sistem, bagaimana ia ditukar dan bagaimana ia meninggalkan sistem Penekanan: aliran data bukannya aliran kawalan Proses yang menerangkan pertukaran input kepada output.

Proses Data masuk Data keluar Pemeriksaan Sintom Fizikal Pengetahuan dan pengalaman perubatan Diagnosis Doktor pakar Ubat Diagnosis Sejarah pesakit Pesakit Rekod pesakit

Model Aliran Data Berdasarkan notasi bahawa sistem boleh dimodelkan sebagai satu set fungsian yang interaktif Mengunakan rajah aliran data untuk mewakili entiti luaran, proses, aliran data dan simpanan data. (Sommerville)

Notasi aliran data proses Entiti luaran Aliran data Simpanan data (Sommerville)

Perbezaan notasi aliran data (DFD) Tidak ada kesepakatan tentang notasi DFD dalam industri Notasi yang ditunjukkan telah ditambah dan diubahsuai oleh DeMarco Gane and Sarson Orr (Sommerville)

Contoh untuk Perpustakaan- Rajah aliran data peringkat kontek (Sommerville)

Contoh untuk Perpustakaan- Rajah aliran data peringkat 1 (Sommerville)

Kawalan Deskripsi Aktiviti Input Output Mekanisma

Analisis berstruktur Pendekatan aliran data boleh dilihat dalam Metod Analisis Berstruktur(“ Structured Analysis”-SA) Dua strategi yang didominasi dalam struktur analisi ialah: Yang lama- dipopularkan oleh DeMarco Yang modern- dipopularkan oleh Yourdon (Sommerville)

SA lama Pendekatan atas-bawah (Sommerville) Pendekatan atas-bawah Penganalisa memetakan sistem fizikal semasa kepada model logikal semasa aliran data Boleh diringkaskan kepada 4 langkah di bawah: Analisis sistem fizikal semasa Proses mendapatkan model logikal Proses mendapatkan model logikal yang dicadangkan Implementasi sistem fizikal yang baru

SA moden Membezakan di antara keperluan sebenar pengguna dan keperluan yang mewakili kelakuan luaran yang memuaskan pengguna Termasuk “real-time extensions” Pendekatan SA yang lain: Structured Analysis and Design Technique (SADT) Structured Systems Analysis and Design Methodology (SSADM) (Sommerville)

SADT Melibatkan perwakilan grafik yang mewakili sistem. Juga dikenali oleh DoD sbg IDEFO 2 bahagian: Structured Analysis (SA) Design (DT)

SA: DT: menspesifikasikan keperluan menggunakan dua jenis diagram Setiap diagram mewakili pertukaran Ada empat faktor: input, output, control mechanism DT: akan menerangkan bagaimana untuk mengintepretasikan keputusan

Model Hubungan (“Relational model”) Data boleh dimodel menggunakan model hubungan Data sebagai satu set jadual, dengan beberapa lajur digunakan sebagai kata kunci Keburukan perlu taip data yang banyak Model hubungan yang tidak mencukupi Model data perlu sertakan maklumat semantik data (Sommerville)

Model semantik Pendekatan model semantik: Model hubungan-entiti (“Entity-relationship” -Chen, 1976) RM/ T (Codd, 1979) SDM (Hammer and McLeod, 1981) Model mengenalpasti entiti dalam pengkalan data, atribut dan hubungan Menggunakan notasi bergambar (Sommerville)

Notasi model semantik data <Nama> <Nama> Satu Entiti Satu Entiti <Keutamaan Input> <Nama> <Keutamaan Output> Satu hubungan dengan entiti Hubungan perwarisan (Sommerville)

Sambungan kepada model hubungan-entiti Model ERM telah disertakan dengan jenis-jenis entity baru (Sub dan Super), disertakan juga Konsep perwarisan Konsep atribut persendirian (“private”) (Sommerville)

Contoh ERM - Keperluan Perisian (Sommerville)

Spesifikasi Berorientasikan Objek Tumpu pada entiti yang terlibat daripada pertukaran input-output Konsep yang membezakan OO dengan bentuk perwakilan yang lain: encapsulate, class hierarchies, inheritance, polymorphism Perbincangan lanjut dalam Kuliah minggu hadapan