bab 4 keperluan/ capturing the requirements. bagaimana keperluan dinyatakan? keperluan biasanya...

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.

ProsesData masuk

Data keluar

PemeriksaanFizikal

Doktor pakar

Rekod pesakit

Diagnosis

Pengetahuan dan pengalaman perubatan

Pesakit

Sejarah pesakit

Ubat

Diagnosis

Sintom

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

Tranfom

Fungsi tamat

Kamus data

Input Output

(Sommerville)

Simpanan data

Entiti luaran

proses

Aliran data

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

PenggunaLibrari

Pinjamkanitem librari

KadLibrari

Item ygdipohon

Item yagdipinjamkan

Penolonglibrari

Tarikhpemulangan

(Sommerville)

Contoh untuk Perpustakaan-Rajah aliran data peringkat 1

PenggunaLibrari

PeriksaPengguna

Pengkalan data item

PeriksaItem

KadLibrari

StatusPengguna

Item ygdipohon

PeminjamanItem

statusitem

Item yangdipinjam

PembaharuanInfo

Pengguna

IDPengguna

IDItem

KemaskiniInfo

Info item

PenolongLibrari

Tarikhpinjam

Pengkalan data pengguna

Perbaharui infoInfo pengguna

(Sommerville)

Deskripsi Aktiviti

Kawalan

Mekanisma

Input Output

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

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

(Sommerville)

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: 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>

<Nama>

<Keutamaan Input>

<Keutamaan Output>

Satu Entiti

Satu Entiti

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

Pencam Sumber Desripsi Jenis Prioriti

Keperluan

ada

PerubahanPencam

Deskripsi

rasional

penulis

1

(0,N)

menentukan VersiN 1,N

Spesifikasi

(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