Rekayasa Kebutuhan Perangkat Lunak

(1)

Rekayasa Kebutuhan Perangkat Lunak

(2)

Topik

 Kebutuhan fungsional dan non-fungsional

 Dokumen kebutuhan perangkat lunak

 Spesifikasi kebutuhan

 Proses rekayasa kebutuhan

 Analisa dan pemunculan kebutuhan

 Validasi kebutuhan

 Manajemen kebutuhan

(3)

Rekayasa Kebutuhan

 Merupakan proses penentuan layanan yang dibutuhkan pelanggan dan batasan sistemnya.

 Kebutuhan itu sendiri merupakan deskripsi layanan sistem dan batasan yang dihasilkan selama proses rekayasa kebutuhan.

(4)

Apakah Kebutuhan itu?

 Kebutuhan mencakup abstraksi layanan dan

batasan sistem hingga fungsi matematis mendetail.

 Kebutuhan dapat bertindak sebagai dua fungsi yaitu:

 Sebagai dasar penawaran kontrak – sehingga harus terbuka terhadap perbedaan penafsiran;

 Sebagai bagian dari kontrak itu sendiri – sehingga harus dibuat mendetail.

(5)

Requirements abstraction (Davis)

“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a

solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization’s needs. Once a contract has been awarded, the contractor must write a system definition for the

client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the

requirements document for the system.”

(6)

Jenis Kebutuhan

 Kebutuhan Pengguna

 Berupa pernyataan dalam bahasa natural dan

diagram berisi layanan yang disediakan sistem dan batasan operasionalnya.

 Ditulis untuk pelanggan.

 Kebutuhan Sistem

 Dokumen terstruktur yang menjelaskan deskripsi lengkap dari fungsi, layanan dan batasan operasional sistem.

 Mendefinisikan apa yang harus diimplementasikan sehingga bisa menjadi bagian kontrak antara klien dan kontraktor.

(7)

Contoh kebutuhan user dan sistem

(8)

Pembaca spesifikasi kebutuhan yang

berbeda

(9)

Kebutuhan Fungsional dan Non-

fungsional

(10)

Kebutuhan fungsional dan non-fungsional

 Kebutuhan fungsional

 Berisi layanan yang harus disediakan sistem, bagaimana sistem bereaksi terhadap suatu input dan bagaimana sistem berperilaku dalam situasi tertentu.

 Mungkin juga menunjukkan apa yang seharusnya tidak dilakukan sistem.

 Kebutuhan non-fungsional

 Batasan layanan atau fungsi yang ditawarkan sistem, misalnya batasan waktu, batasan proses pengembangan, dll.

 Biasanya diaplikasikan pada sistem secara keseluruhan, bukan pada fitur atau layanan tertentu.

 Kebutuhan domain

 Batasan sistem berdasarkan domain operasinya

(11)

Kebutuhan Fungsional

 Mendeskripsikan fungsionalitas atau layanan sistem.

 Tergantung pada jenis perangkat lunak, pengguna dan jenis sistem dimana perangkat lunak

digunakan.

 Kebutuhan fungsional pengguna mungkin

menjelaskan apa yang seharusnya dilakukan sistem.

 Kebutuhan fungsional sistem seharusnya

mendeskripsikan layanan sistem secara detail.

(12)

Kebutuhan fungsional pada sistem manajemen pasien RSJ

 Pengguna harus dapat mencari daftar janji di semua klinik.

 Sistem harus dapat menghasilkan daftar pasien

yang membuat janji setiap hari untuk setiap klinik.

 Semua staf menggunakan pengenal berupa nomer pegawai sebanyak 8 digit.

(13)

Ketidaktepatan Kebutuhan

 Masalah akan muncul ketika kebutuhan tidak ditentukan dengan tepat.

 Kebutuhan yang ambigu mungkin diartikan berbeda oleh pengembang dan pengguna.

 Misal, poin “pencarian” pada sistem manajemen pasien RSJ

 Maksud pengguna – mencari nama pasien di antara semua janji di semua klinik;

 Penafsiran pengembang – mencari nama pasien di sebuah klinik. Pengguna memilih klinik, lalu

melakukan pencarian.

(14)

Kelengkapan dan Konsistensi Kebutuhan

 Pada dasarnya, kebutuhan seharusnya lengkap dan konsisten.

 Lengkap

 Mendeskripsikan semua fasilitas yang dibutuhkan

 Konsisten

 Tidak boleh ada konflik atau kontradiksi pada fasilitas sistem.

 Namun dalam prakteknya, tidak mungkin untuk

menghasilkan dokumen kebutuhan yang lengkap dan konsisten

(15)

Kebutuhan Non-fungsional

 Kebutuhan ini mendefinisikan properti sistem dan batasannya, misalkan ketangguhan, waktu respon, kemampuan alat, dll.

 Kebutuhan proses mencakup perintah penggunaan IDE, bahasa pemrograman atau metode

pengembangan tertentu.

 Kebutuhan non-fungsional bisa jadi lebih penting daripada kebutuhan fungsional, karena jika tidak terpenuhi maka sistem tidak dapat digunakan.

(16)

Implementasi kebutuhan non-fungsional

 Kebutuhan non-fungsional dapat mempengaruhi keseluruhan arsitektur sistem.

 Contoh : untuk memastikan kebutuhan performance, sistem mungkin harus diorganisasi sehingga

meminimalkan komunikasi antar komponen.

 Suatu kebutuhan non-fungsional, misalkan

keamanan, mungkin menghasilkan kebutuhan fungsional tertentu.

 Mungkin juga menghasilkan kebutuhan yang membatasi kebutuhan yang sudah ada.

(17)

Jenis kebutuhan non-fungsional

(18)

Klasifikasi kebutuhan non-fungsional

 Kebutuhan produk

 Kebutuhan yang menentukan bahwa produk yang dihasilkan harus memiliki perilaku tertentu, misalkan kecepatan eksekusi, ketahanan, dll.

 Kebutuhan organisasi

 Kebutuhan yang merupakan konsekuensi dari kebijakan atau prosedur organisasi, misalkan standar proses yang digunakan, kebutuhan implementasi, dll.

 Kebutuhan eksternal

 Kebutuhan yang muncul karena adanya faktor eksternal sistem, misalkan kebutuhan legislatif, dll.

(19)

Contoh kebutuhan non-fungsional manajemen pasien RSJ

Product requirement

The MHC-PMS shall be available to all clinics during normal

working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.

Organizational requirement

Users of the MHC-PMS system shall authenticate themselves using their health authority identity card.

External requirement

The system shall implement patient privacy provisions as set out in HStan-03-2006-priv.

(20)

Ukuran untuk menentukan kebutuhan non-fungsional

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

(21)

Kebutuhan Domain

 Domain operasional menimbulkan adanya kebutuhan dalam sistem.

 Contoh : sistem kendali kereta api harus

mempertimbangkan karakteristik rem dalam kondisi cuaca yang berbeda.

 Kebutuhan domain dapat menjadi kebutuhan fungasional baru, batasan pada kebutuhan

fungsional saat ini atau menentukan komputasi khusus.

 Jika kebutuhan domain tidak terpenuhi, mungkin m tidak akan dapat bekerja dengan benar.

(22)

Contoh : Sistem perlindungan kereta api

 Penurunan kecepatan kereta dihitung dengan persamaan:

 Dtrain = Dcontrol + Dgradient

 Dimana Dgradient = 9.81ms2 * gradient

pengganti/alpha dan nilai 9.81ms2 akan berbeda untuk jenis kereta api yang berbeda.

 Akan sulit untuk orang yang tidak ahli pada domain tersebut memahami maksud dari pernyataan

tersebut dan apa hubungannya dengan kebutuhan lain.

(23)

Masalah pada kebutuhan domain

 Pemahaman

 Kebutuhan diekspresikan dalam domain aplikasi sehingga sering tidak dipahami pengembang

perangkat lunak.

 Implisit

 Sang ahli memahami area ini dengan sangat baik sehingga mereka tidak memikirkan untuk

menyebutkannya secara eksplisit.

(24)

Dokumen Kebutuhan Perangkat Lunak

(25)

Dokumen Kebutuhan Perangkat Lunak

 Dokumen kebutuhan perangkat lunak adalah

pernyataan resmi pengembang tentang kebutuhan sistem.

 Harus mencakup kebutuhan pengguna dan kebutuhan sistem.

 BUKAN dokumen perancangan. Sebisa mungkin harus bisa menjelaskan APA yang harus dilakukan sistem, bukan BAGAIMANA melakukannya.

(26)

Kebutuhan dan metode Agile

 Banyak metode agile yang menyatakan bahwa membuat dokumen kebutuhan hanya akan

menghabiskan waktu karena kebutuhan berubah dengan sangat cepat.

 Sehingga dokumen tersebut menjadi ketinggalan zaman.

 Metode agile seperti XP menggunakan rekayasa kebutuhan bertahap dan mengakspresikan

kebutuhan dalam bentuk ‘cerita penggguna’.

(27)

Dokumen kebutuhan pengguna

(28)

Variasi dokumen kebutuhan

 Informasi yang ada dalam dokumen kebutuhan tergantung pada jenis sistem metode

pengembangan yang digunakan.

 Sistem yang dikembangkan secara bertahap

biasanya memiliki detail yang lebih sedikit di dalam dokumen kebutuhannya.

 Standar dokumen kebutuhan misalkan adalah

standar IEEE. Standar ini sering digunakan untuk mendefinisikan kebutuhan pada proyek rekayasa sistem yang besar.

(29)

Struktur dokumen kebutuhan

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 definition

Here, you describe the services provided for the user. The 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 architecture This chapter should present a high-level overview of the anticipated system architecture, showing the distribution of functions across system modules.

(30)

Struktur dokumen kebutuhan

Chapter Description System

requirements specification

This should describe the functional and nonfunctional requirements in more detail.

If necessary, further detail may also be added to the nonfunctional requirements.

Interfaces to other systems may be defined.

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.

(31)

Spesifikasi Kebutuhan

(32)

Spesifikasi kebutuhan

 Merupakan proses menuliskan kebutuhan pengguna dan sistem ke dalam dokumen kebutuhan.

 Kebutuhan pengguna harus dapat dimengerti pengguna dan pelanggan yang tidak memiliki latar belakang

teknis.

 Kebutuhan sistem dibuat lebih rinci dan mungkin mencakup informasi yang lebih teknis.

 Kebutuhan bisa menjadi bagian kontrak pengembangan sistem

 Oleh karena itu, penting untuk membuatnya selengkap mungkin.

(33)

Kebutuhan dan Perancangan

 Pada prinsipnya, kebutuhan menjelaskan apa yang dilakukan sistem sedangkan desain menjelaskan bagaimana sistem melakukannya.

 Pada prakteknya, kebutuhan dan desain tidak dapat dipisahkan

 Arsitektur sistem dirancang untuk menyusun kebutuhan;

 Sistem dapat beroperasi dengan sistem lain sehingga menghasilkan kebutuhan baru;

 Penggunaan arsitektur khusus untuk memenuhi kebutuhan non-fungsional bisa jadi merupakan kebutuhan domain

(34)

Cara menuliskan spesifikasi kebutuhan 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 don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract

(35)

Spesifikasi bahasa alamiah

 Kebutuhan dapat dituliskan menjadi kalimat

bahasa alami yang dilengkapi dengan diagram dan tabel.

 Digunakan untuk menuliskan kebutuhan karena ekspresif, intutitif dan globalsehingga kebutuhan dapat dimengerti pengguna dan pelanggan.

(36)

Petunjuk penulisan kebutuhan

 Buat format standar dan gunakan untuk semua kebutuhan.

 Gunakan bahasa secara konsisten.

 Gunakan highlight untuk mengidentifikasi bagian penting kebutuhan.

 Hindari penggunaan jargon komputer.

 Beri penjelasan mengapa kebutuhan tersebut penting.

(37)

Masalah penggunaan bahasa alami

 Kurang jelas

 Ketepatan sulit diperoleh tanpa membuat dokumen sulit dibaca.

 Kekacauan kebutuhan

 Kebutuhan fungsional dan non-fungsional sering bercampur.

 Penggabungan kebutuhan

 Beberapa kebutuhan yang berbeda mungkin diekspresikan bersama-sama.

(38)

Contoh kebutuhan dengan bahasa alami untuk sistem pompa insulin

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.)

(39)

Spesifikasi terstruktur

 Kebutuhan dituliskan dengan cara standar.

 Baik untuk beberapa jenis kebutuhan, tapi kaku untuk jenis kebutuhan lainnya.

(40)

Spesifikasi berbasis formulir

 Definisi fungsi atau entitas

 Deskripsi input dan asalnya

 Deskripsi output dan tujuannya

 Informasi kebutuhan komputasi dan entitas lain yang digunakan

 Deskripsi aksi yang diambil

 Kondisi awal dan akhir

 Efek samping suatu fungsi

(41)

Spesifikasi terstruktur kebutuhan pompa

insulin

(42)

Spesifikasi berbentuk tabel

 Digunakan sebagai tambahan bahasa alamiah.

 Sangat penting ketika harus menentukan sejumlah aksi alternatif.

 Contoh : komputasi sistem pompa insulin

berdasarkan perubahan level gula darah dan tabel menjelaskan bagaimana menghitung kebutuhan insulin untuk skenario yang berbeda.

(43)

Tabel spesifikasi komputasi pompa insulin

Condition Action

Sugar level falling (r2 < r1) CompDose = 0 Sugar level stable (r2 = r1) CompDose = 0 Sugar level increasing and rate of

increase decreasing

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

CompDose = 0

Sugar level increasing and rate of increase stable or increasing ((r2 – r1) ≥ (r1 – r0))

CompDose =

round ((r2 – r1)/4) If rounded result = 0 then

CompDose =

MinimumDose

(44)

Proses Rekayasa Kebutuhan

(45)

Proses Rekayasa Kebutuhan

 Proses yang digunakan untuk rekayasa kebutuhan sangat bervariasi tergantung pada domain aplikasi, orang yang terlibat dan organisasi yang

mengembangkan kebutuhan.

 Namun, ada sejumlah aktivitas umum yaitu:

 Pemunculan kebutuhan;

 Analisa kebutuhan;

 Validasi kebutuhan;

 Manajemen kebutuhan.

 Rekayasa kebutuhan adalah aktivitas iteratif yang saling terkait.

(46)

Proses rekayasa kebutuhan bentuk spiral

(47)

Pemunculan dan analisa kebutuhan

 Disebut pemunculan kebutuhan atau penemuan kebutuhan.

 Melibatkan staf teknis yang bekerja bersama pelanggan untuk menemukan domain aplikasi, layanan yang harus disediakan sistem dan batasan operasionalnya.

 Mungkin melibatkan pengguna, manaher, insinyur yang terlibat perawatan sistem, ahli, organisasi buruh, dll

yang biasanya disebut stakeholder

(48)

Proses pemunculan dan analisa

kebutuhan

(49)

Aktivitas proses

 Penemuan kebutuhan

 Berinteraksi dengan stakeholder untuk menemukan kebutuhan mereka. Kebutuhan domain juga ditemukan pada tahap ini.

 Klasifikasi dan penyusunan kebutuhan

 Mengelompokkan kebutuhan yang terkait dan menyusunnya ke dalam kluster yang koheren.

 Penyusunan prioritas dan negosiasi

 Menyusun prioritas kebutuhan dan menyelesaikan konflik kebutuhan.

 Spesifikasi kebutuhan

 Mendokumentasikan kebutuhan dan memasukkannya ke tahap spiral selanjutnya.

(50)

Masalah pada pemunculan kebutuhan

 Stakeholder tidak tahu apa yang sebenarnya diinginkan.

 Stakeholder mengekspresikan kebutuhannya dengan istilah mereka yang tidak dimengerti pengembang.

 Stakeholder yang berbeda bisa mengalami konflik kebutuhan.

 Faktor organisasi dan politik mempengaruhi kebutuhan sistem.

 Kebutuhan berubah selama proses analisa. Stakeholder baru muncul dan lingkungan bisnis berubah.

(51)

Penemuan Kebutuhan

(52)

Penemuan Kebutuhan

 Proses pengumpulan informasi tentang sistem ang ada dan yang dibutuhkan serta pemilihan

kebutuhan pengguna dan sistem dari informasi tersebut.

 Interaksi dengan stakeholder mulai dari manajer hingga regulator eksternal.

(53)

Stakeholder sistem manajemen pasien RSJ

 Pasien yang informasinya disimpan dalam sistem.

 Dokter yang bertanggung jawab memeriksa dan merawat pasien.

 Pereawat yang mengatur konsultasi dan memberikan sejumlah perawatan.

 Resepsionis yang mengelola janji konsultasi pasien.

 Staf IT yang bertanggung jawab menginstall dan merawat pasien.

(54)

Proses penemuan kebutuhan

 Wawancara

 Skenario

 Kasus penggunaan

 Etnografi

(55)

Wawancara

 Wawancara formal dan informal dengan

stakeholder merupakan bagian penting dalam proses rekayasa kebutuhan.

 Jenis wawancara

 Wawancara tertutup berdasarkan daftar pertanyaan

 Wawancara terbuka dimana berbagai masalah didapatkan dari stakeholder.

 Wawancara efektif

 Berpikiran terbuka, hindari membuat asumsi awal dan dengarkan stakeholder.

 Dorong orang yang diwawancara untuk berdiskusi

(56)

Praktek wawancara

 Biasanya campuran antara wawancara terbuka dan tertutup.

 Wawancara baik untuk memahami apa yang dilakukan dtakeholder dan bagaimana mereka akan berinteraksi dengan sistem.

 Wawancara tidak baik untuk memahami kebutuhan domain

 Pengembang tidak memahami terminologi domain tertentu;

(57)

Skenario

 Skenario adalah contoh nyata bagaimana sistem digunakan.

 Skenario mencakup

 Deskripsi situasi awal;

 Deskripsi aliran kejadian normal;

 Deskripsi kesalahan yang mungkin terjadi;

 Informasi aktivitas selanjutnya;

 Deskripsi kondisi ketika skenario selesai.

(58)

Skenario pengumpulan catatan medis

pasien RSJ

(59)

Kasus Penggunaan (Use Case)

 Kasus penggunaan merupakan teknik bernasis skenario pada UML yang mengidentifikasi aktor dan interaksi dalam sistem.

 Sejumlah kasus penggunaan harus

mendeskripsikan semua interaksi yang munkin dalam sistem.

 Diagram sekuens dapat digunakan untuk memperinci kasus penggunaan dengan

menunjukkan urutan kejadian dalam sistem.

(60)

Kasus penggunaan sistem manajemen

pasien RSJ

(61)

Etnografi

 Ilmuwan sosial mengamati dan menganalisa bagaimana orang bekerja, sehingga mereka tidak perlu

menjelaskan pekerjaannya

 Faktor organisasi dan sosial penting mungkin diamati

(62)

Ruang lingkup etnografi

 Kebutuhan didapatkan dengan mengamati bagaimana orang bekerja, bukan bagaimana seharusnya mereka bekerja.

 Kebutuhan didapatkand ari kerjasama dan kesadaran akan aktivitas orang lain.

 Etnografi efektif untuk memahami proses yang ada, bukan untuk mengidentifikasi fitur baru yang harus ditambahkan ke dalam sistem.

(63)

Etnografi dan prototipe untuk analisa

kebutuhan

(64)

Validasi kebutuhan

 Bertujuan untuk menunjukkan bahwa kebutuhan sesuai dengan yang diinginkan pelanggan.

 Biaya kesalahan definisi kebutuhan sangat tinggi sehingga validasi sangat penting

 Memperbaiki kesalahan kebutuhan setelah

penggunaan sistem membutuhkan biaya hingga 100 kali memperbaiki kesalahan implementasi.

(65)

Pemeriksaan kebutuhan

 Kebenaran. Apakah sistem menyediakan fungsi yang dibutuhkan pelanggan?

 Konsistensi. Apakah ada konflik kebutuhan?

 Kelengkapan. Apakah semua fungsi yang dibutuhkan pelanggan tersedia?

 Realisme. Dapatkah kebutuhan diimplementasikan dengan anggaran dan teknologi yang ada?

 Verifikasi. Dapatkah kebutuhan diperiksa?

(66)

Manajemen Kebutuhan

 Manajemen kebutuhan adalah proses pengelolaan perubahan kebutuhan selama proses rekayasa

kebutuhan dan pengembangan sistem.

 Kebutuhan baru muncul saat sistem dikembangkan dan setelah digunakan.

 Anda perlu melacak kebutuhan dan merawat

hubungan antara kebutuhan yang saling tergantung satu sama lain sehingga bisa menilai efek

perubahan kebutuhan.

(67)

Perubahan Kebutuhan

 Lingkungan bisnis dan teknis berubah setelah proses instalasi.

 Adanya perangkat lunak baru atau perubahan

prioritas bisnis dapat mengubah kebutuhan sistem.

 Orang yang membayar pengembangan sistem dan pengguna sistem biasanya berbeda.

 Pelanggan menentukan kebutuhan karena batasan anggaran dan organisasi yang mungkin bertentangan dengan kebutuhan pengguna, sehingga setelah

digunakan perlu menambahkan fitur baru sehingga sistem sesuai dengan tujuannya.

(68)

Perubahan Kebutuhan (2)

 Sistem yang besar biasanya memiliki pengguna yang bermacam-macam, dengan kebutuhan yang berbeda dan prioritas kebutuhan dapat

menimbulkan pertentangan.

 Kebutuhan akhir harus merupakan kompromo antar pengguna.

(69)

Evolusi kebutuhan

(70)

Manajemen perubahan kebutuhan

 Analisa masalah dan spesifikasi perubahan

 Pada tahap ini, masalah atau perubahan dianalisa untuk memeriksa apakah sudah sesuai. Hasilnya bisa berupa perubahan kebutuhan atau penolakan permintaan

perubahan.

 Analisa dan pembiayaan perubahan

 Perubahan dianalisa dan biaya perubahan kebutuhan dihitung untuk menentukan apakah akan memproses perubahan kebutuhan atau tidak.

 Implementasi perubahan

 Modifikasi dokumen kebutuhan, desain sistem dan implementasi. Idealnya, dokumen diorganisir kembali sehingga perubahan dapat diimplementasikan dengan mudah.

(71)

Manajemen perubahan kebutuhan

(72)

Referensi

 Sommerville, I., Software Engineering 8th edition, Addison-Wesley, 2007