3. Analysis Concepts and Principles

Overview

•After system engineering is completed, software engineers need to look at the role of software in the proposed system.
•Software requirements analysis is necessary to avoid creating a software product that fails to meet the customer’s needs.
•Data, functional, and behavioral requirements are elicited from the customer and refined to create a specification that can be used to design the system.
•Software requirements work products must be reviewed for clarity, completeness, and consistency
Requirements Analysis
•Software engineering task that bridges the gap between system level requirements engineering and software design
•Provides software designer with a representation of system information, function, and behavior that can be translated to data, architectural, and component-level designs.
•Expect to do a little bit of design during analysis and a little bit of analysis during design
Software Requirements Analysis Phases (analisis persyaratan)
• Problem recognition
• Evaluation and synthesis (focus is on   what not how)
• Modeling (data flow and control)
• Specification (inherent from modelling)
• Review
Communication Technic
•Analisis persyaratan PL selalu dimulai dengan komunikasi antara 2 bagian atau lebih
•Seorang pelanggan memiliki masalah yang dapat dipertanggungjawabkan melalui pemecahan berbasis komputer
•Pengembang merespon masalah dari pelanggan
•Komunikasi dimulai
1. Mengawali proses
•Teknik analisis yang paling umum digunakan untuk menjembatani jurang komunikasi antara pelanggan dan pengembang-> pertemuan/wawancara
•Biasanya kedua pihak ini tidak tahu harus mulai dari mana, keduanya ingin pertemuan itu segera berakhir dan pada saat yang sama keduanya ingin berhasil
Pertanyaan2 yang biasa ditanyakan seorang analis
•Siapa dibalik permintaan untuk pekerjaan ini?
•Siapa yang akan menggunakan pemecahan ini?
•Apa keuntungan ekonomi dari pemecahan yang berhasil?
•Apakah ada sumber lain untuk pemecahan yang anda inginkan?

Pertanyaan lanjutan yang bisa ditanyakan?

•Bagaimana anda akan menandai output yang baik yang akan didapatkan oleh pemecahan yang berhasil?
•Masalah apakah yang akan diselesaikan oleh pemecahan ini?
•Dapatkah anda memperlihatkna kepada saya (atau menjelaskan) lingkungan dimana pemecahan tersebut akan digunakan?
•Adakah masalah / batasan kinerja yang khusus yang akan mempengaruhi cara pemecahan tersebut?
2.Facilitated Action Specification Techniques (FAST)
•Meeting held at neutral site, attended by both software engineers and customers
•Rules established for preparation and participation
•Agenda suggested to cover important points and to allow brainstorming
•Meeting controlled by facilitator (customer, developer, or outsider)
•Definition mechanism (flip charts, stickers, electronic device, etc) is used
•Goal is to identify problem, propose elements of solution, negotiate different approaches, and specify a preliminary set of solution requirements
3. Quality Function Deployment (QFD) (penyebaran fungsi kualitas)
-Adalah teknik manajemen kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi PL

QFD mengidentifikasi 3 tipe persyaratan:

•Persyaratan normal: sasaran dan tujuan dinyatakan bagi sebuah produk/sistem selama pertemuan dengan pelanggga. Contoh: tipe tampilan grafis yang diminta, fungsi sistem spesifik, dan tingkat kinerja yang didefinisikan
•Persyaratan yang diharapkan: persyaratan ini implisit terhadap produk/sistem dan sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Contoh: reabilitas dan kebenaran operasional keseluruhan, mudahnya instalasi PL dll
•Exciting requirement: persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan. Contoh: PL pengolah kata dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang bagus dan tidak terduga.
Use-Cases
•Scenarios that describe how the product will be used in specific situations
•Written narratives that describe the role of an actor (user or device) as interaction with the system occurs
•Use-cases are designed from the actor’s point of view
•Not all actors can be identified during the first iteration of requirements elicitation, but it is important to identify the primary actors before developing the use-cases
Analysis Principles
•The information domain of the problem must be represented and understood
•The functions that the software performs must be defined
•Software behavior must be represented
•Modles depicting information, function, and behavior must be partitioned in a hierarchical manner that uncovers detail
•The analysis process should move from the essential information toward implementation detail
Iklan

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s