Requirements Engineering

Nama : Fachry Frisandi NIM

: 13507027

Review Chapter 1 Requirements Engineering Pada jaman sekarang, teknologi berkembang dengan pesat dan kompetisi pun kian meningkat. Hal tersebut menimbulkan tekanan pada proses pengembangan atau development suatu proyek. Terdapat 3 Faktor yang mempengaruhi trend tersebut, yakni : 1) Arbitrary complexity (Kompleksitas yang bersifat subyektif) karena kompleksitas suatu produk hanya dibatasi oleh yang mengembangkan produk tersebut dan kompleksitas tersebut terintegrasi dengan komponen-komponen yang berada di dalam sistem tersebut. 2) Instant distribution (Distribusi dalam waktu singkat) yang diakibatkan dengan adanya teknologi yang memudahkan distribusi suatu software. 3) “Off-the-Shelf” components ,yang berarti bahwa sistem dibangun dengan teknologi yang dibeli (bought-in technology) dan komponen-komponen siap pakai (ready-made components). Hal tersebut berdampak pada tekanan untuk mengurangi siklus pengembangan (development cycle) dan waktu untuk mempersiapkan penggunaan sistem tersebut. Namun, sasaran dalam suatu pengembangan sistem atau produk adalah untuk menentukan waktu yang tepat untuk menjual ke pasar dengan produk yang tepat (time to market with the right product), bukan hanya menentukan waktu yang tepat. Dengan menyatakan dan menganalisis requirements (kebutuhan) maka hal tersebut dapat memvisualisasikan suatu produk yang benar (right product) untuk dipasarkan. Peran penting suatu rekayasa kebutuhan (requirements engineering) adalah untuk mendefinisikan ruang lingkup suatu permasalahan dan menghubungkan semua informasi yang berkaitan dengan definisi permasalahan tersebut. Pada dasarnya, requirements merupakan dasar dari setiap proyek dan berfungsi untuk mendefinisikan kebutuhan para pemangku kepentingan dari suatu sistem baru potensial dan apa yang sistem tersebut harus lakukan untuk memenuhi kebutuhan tersebut. Kebutuhan (requirements) mengatur atau menentukan aktivitas dari suatu proyek. Requirements diperlukan untuk menentukan goal atau tujuan akhir dari suatu proyek. Requirements juga memungkinkan manajemen resiko dari tahap awal pengembangan suatu proyek. Dengan dinyatakannya kebutuhan, resiko dapat diperkirakan dan dampak dari resiko tersebut dapat diprediksi. Requirements membentuk basis untuk :

• • • • •

Project Planning Risk Management Acceptance Test Tradeoff Change control

Pendefinisian serta organisasi kebutuhan yang tidak baik seringkali menjadi salah satu faktor dalam kegagalan suatu proyek. 2 Faktor lainnya yang sering menjadi penyebab kegagalan suatu proyek adalah permasalahan manajemen sumber daya dan masalah politik. Kebutuhan (requirements), dari stakeholder requirements hingga system requirements, merupakan hal yang penting untuk diperhatikan dalam pengembangan suatu sistem, karena dapat digunakan untuk mengukur kemajuan (progress) suatu proyek dan memeriksa resiko yang mungkin muncul di dalam pengembangan suatu proyek.

Introduction to System Engineering Kebanyakan kebutuhan dipenuhi oleh properti-properti yang muncul dari perilaku sistem secara keseluruhan. Definisi suatu sistem itu sendiri adalah : • • •

Koleksi dari komponen – mesin, software, dan manusia – Yang bekerja sama dalam cara yang terorganisir Untuk mencapai sebuah hasil yang diharapkan – requirements

Secara umum, kegunaan suatu sistem dapat tergambar dengan cara komponenkomponen sistem tersebut berinteraksi. Konsep yang penting dalam pendefinisian suatu sistem adalah system of system , yakni setiap sistem dapat dipersepsikan sebagai bagian dari sistem yang lebih besar dan juga sistem yang berada di sekitarnya. Sehingga untuk mengerti kebutuhan dari suatu sistem secara tepat, kita harus mengerti hal-hal yang mengelilingi sistem tersebut (environment). Kemampuan dari sebuah sistem untuk memenuhi tujuannya bergantung pada : • • • •

Properti – properti yang muncul dari interaksi antar komponen-komponen dari sistem tersebut Antarmuka (interfaces) yang tepat untuk komponen – komponen eksternal Penggabungan yang tepat dengan sistem-sistem yang mengelilinginya Kehadiran lingkungan (environment) yang tepat

Requirements and Quality Kualitas didefinisikan sebagai kesesuaian sesuatu terhadap tujuannya atau “fitness for purpose”. Sehingga kualitas suatu produk ditentukan dengan kemampuan produk tersebut dalam memenuhi tujuan dibuatnya produk tersebut. Sebagai contoh, mobil yang memiliki kualitas yang baik bukanlah hanya mobil-mobil yang mahal seperti Jaguar, BMW dan seterusnya, akan tetapi harus dilihat dari konteks tujuan mobil tersebut dibuat. Mobil-mobil mewah seperti itu mempunyai kualitas yang tinggi untuk menunjang penampilan bagi pemakainya namun mempunyai kualitas yang buruk dalam balapan di medan yang berat. Begitu pun halnya dengan suatu sistem, kualitas suatu sistem diukur berdasarkan kesesuaiannya dengan tujuan dibentuknya sistem tersebut yaitu pemenuhan kebutuhan (requirements). Dari pengertian tersebut, dapat kita simpulkan, untuk meningkatkan kualitas suatu sistem atau produk, kita terlebih dahulu harus meningkatkan kualitas pendefinisian kebutuhan dari sistem atau produk tersebut.

Requirements and the lifecycle Requirements engineering mempunyai peranan yang penting dalam setiap tahap pengembangan suatu sistem, tidak hanya pada tahap awal pengembangan suatu sistem. Suatu sistem pada akhirnya akan dihadapkan pada acceptance test, yakni sebuah test untuk menilai apakah sebuah sistem sudah memenuhi kebutuhan dari para pemegang kepentingan. Sehingga dapat kita simpulkan, kebutuhan yang didefinisikan pada tahap awal pengembangan tetap digunakan hingga tahap akhir dari pengembangan suatu sistem. Model klasik V-Model seperti digambarkan dibawah memberikan gambaran mengenai tahap-tahap dalam pengembangan dan hubungan antara testing dan requirements pada setiap tahap.

Requirements bertindak sebagai suatu cara untuk berkomunikasi diantara proyek-proyek. Requirements sebagai bentuk komunikasi ini merupakan suatu pendekatan yang baik, karena hal tersebut memaksimalkan kemampuan penggunaan kembali (reusable) dari komponen-komponen sistem lain yang telah dikembangkan terlebih dahulu, kemudahan mengatur kumpulan produk – produk yang serupa, memungkinkan organisasi untuk menggunakan manajemen program untuk mengkoordinasikan aktivitas-aktivitas dan mengoptimasi proses dengan belajar dari pengalaman proyek-proyek sebelumnya. Kumpulan requirements dari para stakeholder (pemangku kepentingan) memberikan gambaran yang singkat dan deskripsi non-technical mengenai apa yang sedang dikembangkan oleh suatu sistem kepada para senior management. Sedangkan, system requirements memberikan ringkasan mengenai hal-hal teknis tentang proyek yang sedang dikembangkan. Deskripsi ini dapat menyediakan basis atau landasan dalam membandingkan suatu proyek dengan proyek yang lain. Hal ini digambarkan pada gambar dibawah

Requirements berhubungan erat dengan manajemen perubahan (change management). Dampak dari perubahan kualitas, biaya serta schedule perlu untuk diperhatikan dan diperiksa. Pemeriksaan ini menjadi basis untuk : • • •

Menerima atau menolak suatu perubahan Menegosiasikan biaya dari suatu perubahan Mengorganisasikan pekerjaan pengembangan kembali (Redevelopment)

Dari gambar diatas, dapat terlihat bahwa change management merupakan suatu bagian dari requirements engineering. Konsep utama yang memungkinkan analisa dampak dari suatu perubahan adalah dengan requirements traceability. Terlepas dari change management, kemampuan manajer untuk mengontrol suatu proyek dapat ditingkatkan dengan requirements engineering yang baik. Tanpa adanya pendefinisian kebutuhan, project manager tidak akan mengetahui perkembangan dari suatu proyek atau apakah proyek sudah berjalan di arah yang tepat. Kesimpulannya, requirements dibutuhkan merupakan sesuatu yang essensial bagi pengembangan suatu sistem.

Requirements Traceability Tracebility berbicara mengenai bagaimana requirements pada tahap yang lebih tinggi (high-level requirements) di transformasikan menjadi requirements pada

tahap yang lebih rendah (low-level requirements). Traceability memungkinkan suatu proyek untuk diikuti perkembangannya. Terdapat 3 tipe traceability analysis : 1) Impact analysis, yang digunakan untuk menentukan dampak yang dirasakan suatu obyek apabila obyek lain berubah 2) Derivation analysis, digunakan untuk menelusuri obyek pada level tinggi yang menimbulkan adanya obyek pada level yang lebih rendah. 3) Coverage analysis, digunakan untuk menelusuri apakah semua requirements sudah dipenuhi baik pada obyek yang lebih rendah maupun pada tahap testing.

Requirements and Modelling Penting untuk mengetahui hubungan antara pemodelan dan requirements . Kedua hal tersebut saling menunjang dalam proses pengembangan suatu sistem. Hubungan antara kedua hal tersebut dapat diibaratkan sebagai sandwich (roti isi) yang mempunyai banyak lapisan dan diantara lapisan-lapisan tersebut terdapat isi. Apabila dianalogikan menggunakan roti isi, pemodelan merupakan “isi” diantara lapisan-lapisan sandwich sedangkan requirements adalah lapisanlapisan roti. Dalam pengembangan suatu sistem, pemodelan suatu sistem berperan dalam menjelaskan dan menjabarkan analisis dan design yang mengantarkan pada layer requirements yang berikutnya.

Requirements and Testing Pengetesan (testing) adalah suatu bagian yang sangat berkaitan dengan requirements pada setiap level. Aktivitas pengetesan meliputi review, inspeksi, analisis melalui model sebagai tambahan dari test yang dilakukan pada komponen, sub sistem dan sistem. Pada proses pengembangan, kualifikasi diperkenalkan pada tahap awal dari sebuah sistem karena apabila kualifikasi dari sebuah sistem diperkenalkan pada tahap akhir maka biaya untuk perbaikan akan sangat besar. Oleh karena itu, strategi kualifikasi diperlukan untuk memastikan kualifikasi-kualifikasi tertentu terdapat pada tahap – tahap dari perancangan suatu sistem. Strategi kualifikasi dapat digambarkan dengan menggunakan VModel seperti berikut

Requirements in the Problem and Solution Domain System engineering berfokus pada pengembangan dan pengaturan solusi yang efektif terhadap permasalahan. Agar tujuan tersebut dapat dicapai, harus terdapat pembedaan yang jelas antara domain permasalahan dan domain solusi. Tahap pada pengembangan sistem yang meliputi deskripsi sistem secara umum, seperi stakeholder requirements, harus diletakkan pada domain permasalahan. Sedangkan tahap-tahap berikutnya, yakni dimulai dengan system requirements harus diletakkan pada domain solusi permasalahan. Pemodelan dalam hal ini berperan dalam menentukan layer selanjutnya dari requirements sistem dan cenderung untuk mempertimbangkan solusi yang terbaik, walaupun dalam level yang masih tinggi. Untuk menghindari distorsi solusi dari sebuah permasalahan, maka sebaiknya pada tahap awal pemodelan suatu sistem memperhatikan sistem yang mengelilinginya (enclosing system).

Review Chapter 2 – A Generic Process for Requirements Engineering Sebelum sebuah sistem dikembangkan, hal yang penting untuk dilakukan adalah mendefinisikan kebutuhan dari sebuah sistem. Statement kebutuhan dari sebuah sistem diperlukan sebagai guideline dari pengembangan suatu sistem, agar ketika sistem tersebut telah dikembangkan mampu menjawab kebutuhan dari para pemegang kepentingan (stakeholders). Proses pengembangan suatu sistem diinisiasi oleh pernyataan kebutuhan (statement of needs), yakni suatu pernyataan mengenai apa yang diharapkan dari sebuah sistem. Pernyataan kebutuhan tersebut dapat diekspresikan dengan pernyataan yang masih belum jelas. Peran requirements engineering disini adalah untuk mentransformasikan pernyataan kebutuhan yang masih belum jelas menjadi kumpulan requirements yang berasal dari proses pengembangan sistem. Proses pengembangan suatu sistem secara keseluruhan dapat terlihat pada diagram berikut.

Setelah melalui proses untuk mendapatkan stakeholder requirements, maka dimungkinkan untuk langsung berpikir mengenai solusi yang potensial dan mulai melakukan tahap design. Namun, akan lebih baik, apabila mendeskripsikan karakteristik apa saja yang harus muncul dari sistem tersebut. Proses ini disebut mendefinisikan system requirements. Apabila telah diperoleh system requirements, maka dimungkinkan untuk memikirkan mengenai alternatif dari arsitektur desain sebuah sistem. Arsitektur desain sistem digambarkan sebagai kumpulan komponen – komponen yang saling berinteraksi secara bersama-sama yang menghasilkan properti atau karakteristik yang diinginkan dari sebuah sistem. Properti yang muncul dari sebuah sistem harus sama dengan karakteristik yang diinginkan dari sebuah sistem yang dinyatakan dalam system requirements.

Dari diagram tersebut, penting untuk diketahui bahwa pada setiap level proses pengembangan sistem terdapat requirements, yaitu :

• • • • •

Needs statement Stakeholder requirements System requirements System component requirements Subsytem component requirements

Generic Process Context Pada setiap tahap terdapat derajat kesamaan yang signifikan untuk pekerjaan yang dilakukan. Proses yang hampir sama digunakan pada setiap tahap pengembangan sistem yaitu proses engineer requirements.

Input and Derived requirements

Requirements

Pada proses pengembangan, requirements yang diturunkan dari suatu proses akan menjadi input requirements bagi proses lainnya. Kesimpulannya adalah proses engineer requirements secara umum menerima masukan berupa input requirements dan menghasilkan derived requirements.

Acceptance criteria and qualification strategy Untuk mengerti secara menyeluruh tentang arti dari requirements dan pada akhirnya tercapai kesepakatan bahwa requirements menyediakan basis yang baik untuk pengembangan suatu sistem, perlu dipikirkan bagaimana suatu sistem yang telah diimplementasikan akan didemonstrasikan. Oleh sebab itu diperlukan strategi kualifikasi untuk menilai apakah sistem yang telah diimplementasikan dapat diterima oleh customer. Testing pada setiap tahap pengembangan merupakan salah satu metode strategi kualifikasi. Strategi kualifikasi yang lain meliputi percobaan (trials) , sertifikasi (certification), dan inspeksi (inspection). Proses engineer requirements secara umum digambarkan dengan diagram di bawah ini

Generic Process

Introduction

Ideal Development Suatu proses dimulai dengan kebutuhan yang perlu disetujui oleh customer pada level atas untuk menyetujui input informasi. Kemudian setelah input informasi disepakati, aktivitas selanjutnya adalah menganalisa input informasi dan memikirkan bagaimana untuk menghasilkan keluaran yang diinginkan. Aktivitas ini menghasilkan model dan laporan analisis, yang bersama-sama digunakan sebagai basis untuk penurunan requirements dan strategi kualifikasi.

Development in the context of change Pada kenyataan, persetujuan yang telah disepakati sebelumnya mungkin untuk berubah. Oleh sebab itu, untuk menangani perubahan tersebut proses secara umum yang sebelumnya perlu dimodifikasi untuk menangani perubahan yang terjadi selama proses pengembangan. Selama tahap awal, perubahan harus dapat ditangani dengan mudah sehingga pengembangan dapat terus berjalan. Namun, ada saatnya, perubahan tidak langsung diterima melainkan harus diajukan terlebih dahulu untuk kemudian di analisa dampaknya terhadap pengembangan yang sedang berlangsung. Proses engineer requirements pada konteks perubahan dapat terlihat dari diagram berikut.

Pada diagram terlihat bahwa perubahan hampir dapat terjadi pada setiap proses dan memiliki arah aliran keatas. Namun, hal tersebut tidak berarti bahwa perubahan hanya terjadi pada level rendah. Perubahan yang terjadi pada level yang lebih tinggi sudah ditangani pada aliran normal.

Generic Process Information Model Information Classes Tipe informasi yang ditemukan pada generic process context , diantaranya :

• • • • •

Input requirement Derived requirement Qualification strategy for Input requirements Qualification strategy for Derived requirements Change request

Keterkaitan serta hubungan antar informasi dapat digambarkan sebagai suatu model informasi.

Pada model informasi diatas dapat terlihat hubungan antar informasi. Sebagai contoh, hubungan antara Derived requirements dan Input requirements, Derived requirements memenuhi (satisfies) Input requirements. Tanda bintang pada model informasi menggambarkan hubungan many-to-many. Dari model

informasi tersebut, dapat disimpulkan pula bahwa perubahan pada permintaan akan berpengaruh pada seluruh informasi yang terdapat di dalam proses. Setiap kelas informasi memiliki atribut, diantaranya : •

• •

Agreement State, memiliki 2 nilai yakni (setuju) agreed dan (tidak setuju) not agreed . Pada tahap ini terdapat 2 aktor yang terlibat yakni customer dan supplier. Qualification State, memiliki 2 nilai yakni strategi kualifikasi disetujui dan tidak disetujui. Satisfaction State

Keadaan yang ideal untuk setiap requirements di setiap pengembangan sistem adalah : • • •

Kesepakatan antara customer dan supplier Mempunyai strategi kualifikasi yang disepakati Dipenuhi oleh requirements pada tahap yang lebih rendah