Anda di halaman 1dari 31

7013TAdvancedSoftwareEngineering

LECTURE NOTES







REKAYASA PERSYARATAN





Abdul Aziz, Ir. MSc., PhD
e-mail: abdulazizpro@yahoo.com




7013TAdvancedSoftwareEngineering

Tujuan Pembelajaran

Setelah membaca bab ini, mahasiswa akan mempunyai kemampuan:
menjelaskan model persyaratan, manajemen desain dan proyek menghasilkan produk
berkualitas tinggi.

Topik Bahasan
Persyaratan fungsional dan non-fungsional
Dokumentasi persyaratan perangkat lunak
Spesifikasi persyaratan
Proses rekayasa (Rancang Bangun) persyaratan
Penimbulan dan analisa persyaratan
Validasi persyaratan
Manajemen persyaratan

Garis Besar Materi

Rekayasa persyaratan
Persyaratan fungsional dan Non-fungsional
Dokumentasi Persyaratan Perangkat Lunak
Spesifikasi persyaratan user
Proses Rancang-bangun persyaratan es
Penimbulan persyaratan dan analisa
Pengesahan persyaratan
Manajemen persyaratan
Modularity

7013TAdvancedSoftwareEngineering

ISI

Rekayasa Persyaratan
Proses menberikan layanan sesuai persyaratan user dan batasan dimana sistem ini bekerja
dan dikembangkan.
Persyaratan adalah deskripsi dari sistem layanan dan kendala yang dihasilkan saat proses
rekayasa persyaratan dijalankan.
Apa itu persyaratan?
Rentangan persyaratan bisa dimulai pernyataan abstrak tingkat tinggi dari suatu layanan
atau dari suatu batasan sistem hingga ke rincian detil fungsional matematis.
Hal ini tidak terelakan karena persyaratan dapat bertindak dengan fungsi ganda.
o Dapat menjadi dasar penawaran untuk kontrak oleh karena itu harus terbuka
dalam intrepetasi;
o Dapat menjadi dasar untuk kontrak itu senriri oleh karena itu harus didefinisikan
secara rinci;
o Kedua pernyataan dapat dikatakan sebagai persyaratan.

Abstraksi Persyaratan (Davis)
J ika keinginan/harapan suatu perusahaan menghasilkan suatu kontrak proyek besar
pengembangan perangkat lunak, dia harus mendefinisikan kebutuhan-kebutuhannya cukup
secara abstrak dari solusi belum didefinisikan sebelumnya.
Persyaratan harus ditulis sehingga beberapa kontraktor dapat melakukan penawaran kontrak,
barangkali, cara yang berbeda dalam memenuhi persyaratan organisasi klien. Ketika suatu
kontrak telah diberikan, kontraktor harus menulis definisi sistem untuk klien secara lebih detil
sehingga klien mengerti dan dapat menvalidasi apa yang akan dilakukan perangkat lunak. Kedua
dokumen tersebut dipakai disebut sebagai dokumen persyaratan sistem.


7013TAdvancedSoftwareEngineering

Tipe-tipe Persyaratan
Persyaratan User (pengguna)
o Pernyataan bahasa alami ditambah diagram tambahan dari layanan yang
disediakan sistem dan batasan operasionalnya. Ditulis untuk pelanggan.
Persyaratan sistem
o Satu dokumen terstruktur menetapkan uraian detil dari fungsi-fungsi sistem,
batasan layanan dan operasional. Mendefinisikan apa yang harus
diimplementasikan yang mungkin menjadi bagian suatu kontrak antara klien dan
kontraktor.
Persyaratan-persyaratan User dan Sistem

Definisi Persyaratan User
1. Perangkat lunak harus memberikan bantuan dalam merepresentasikan dan mencaakses
file-file eksternal yang dibuat dengan alat bantu (tool) lain.
Spesifikasi persyaratan sistem
1.1 User harus diberi fasilitas untuk mendefinisikan tipe file eksternal.
1.2 Setiap file eksternal bisa memiliki alat bantu relevan yang bisa diterapkan pada file
tersebut.
1.3 Setiap file eksternal bisa direpresentasikan sebagai ikon yang spesifik pada display
user.
1.4 Fasilitas harus disediakan untuk ikon yang merepresentasikan suatu tipe file eksternal
yang akan didefinisikan oleh user.
1.5 Ketika user memilih sebuah ikon yang merepresentasikan file eksternal, efek
pemilihan. itu adalah penerapan alat bantu yang berhubungan dengan tipe file
eksternal ke file yang direpresentasikan oleh ikon yang dipilih.



7013TAdvancedSoftwareEngineering

Reader dari tipe berbeda spesifikasi persyaratan













Persyaratan Fungsional dan Non-fungsional
Persyaratan Fungsional
- Pernyataan dari layanan yang disediakan sistem, bagaimana seharusnya sistem
bertindak terhadap input tertentu dan bagaimana sistem harus berkelakuan pada
situasi tertentu.
- Mungkin mencatumkan apa yang sebaiknya sistem tidak boleh lakukan.
Persyaratan Non-fungsional
- Batasan pada layanan atau fungsi yang ditawarkan oleh sistem seperti batasan waktu,
batasan pengembangan proses, standar, dsb.
- Sering berlaku bagi sistem secara keseluruhan dibandingkan dengan fitur atau
layanan individu.
Persyaratan Domain
- Batasan pada sistem dari domain operasi


7013TAdvancedSoftwareEngineering

Persyaratan Fungsional
Menjelaskan fungsi atau layanan sistem.
Bergantung kepada tipe dari perangkat lunak, harapan user dan tipe sistem dimana
perangkat lunak dipergunakan.
Persyaratan fungsional user mungkin pernyataan tingkat tinggi dari apa yang akan sistem
harus lakukan.
Persyaratan sistem fungsional harus mendeskripsikan detil layanan sistem.
Persyaratan Fungsional untuk MHC PMS
Seorang user harus mampu melakukan pencarian daftar perjanjian untuk seluruh klinik.
Sistem akan menghasilkan daftar pasien yang diduga dapat memenuhi perjanjiannya
setiap hari, untuk masing-masing klinik.
Setiap anggota yang akan menggunakan sistem harus dapat diidentifikasi secara unik
dengan keanggotaannya atau menggunakan 8 digit nomor identitasnya.

Ketidaktepatan Persyaratan
Problem akan muncul ketika persyaratan tidak tepat dinyatakan.
Persyaratan yang ambigu (rancu) mungkin diinterpretasikan secara beda baik oleh
pengembang maupun user.
Pertimbangkan istilah pencarian di persyaratan 1
- Intensi user mencari satu nama pasien dari semua perjanjian (appointments) pada
semua klinik;
- Interpretasi pengembang mencari satu nama pasien dari klinik individu. User
memilih klinik selanjutnya melakukan pencarian.

Kelengkapan Persyaratan dan Konsistensi
Pada prinsipnya, persyaratan harus memenuhi keduanya yaitu lengkap dan konsisten.
Lengkap
- Mereka harus menguraikan semua fasilitas diperlukan.
Konsisten
- Tidak boleh ada konflik atau kontradiksi dalam uraian fasilitas sistem.
Dalam praktek, ini mustahil untuk menghasilkan dokumen persyaratan yang lengkap dan
konsisten.
7013TAdvancedSoftwareEngineering

Persyaratan Nonfungsional
Sistem mendefinisikan karakteristik (properti) dan batasan-batasannya misalnya
keandalan, persyaratan waktu tanggap dan kebutuhan penyimpanan. Batasan-batasan
adalah kemampuan peralatan masukan/keluaran, representasi sistem, dsb.
Persyaratan roses juga boleh ditetapkan pada IDE tertentu, bahasa pemrograman atau
metode pengembangan.

Persyaratan non-fungsional mungkin lebih kritikal dibandingkan persyaratan fungsional.
J ika tidak ditemui kesepakan, sistem mungkin akan sia-sia.

Tipe Persyaratan Non-functional


















7013TAdvancedSoftwareEngineering

Implementasi Persyaratan Non-fungsional


Persyaratan non-fungsional mungkin lebih mempengaruhi arsitektur keseluruhan sistem
dibandingkan komponen individu.
- Antara lain, untuk memastikan kinerja itu persyaratan dijumpai, anda mungkin harus
mengorganisir sistem untuk memperkecil komunikasi di antara komponen.
Sebuah persyaratan non-fungsional, seperti persyaratan jaminan sekuritas, akan
menghasilkan sejumlah persyaratan fungsional yang terkait yang mendefinisikan layanan
sistem yang diperlukan.
- Mungkin juga menghasilkan persyaratan yang membatasi persyaratan yang sudah
ada.

Klasifikasi Non-fungsional
Persyaratan produk
- Persyaratan yang menetapkan bahwa penyampaian produk harus dilakukan dengan
cara tertentu misalnya kecepatan pelaksanaan, keandalan, dsb.
Persyaratan organisasi
- Persyaratan yang merupakan konsekwensi dari kebijakan organisasi dan prosedur
misalnya proses standar terpakai, persyaratan implementasi, dsb.
Persyaratan eksternal
- Persyaratan yang dibangun dari faktor-faktor eksternal dari sistem dan proses
pengembangannya misalnya persyaratan interoperability, persyaratan legislatif, dsb.
Contoh dari persyaratan nonfunctional pada MHC PMS








7013TAdvancedSoftwareEngineering

Tujuan-tujuan dan Persyaratan


Bukan persyaratan fungsional mungkin sangat sulit ke status secara tepat dan persyaratan
tidak tepat mungkin sulit untuk verifikasi.
Tujuan
- Satu niat umum dari user seperti kemudahan dari penggunaan.
Verifiable bukan persyaratan fungsional
- Satu penggunaan pernyataan beberapa ukur yang secara obyektif teruji.
Gol sangat menolong ke pengembang saat mereka menyampaikan niat dari user sistem.
Persyaratan Usability
Sistem harus menjadi mudah untuk mempergunakan oleh staf medis dan harus
diorganisir sedemikian user itu kesalahan diperkecil. (Gol)
Staf medis harus mampu untuk penggunaan semua fungsi sistem setelah empat jam
pelatihan. Setelah pelatihan ini, angka rata-rata dari kesalahan yang dibuat oleh user
berpengalaman tidak boleh melebihi dua per jam dari penggunaan sistem. (Testable
bukan persyaratan fungsional)

Ukuran Spesifikasi Persyaratan Non-functional










7013TAdvancedSoftwareEngineering

Persyaratan Domain
Operasionalnya sistem domain memaksakan persyaratan pada sistem.
- Antara lain, satu sistem kendali kereta api harus mempertimbangkan karakteristik
pengereman pada kondisi cuaca berbeda.
Persyaratan daerah menjadi persyaratan lagi fungsional, batasan pada persyaratan yang
sudah ada atau mendefinisikan perhitungan spesifik.
Kalau persyaratan daerah bukan dipuaskan, sistem mungkin tidak dapat dilaksanakan.

Melatih Sistem Perlindungan
Ini adalah satu persyaratan domain untuk satu sistem perlindungan kereta api:
Deselarasi dari kereta api harus dihitung seperti:
- Dtrain =Dcontrol +Dgradient

- Dimana Dgradient adalah 9.81ms2 * gradien hidrolik kritis terkompensasi / alfa dan
darimana nilai dari 9.81ms2 / alfa diketahui untuk tipe berbeda kereta api.
Ini adalah sulit untuk satu bukan spesialis untuk memahami implikasi dari ini dan
bagaimana ini saling berinteraksi dengan persyaratan lain.

Masalah Persyaratan Domain
understandability
- Persyaratan diekspresikan pada bahasa dari daerah aplikasi;
- Ini adalah sering tidak dipahami oleh lunak insinyur perangkat mengembangkan
sistem.
implicitness
- Spesialis daerah memahami area sangat baik bahwa mereka tidak memikirkan
bagaimana membuat persyaratan daerah tegas.











7013TAdvancedSoftwareEngineering

SIMPULAN

Persyaratan untuk satu lunak sistem perangkat memperkenalkan apa sistem harus lakukan
dan mendefinisikan batasan di atasnya operasi dan implementasi.
Persyaratan fungsional adalah pernyataan dari layanan yang sistem harus menyediakan
atau adalah uraian dari bagaimana beberapa perhitungan harus diselesaikan.
Bukan persyaratan fungsional sering menghambat sistem dikembangkan dan proses
perkembangan dipergunakan.
Mereka sering berhubungan ke hak milik muncul dari sistem dan oleh karenanya berlaku
bagi sistem secara keseluruhan.































7013TAdvancedSoftwareEngineering

Dokumentasi Persyaratan perangkat lunak


Dokumentasi persyaratan perangkat lunak adalah pernyataan resmi dari yang diperlukan
dari pengembang sistem.
Harus termasuk keduanya satu definisi persyaratan user dan satu spesifikasi dari
persyaratan sistem.
Ini adalah Tak Satu Pun disain dokumen. Sejauh mungkin, ini harus setelan dari APA
sistem harus lakukan agak dibandingkan Bagaimana yang ini harus lakukan ini.
Metode tangkas (Agile) dan Persyaratan
Banyak cara tangkas membantah yang menghasilkan satu dokumen persyaratan adalah
satu pemborosan waktu saat persyaratan mengubah sangat dengan cepat.
Dokumen kemudian selalu basi.
Kiat seperti XP mempergunakan persyaratan rancang-bangun incremental dan
persyaratan ekspresi sebagai cerita user (didiskusikan di Bab 3).
Ini adalah praktis untuk sistem bisnis tapi ragukan untuk sistem yang memerlukan banyak
pra pengiriman analisa (misalnya. sistem kritis) atau sistem yang dikembangkan oleh
beberapa pasukan.
Dokumen Persyaratan User









7013TAdvancedSoftwareEngineering


Dokumentasi Persyaratan Variabilitas
Keterangan di dokumen persyaratan bergantung kepada tipe dari sistem dan pendekatan
ke pembangunan terpakai.
Sistem mengembangkan incrementally akan, secara khas, punya kurang perincian pada
dokumen persyaratan.
Persyaratan mendokumentasikan standar telah didisain misalnya IEEE standar. Ini
kebanyakan bisa diterapkan ke persyaratan untuk proyek besar rancang-bangun sistem.
Struktur dari Dokumen Persyaratan
Bab Keterangan
Prakata
Bagian ini harus mendefinisikan bagaimana keterbacaan dokumen yang
diharapkan dan menjelaskan sejarah versinya, termasuk dasar
pernikiran pembuatan versi yang baru dan rangkuman perubahan yang
dibuat pada setiap versi.

Pendahuluan
Bab ini harus menerangkan kebutuhan akan sistem. Bagian ini harus
secara singkat mendeskripsikan fungsinya dan menjelaskan bagaimana
cara kerjanya dengan sistem yang lain. Harus dideskripsikan
bagaimana sistem ini digabungkan dalarn bisnis secara keseluruhan
atau tujuan strategis organisasi yang menugaskan pembuatan perangkat
lunaknya.

Daftar istilah Bagian ini harus mendefinisikan istilah-istilah teknis yang digunakan
pada dokumen. Anda tidak boleh membuat asumsi mengenai;
pengalaman atau keahlian pembaca.
Definisi
persyaratan user
Layanan yang diberikan bagi user dan persyaratan sistern non-
fungsional harus dijelaskan pada bagian ini. Deskripsi ini bisa
menggunakan bahasa natural, diagram atau notasi lainnya yang dapat
dipahami pelanggan. Standar produk dan proses yang mesti diikuti
harus dispesifikasi.

Arsitektur sistern Bab ini memberikan tinjauan tingkat tinggi mengenai arsitektur sistern
yang diantisipasi yang menunjukkan distribusi fungsi pada modul
sistem. Komponen arsitektural yang dipakai ulang harus dijelaskan.
Spesifikasi
persyaratan
sistem
Bagian ini mendeskripsikan persyaratan fungsional dan non-fungsional
dengan lebih rinci. J ika perlu, perincian lebih lanjut juga dapat
ditambahkan pada persyaratan non-fungsional, misalnya interface ke
sistern yang lain dapat didefinisikan.
Model sistern Bab ini menentukan satu atau lebih model sistem yang menunjukkan
hubungan antara komponen-komponen sistem dan sistern dan
lingkungannya. Ini bisa berupa model objek, model aliran data, dan
model data semantik.
7013TAdvancedSoftwareEngineering

Evolusi sistern
Bab ini mendeskripsikan asumsi dasar di atas mana sistern bertumpu
dan perubahan yang diantisipasi yang disebabkan oleh evolusi
perangkat keras, perubahan kebutuhan user, dll.
Lampiran
Bagian ini memberikan informasi yang rinci dan spesifik yang
berhubungan dengan aplikasi yang sedang dibuat. Contoh lampiran
yang bisa disertakan adalah deskripsi perangkat keras dan database.
Persyaratan perangkat keras mendefinisikan konfigurasi minimal dan
optimal bagi sistern. Persyaratan database mendefinisikan organisasi
logika dari data yang dipakai oleh sistern dan hubungan antara data.
Indeks
Beberapa indeks dokumen juga dapat disertakan. Selain indeks
alfabetis biasa, kemungkinan ada juga indeks diagram, indeks fungsi,
dsb.

Spesifikasi Persyaratan
Proses dari penulisan mengenakan persyaratan user dan sistem pada satu dokumen
persyaratan.
Persyaratan user harus yang dapat dimengerti oleh pemakai akhir dan pelanggan siapa
tidak mempunyai satu latar belakang teknis.
Persyaratan sistem adalah persyaratan lebih terperinci dan mungkin termasuk lebih teknis
keterangan.
Persyaratan mungkin menjadi bagian dari satu kontrak untuk pembangunan sistem
- Maka adalah penting bahwa ini adalah selengkap mungkin.








7013TAdvancedSoftwareEngineering

Cara Penulisan Spesifikasi Persyaratan Sistem























Notation Description
Natural
language
The requirements are written using numbered
sentences in natural language. Each sentence
should express one requirement.
Structured
natural
language
The requirements are written in natural language on
a standard form or template. Each field provides
information about an aspect of the requirement.
Design
description
languages
This approach uses a language like a programming
language, but with more abstract features to specify
the requirements by defining an operational model of
the system. This approach is now rarely used
although it can be useful for interface specifications.
Graphical
notations
Graphical models, supplemented by text annotations,
are used to define the functional requirements for the
system; UML use case and sequence diagrams are
commonly used.
Mathematical
specifications
These notations are based on mathematical
concepts such as finite-state machines or sets.
Although these unambiguous specifications can
reduce the ambiguity in a requirements document,
most customers dont understand a formal
specification. They cannot check that it represents
what they want and are reluctant to accept it as a
system contract

7013TAdvancedSoftwareEngineering

Persyaratan dan desain


Pada prinsipnya, persyaratan harus menyatakan apa sistem harus lakukan dan desain
harus mendeskripsikan bagaimana ini lakukan ini.
Dalam praktek, persyaratan dan desain adalah tidak dapat dipisahkan
- Satu arsitektur sistem mungkin didisain ke struktur persyaratan;
- Sistem mungkin mengebumikan mengoperasikan dengan sistem lain yang
menghasilkan persyaratan desain;
- Penggunaan dari satu arsitektur spesifik untuk memuaskan bukan persyaratan
fungsional mungkin satu persyaratan daerah.
Ini mungkin konsekwensi dari satu persyaratan pengatur.
Spesifikasi Bahasa Alami
Persyaratan ditulis saat bahasa alami menghukum dilengkapi oleh diagram dan tabel.
Dipergunakan untuk menulis persyaratan karena ini adalah ekspresif, intuitif dan
universal. Ini memaksudkan bahwa persyaratan dapat dipahami oleh user dan pelanggan.
Petunjuk Untuk Persyaratan Penulisan
Temukan satu format standar dan penggunaan ini bagi seluruh persyaratan.
Pergunakan bahasa pada satu cara konsisten. Penggunaan harus untuk persyaratan yang
diberi kekuasaan, harus untuk persyaratan diinginkan.
Mempergunakan penyorotan teks untuk mengidentifikasi kunci terpisah persyaratan.
Hindari penggunaan dari jargon komputer.
Liputi satu keterangan (dasar pemikiran) dari kenapa satu persyaratan perlu.
Masalah Dengan Bahasa Alami
Kekurangan dari kejelasan
- Ketepatan adalah sulit tanpa pembuatan dokumen sulit ke bacaan.
Kebingungan persyaratan
- Fungsional dan bukan persyaratan fungsional cenderung dikacaukan.
Leburan dalam air raksa persyaratan
- Beberapa persyaratan berbeda mungkin diekspresikan bersama-sama.
7013TAdvancedSoftwareEngineering

Contoh Persyaratan Sistem Perangkat Lunak Pompa Insulin








Spesifikasi Struktur
Satu pendekatan untuk menulis persyaratan dimana kebebasan untuk penulis persyaratan
adalah terbatas dan persyaratan diberi suara dengan menulis nama satu standar cara.
Sumur pekerjaan ini untuk beberapa tipe persyaratan misalnya persyaratan untuk sistem
kendali terlekat kecuali sering menjadi juga kaku untuk menulis persyaratan sistem
bisnis.
Bentuk Spesifikasi Berdasar
Definisi dari fungsi atau kesatuan.
Uraian tentang input dan darimana mereka.
Uraian tentang keluaran dan kemana mereka pergi.
Keterangan sekitar keterangan yang diperlukan untuk perhitungan dan terpakai kesatuan
lain.
Uraian tentang aksi diambil.
Pra dan kondisi tempatkan (kalau sesuai).
Akibat sampingan (kalau apapun) dari fungsi.




3.2Thesystemshallmeasurethebloodsugaranddeliverinsulin,ifrequired,every10
minutes.(Changesinbloodsugararerelativelyslowsomorefrequentmeasurementis
unnecessary;lessfrequentmeasurementcouldleadtounnecessarilyhighsugarlevels.)
3.6Thesystemshallrunaselftestroutineeveryminutewiththeconditionstobetestedand
theassociatedactionsdefinedinTable1.(Aselftestroutinecandiscoverhardwareand
softwareproblemsandalerttheusertothefactthenormaloperationmaybeimpossible.)
7013TAdvancedSoftwareEngineering

Struktur Spesifikasi Persyaratan Pompa Insulin


Spesifikasi Bentuk Tabel
Dipergunakan untuk pelengkap bahasa alami.
Terutama berguna ketika kamu yang harus mendefinisikan sejumlah kursus alternatif
kemungkinan dari aksi.
Antara lain, sistem pompa hormon insulin basis perhitungan ini pada rate dari perubahan
dari taraf gula darah dan spesifikasi bentuk tabel menjelaskan bagaimana caranya
menghitung persyaratan hormon insulin untuk skenario berbeda.

Spesifikasi Bentuk Tabel Dari Perhitungan Pompa Insulin
Proses Rekayasa Persyaratan
Proses yang dipergunakan untuk Tentang membedakan secara luas bergantung kepada
daerah aplikasi, orang-orang melibatkan dan organisasi mengembangkan persyaratan.
Bagaimanapun, ada sejumlah umum aktivitas umum terhadap semuanya proses
- Penimbulan persyaratan;
- Analisa keperluan;
- Pengesahan persyaratan;
- Manajemen persyaratan.
Dalam praktek, Tentang adalah satu aktivitas iterative dimana proses ini disisipkan antar
halaman.








7013TAdvancedSoftwareEngineering

Bentuk Spiral Proses dari Rekayasa Persyaratan





Penimbulan persyaratan dan analisa
Kadang kala penimbulan persyaratan dipanggil atau penemuan persyaratan.
Libatkan staf teknis mengerjakan dengan pelanggan untuk menemukan sekitar daerah
aplikasi, layanan yang sistem harus menyediakan dan operasionalnya sistem batasan.
Bolehkan melibatkan pemakai akhir, manajer, insinyur terbelit di pemeliharaan, pakar
daerah, perserikatan Trade, dsb. Ini dipanggil pemegang taruhan.

Masalah dari analisa keperluan
Pemegang taruhan tidak mengetahui apa mereka ingin sekali.
Pemegang taruhan mengekspresikan persyaratan pada kondisi mereka sendiri.
Pemegang taruhan berbeda mungkin punya persyaratan konflik.
Faktor organisasi dan politis mungkin mempengaruhi persyaratan sistem.
Perubahan persyaratan selama proses analisa. Pemegang taruhan lagi mungkin muncul
dan lingkungan bisnis mungkin berganti.
Penimbulan persyaratan dan analisa
7013TAdvancedSoftwareEngineering

Lunak insinyur perangkat bekerja dengan satu jangkauan pemegang taruhan sistem untuk
menemukan sekitar daerah aplikasi, layanan yang sistem harus sediakan, sistem
diperlukan kinerja, batasan perangkat keras, sistem lain, dsb.
Langkah termasuk:
- Penemuan persyaratan,
- Klasifikasi persyaratan dan organisasi,
- Persyaratan prioritization dan negosiasi,
- Spesifikasi persyaratan.


Penimbulan Therequirements dan proses analisa





7013TAdvancedSoftwareEngineering


Proses aktivitas
Penemuan persyaratan
- Saling berinteraksi dengan pemegang taruhan untuk menemukan persyaratan mereka.
Persyaratan daerah ditemukan di langkah ini.
Klasifikasi persyaratan dan organisasi
- Golongkan persyaratan terkait dan mengorganisir mereka ke dalam seikat terpadu.
Prioritisation dan negosiasi
- Memprioritas persyaratan dan pemecahan konflik.
Spesifikasi persyaratan
- Persyaratan didokumentasikan dan memasuki ke dalam ronde berikutnya dari
berpilin.

Masalah dari penimbulan persyaratan
Pemegang taruhan tidak mengetahui apa mereka ingin sekali.
Pemegang taruhan mengekspresikan persyaratan pada kondisi mereka sendiri.
Pemegang taruhan berbeda mungkin punya persyaratan konflik.
Faktor organisasi dan politis mungkin mempengaruhi persyaratan sistem.
Perubahan persyaratan selama proses analisa. Pemegang taruhan lagi mungkin memuncul
dan lingkungan bisnis berganti.








7013TAdvancedSoftwareEngineering


SIMPULAN

Dokumen persyaratan perangkat lunak adalah satu pernyataan disetujui dari persyaratan
sistem. Ini harus diorganisir sangat itu berdua pelanggan sistem dan pengembang
perangkat lunak dapat mempergunakan ini.
Proses rancang-bangun persyaratan adalah satu iterative memproses termasuk persyaratan
penimbulan, spesifikasi dan pengesahan.
Penimbulan persyaratan dan analisa adalah satu iterative memproses yang dapat diwakili
sebagai satu pilinan aktivitas penemuan persyaratan, klasifikasi persyaratan dan
organisasi, negosiasi persyaratan dan dokumentasi persyaratan.


























7013TAdvancedSoftwareEngineering


Penemuan persyaratan
Proses dari keterangan kumpul-kumpul sekitar sistem diperlukan dan yang sudah ada dan
menyaring persyaratan user dan sistem dari keterangan ini.
Interaksi bersama pemegang taruhan sistem dari manajer ke pelaras eksternal.
Sistem secara normal mempunyai satu jangkauan pemegang taruhan.

Pemegang taruhan pada MHC PMS
Keterangan Patientswhose direkam pada sistem.
Doctorswho adalah bertanggung-jawab untuk mengaji dan memperlakukan pasien.
Rawat yang mengoordinir konsultasi dengan dokter dan mengurus beberapa perlakuan.
Medis receptionistswho mengatur pertemuannya pasien.
Staf ini siapa bertanggung-jawab untuk menginstal dan memelihara sistem.

Pemegang taruhan pada MHC PMS
Satu manajer etika medis yang harus memastikan bahwa arus pertemuan sistem petunjuk
etis untuk kekhawatiran pasien.
Kesehatan pelayanan managerswho memperoleh informasi manajemen dari sistem.
Catatan mengenai kesehatan staffwho adalah bertanggung-jawab untuk memastikan
sistem itu keterangan dapat dipelihara dan diawetkan, dan pencatatan itu prosedur dengan
baik penerapan.

Pewawancaraan
Formal atau informal wawancara dengan pemegang taruhan menjadi bagian dari paling
tentang proses.
Tipe dari wawancara
- Menutup wawancara berlandaskan pra daftar bertekad dari pertanyaan
- Membuka wawancara dimana berbagai Issue dieksplorasi dengan pemegang taruhan.
Pewawancaraan efektif
- J adilah berpandangan terbuka, menghindari pra ide terbenihkan sekitar persyaratan
dan akan untuk mendengarkan pemegang taruhan.
7013TAdvancedSoftwareEngineering

- Bisikkan orang sedang diwawancarai untuk memperoleh pergi bahasan


mempergunakan satu pertanyaan papan loncatan, satu usulan persyaratan, atau
dengan mengerjakan bersama-sama pada satu sistem contoh asli.

Mewawancarai dalam praktek
Secara normal satu campuran dengan pewawancaraan tertutup dan terbuka.
Wawancara adalah berguna bagi semakin satu pemahaman keseluruhan dari apa
pemegang taruhan lakukan dan bagaimana yang mereka mungkin saling berinteraksi
dengan sistem.
Wawancara bukan berguna bagi persyaratan daerah pemahaman
- Insinyur persyaratan tidak dapat memahami daftar kata-kata penting daerah spesifik;
- Beberapa daerah pengetahuan juga terbiasa bahwa penemuan orang-orang ini susah
untuk mengartikulasikan atau memikirkan bahwa ini tidak berharga
mengartikulasikan.

Skenario
Skenario adalah contoh kehidupan nyata dari bagaimana satu sistem dapat dipergunakan.
Mereka harus termasuk
- Satu uraian tentang keadaan awal;
- Satu uraian tentang aliran normal dari peristiwa;
- Satu uraian tentang apa yang dapat seleweng;
- Keterangan sekitar aktivitas berbarengan yang lain;
- Satu uraian tentang status ketika selesai skenario.

Skenario untuk sejarah medis pengumpulan di MHC PMS
Pergunakan kasus
Mempergunakan kasus adalah satu skenario mendasari ilmu pengetahuan tentang teknik
pada UML yang mengidentifikasi aktor pada satu interaksi dan yang mendeskripsikan
interaksi sendiri.
Seperangkat kasus penggunaan harus mendeskripsikan semua mungkin interaksi dengan
sistem.

7013TAdvancedSoftwareEngineering

Pada taraf yang tinggi model grafis dilengkapi oleh uraian lebih terperinci bentuk tabel
(melihat Bab 5).
Diagram urutan biasanya menambahkan perincian untuk mempergunakan kasus dengan
memperlihatkan urutan dari proses peristiwa pada sistem.

Pergunakan kasus untuk MHC PMS
Etnografi
Satu pengetahuan masyarakat sarjana membelanjakan satu waktu pantas dipertimbangkan
mengamati dan menganalisa bagaimana orang-orang sebenarnya kerjakan.
Orang-orang tidak mempunyai untuk menjelaskan atau mengartikulasikan pekerjaan
mereka.
Faktor sosial dan organisasi dari kepentingan mungkin diamati.
Pembahasan etnografi mempunyai terlihat bahwa pekerjaan biasanya lebih kaya dan lebih
rumit dibandingkan disarankan oleh sistem sederhana modelkan.

Bidang lapangan dari etnografi
Persyaratan yang diperoleh dari jalannya orang-orang itu sebenarnya kerjakan agak
dibandingkan jalannya aku yang memproses definisi menyarankan bahwa mereka
harusnya bekerja.
Persyaratan yang diperoleh dari bantuan kerjasama dan kesadaran akan orang lain
aktivitas.
- Kesadaran akan apa orang lain sedang melakukan Lead untuk berganti di jalanan
dimana kita yakinkan.
Etnografi adalah efektif untuk memahami proses yang sudah ada kecuali tidak dapat
mengidentifikasi fitur lagi itu harus ditambahkan ke satu sistem.

Memfokuskan etnografi
Dikembangkan pada satu proyek mempelajari proses pengawasan lalu lintas udara
Kombinasikan etnografi dengan pemrototipean
Hasil pembangunan contoh asli pada pertanyaan tidak dijawab yang memfokuskan
analisa etnografi.
Masalah dengan etnografi adalah yang ini mempelajari praktek yang sudah ada yang
7013TAdvancedSoftwareEngineering

yang mungkin punya beberapa basis historis yaitu tidak lagi relevan.

Etnografi dan pemrototipean untuk analisa keperluan
Pengesahan persyaratan
Dikaitkan dengan mempertunjukkan bahwa persyaratan mendefinisikan sistem yang
pelanggan ingin sekali.
Biaya kesalahan persyaratan adalah tinggi sangat pengesahan adalah sangat penting
- Memperbaiki satu kesalahan persyaratan setelah pengiriman mungkin berharga
sampai 100 times ongkos perbaikan satu kesalahan implementasi.

Pengecekan persyaratan
Kebenaran. Apakah sistem menyediakan fungsi yang mana dukungan terbaik
persyaratannya pelanggan?
Konsistensi. Ada di sana apapun konflik persyaratan?
Kelengkapan. Adalah semua fungsi diperlukan oleh pelanggan termasuk?
Realisme. Dapat persyaratan menjadi tertentu yang penerapan anggaran keuangan
tersedia dan teknologi
Verifiability. Dapat persyaratan menjadi diperiksa?

Ilmu pengetahuan tentang teknik pengesahan persyaratan
Ulasan persyaratan
- Analisa manual sistematis dari persyaratan.
Pemrototipean
- Mempergunakan satu model executable dari sistem untuk mencek persyaratan.
Diliputi di Bab 2.
Generasi kasus menguji
- Mengembangkan test untuk persyaratan cek testability .


Ulasan persyaratan
Ulasan tetap harus digenggam sementara definisi persyaratan dirumuskan.
7013TAdvancedSoftwareEngineering

Klien berdua dan staf kontraktor harus dilibatkan di ulasan.


Ulasan mungkin formal (dengan dokumen lengkap) atau informal. Komunikasi baik di
antara pengembang, pelanggan dan user dapat memecahkan masalah pada satu langkah
awal.

Telaah pengecekan
Verifiability
- Adalah persyaratan secara realistis testable?
Bisa dimengerti
- Adalah persyaratan dengan baik mengerti?
Traceability
- Adalah asal dari persyaratan dengan jelas berkata?
Daya penyesuaian
- Dapat persyaratan menjadi berubah tanpa satu dampak besar pada persyaratan lain?

Manajemen persyaratan
Manajemen persyaratan adalah proses dari persyaratan berganti pengelolaan selama
rancang-bangun persyaratan berjalan dan pembangunan sistem.
Persyaratan lagi memuncul sebagai satu sistem dikembangkan dan setelah ini sudah pergi
ke dalam penggunaan.
Kamu perlu menjejaki dari persyaratan individu dan memelihara hubungan terkait di
antara persyaratan bergantung sangat yang kamu dapat mengaji dampak dari perubahan
persyaratan. Kamu perlu mendirikan satu proses formil untuk usulan perubahan
pembuatan dan menghubungkan ini ke persyaratan sistem.

Mengubah persyaratan
Lingkungan bisnis dan teknis dari sistem selalu mengubah setelah instalasi.
- Perangkat keras lagi mungkin diperkenalkan, ini mungkin perlu untuk
menghubungkan sistem dengan sistem lain, prioritas bisnis mungkin berganti (dengan
perubahan sebagai akibat pada dukungan sistem diperlukan), dan legislasi baru dan
peraturan mungkin diperkenalkan bahwa sistem harus seharusnya menaati.
Orang-orang siapa traktir satu sistem dan user dari bahwa sistem jarang orang-orang yang
sama.
7013TAdvancedSoftwareEngineering

- Pelanggan sistem memaksakan persyaratan karena akibat batasan organisatoris dan


budgeter. Ini mungkin menikai dengan persyaratan pemakai akhir dan, setelah
pengiriman, fitur lagi mungkin harus ditambahkan untuk dukungan user kalau sistem
adalah untuk menjumpai gol ini.

Mengubah persyaratan
Sistem besar biasanya mempunyai satu komunitas user berbeda, dengan banyak user
mempunyai persyaratan berbeda dan prioritas yang mungkin tikai atau berlawanan.
- Sistem akhir persyaratan tak bisa diacuhkan satu berkompromi di antara mereka dan,
dengan pengalaman, ini adalah sering ditemukan itu seimbang dari dukungan
memberikan ke user berbeda harus diubah.

Evolusi persyaratan
Perencanaan manajemen persyaratan
Dirikan taraf dari perincian manajemen persyaratan yang diperlukan.
Keputusan manajemen persyaratan:
- Identifikasi persyaratan Masing-masing persyaratan dengan uniknya diidentifikasi
sangat bahwa ini dapat acuan yang seberang dengan persyaratan lain.
- Satu proses manajemen perubahan Ini adalah setelan dari aktivitas yang mengaji
dampak dan ongkos perubahan. Aku mendiskusikan proses ini secara lebih detil pada
bagian berikut.
- Kebijakan Traceability Kebijakan ini mendefinisikan hubungan di antara masing-
masing persyaratan dan di antara persyaratan dan desain sistem itu harus direkam.
- Dukungan alat Alat yang mungkin dipergunakan terbentang dari manajemen
persyaratan spesialis sistem ke database spreadsheet dan sederhana sistem.

Persyaratan mengubah manajemen
Memutuskan kalau satu perubahan persyaratan harus diterima
Spesifikasi analisa permasalahan dan perubahan
Selama langkah ini, masalah atau usulan perubahan diteliti untuk mencek
bahwa ini adalah sah. Analisa ini diberi makan kembali perubahan requestor
yang mungkin menjawab dengan satu persyaratan spesifik lagi mengubah
usulan, atau putuskan untuk menarik permintaan.
Ubah analisa dan berharga
Akibat dari perubahan diusulkan dikaji mempergunakan keterangan
traceability dan pengetahuan umum dari persyaratan sistem. Satu kali analisa
7013TAdvancedSoftwareEngineering

ini dilengkapi, satu keputusan dibuat apakah atau tidak untuk diproses dengan
perubahan persyaratan.
Ubah implementasi
Dokumen persyaratan dan, dimana diperlukan, desain sistem dan
implementasi, dimodifikasi. Idealnya, dokumen harus diorganisir sangat
perubahan itu dapat mudah penerapan.

Persyaratan mengubah manajemen

Titik kunci
Kamu dapat mempergunakan satu jangkauan ilmu pengetahuan tentang teknik untuk
penimbulan persyaratan termasuk wawancarai, skenario, pergunakan kasus dan etnografi.
Pengesahan persyaratan adalah proses untuk mencek persyaratan untuk kebenaran,
konsistensi, kelengkapan, realisme dan verifiability.
Bisnis, perubahan organisatoris dan teknis tak bisa diacuhkan pimpin untuk mengubah ke
persyaratan untuk satu lunak sistem perangkat. Manajemen persyaratan adalah proses
dari pengelolaan dan pengontrol perubahan ini.



7013TAdvancedSoftwareEngineering

SIMPULAN
Anda dapat mempergunakan satu jangkauan ilmu pengetahuan tentang teknik untuk
penimbulan persyaratan termasuk wawancarai, skenario, pergunakan kasus dan etnografi.
Pengesahan persyaratan adalah proses untuk mencek persyaratan untuk kebenaran,
konsistensi, kelengkapan, realisme dan verifiability.
Bisnis, perubahan organisatoris dan teknis tak bisa diacuhkan pimpin untuk mengubah ke
persyaratan untuk satu lunak sistem perangkat. Manajemen persyaratan adalah proses dari
pengelolaan dan pengontrol perubahan ini.



































7013TAdvancedSoftwareEngineering

DAFTAR PUSTAKA

Ian Sommerville(2010), Software Engineering, chapter 4, 9th edition, Pearson. USA. ISBN:
978-0-13-705346-9.

Sumber lain:
http://www.acm.org/about/se-code
http://www.computer.org/cms/Computer.org/Publications/code-of-ethics.pdf

Beri Nilai