MODUL KULIAH

SEKOLAH TINGGI TEKNOLOGI INFORMASI NIIT

Mata Kuliah Rekayasa Perangkat Lunak

Semester Ganjil 2020/2021
Dosen Susana Dwi Yulianti, M.Kom

Modul 4 (Empat)
Pertemuan 4 (Empat)
Topik Konsep dan Prinsip Analisis
Sub Topik Konsep dan Prinsip Analisis
 Requirement Engineering
 Kebutuhan fungsional dan Non Fungsional
Materi  Dokumen persyaratan perangkat lunak
 Requirements specification

 Mahasiswa dapat menjelaskan maksud dari analisis
kebutuhan
 Mahasiswa dapat memahami beberapa teknik komunikasi
Tujuan  Mahasiswa dapat menjelaskan prinsip-prinsip analisis
 Mahasiswa dapat menjelaskan model prototype perangkat
lunak
 Mahasiswa dapat menjelaskan spesifikasi kebutuhan
perangkat lunak

Modul Perancangan Database dan ImplementasiPage 1

 PERTEMUAN 4
KONSEP DAN PRINSIP ANALISIS

A. Requirements engineering
Persyaratan untuk sistem adalah deskripsi tentang apa yang dapat
dilakukan oleh sistem layanan yang diberikannya dan kendala dalam
operasinya. Persyaratan ini mencerminkan kebutuhan pelanggan
terhadap sistem yang menyediakan tujuan tertentu. Persyaratan itu sendiri
adalah deskripsi dari layanan sistem dan kendala yang dihasilkan selama
proses rekayasa persyaratan.
Requirement Engineering (RE) adalah Proses mencari tahu,
menganalisis, mendokumentasikan dan memeriksa layanan dan kendala.
Terdapat 2 type dari requirement yaitu:
1. Persyaratan pengguna (User requirements)
Pernyataan dalam bahasa alami ditambah diagram dari layanan yang
disediakan sistem dan kendala operasionalnya. Ditulis untuk customer.
2. Persyaratan sistem (System requirements)
Dokumen terstruktur yang menjabarkan deskripsi terperinci fungsi
sistem, layanan, dan kendala operasional. Menentukan apa yang
harus dilaksanakan sehingga dapat menjadi bagian dari kontrak antara
klien dan kontraktor.
Contoh:

Modul Perancangan Database dan ImplementasiPage 2

Pembaca dari berbagai jenis spesifikasi persyaratan:

B. Functional and non-functional requirements

Functional requirements adalah Pernyataan layanan yang harus
disediakan sistem, bagaimana sistem harus bereaksi terhadap masukan
tertentu dan bagaimana sistem harus berperilaku dalam situasi tertentu.
Dapat menyatakan apa yang seharusnya tidak dilakukan oleh sistem.
Contoh Functional requirements for the MHC-PMS:
 Seorang pengguna harus dapat mencari daftar janji untuk semua
klinik.
 Sistem akan menghasilkan setiap hari, untuk setiap klinik, daftar
pasien yang diharapkan untuk menghadiri janji pada hari itu.
 Setiap anggota staf yang menggunakan sistem harus diidentifikasi
secara unik dengan nomor karyawan 8 digit miliknya.

Non-functional requirements adalah Batasan pada layanan atau

fungsi yang ditawarkan oleh sistem seperti batasan waktu, kendala pada
proses pengembangan, standar, dll. Seringkali berlaku untuk sistem
secara keseluruhan daripada fitur atau layanan individual.

Modul Perancangan Database dan ImplementasiPage 3

 Type non-fungsional requirement:

Persyaratan non-fungsional dapat mempengaruhi keseluruhan

arsitektur sistem daripada komponen individu. Misalnya, untuk
memastikan bahwa persyaratan kinerja terpenuhi, Anda mungkin harus
mengatur sistem untuk meminimalkan komunikasi antar komponen.
Persyaratan non-fungsional tunggal, seperti persyaratan
keamanan, dapat menghasilkan sejumlah persyaratan fungsional terkait
yang menentukan layanan sistem yang diperlukan. Ini juga dapat
menghasilkan persyaratan yang membatasi persyaratan yang ada.
Klasifikasi kebutuhan non-fungsional:
1. Persyaratan produk
Persyaratan yang menentukan bahwa produk yang dikirim harus
berperilaku dengan cara tertentu mis. kecepatan eksekusi,
keandalan, dll.
2. Persyaratan organisasi
Persyaratan yang merupakan konsekuensi dari kebijakan dan
prosedur organisasi, mis. standar proses yang digunakan,
persyaratan implementasi, dll.
3. Persyaratan eksternal

Modul Perancangan Database dan ImplementasiPage 4

 Persyaratan yang muncul dari faktor-faktor yang berada di luar
sistem dan proses pengembangannya mis. persyaratan
interoperabilitas, persyaratan legislatif, dll.
Contoh nonfunctional requirements in the MHC-PMS:

Product requirement
MHC-PMS harus tersedia untuk semua klinik selama jam kerja
normal (Sen-Jum, 08.30-17.30). Downtime dalam jam kerja normal
tidak melebihi lima detik dalam satu hari.

Organizational requirement
Pengguna sistem MHC-PMS harus mengotentikasi diri mereka
sendiri menggunakan kartu identitas otoritas kesehatan mereka.

External requirement
Sistem harus menerapkan ketentuan privasi pasien sebagaimana
ditetapkan dalam HStan-03-2006-priv.

Persyaratan non-fungsional mungkin sangat sulit untuk dinyatakan

secara tepat dan persyaratan yang tidak tepat mungkin sulit untuk
diverifikasi.
Tujuan : Maksud umum dari pengguna seperti kemudahan penggunaan.
Kebutuhan non-fungsional yang dapat diverifikasi : Pernyataan
menggunakan beberapa ukuran yang dapat diuji secara objektif. Sasaran
bermanfaat bagi pengembang saat mereka menyampaikan niat dari
pengguna sistem.

Modul Perancangan Database dan ImplementasiPage 5

Metrics for specifying nonfunctional requirements:

Property Measure

Speed Processed transactions/second

User/event response time
Screen refresh time

Size Mbytes
Number of ROM chips

Ease of use Training time

Number of help frames

Reliability Mean time to failure

Probability of unavailability
Rate of failure occurrence
Availability

Robustness Time to restart after failure

Percentage of events causing failure
Probability of data corruption on failure

Portability Percentage of target dependent statements

Number of target systems

Domain requirements adalah Batasan pada sistem dari domain

operasi. Domain operasional sistem menerapkan persyaratan pada
sistem. Sebagai contoh, sistem kontrol kereta harus memperhitungkan
karakteristik pengereman dalam kondisi cuaca yang berbeda.
Persyaratan domain adalah persyaratan fungsional baru, kendala
pada persyaratan yang ada atau menentukan perhitungan tertentu. Jika
persyaratan domain tidak dipenuhi, sistem mungkin tidak dapat dijalankan.

Modul Perancangan Database dan ImplementasiPage 6

Contoh domain requirement dari Train protection system:
Ini adalah persyaratan domain untuk sistem perlindungan kereta api:
Perlambatan kereta api akan dihitung sebagai:
Dtrain = Dcontrol + Dgradient
di mana Dgradient adalah 9.81ms2 * kompensasi gradien / alfa dan di
mana nilai 9.81ms2 / alpha dikenal untuk berbagai jenis kereta.

Sulit bagi non-spesialis untuk memahami implikasi dari ini dan bagaimana
ia berinteraksi dengan persyaratan lain.

Pada prinsipnya, persyaratan harus lengkap dan konsisten.

Lengkap yaitu harus menyertakan deskripsi semua fasilitas yang
dibutuhkan. Konsisten Seharusnya tidak ada konflik atau kontradiksi
dalam deskripsi fasilitas sistem. Dalam prakteknya, tidak mungkin
menghasilkan dokumen persyaratan yang lengkap dan konsisten.

C. Dokumen persyaratan perangkat lunak

Dokumen persyaratan perangkat lunak adalah pernyataan resmi
tentang apa yang diperlukan dari pengembang sistem. Harus mencakup
definisi kebutuhan pengguna dan spesifikasi persyaratan sistem. Ini
BUKAN dokumen desain. Sejauh mungkin, harus mengatur APA yang
seharusnya dilakukan oleh sistem daripada BAGAIMANA ia harus
melakukannya.
Users of a requirements document:

Modul Perancangan Database dan ImplementasiPage 7

 Informasi dalam dokumen persyaratan tergantung pada jenis sistem
dan pendekatan pengembangan yang digunakan. Sistem yang
dikembangkan secara bertahap akan, biasanya, memiliki lebih sedikit
detail dalam dokumen persyaratan. standar dokumen Persyaratan telah
dirancang misalnya Standar IEEE. Ini sebagian besar berlaku untuk
persyaratan untuk proyek rekayasa sistem besar.
The structure of a requirements document:

Chapter Description

Preface This should define the expected readership of the document and
describe its version history, including a rationale for the creation of
a new version and a summary of the changes made in each
version.

Introduction This should describe the need for the system. It should briefly
describe the system’s functions and explain how it will work with
other systems. It should also describe how the system fits into the
overall business or strategic objectives of the organization
commissioning the software.

Glossary This should define the technical terms used in the document. You
should not make assumptions about the experience or expertise of
the reader.

User requirements Here, you describe the services provided for the user. The
definition nonfunctional system requirements should also be described in
this section. This description may use natural language, diagrams,
or other notations that are understandable to customers. Product
and process standards that must be followed should be specified.

System This chapter should present a high-level overview of the

architecture anticipated system architecture, showing the distribution of
functions across system modules. Architectural components that
are reused should be highlighted.

System This should describe the functional and nonfunctional

requirements requirements in more detail. If necessary, further detail may also
specification be added to the nonfunctional requirements. Interfaces to other
systems may be defined.

Modul Perancangan Database dan ImplementasiPage 8

System models This might include graphical system models showing the
relationships between the system components and the system and
its environment. Examples of possible models are object models,
data-flow models, or semantic data models.

System evolution This should describe the fundamental assumptions on which the
system is based, and any anticipated changes due to hardware
evolution, changing user needs, and so on. This section is useful
for system designers as it may help them avoid design decisions
that would constrain likely future changes to the system.

Appendices These should provide detailed, specific information that is related

to the application being developed; for example, hardware and
database descriptions. Hardware requirements define the minimal
and optimal configurations for the system. Database requirements
define the logical organization of the data used by the system and
the relationships between data.

Index Several indexes to the document may be included. As well as a

normal alphabetic index, there may be an index of diagrams, an
index of functions, and so on.

D. Requirements specification
Proses penulisan kebutuhan pengguna dan persyaratan sistem dalam
dokumen persyaratan. Kebutuhan pengguna harus dimengerti oleh
pengguna akhir dan customer yang tidak memiliki latar belakang teknis.
Persyaratan sistem adalah persyaratan yang lebih rinci dan dapat
mencakup lebih banyak informasi teknis. Persyaratan dapat menjadi
bagian dari kontrak untuk pengembangan system Karena itu penting
bahwa ini selengkap mungkin.

Ways of writing a system requirements specification:

Modul Perancangan Database dan ImplementasiPage 9

 Notation Description

Natural Persyaratan ditulis menggunakan kalimat bernomor dalam bahasa

language alami. Setiap kalimat harus mengungkapkan satu persyaratan.

Structured Persyaratan ditulis dalam bahasa alami pada formulir atau template
natural standar. Setiap bidang menyediakan informasi tentang aspek
language persyaratan.

Design Pendekatan ini menggunakan bahasa seperti bahasa pemrograman,

description tetapi dengan fitur yang lebih abstrak untuk menentukan persyaratan
languages dengan mendefinisikan model operasional sistem. Pendekatan ini
sekarang jarang digunakan meskipun dapat berguna untuk spesifikasi
antarmuka.

Graphical Model grafis, dilengkapi dengan anotasi teks, digunakan untuk

notations menentukan persyaratan fungsional untuk sistem; UML use case dan
sequence diagram biasanya digunakan.

Mathematical Notasi-notasi ini didasarkan pada konsep-konsep matematika seperti

specifications mesin atau rangkaian finite-state. Meskipun spesifikasi yang tidak
ambigu ini dapat mengurangi ambiguitas dalam dokumen persyaratan,
sebagian besar pelanggan tidak memahami spesifikasi formal. Mereka
tidak dapat memeriksa bahwa itu mewakili apa yang mereka inginkan
dan enggan menerimanya sebagai kontrak sistem

E. Requirements and design

Pada prinsipnya, persyaratan harus menyatakan apa yang harus
dilakukan oleh sistem dan desain harus menggambarkan bagaimana hal
ini dilakukan. Dalam prakteknya, persyaratan dan desain tidak dapat
dipisahkan:
 Suatu arsitektur sistem dapat dirancang untuk menyusun
persyaratan;
 Sistem dapat saling beroperasi dengan sistem lain yang
menghasilkan persyaratan desain;
 Penggunaan arsitektur khusus untuk memenuhi persyaratan non-
fungsional mungkin merupakan persyaratan domain.

Modul Perancangan Database dan ImplementasiPage 10

  Ini mungkin konsekuensi dari persyaratan peraturan.

Guidelines for writing requirements:

 Buat format standar dan gunakan untuk semua persyaratan.
 Gunakan bahasa dengan cara yang konsisten. Penggunaan harus
untuk persyaratan wajib, harus untuk persyaratan yang diinginkan.
 Gunakan penyorotan teks untuk mengidentifikasi bagian-bagian
kunci dari persyaratan.
 Sertakan penjelasan (alasan) mengapa persyaratan diperlukan.

Problems with natural language:

 Kurang kejelasan
Presisi sulit tanpa membuat dokumen sulit dibaca.
 Kebutuhan ambigu
Persyaratan fungsional dan non-fungsional cenderung campur
aduk.
 Persyaratan penggabungan
Beberapa persyaratan yang berbeda dapat diekspresikan bersama.

Contoh Example requirements for the insulin pump software system:

3.2 The system shall measure the blood sugar and deliver insulin, if
required, every 10 minutes. (Changes in blood sugar are relatively
slow so more frequent measurement is unnecessary; less frequent
measurement could lead to unnecessarily high sugar levels.)

3.6 The system shall run a self-test routine every minute with the
conditions to be tested and the associated actions defined in Table 1.
(A self-test routine can discover hardware and software problems
and alert the user to the fact the normal operation may be
impossible.)
A structured specification of a requirement for an insulin pump:

Modul Perancangan Database dan ImplementasiPage 11

 Ins

Modul Perancangan Database dan ImplementasiPage 12

Ac
Tabular specification
Digunakan untuk melengkapi bahasa alami. Sangat berguna ketika
Anda harus menentukan sejumlah kemungkinan tindakan alternatif.
Sebagai contoh, sistem pompa insulin mendasarkan perhitungannya pada
tingkat perubahan tingkat gula darah dan spesifikasi tabular menjelaskan
bagaimana menghitung kebutuhan insulin untuk skenario yang berbeda.

Contoh Tabular specification of computation for an insulin pump:

Condition Action

Sugar level falling (r2 < r1) CompDose = 0

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate of increase CompDose = 0

decreasing
((r2 – r1) < (r1 – r0))

Sugar level increasing and rate of increase stable CompDose =

or increasing round ((r2 – r1)/4)
((r2 – r1) ≥ (r1 – r0)) If rounded result = 0 then
CompDose =
MinimumDose

F. Requirements engineering processes

Proses yang digunakan untuk RE sangat bervariasi tergantung pada
domain aplikasi, orang-orang yang terlibat dan organisasi yang
mengembangkan persyaratan. Namun, ada sejumlah aktivitas umum yang
umum untuk semua proses yaitu:
1. Persyaratan elisitasi;
2. Analisa Kebutuhan;
3. Persyaratan validasi;
4. Persyaratan manajemen.
Dalam prakteknya, RE adalah kegiatan iteratif di mana proses ini
disisipkan.

Modul Perancangan Database dan ImplementasiPage 13

A spiral view of the requirements engineering process:

Requirements elicitation and analysis

Terkadang disebut persyaratan elisitasi atau penemuan
persyaratan. Melibatkan staf teknis yang bekerja dengan pelanggan untuk
mencari tahu tentang domain aplikasi, layanan yang harus disediakan
sistem dan kendala operasional sistem. Dapat melibatkan pengguna akhir,
manajer, insinyur yang terlibat dalam pemeliharaan, ahli domain, serikat
pekerja, dll. Ini disebut pemangku kepentingan.
Masalah yang dihadapi pada tahap requirement analysis adalah:
 Pemangku kepentingan tidak tahu apa yang sebenarnya mereka
inginkan.
 Pemangku kepentingan menyatakan persyaratan dalam istilah
mereka sendiri.
 Pemangku kepentingan yang berbeda mungkin memiliki
persyaratan yang saling bertentangan.
 Faktor organisasi dan politik dapat mempengaruhi persyaratan
sistem.
 Persyaratan berubah selama proses analisis. Pemangku
kepentingan baru dapat muncul dan lingkungan bisnis dapat
berubah.

Modul Perancangan Database dan ImplementasiPage 14

 Software engineer bekerja dengan berbagai pemangku kepentingan
sistem untuk mencari tahu tentang domain aplikasi, layanan yang harus
disediakan sistem, kinerja sistem yang diperlukan, kendala perangkat
keras, sistem lain, dll.
Tahapan termasuk:

1. Requirement Discovery
Berinteraksi dengan para pemangku kepentingan untuk menemukan
kebutuhan mereka. Persyaratan domain juga ditemukan pada tahap
ini.
2. Requirement Classification and Organization
Kelompok persyaratan terkait dan mengatur mereka ke dalam
kelompok yang koheren.
3. Requirement Prioritization and Negotiation
Memprioritaskan persyaratan dan menyelesaikan persyaratan konflik.
4. Requirement Spesification
Persyaratan didokumentasikan dan dimasukkan ke putaran spiral
berikutnya.

Requirements validation
Fokus dengan menunjukkan bahwa persyaratan menentukan
sistem yang benar-benar diinginkan oleh pelanggan. Kebutuhan biaya
kesalahan tinggi sehingga validasi sangat penting. Memperbaiki
kesalahan persyaratan setelah pengiriman dapat biaya hingga 100 kali
biaya memperbaiki kesalahan implementasi.

Modul Perancangan Database dan ImplementasiPage 15

Requirements validation techniques:
 Requirements reviews
Analisis manual sistematis dari persyaratan.
 Prototyping
Menggunakan model yang dapat dieksekusi dari sistem untuk
memeriksa persyaratan.
 Test-case generation
Mengembangkan tes untuk persyaratan untuk memeriksa
testability.

Modul Perancangan Database dan ImplementasiPage 16

 Latihan Soal Pertemuan 4

1. Bentuk kelompok beranggotakan 2 orang kemudian cari template

requirement document sesuai standar IEEE.
2. Buatlah sebuah dokumen persyaratan (requirement document) untuk
sebuah pembangunan software!
3. Presentasikan di pertemuan berikutnya!

Modul Perancangan Database dan ImplementasiPage 17