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) Jika 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. Jika 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. Jika 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,every10minutes.(Changesinbloodsugararerelativelyslowsomorefrequentmeasurementisunnecessary;lessfrequentmeasurementcouldleadtounnecessarilyhighsugarlevels.)

3.6ThesystemshallrunaselftestroutineeveryminutewiththeconditionstobetestedandtheassociatedactionsdefinedinTable1.(Aselftestroutinecandiscoverhardwareandsoftwareproblemsandalerttheusertothefactthenormaloperationmaybeimpossible.)

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