Software Requirement Requirements engineering adalah fase terdepan dari proses rekayasa perangkat lunak software engineering dimana software requirements ID: 662968
Download Presentation The PPT/PDF document "UML Process From Requirement" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
UML Process
From RequirementSlide2
Software Requirement
Requirements engineering
adalah
fase
terdepan
dari
proses
rekayasa
perangkat
lunak
(
software engineering
),
dimana
software requirements
(
kebutuhan
)
dari
user (
pengguna
)
dan
customer (
pelanggan
)
dikumpulkan
,
dipahami
dan
ditetapkan
.
Kebanyakan
kegagalan
pengembangan
software
disebabkan
karena
adanya
:
Ketidakkonsistenan
(
inconsistent
),
Ketidaklengkapan
(
incomplete
),
maupun
Ketidakbenaran
(
incorrect
)
dari
requirements specification
(
spesifikasi
kebutuhan
)Slide3
Software Requirement
Studi
di
The Standish Group
mencatat
bahwa
prosentase
akumulatif
kegagalan
sebuah
project
pengembangan
software
sebagian
besar
disebabkan
oleh
masalah
requirements
dan
spesifikasinya
[Standish-94].Slide4
Software Requirement - Definisi
Requirements engineering
adalah
cabang
dari
software engineering
yang
mengurusi
masalah
yang
berhubungan
dengan
:
tujuan
(
dunia
nyata
),
fungsi
,
dan
batasan-batasan
pada
sistem
software.
Termasuk
hubungan
faktor-faktor
tersebut
dalam
menetapkan
spesifikasi
yang
tepat
dari
suatu
software
,
proses
evolusinya
baik
berhubungan
dengan
masalah
waktu
maupun
dengan
software lain [Zave-97]Slide5
Software Requirement
Requirements engineering
dibagi
dalam
3
proses
besar
yaitu
:
elicitation,
specification,
validation and verification.
Formula
ini
kemudian
juga
dikenal
dengan
nama
The Three Dimensions of Requirements Engineering
Proses
requirements engineering
ini
dilakukan
secara
iterasi
dengan
mengakomodasi
adanya
feedback
dari
customer (user).Slide6
Software Requirement
Software Requirement ProcessSlide7
Requirements Elicitation
Adalah
proses
mengumpulkan
dan
memahami
requirements
dari
user.
Kadang
masalah
yang
muncul
berakar
dari
gap
masalah
knowledge domain
(
perbedaan
disiplin
ilmu
yang
dimiliki
). Customer
adalah
expert
pada
domain yang
softwarenya
ingin
dikembangkan
(
domain specialist
),
dilain
pihak
sang
pengembang
(
requirements analyst
)
adakalanya
sama
sekali
buta
terhadap
knowledge domain
tersebut
Gap knowledge domain
tersebut
yang
diharapkan
bisa
diatasi
dengan
adanya
interaksi
terus
menerus
dan
berulang
(
iterasi
)
antara
pengembang
dan
customerSlide8
Requirements Specification
Setelah
masalah
berhasil
dipahami
,
pengembang
mendeskripsikannya
dalam
bentuk
dokumen
spesifikasi
.
Spesifikasi
ini
berisi
tentang
fitur
dan
fungsi
yang
diinginkan
oleh
customer,
dan
sama
sekali
tidak
membahas
bagaimana
metode
pengembangannya
.
IEEE
mengeluarkan
standard
untuk
dokumen
spesifikasi
requirements
yang
terkenal
dengan
nama
IEEE Recommended Practice for Software Requirements Specifications [IEEE-830].
Dokumen
spesifikasi
requirements
bisa
berisi
functional requirements, performance requirements, external interface requirements, design constraints,
maupun
quality requirements.Slide9
Requirements Validation and Verification
Setelah
spesifikasi
requirements
berhasil
dibuat
,
perlu
dilakukan
dua
usaha
:
Validation (
validasi
)
,
yaitu
proses
untuk
memastikan
bahwa
requirements yang
benar
sudah
ditulis
.
Verification (
verifikasi
)
,
yaitu
proses
untuk
memastikan
bahwa
requirements
sudah
ditulis
dengan
benar
.
Proses
validasi
dan
verifikasi
ini
melibatkan
customer (user)
sebagai
pihak
yang
menilai
dan
memberi
feedback
berhubungan
dengan
requirements.Slide10
Requirement (Persyaratan
)
Requirement
adalah
pernyataan
yang
mendefinisikan
tujuan
atau
batasan
sistem
yang
harus
terpenuhi
Perlu
dipahami
oleh
tim
pengembang
dan
divalidasi
oleh
para
stakeholder
dan
pengguna
(
user
)
Sebagai
kriteria
penentuan
lolos
/
gagal
yang
dapat
diverifikasi
oleh
tim
penguji
Prioritas
yang
ditetapkan
dalam
kaitannya
dengan
persyaratan
lainSlide11
Requirement (Persyaratan
)
Requirement
dibagi
menjadi
2 (
dua
):
Functional Requirement
(
persyaratan
fungsional
)
“
Functional requirements define what the system or application will do
”
Non-functional Requirement
(
persyaratan
non
fungsional
)
“A software requirement that describes not what the software will do, but how the software will do it, for example software performance requirements, software external interface requirements, design constraints, and software quality attributes” IEEE DefinitionSlide12
Non Functional Requirement (NFR)
Persyaratan
perangkat
lunak
yang
menggambarkan
bagaimana
perangkat
lunak
akan
melakukannya
,
misalnya
,
persyaratan
kinerja
perangkat
lunak
,
persyaratan
antarmuka
eksternal
perangkat
lunak
,
dan
atribut
kualitas
perangkat
lunak
.
Persyaratan
nonfungsional
sulit
untuk
diuji
oleh
karena
itu
,
mereka
biasanya
dievaluasi
secara
subyektifSlide13
Contoh
Functional & Non Functional
Contoh
Functional & Non Functional requirements
dalam
pengembangan
Mobile Application
:
Functional Requirement:
Cross platform compatible and works on most mobile browser
Integrates a selected number of popular social networking sites in one place
Communicates with social networking APIs
Uses login and
OAuth
mechanisms to authorize
Records and monitors social networking activity
Stores the data locally Displays total statistics for the userSlide14
Contoh
Functional & Non Functional
Non functional requirements
Record statistics accurately
Fast navigation
Flexibility to choose which sites they want to integrate out of 3 and do not always have to use all 3. For example; the user should still be able to use
Facebook
and Twitter in the App and leave out YouTube (if they are not interested
inYouTube
).
App should be able to function with chosen sites.
Should be flexible in terms of being able to integrate other popular social networking sites too
Should be available to users to use anytimeSlide15
Analisis
Berorientasi
Objek
Analisis
Berorientasi
Objek
Berfokus
pada
pendefinisian
kelas-kelas
dan
cara
bagaimana
mereka
saling
bekerjasama
satu
dengan
yang
lainnya
untuk
memenuhi
kebutuhan
para
pelanggan
.
Pada
Paradigma
Analysis Design
Unified Modeling Language
(UML)
merupakan
perkakas
(
tools
)
yang
digunakan
untuk
melakukan
pemodelan
berorientasi
objekSlide16
What is the UML?
UML:
Unified Modeling Language
UML
dapat
digunakan
untuk
memodelkan
semua
proses
dalam
siklus
hidup
pengembangan
dan
seluruh
teknologi
implementasi
yang
berbeda
UML adalah
bahasa standar
untuk memvisualisasikan,
menspesifiksi
,
konstruksi
, dan mendokumentasikan artifak dari sistem perangkat lunak
UML
adalah
suatu
alat
komunikasi
untuk
team
dan
para
stakeholdersSlide17
Object-oriented Systems
UML Diagram dibagi menjadi 3 kategori:
1. Structure diagrams
2. Behavior diagrams
3. Interaction diagramsSlide18
Structure diagrams
Termasuk
pada
Structure Diagram
meliputi
:
Class diagrams
Composite structure diagrams
Component diagrams
Deployment diagrams
Object diagrams
Package diagramsSlide19
Structure diagramsSlide20
Behavior diagrams
Termasuk
pada
Behavior diagrams
meliputi
:
1. Activity diagrams
2. Use case diagrams
3. State machine diagramsSlide21
Interaction diagrams
Termasuk
pada
Interaction diagrams
meliputi
:
1. Sequence diagrams
2. Timing diagrams
3. Communication diagrams
4. Interaction overview diagramsSlide22Slide23
UML Process (Kendal, 2011)
Sebuah
use case diagram
,
menggambarkan
bagaimana
sistem
yang
digunakan
.
Analis
memulai
dengan
use case diagram
Sebuah
activity diagram
,
menggambarkan
aliran
keseluruhan
kegiatan
.
Setiap
use case
dapat
membuat
satu
diagram
aktivitas
Sequence diagram,
menunjukkan
urutan
kegiatan
dan
hubungan
kelas
.
Setiap
use case
dapat
membuat
satu
atau
lebih
sequence diagram
Class diagrams
,
menunjukkan
kelas
dan
hubungan
.
Sequence diagram
digunakan
untuk
menentukan
kelas
Statechart
diagram,
menunjukkan
keadaan
transisi
.
Setiap
kelas
dapat
membuat
statechart
diagram, yang
berguna
untuk
menentukan
class methodSlide24
(Kendall and Kendall, 2011)Slide25
STATE MACHINE DIAGRAMSlide26
State Machine Diagram
State Machine Diagram merupakan teknik yang umum digunakan untuk menggambarkan behavior sebuah sistem
Berbagai bentuk State telah ada sejak tahun 1960-an dan teknik berorientasi objek yang paling awal mengadopsinya untuk menampilkan behavior
Dalam pendekatan berorientasi objek, State Machine Diagram digambarkan untuk suatu Kelas tunggal yang menunjukkan behavior sebuah objek tersebutSlide27
Notasi State Machine DiagramSlide28
Story
Dalam suatu kastil yang gelap tersimpanlah barang-barang berharga dalam suatu lemari besi. Untuk menunjukkan lubang kunci pada lemari besi tersebut, harus menggunakan obor sebagai media penerangan. Hal ini berlaku bila pintu dalam keadaan tertutup. Jika lubang kunci sudah terlihat, kunci dapat dimasukkan untuk membuka lemari besi. Sebagai prosedur keamanan, lemari tersebut dapat terbuka jika obor terpasang. Namun jika obor tsb tidak terpasang, maka akan kastil akan mengeluarkan monster.Slide29
Example State Machine Diagram
Tunggu
Terkunci
Buka
Obor diambil [Pintu tertutup] /
Menunjukkan lubang kunci
Kunci diputar[Obor terpasang] / Membuka lemari besi
Lemari besi tertutup
Kunci diputar[Obor tidak terpasang] / Mengeluarkan monster
Note:
Event [Guard] / Activity
Note:
Titik Awal (Start)
Note:
State
Note:
Titik akhir (end)
Note:
Point / TransisiSlide30
Penjelasan
Diagram di atas menunjukkan adanya 3 (tiga) State: Tunggu, Terkunci, dan Buka.
Diagram di atas juga menjelaskan mengenai aturan-aturan untuk berpindah dari satu State ke State lain (Aturan tertulis dalam Transisi)
Transisi menunjukkan pergerakan dari suatu State ke State lain. Transisi memiliki label yang terdiri dari 3 (tiga) bagian:
event [guard] / activity
Event
berupa
trigger
/pemicu terjadinya peralihan pada state
Guard
menunjukkan adanya kondisi (jika mensyaratkan adanya kondisi) dalam bentuk
boolean
Activity
merupakan behavior yang dieksekusi selama transisiSlide31
Penjelasan [lanj]
Dalam state Tunggu jika obor diambil dengan pintu tertutup, maka akan melakukan aktivitas menunjukkan lubang kunci dan pindah ke state terKunci
Pada state Terkunci jika kunci diputar dengan kondisi obor terpasang maka akan melakukan aktivitas membuka lemari besi, namun jika kunci diputar dengan kondisi obor tidak terpasang maka akan mengeluarkan monster dan selesaiSlide32
State
UML mendefinisikan beberapa macam State:
Simple State
Composite StateSlide33
Simple State
Suatu Simple State merupakan state yang tidak memiliki substate, region
Simple State boleh memiliki
Compartment
(ruang),
compartment
beserta Ruang Aktivitas Internal /
Internal aktivities compartment
Simple state Waiting for Customer Input. Slide34
Simple State
Internal activities compartment
Terdapat beberapa label sudah ada pada sistem yang tidak boleh digunakan
Beberapa lebel tersebut meliputi:
Entry
Do
Exit
Simple state
Waiting for Customer Input
dengan nama dan ruang aktivitas internal (entry dan exit)Slide35
Composite State
Composite State
didefinisikan sebagai state yang memiliki
substates
(
nested states
)
Composite State
terdiri dari 2 (dua) jenis:
Simple Composite State
: memuat hanya 1
region
Orthogonal Composite State:
memiliki lebih dari 1 region
Simple composite state Serving Customer has two
substates
. Slide36
Contoh Online Banking System
Contoh model diagram untuk login yang merupakan bagian dari Online Banking System.
Logging in terdiri atas masukan input Social Security Number dan Personal Id Number yang berlaku, lalu memutuskan kesahan dari informasi tersebut.Slide37
Contoh Online Banking System
Logging in dapat dibagi menjadi empat tahapan proses, yaitu :
Getting SSN (masukkan SSN),
Getting PIN (masukkan PIN),
Validating (periksa kesahannya), dan
Rejecting (keluar).Slide38
Online Banking SystemSlide39
Proses peralihan digambarkan dengan panah dari satu state ke yang lainnya.
Event
(peristiwa) atau
condition
(keadaan) yang menyebabkan perubahan dituliskan pada samping panah
Diagram ini mengandung dua
self-transition
(transisi sendiri)
,
satu
pada getting SSN dan lainnya pada getting PINSlide40
Keadaan awal
Start (black circle
/lingkar hitam) adalah
dummy
(model)
untuk memulai action (kegiatan). Keadaan akhir juga keadaan model yang menghentikan kegiatan
Aksi yang terjadi sebagai hasil dari suatu peristiwa atau keadaan ditandai dalam bentuk
/action
. Slide41
Pada Validating State, obyek tidak menunggu peristiwa dari luar untuk menyebabkan suatu perubahan. Sebagai gantinya melakukan suatu
activity
(aktifitas). Hasil dari aktifitas tersebut menentukan keadaan berikutnya dari obyek
tersebut.Slide42
SEQUENCE & COLLABORATION DIAGRAMSlide43
Example Sequence Hotel ReservationSlide44
Penjelasan Sequence
Gambar di atas adalah diagram Sequence untuk pembuatan Hotel Reservation. Obyek yang mengawali urutan
message
adalah
‘aReservation Window
‘
Reservation window
’
mengirim
pesan
makeReservation
()
ke
‘HotelChain’
. Kemudian
‘HotelChain’
mengirim pesan yang sama ke ‘
Hotel
’. Bila ‘
Hotel
’ punya kamar kosong, maka dibuat ‘
Reservation
’ dan ‘
Confirmation
’.Slide45
Penjelasan Sequence
Pada gambar diagram , terlihat bahwa ‘
Hotel
’ telah melakukan pemanggilan
diri sendiri untuk pemeriksaan jika ada kamar kosong. Bila benar, maka ‘Hotel’
membuat ‘Reservation’ dan ‘Confirmation’.
Pemanggilan diri sendiri disebut dengan
iterasi. Expression
yeng dikurung dengan
“[ ]”,
adalah
condition
(keadaan kondisi).Slide46
Diagram Collaboration juga merupakan
diagram interaction.
Diagram
membawa informasi yang sama dengan diagram
Sequence
, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkanSlide47
Collaboration DiagramSlide48
PACKAGE DIAGRAMSlide49
Package Diagram
Untuk mengatur pengorganisasian diagram Class yang
kompleks,
dapat dilakukan pengelompokan kelas-kelas berupa
package (paket-paket).
Package
adalah
kumpulan elemen-elemen logika UML. Gambar di bawah ini mengenai model bisnis dengan pengelompokan kelas-kelas dalam bentuk paket-paketSlide50
Contoh Package DiagramSlide51
Component DiagramSlide52
Component Diagram
Component diagram
menggambarkan
struktur
dan
hubungan
antar
komponen
piranti
lunak
,
termasuk
ketergantungan
(
dependency
)
di
antaranya
.
Komponen
piranti
lunak
adalah
modul
baik
berisi
source code
,
binary code
,
library
maupun
executable
Pada
umumnya
komponen
terbentuk
dari
beberapa
class
dan
/
atau
package
,
tapi
dapat
juga
dari komponen-komponen yang lebih
kecil. Komponen
dapat juga berupa
interface, yaitu kumpulan
layanan yang disediakan sebuah komponen untuk komponen
lain.Slide53
Contoh Component Diagram
applet1
.class
Demo.html
applet2.class
logo.gif
applet1
.
java
applet2
.
javaSlide54
Deployment DiagramSlide55
Deployment Diagram
Deployment/physical diagram
menggambarkan
detail
bagaimana
komponen
di
-
deploy
dalam
infrastruktur
sistem
,
di
mana
komponen
akan
terletak
(
pada
mesin
, server
atau
piranti
keras
apa
)
Sebuah
node
adalah
server,
workstation
,
atau
piranti
keras
lain yang
digunakan
untuk
men-
deploy
komponen
dalam
lingkungan
sebenarnya
.
Hubungan
antar
node
(
misalnya
TCP/IP)
dapat
didefinisikan
dalam diagram ini.
Artifak merupakan manifestasi fisik dari perangkat lunak yang di-deploy. Atifak dapat berupa file-file seperti .exe, binary, jar, assemby, script, file data, file konfigurasi, dokuman html dsbSlide56
Contoh Deployment DiagramSlide57
Contoh Deployment