PEMODELAN ANALISIS

Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan yang

membawa kepada suatu spesifikasi lengkap dari persyaratan representasi dan representasi desain yang

komprehensip bagi perangkat lunak yang dibangun.

Elemen Model Analisis

Model analisis harus dapat mencapai tiga sasaran utama yakni untuk :

• Menggambarkan apa yang dibutuhkan untuk pelanggan

• Membangun dasar bagi pembuatan desain perangkat lunak

• Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.

Rekayasa Perangkat Lunak

Untuk mencapai sasaran tersebut dibuatlah model analisis yang berisi:

• Data Dictionary

Penyimpanan yang berisi deskripsi dari semua obyek data yang dikonsumsi atau diproduksi

oleh perangkat lunak.

• Entity Relationship Diagram (ERD)

Menggambarkan hubungan antara obyek data.

• Data Flow Diagram (DFD)

o Memberikan indikasi mengenai bagaiman data ditransformasi pada saat data bergerak

melalui sistem

o Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentransformasikan aliran data.

• State Transition Diagram

Menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal.

• Control Specification (CSPEC)

Informasi tambahan mengenai aspek kontrol dari perangkat lunak 

Pemodelan Data

Untuk dapat menjawab sebagai berikut :

• Bagaimana komposisi dari masing-masing obyek data dan atribut apa yang menggambarkab

obyek tersebut?

• Dimana obyek saat ini berada?

• Bagaimana hubungan antara masing-masing obyek data dan obyek lainnya?

• Bagaimana hubungan antara obyek dengan proses yang mentransformasikannya?

Digunakan Entity Relational Diagram (ERD)

Obyek Data, Atribut dan Hubungan

• Obyek Data

Adalah representasi dari hamper semua informasi gabungan yang harus dipahami oleh

perangkat lunak

 • Atribut

Menentukan property suatu obyek data dan mengambil salah satu dari tiga karakteristik yang

berbeda.

o Menamai sebuah contoh dari obyek data

o Menggambarkan contoh

o Membujat referensi ke contoh yang lain pada tabel yang lain.

• Hubungan

Obyek data disambungkan satu dengan lainnya dengan berbagai macam cara. 

Kardinalitas dan Modalitas

Kardinalitas

Model data harus dapat merepresentasikan jumlah peristiwa dari obyek di dalam hubungan yang

diberikan

o Satu ke satu (1:1) 

Misalnya: seorang suami hanya dapat memiliki satu istri, dan seorang istri hanya mempunyai

satu suami.

o Satu ke banyak (1:N)

Misalnya: seorang ibu dapat memiliki banyak anak, tetapi seorang anak hanya dapat memiliki

satu ibu.

o Banyak ke banyak (M:N)

Misalnya: seorang paman dapat memiliki banyak keponakan, sementara itu seorang keponakan

dapat memiliki banyak paman.

Modalitas

 Modalitas dari suatu hubungan adalah nol bila tidak ada kebutuhan eksplisit untuk hubungan yang

terjadi atau hubungan itu bersifat opsional. Modalitas bernilai satu jika suatu kejadian dari hubungan

merupakan perintah.

Entity Relational Diagram

Pada mulanya digunakan untuk desain sistem database relational dan telah dikembangkan oleh

yang lainnya. Serangkaian komponen utama diidentifikasikan untuk ERD: obyek data, atribut,

hubungan dan berbagai tipe indicator. Tujuan utama dari ERD adalah untuk mewakili obyek data dan

hubungan mereka.

Pemodelan Fungsional dan Aliran Informasi.

Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistem berbasis komputer.

Sistem tersebut menerima input dengan berbagai cara dan menghasilkan suatu output. Akibatnya kita

dapat menciptakan suatu model aliran bagi setiap sistem berbasis komputer tanpa melihat ukuran dan

kompleksitasnya.

Diagram Aliran Data/ Data Flow Diagram (DFD)

Merupakan sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang

diaplikasikan pada saat data bergerak dari input menjadi output.

 Dikenal juga dengan sebutan grafik aliran data atau buble chart.

Komponen-komponen DFD :

o Proses

o External entity

o Data Flow

o Data Store  

Proses

o Simbol proses adalah :  

o Proses menunjukkan apa yang dikerjakan oleh sistem

o Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol. 

File atau Data Store 

o Simbol : 

o File atau Data Store adalah tempat penyimpanan data

o Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store

o Setiap data store mempunyai nama yang unik

External Entity

External entity adalah di luar sistem, tetapi mereka merupakan salah satu bagian yang memberikan

input data ke dalam sistem atau digunakan oleh output sistem

Source : External entity yang memberikan input data ke dalam sistem

Sinks : External entity yang menggunakan data sistem

Data Flow

Simbol :    anak panah menunjukkan arah aliran

Aliran data pada sistem :

 antara dua proses

 dari sebuah data store ke sebuah proses

 dari sebuah proses ke sebuah data store

 dari sebuah source ke sebuah proses

 dari sebuah proses ke sebuah sink

Menggambarkan Sistem Dengan Dataflow Diagram 

Langkah awal adalah membuat “DIAGRAM KONTEKS”

Diagram konteks : DFD di mana sistem terdiri dari satu proses

Pada tahap ini terlihat semua external entity yang berinteraksi dengan sistem dan data flow, antara

external entity dan sistem

•  Budget monitoring system
• System berinteraksi dengan 3 external entity, yaitu :

1. DEPARTEMENTS
2.  MANAGEMENTS
3. SUPPLIERS 

•  Aliran data utama dari Departements adalah “Spending Request”.

Sebagai tanggapan dari sistem, Departemen menerima “Rejected Request” atau aliran data

“Delivery Advice”

• Management menerima data flow “Request For Special Approval”, yang kemudian memberikan respons
• Management juga mengirim data flow “Budget Allocation” ke sistem dan mendapatkan data flow “Spending Summaries”
• Supplier menerima data flow “Part Order” dan mengembalikan data flow “Supplier Delivery Advice”

Setelah mendapatkan “Diagram Konteks”, langkah selanjutnya adalah membuat DFD yang

memperlihatkan proses dari sistem utama, yang dinamakan dengan TOP LEVEL DFD

•  Top level DFD memperlihatkan berbagai proses yang membentuk sistem
•  Setiap proses mempunyai sebuah nama unik dan nomor proses
• Dari DFD di atas kita lihat bahwa data flow “Spending Request” dari Departements menuju ke proses “Check Funding”. Proses “Check Funding” melihat “Allocated Budget” dan menetapkan apakah izin khusus diperlukan dari management untuk diteruskan ke permintaan.
• Data flow “Approved Request” menuju ke proses “Classify Expenditure”, dan kemudian dimasukkan pada data store “Departemental-Accounts” dan “Type-Accounts”.
•  Akhirnya, jika diperlukan, “Part Order” untuk menetapkan bagian ( part ) semula dalam “Spending Request” diurus oleh supplier.
• Dua proses lainnya : “Setup Budget” dan “Provide Spending Summaries”

Kita dapat memperluas setiap proses pada Top Level DFD. Sebagai contoh diambil proses “Classify

Expenditure”

Data Flow Diagram yang baik :

1. Ketiadaan dari struktur flowchart
2. Penyimpanan data
3. Penamaan yang baik

Perbedaan antara Flowchart dan Data Flow Diagram :

Flowchart terdiri dari box-box yang mendeskripsikan :

•  Komputasi
• Decision / Keputusan
• Iterasi
• Loop

Data Flow Diagram bukan Flowchart program dan tidak mempunyai elemen kontrol

DFD yang baik harus :

•  Tidak mempunyai aliran data yang split up ke dalam sejumlah aliran data lain
• Tidak mempunyai garis yang berpotongan
• Tidak terdapat iterasi antara 2 proses ; 1 proses dengan dirinya sendiri 
• Tidak mengandung aliran data yang berfungsi sebagai signal untuk mengaktifkan suatu proses 

 

Mekanik dari Analisis Terstruktur

Membuat sebuah diagram hubungan Entitas

Diagram hubungan  entitas memungkinkan seorang perekayasa perangkat lunak untuk secara penuh menspesifikasikan objek data yang merupakan input dan output dari system. Pendekatan berikut ini perlu diketahui dalam membuat diagram Entitas :

ü  1.Selama pengumpulan persyaratan, pelanggan diminta untuk mendaftar ‘hal-hal’ yang akan dituju oleh proses bisnis dan aplikasi. ‘Hal-hal’ ini dimasukkan kedalam sebuah daftar objek data input dan output dan entitas eksternal yang menghasilkan atau mengkonsumsi informasi.

ü  2.Dengan mengambil objek satu pada satu saat , analis dan pelanggan mendefinisikan apakah ada sambungan (tidak diberi nama pada tahap ini ) ada diantara objek data  dan objek lain.

ü 3. Dimanapun sambungan ada, analis dan pelanggan menciptakan satu pasangan hubungan objek atau lebih .

ü 4. Untuk masing-masing pasangan hubungan objek, dicari kardinalitas dan modalitas.

ü  5.Langkah 2 sampai 4 dilanjutkan secara iterative sampai semua pasangan hubungan objek sudah didefinisikan. Sudah menjadi kebiasaan untuk menemukan penghilangan pada saat proses ini berlanjut. Objek dan hubungan baru akan ditambahkan pada saat jumlah iterasi bertambah.

ü 6. Atribut dari masing-masing eantitas didefinisikan

ü  7. Diagram entitas diformalisasikan dan dikaji

ü                  Langkah 1 sampai 7 diulangi smpai pemodelan data terlengkap

   Membuat Sebuah Model Aliran Data

            Diagram aliran data (DFD) memungkinkan perekayasa perangkat lunak untuk mengembangkan model domain informasi dan domain fungsional pada saat yang sama. Beberapa tuntunan sederhana dengan terukur dapat membantu selama derivasi  sebuah diagram aliran data :

1.      diagram aliran data tingkat 0 harus menggambarkan perangkat lunak/system sebagai gelembung tunggal.

2.      input dan output utama harus dicatat secara berhati – hati

3.      penyaringan harus dimulai dengan mengisolasi proses calon, objek data, dan penyimpanan yang akan direpresentasikan pada tingkat selanjutnya.

4.      semua anak panah dan gelembung harus diberi label dengan nama yang berarti

5.      kontinyuitas aliran informasi harus dijaga dari tingkat ke tingkat

6.       satu gelembung pada satu saat harus disaring.

   Ada  kecenderungan natural untuk terlalu mengkomlikasikan diagram aliran data. Hal ini terjadi bila analisis ingin menunjukkan terlalu banyak  detail pada saat yang terlalu dini

                                                  

Me        membuat Sebuah Model Aliran Kontrol

      Untuk beberapa tipe aplikasi pemrosesan, model data dan diagram aliran data meruapakan hal yang diperlukan untuk memperoleh wawasan yang berarti kedalam persyaratan perangkat lunak. Tetapi, seperti yang telah dicatat, disana ada suatu kelas aplikasi yang besar yang lebih dikendalikan oleh kejadian dari pada data, yang lebih menghasilkan informasi control dari pada menghasilkan laporan dan tampilan. Dan yang memproses informasi dengan perhatian besar kepada waktu dan kinerja kerja. Aplikasi semacam itu mambutuhkan pemodelan aliran control sebagai tambahan kepemodelan aliran data.

         lelah kita catat bahwa sebuah kejadian atau item control diimplementasikan sebagai harga Boolean (misalnya; benar atau salah, on atau off, 1 atau 0) atau sebuah daftar diskrit dari keadaan (kosong,penuh), untuk memilih calon kejadian yang potensial, diusulkan tuntutan berikut ini :

·              Daftarlah semua sensor yang dibaca oleh perangkat lunak

·              Daftarlah semua keadaan interupsi

·              Bacalah semua saklar yang diaktuasi oleh operator

·              Daftarlah semua keadaan data

·              Dengan menarik uraian data kerja dan data benda yang diaplikasikan ke narasi pemrosesan, kajilah semua item control sebagai input /output CSPEC yang mungkin

·              Gambarkanlah tingkah laku dari system dengan mengidentifikasi keadaannya ; identifikasikanlah bagaimana keadaan dicapai dan definisikanlah transisi antar keadaan.

·              Fokuskanlah penghilangan yang mungkin sebuah kesalahan yang paling umum didalam menspesifikasikan control (misalnya, tanyakanlah ; adakah suatu cara dimana saya dapat masuk ke keadaan itu atau keluar darinya).

   Spesifikasi Kontrol

            CSPEC mempresentasikan tingkah laku system (pada tingkat dimana dia direferensikan) didalam dua cara yang berbeda. CSPEC berisi sebuah diagram transisi keadaan (STD) yang merupakan suatu spesifikasi sekuensial dari tingkah laku. Dia juga dapat berisi suatu table aktifitas proses (PAT) – sebuah spesifikasi  kombinaturial dari tingkah laku. 

    Spesifikasi Proses

            Spesifikasi Proses (PSPEC) digunsksn untuk menggambarkan semua proses model aliran yang nampak pada tingkat akhir penyaringan.Kandungan dari spesifikasi proses dapat termasuk teks naratif, bahasa design program/Progamme Design Language (PDL) dari Algoritma proses, persamaan Matematika, table, diagram atau bagan, dengan memberikan sebuah PSPEC untuk mengiringi masing-masing gelembung didalam model aliran, berarti perekayasa perangkat lunak menciptakan sebuah “spesifikasi mini”yang dapat berfungsi sebagai sebuah langkah pertama didalam kreasi spesifikasi persyaratan perangkat lunak dan sebagai penuntun bagi desaign komponen program yang akan mengimplementasikan program.

  Kamus Data

Kamus data adalah suatu kumpulan data elemen yang terstruktur dengan pengertian yang
konsisten dan sesuai dengan sistem, sehingga pengguna maupun analis sistem memiliki
pemahama yang sama mengenai masukan, keluaran dan komponen simpanan data .
Pembentukan kamus data didasarkan pada alur data yang terdapat pada Diagram Alir Data (DAD). Alira data pada DAD bersifat umum (hanya menunjukkan nama alur datanya tanpa
menunjukkan struktur dari alur data). Unutk menunjukkan struktur dari aliran data
secara detail maka dibutuhkan sebuah kamus data.


Kamus Data (KD) dibuat pada tahap analisis sistem dan digunakan baik pada tahap analisis maupun pada tahap perancangan sistem. Pada tahap analisis sistem, KD dapat digunakan sebagai alat komunikasi antara analisis sistem dengan pemakai sistem tentang data yang mengalir di sistem, yaitu tentang data yang masuk ke sistem dan tentang informasi yang dibutuhkan oleh pemakai sistem. Pada tahap perancangan sistem, KD digunakan untuk merancang input, merancang laporan-laporan dan database. Kamus data dibuat berdasarkan arus data yang ada di DAD.

Manfaat Kamus Data

Kamus Data (KD) adalah katalog fakta tentang data dan kebutuhan-kebutuhan informasi
dari suatu sistem informasi. Kamus data selain digunakan untuk dokumentasi dan mengurangi redudansi, juga dapat digunakan untuk:

• Memvalidasi diagram aliran data dalam hal kelengkapan dan keakuratan
• Menyediakan suatu titik awal untuk mengembangkan layar dan laporan-laporanMenentukan muatan data yang disimpan dalam file-file
• Mengembangkan logika untuk proses-proses diagram aliran data

Fungsi Kamus Data

Kamus Data mendefinisikan elemen data dengan fungsi sebagai berikut:

• Menjelaskan arti aliran data dan penyimpanan data dalam DFD
• Mendeskripsikan komposisi paket data yang bergerak melalui aliran (misalnya
  alamat
• diuraikan menjadi kota, negara dan kode pos)
• Mendeskripsikan komposisi penyimpanan data
• Menspesifikasikan nilai dan satuan yang relevan bagi penyimpanan dan aliran
• Mendeskripsikan hubungan detil antar penyimpanan (yang akan menjadi titik perhatian dalam entity-relationship diagram)

Hubungan antara DFD dan KD

Kamus data dibuat dengan memperhatikan dan menggambarkan muatan aliran data,
simpanan dataa dan proses-proses seperti pada gambar di atas. Setiap simpanan data dan
aliran data bisa ditetapkan dan kemudian diperluas sampai mencakup detail-detail elemen
yang dimuatnya. Logika dari setiap proses ini bisa digambarkan dengan menggunakan data
yang mengalir menuju dan keluar dari proses tersebut.

Overview mengenai metode analisis

Data Structured Systems Development
Data Structure System Development (DSSD), yang disebut juga dengan metodologi Warnier-Orr terjadi dari kerja perintis mengenai analisis domain informasi yang dilakukan oleh J.D Warnier. Warnier mengembangkan sebuah notasi untuk mempresentasikan hirarki informasi dengan menggunakan tiga kontruksi untuk urutan, pemilihan, dan pengulangan dan mendemonstrasikan bahwa struktur perangkat lunak dapat ditarik dari struktur data.
Jackson System Development
Jackson System Development (JDS) mengembangkan kerja yang dilakukan oleh M.A. Jackson tentang analisis domain informasi dan hubungannya dengan desain system dan program.
SADT
Structured analysis and design technique (SADT) adalah sebuah teknik yang telah digunakan secara luas sebagai sebuah notasi untuk definisi system, representasi proses, analisis persyaratan perangkat lunak dan desaign system /perangkat lunak.

SUMBER

http://minangmylife.blogspot.co.id/2016/04/pemodelan-analisis.html 

http://fairuzelsaid.com/kamus-data/

http://lhabreinda.blogspot.co.id/2012/06/pemodelan-analisis-mekanik-dari.html

http://ermawita91.blogspot.co.id/2012/06/materi-pemodelan-analisis.html

http://rickyrahmanharvard.blogspot.co.id/2012/06/pemodelan-fungsional-dan-aliran.html

Konsep dan Prinsip Analisis

Prinsip & Konsep Analisa Kebutuhan

Analisa Kebutuhan
- Teknik Komunikasi
- Memulai Proses
- Teknik Spesifikasi Aplikasi Yang dimudahkan
- Prinsip Analisa
- Daerah Informasi
- Modeling
- Penyekatan
- Prototipe Software
- Pemilihan Pendekatan Prototipe
- Metode Prototipe dan perkakasnya.
- Spesifikasi kebutuhan perangkat lunak
- Prinsip Spesifikasi
- Penyajian

Analisa Kebutuhan

Analisa kebutuhan
Adalah Suatu proses penemuan, perbaikan, modeling, dan spesifikasi.

Sepanjang proses, kedua-duanya pelanggan dan pengembang mengambil suatu peran aktif.

Terpusat pada: “ apa” sebagai pengganti “ bagaimana”

Input dari proses analisa kebutuhan:
- Rencana Proyek Software - Spesifikasi sistem ( jika terdapat)

Output
Adalah Spesifikasi dokumen kebutuhan software - menyediakan software insinyur dengan model yang dapat diterjemahkan ke dalam data, secara ilmu bangunan, alat penghubung, dan disain prosedur.

- pengembang dan pelanggan dapat memeriksa mutu dari software dan menyediakan pengaruh arus balik.

Yang melaksanakan analisa kebutuhan: analis sistem

Usaha dan tugas utama :
- Pengenalan masalah ( atau pemahaman sistem)
- Menemukan dan memahami kebutuhan system
- Menyuling kebutuhan
- Sintese dan Evaluasi:
- apakah merupakan solusi alternative
- memusatkan pada solusi apa harus dipilih atau digunakan sebagai ganti bagaimana cara menerapkan suatu solusi.
- Modeling: untuk menghadirkan berbagai aspek dari system
- data yang diperlukan
- informasi dan mengendalikan arus
- perilaku operasi
- Spesifikasi:
- fungsi software, dan tampilan
- menghubungkan antar unsur-unsur system
- batasan sistem

Proses Rancang Bangun Kebutuhan

Studi kelayakan:
- Mengidentifikasi dan perkiraan untuk melihat jika kebutuhan pemakai dapat dicukupi dengan menggunakan teknologi dan teknik sekarang.

- Analisa kebutuhan:
- Proses menurunkan kebutuhan sistem melalui pengamatan atas sistem yang berjalan, diskusi dengan para pemakai dan pelanggan, analisis tugas, dan seterusnya.

Definisi kebutuhan:
- Menterjemahkan informasi ke dalam suatu REQ. dokumen.

Spesifikasi kebutuhan:
- Menggambarkan kebutuhan sistem yang menggunakan suatu ketepatan yang konsisten, dan cara lengkap.
- Penggunaan beberapa metoda spesifikasi kebutuhan

Proses Analisa Kebutuhan

Pemahaman daerah:
- Pemahaman daerah aplikasi.
- Koleksi kebutuhan:
- Proses dari saling berinteraksi dengan pelanggan, para pemakai untuk menemukan kebutuhan untuk sistem itu.

- Penggolongan kebutuhan:
- Menggrupkan dan menggolongkan kebutuhan yang dikumpulkan itu.

- Resolusi konflik:
- Memecahkan kebutuhan konflik.

- Prioritisasi:
- Mengidentifikasi dan mendaftar kebutuhan menurut kepentingan mereka

- Pengesahan kebutuhan:
- Memeriksa dan mengesahkan kebutuhan yang dikumpulkan untuk melihat jika mereka lengkap, benar, dan  serasi

 

TEKNIK KOMUNIKASI 

   

       

·                                 Merupakan permulaan yang (selalu) perlu dilakukan agar seorang pelanggan memiliki masalah yang dapat dipertanggung jawabkan melalui pemecahan berbasis komputer

·                                 Agar pengembang dapat merespon permintaan bantuan (help) dari pelanggan

·                                  Biasanya jalan komunikasi ke pemahaman penuh dengan “lobang-lobang”

MENGAWALI PROSES

·                                 Untuk menjembatani jurang / lobang-lobang komunikasi antara pelanggan dan pengembang, sekaligus untuk memulai proses komunikasi, perlu dilakukan pertemuan pendahuluan atau wawancara

·                                  Harus dimulai dengan pertanyaan-pertanyaan yang bebas konteks :

o   Siapa dibalik permintaan untuk pekerjaan ini ?o   Siapa yang akan menggunakan pemecahan ini ?o   Apa keuntungan ekonomi dari pemecahan yang berhasil ?o   Apakah ada sumber lain untuk pemecahan yang anda inginkan ?

·                                 Dilanjutkan dengan pertanyaan agar seorang analis mendapat pemahaman yang lebih baik akan mengenai masalah dari pelanggan

o   Bagaimana anda akan menandai output yang baik ?o   Masalah apa yang akan diselesaikan oleh pemecahan ini ?o   Dapatkah anda memperlihatkan kepada saya (atau menjelaskan) lingku ngan dimana pemecahan tersebut akan digunakan ?o   Apakah masalah atau batasan kinerja yang khusus yang akan mempenga ruhi cara pemecahan tersebut didekati ?

·                                  Diakhiri dengan pertanyaan yang berfokus pada efektivitas pertemuan

o   Apakah anda adalah orang yang tepat untuk menjawab pertanyaan-pertanyaan ini ? dan apakah jawaban anda bersifat resmi ?o   Apakah pertanyaan saya ini relevan dengan masalah yang anda hadapi ?o   Apakah anda mengajukan terlalu banyak pertanyaan ?o   Apakah ada orang lain yang dapat memberikan informasi tambahan ?o   Apakah ada hal lain yang harus saya tanyakan kepada anda ? FAST (Facilitated Application Specification Techniques)TENTANG FASTMemacu kreasi kerjasama dari tim (pelanggan dan pengembang) yang bekerja sama untuk :

·                                  Mengidentifikasi masalah

·                                  Menyiapkan elemen-elemen solusi

·                                 Menegosiasikan pendekatan yang berbeda

·                                  Menetapkan sebelumnya kebutuhan solusi yang diperlukan

Banyak pendekatan yang digunakan dan masing-masing pendekatan menggunakan scenario yang berbeda, namun semuanya menerapkan variasi tuntunan dasar berikut ini:

·                                   Pertemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan

·                                   Aturan main untuk persiapan dan partisipasi dibuat

·                                    Perlunya agenda

·                                   Perlunya seorang fasilitator

·                                  Harus adanya mekanisme definisi

PANDUAN FASTJ. Wood dan D. Silver menyarankan beberapa panduan umum FAST yang dapat digunakan yaitu :

·                                 Peserta harus menghadiri semua rapat

·                                 Semua peserta adalah sama

·                                 Persiapan harus sama pentingnya dengan rapat yang sebenarnya

·                                 Semua dokumen sebelum rapat harus dikaji ulang

·                                 Lokasi rapat diluar ruangan terkadang diperlukan

·                                 Tentukan agenda dan jangan sampai mengalami perubahan

·                                 Jangan sampai terbawa dalam hal-hal teknis yang terlalu rinci

PENYEBARAN FUNGSI KUALITAS (QUALITY FUNCTION DEPLOYMENT = QFD)QFD sebagai perkenalan :

·                                 Teknik manajemen kualitas yang menterjemahkan kebutuhan pelanggan kedalam kebutuhan teknis untuk perangkat lunak

·                                 Pertama kali diperkenalkan di Jepang untuk memaksimalkan kepuasan pelanggan

·                                 Menekankan pemahaman tentang apa yang berguna kepada pelanggan dan kemudian menyebarkan nilai-nilai tersebut melalui proses rekayasa

QFD mengidentifikasi tiga tipe persyaratan yaitu :

1. .Persyaratan  normal : Sasaran dan tujuan bagi sebuah produk atau system selama pertemuan dengan pelanggan. Bila persyaratan ini ada, maka pelanggan akan menjadi puas, misalnya tampilan grafis yang sempurna. 

2. Persyaratan yang diharapkan : Persyaratan ini implicit terhadap produk atau system yang sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Ketidakhadirannya akan menyebabkan ketidakpuasan yang sangat mendalam. Contohnya adalah mudahnya operasional interaksi manusia dan mesin, reliabilitas dan kebenaran operasional keseluruhan dan mudahnya instalasi perangkat lunak\

3.   Exciting requirement : Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada, misal kemampuan perangkat pengolah kata yang memiliki kemampuan layout halaman, dsb.   

 

Prinsip Analisa

1. 
   Masing-masing metoda analisa mempunyai suatu segi pandangan unik.
   Semua metoda analisa terkait oleh satu set prinsip operasional:
   - menghadirkan dan memahami daerah informasi- menggambarkan fungsi software
   - menghadirkan perilaku dari software – menggunakan model untuk melukiskan informasi, fungsi, dan perilaku--> membongkar detil di dalam suatu lapisan pertunjukan.
   - bergerak dari informasi penting ke arah yang lebih detil
   
   Satu set petunjuk untuk rancang-bangun kebutuhan:
   - memahami masalah sebelum permulaan untuk menciptakan model analisa
   - mengembangkan prototipe untuk membantu pemakai untuk memahami bagaimana interaksi manusia dan mesin
   - merekam asal dan pertimbangan untuk tiap-tiap kebutuhan
   - menggunakan berbagai pandangan kebutuhan
   - memprioritaskan kebutuhan
   - bekerja untuk menghapuskan kerancuan
   
   Daerah Informasi Software
   
   Software dibangun untuk memproses data, untuk mengubah bentuk data dari yang satu dengan yang lain.
   Software juga memproses peristiwa.
   Prinsip analisis operasi yang pertama perlu untuk menguji daerah informasi.
   Daerah informasi berisi tiga pandangan yang berbeda menyangkut data dan kendali:
   - hubungan dan isi informasi:
   isi informasi--> menghadirkan data individu dan object kendali
   ada hubungan berbeda antara object dan data
   
   - arus informasi:
   menghadirkan cara di mana data dan kontrol berubah dari masing- masing gerak melalui suatu sistem. Data dan control bergerak antara dua perubahan bentuk ( fungsi).
   
   - struktur informasi:
   menghadirkan organisasi yang internal dari berbagai data dan materi kendali- struktur pohon data - data tebel ( n-dimensi)
   
   Pemodelan
   
   Selama modeling software kebutuhan analisa, kita menciptakan model menyangkut sistem untuk
   
   Model Fungsional
   Software Model fungsional mengubah bentuk informasi. Tiga fungsi umum:- masukan, memproses, keluaran
   
   - Model Perilaku
   Kebanyakan perilaku model software bereaksi terhadap peristiwa dari dunia luar. Suatu model perilaku menciptakan suatu penyajian menyangkut status software dan peristiwa yang menyebabkan perangkat lunak untuk berubah status
   
   Peran penting model:
   Model menopang analis di dalam pemahaman informasi, fungsi, dan perilaku dari suatu sistem.
   Model menjadi titik-api untuk tinjauan ulang di dalam aspek kelengkapan, konsistensi, dan ketelitian dari spesifikasi itu.
   Model menjadi pondasi untuk disain, menyediakan perancang dengan suatu penyajian penting dari software. 

PROTOTYPING PERANGKAT LUNAK

 Dalam beberapa hal adalah mungkin untuk menerapkan analisis operasi prinsip dan memperoleh suatu model software dari suatu disain yang dapat dikembangkan.

Memilih pendekatan prototipe:
Pendekatan closed-ended disebut lembaran prototype iklan.
- Sebuah prototipe melayani sebagai demonstrasi keras dari kebutuhan.

Pendekatan open-ended disebut evolusiner membuat prototip.
- suatu prototipe bertindak sebagai evolusi pertama dari sistem yang telah selesai.


Prototipe Perkakas dan Metoda:
- Teknik Generasi Keempat
- Komponen Software dapat dipakai kembali
- Spesifikasi Formal dan Lingkungan Prototipe

Spesifikasi Software

Prinsip Spesifikasi
Memisahkan kemampuan dari implementasi
Mengembangkan suatu model menyangkut perilaku yang diinginkan dari suatu system
Menetapkan konteks di mana software beroperasi
Menggambarkan lingkungan di mana sistem beroperasi
Menciptakan suatu model teori dibanding suatu implementasi atau disain model
Spesifikasi adalah suatu model abstrak dari suatu sistem riil
Menetapkan struktur dan isi dari suatu spesifikasi ( mudah untuk diubah)

Petunjuk untuk penyajian:
Isi dan Format penyajian harus relevan kepada masalah
Informasi yang dimasukkan di dalam spesifikasi harus sekumpulan
Diagram dan notasi format lain harus terbatas dalam jumlah dan digunakan secara konsisten.
Penyajian harus bisa berhadap-hadapan kembali

Standar spesifikasi kebuthan software:
IEEE ( standard No. 830-1984) dan U.S. Departemen Pertahanan
Dalam banyak kesempatan, suatu persiapan penggunaan manual harus disajikan untuk menghadiahi perangkat lunak sebagai black-box. 

 

SUMBER

  http://lokomediasi.blogspot.co.id/2009/08/prinsip-konsep-analisa-kebutuhan.html

  http://teknikbelajarprogram.blogspot.co.id/2016/04/tugas-rekayasa-perangkat-lunak-npm.html