Requirement Enginering

35
Requirement Enginering Firdaus, M.T.

description

Requirement Enginering. Firdaus , M.T. TIK. Mahasiswa dapat : Memahami metode requirement dalam merencanakan sistem. Bagian yang tersulit dari pembuatan sotftware adalah memutuskan apa yang akan di buat [Fred Brooks] . - PowerPoint PPT Presentation

Transcript of Requirement Enginering

Page 1: Requirement  Enginering

Requirement Enginering

Firdaus, M.T.

Page 2: Requirement  Enginering

TIK

Mahasiswa dapat :• Memahami metode requirement dalam

merencanakan sistem

Page 3: Requirement  Enginering

Bagian yang tersulit dari pembuatan sotftware adalah memutuskan apa yang akan di buat

[Fred Brooks]

Page 4: Requirement  Enginering

• Antara 40% - 60% dari kegagalan dan kerusakan software disebabkan karena lemahnya manajemen software dan mendifinisikan permintaan

Page 5: Requirement  Enginering

Salah satu isu terbesar adalah waktu yang dimiliki untuk menuliskan requirement. Terkadang ketika deadline waktu sangat sempit, developer software mungkin memulai sebelum requirement dilengkapi, dan ini akan menyebakan banyak masalah di kemudian hari

Page 6: Requirement  Enginering

• Requirement Engineering menyediakan mekanisme yang tepat untuk memahami yang diinginkan pengguna, analisa kebutuhan, menaksir kemungkinan, negosiasi solusi yang layak, menspesifikasikan solusi yang tidak ambigu, memvalidasi spesifikasi, memenej requirement.

Page 7: Requirement  Enginering

Tehnik Investigasi Requirement

• Interview bertanya langung kepada user• Workshop Diskusi forum• Observasi Melihat langsung ke lapangan

Page 8: Requirement  Enginering

Tugas Requirement Enginering

Page 9: Requirement  Enginering

Inception (Pendahuluan)• Pada tahap ini, perekayasa sistem informasi

menanyakan pertanyaan bebas.• Menetapkan permasalahan dasar dari masalah• Menentukan orang yang menginginkan solusi• Menentukan Sifat dasar solusi yang di inginkan• Ke efektifan komunikasi dan kolaborasi

pendahuluan antara pelanggan dan pengembang

Page 10: Requirement  Enginering

Elicitation (Pemunculan)

• Bagaimana sistem/produk sesuai dengan kebutuhan bisnis

• Bagaimana sistem digunakan

• Permasalahan elicitation– Permasalahan scope– Permasalahan Pengertian

Page 11: Requirement  Enginering

Elaboration

• Informasi yang diperoleh dari konsumen/pengguna selama proses inception dan elicitation diperluas dan disharing selama elaborasi

• Elaborasi adalah tahapan awal analisa model• Hasil : informasi, fungsi dan kebiasaan

Page 12: Requirement  Enginering

Negotiation

• Negosiasi konflik– Scope kerja– Prioritas– Pengukuran kepuasan

• Bagaimana mengerjakan ini?– Definisikan prioritas!

Page 13: Requirement  Enginering

Specification

• Spesifikasi adalah produk final dari requirement

• Spesifikasi dapat berupa:– Dokumen tulisan Written document– Model grafis Graphical model– Model matematika Math model– Koleksi skenario penggunaan– Prototype

Page 14: Requirement  Enginering

Validation

• Validasi requirement menguji spesifikasi untuk menjamin bahwa requirement software telah dipertimbangkan

• Mekanisme validasi requiremen adalah dengan me-review teknis formal

Page 15: Requirement  Enginering

Step by Step Process

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

Req

uire

men

t M

anag

emen

t

Page 16: Requirement  Enginering

Proses Requirement Engineering a. Identifikasi Stakeholder

• Stakeholder adalah siapapun yang memperoleh keuntungan dari sistem yang dikembangkan, seperti manajer bisnis operasi, manajer produk, pelanggan, dll

• Setiap stakeholder memiliki perbedaan pandangan terhadap sistem dan memiliki keuntungan yang berbeda

• Pada tahap inception, perekayasa sistem harus membuat daftar stakeholder

Page 17: Requirement  Enginering

Proses Requirement Engineering b. menghargai beragam sudut pandang

• Setiap stakeholder akan mengeksplor beragam sudut pandang

• Requirement yang muncul mungkin menjadi tidak konsisten atau mungkin bertentangan satu dengan yang lainnya.

• Tugas seorang perekayasa adalah mengkategorikan seluruh informasi dari stakeholer, termasuk ketidak konsistenan dan pertentangan

Page 18: Requirement  Enginering

Proses Requirement Engineering c. Bekerja Menuju Kolaborasi

• The job of requirement engineer is to identify areas of commonality and area of conflict or inconsistent.

• In many cases, stakeholders collaborate to make final decision about which requirements make the cut.

Page 19: Requirement  Enginering

Proses Requirement Engineering d. Asking the First Questions (1 of 3)

To know, who will have interest in the software to be built?

• Who is behind the request for this work?• Who will use the solution?• What will be the economic benefit of a

successful solution?• Is there another source for the solution

that you need?

Page 20: Requirement  Enginering

Proses Requirement Engineering e. Asking the First Questions (2 of 3)

• To gain a better understanding

• How would you characterize “good” output that would be generated by a successful solution?

• What problems will this solution address?• Can you show me the business

environment in which the solution be used?

Page 21: Requirement  Enginering

Proses Requirement Engineering f. Asking the First Questions (3 of 3)

To know the effectiveness of the communication activity itself

• Are you the right person to answer these question?

• Are your answer official?• Are my question relevant to the problem

that you have?

Page 22: Requirement  Enginering

Step by Step Process

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

Req

uire

men

t M

anag

emen

t

Page 23: Requirement  Enginering

Proses Requirement Engineering a. Eliciting Requirements

• QFD (Quality Function Deployment) is a technique that translates the needs of the customer into technical requirements for software.

• Three types of QFD requirement– Normal requirements– Expected requirements (ex: HMI)– Exciting requirements

Page 24: Requirement  Enginering

Proses Requirement Engineering b. Eliciting Requirements

Page 25: Requirement  Enginering

Proses Requirement Engineering c. Developing Use-Cases (1)

• Who is the primary actor(s), the secondary actor(s)?• What are the actor’s goals?• What preconditions should exist before the story begins?• What main tasks of functions are performed by the actor?• What expectations might be considered as the story is

described?• What variation in the actor’s interaction are possible?• What ………………..

[refer to chapter 7 …]

Page 26: Requirement  Enginering

Proses Requirement Engineering d. Developing Use-Cases (2)

• In this case, there are three actors: homeowner, configuration manager, sensors and monitoring sub system (sensors).

Page 27: Requirement  Enginering

Proses Requirement Engineering e. Developing Use-Cases (3)

Page 28: Requirement  Enginering

Proses Requirement Engineering e. Developing Use-Cases (3)

Actor

Actor

Actor

Use Case

Use Case

Use Case

Use Case

Use Case

SystemBoundary

Page 29: Requirement  Enginering

Step by Step Process

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

Req

uire

men

t M

anag

emen

t

Page 30: Requirement  Enginering

Proses Requirement Engineering a. Building ‘early’ Analysis Model

UML Class Diagram UML State Diagram

Classname

Classattribu

-tes

Classmethod

s

Page 31: Requirement  Enginering

Step by Step Process

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

Req

uire

men

t M

anag

emen

t

Page 32: Requirement  Enginering

Proses Requirement Engineering 7. Negotiating Requirements

• It is natural, the developer and customer enter into process of negotiation

• The best negotiation strive for a “win-win” result

Page 33: Requirement  Enginering

Step by Step Process

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

Req

uire

men

t M

anag

emen

t

Page 34: Requirement  Enginering

Proses Requirement Engineering a. Validating Requirement

• Is each requirement consistent with overall objective for the system/product?

• Have all requirements been specified at the proper level of abstraction?

• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

• ……….. [refer to chapter 7, page 203-204]

Page 35: Requirement  Enginering

Final Results

• The hardest single part of building a software is deciding what to build ….

• Requirement Engineering Steps: (1) Inception, (2) Elicitation, (3) Elaboration, (4) Negotiation, (5) Specification, and (6) Validation

• Requirement engineering should be supported by Requirement Management

• Unsolved problem in requirement engineering will cause problem in next engineering process, and will be very costly