Model Analisis Aplikasi Inventory (bag 2)

Bagian ini merupakan lanjutan dari tulisan saya pada bagian Pertama, yang dapat diakses disini:

http://stanlysk.blogspot.com/2012/10/model-analisis-aplikasi-inventory.html

Setelah melakukan analisis proses bisnis yang mendalam, dan kemudian mengidentifikasi kebutuhan, termasuk berbagai permasalahan yang akan diselesaikan, maka langkah selanjutnya adalah membuat model diagram dari sistem aplikasi yang akan dikembangkan.

Kita ketahui bersama bahwa pendekatan Model Driven Architecture (MDA) biasanya akan membuat beberapa jenis model perangkat lunak. Menurut Pressman, maka terdapat 5 jenis model yang bisa dikembangkan.

1. Model Scenario-based

Untuk Model berbasis-skenario, maka akan digunakan Diagram Aktivitas, Diagram Use Case dan Tabel Use Case. Berikut adalah tampilan gambar model tersebut.

Ketiga gambar diatas merupakan sebuah gambar model berbasis skenario, dimana pada bagian Tabel Use Case hanya ditampilkan sebuah deskripsi use case Menerima Item.

2. Model Kelas

Untuk pemodelan kelas, akan digunakan pendekatan model CRC dan Kelas Diagram. Berikut adalah contoh tampilannya.

Selain menggunakan CRC Cards, identifikasi kelas pada sistem aplikasi juga dapat menggunakan teknik yang lebih sederhana, misalnya Teknik Indentifikasi Kata. Untuk teknik ini akan diterangkan pada bagian yang lain.

3. Model Perilaku

Model perilaku akan digambarkan dengan diagram sequence. Dalam hal ini, pemaparan model perilaku digambarkan dengan tiga keadaan berbeda, yakni:

Untuk skenario masuknya item yang telah terdaftar dalam inventori, dalam use case Memasukkan Item:

Untuk skenario keluarnya item yang memiliki kadaluarsa, dalam use case Mengeluarkan Item:

 

Untuk skenario diperlukannya peramalan berdasarkan histori pengeluaran, dalam use case Mengadakan Item:

Kemudian, state diagram digunakan untuk memodelkan keadaan object dari sistem aplikasi yang akan dikembangkan, yakni:

Class Transaksi Keluar dinilai cukup kompleks sehingga di sini diberikan penjelasan lebih lanjut dengan menggunakan behavioral state machine: 

Demikianlah sebuah contoh pemodelan sistem aplikasi inventory.

Model Analisis Aplikasi Inventory

Berikut ini saya berikan sebuah contoh Model Analisis Aplikasi Inventory.

I. Pengumpulan Informasi

Pada bagian pengumpulan informasi, maka tim pengembang mengelompokkan kebutuhan-kebutuhan (fungsional dan non fungsional) yang akan dikembangkan dalam aplikasi.

I.1 Ketentuan Fungsional

Beberapa syarat fungsional yang harus dipenuhi sistem yang dibuat antara lain:

1. Penerimaan Item

• 1.1. Sistem Inventori akan menerima item dari pemasok dan dimasukkan kedalam sistem baik secara manual ataupun menggunakan barcode sistem.
• 1.2. Setiap item masuk akan dicek apakah item tersebut baru ataupun lama yang akan dicek juga kadaluarsanya untuk memudahkan penyusunan Item digudang
• 1.3. Item yang memiliki kadaluarsa harus disusun secara FIFO, yaitu kadaluarsa yang paling dulu harus dikeluarkan paling duluan.
• 1.4. Semua aktifitas penerimaan dilakukan oleh staff inventori.

2. Pengeluaran Item

• 2.1. Setiap item yang keluar merupakan permintaan dari staff lain di perusahaan dan harus tercatat dalam inventori.
• 2.2. Setiap item yang keluar harus diperiksa apakah memiliki kadaluarsa atau tidak, apabila memiliki maka harus dikeluarkan berdasarkan FIFO kadaluarsa,yaitu masa kaduarsa paling dulu harus keluar duluan.

3.  Pengadaan Item

• 3.1. Staf Pengadaan akan bertanggung jawab terhadap semua penyediaan item dalam inventori.
• 3.2   Dalam melakukan pengadaan item, staff pengadaan dapat melihat histori data item yang pernah dikeluarkan dan dibuat dalam bentuk peramalan
• 3.3  Sistem peramalan yang dibuat dapat berbentuk peramalan tahunan, triwulan, dan mingguan.

4. Pembuatan laporan

• 4.1. Semua aktifitas dalam sistem inventori harus tercatat dalam laporan yang dapat digenerate dalam beberapa satuan waktu.
• 4.2.  Laporan mencatat aktifitas transaksi masuk, transaksi kirim, transaksi keluar, transaksi pesan, dan daftar konsinyasi

I.2 Ketentuan Non-Fungsional

Ketentuan non fungsional dibedakan menjadi ketentuan operasional, ketentuan performansi dan ketentuan keamanan, yakni sebagai berikut:

1. Ketentuan Operasional 

1.1. Sistem Inventori akan melakukan pencatatan semua aktifitas inventori dan akan ada aktifitas create,read, update, delete pada maindatabase.

1.2. Sistem akan mencatat detail dari masing-masing item seperti (nama item, jenis item, tanggal kadaluarsa, id item, jumlah item, dan harga)

2. Ketentuan Performansi 

2.1. Sistem harus bisa menangani jumlah kuantitas item yang besar dan otomatisasi menggunakan barcode

3. Ketentuan Keamanan

3.1. Sistem harus membagi hak akses masing-masing staff sesuai otorisasinya.

4. Ketentuan Politik dan budaya 

4.1. Tidak ada ketentuan politik dan budaya

II. Analisis Proses Inventori Dalam Perusahaan

Proses bisnis yang sedang berjalan pada perusahaan X dijelaskan pada bagian ini sebagai proses yang berkaitan erat dengan pemesanan item sebagai penyediaan item. X merupakan suatu perusahaan yang masih baru dan berkembang, sehingga untuk dapat mencapai suatu keputusan melalui birokrasi yang rumit. Dimulai dari Definisi Kebutuhan,  Perusahaan (Pengadaan), Perencanaan pemesanan, Pemesanan, Penerimaan item, Penyimpanan (dalam Gudang), sampai dengan penyaluran ke Warnet/user.

Proses inventori yang sekarang ada didalam X masih manual dan komputer digunakan hanya untuk pengetikan, sehingga memperlambat proses kerja yang ada. 

Proses  inventori dimulai dari adanya permintaan gudang, lalu bagian pengadaan membuat SPK ( Surat Perintah Kerja ). Setelah itu bagian pengadaan akan mengirimkan kepada Pemasok. Sesuai dengan SPK yang diterima Pemasok mengirimkan item, dan panitia penerimaan item bersama staff inventori akan menerima item tersebut. Pencatatan item masuk dilakukan secara manual dan diketikkan kedalam komputer. Sesudahnya item tersebut diserahkan pada penangungjawab item.

II.1. Proses Berjalan

Proses bisnis yang sedang berjalan pada X dijelaskan pada bagian ini sebagai proses yang berkaitan erat dengan pemesanan item sebagai penyediaan item. X merupakan suatu perusahaan yang beru berkembang, sehingga untuk dapat mencapai suatu keputusan melalui birokrasi yang rumit. Dimulai dari Definisi Kebutuhan,  Perusahaan (Pengadaan), Perencanaan pemesanan, Pemesanan, Penerimaan item, Penyimpanan (dalam Gudang), sampai dengan penyaluran ke Warnet.

II.1.1 Definisi Kebutuhan Perusahaan (Pengadaan)

Bagian pengadaan adalah bagian yang menyiapkan pemesanan item yang berhubungan dengan Pemasok. Bagian pengadaan mengadakan pesanan selama tiga bulan sekali. Dalam hal ini bagian pengadaan berhak menentukan Pemasok yang mana yang harus dipilih untuk menerima pesanan yaitu dalam bentuk tender. Pengadaan akan menentukan Pemasok dengan harga murah dan item cukup berkualitas.

II.1.2. Pemesanan

X melakukan perencanaan keuangan dalam waktu setahun sekali. Dalam hal pengadaan item maka X melakukan prediksi yang kurang akurat, karena data-data masih dicatat secara manual, dan terkadang terjadi kelangkaan item atau kadaluarsa. Item yang diperlukan perusahaan pertama kali didaftar kebutuhan setiap warnet, yang kemudian akan disetujui oleh staff inventori dan dibuat arsip. Daftar tersebut akan diserahkan kepada sekretariat untuk dicatat dalam buku serah terima, lalu dilaporkan kepada direktur keuangan untuk disetujui, kemudian diserahkan ke bagian keuangan untuk dimasukkan kedalam anggaran penggunaan. Setelah itu dikeluarkan SPK untuk bagian pengadaan serahkan kepada Pemasok. Bagian pengadaan akan mengadakan kualifikasi untuk menentukan pemasok yang akan dipilih, tetapi sebelumnya para pemasok akan membuat proposal penawaran kepada direktur utama. Setelah dipilih pemasok yang harganya sesuai, maka pengadaan akan ke bagian sekretariat untuk mencatat serah terima dan pemenang lelang. Selanjutnya sekretariat akan mengirimkan kartu kerja (KK),  dan lembar disposisi. Sekretariat akan memisahkan item yang dipesan antara item kadaluarsa dan yang bukan, lalu  bagian Pengadaan  membuat SPK yang disetujui direktur utama. Selanjutnya SPK itu diserahkan kepada sekretariat. SPK kemudian dikirimkan kepada pemasok terpilih, lalu pemasok akan memenuhi pesanan sesuai SPK dan kemudian unit kerjanya mengirimkan item  dan memberikan surat penagihan

II.1.3 Penerimaan Item

Pada proses penerimaan item akan dimulai dari Pemasok. Pemasok akan mengirimkan item bersama dengan SPK yang sesuai dan surat tagihan. Panitia penerimaan item akan memeriksa apakah jumlah dan jenis item yang dikirim oleh pemasok sesuai dengan SPK, jika tidak akan dikembalikan kepada pemasok, jika sesuai lalu panitia penerimaan item akan membuat BAPB (Berita Acara Penerimaan Item) yang selanjutnya Staff inventori akan memeriksa kembali Jenis dan jumlah item, bila sesuai maka akan dibuat arsip dan diserahkan kepada penanggungjawab kelompok item. Setelah item disimpan, bagian keuangan akan memeriksa BPAB dan tagihan. Setelah semua sesuai, maka bagian keuangan akan membuat surat pembayaran untuk ditandatangani oleh direktur keuangan. Selanjutnya bagian keuangan akan membayar jumlah tagihan kepada pemasok.

II.1.4. Penyaluran ke Warnet

Warnet merupakan perpanjangan tangan dari gudang, yang ada di banyak daerah. Warnet langsung berhubungan dengan customer atau pembeli. Warnet akan memesan item ke gudang dengan surat permintaan, lalu staff inventori akan memeriksa pesanan dan diserahkan kepada penanggungjawab gudang apakah item tersebut ada atau tidak. Bila pesanan ada, maka staff inventori akan membuat surat persetujuan dan item akan dikirim ke warnet, bila tidak ada, maka tidak dikirimkan. Staff inventori akan mencatat semuanya kedalam pembukuan dan menyimpan datanya juga dikomputer.

III. Analisa Kebutuhan Sistem
Pada saat ini perusahaan sangat membutuhkan sistem inventori yang dapat mengatur dan menyimpan aliran data pengelolaan item yang memiliki kadaluarsa (voucher). Sistem inventori akan sangat membantu karyawan dalam menangani proses penyimpanan item terutama untuk bagian gudang. Sistem inventori ini juga akan terintegrasi dengan bagian keuangan dan manajemen, sehingga sistem ini akan sangat membantu kebutuhan  perusahaan dalam menangani aliran data item-item yang keluar dan masuk

III.1. Kebutuhan Basis Data
Perancangan basis data untuk sistem inventori pada perusahaan X diperlukan guna menampung kebutuhan data-data yang akan diproses bagi laporan dan perencanaan ke depan. Basis data terdiri dari tabel-tabel yang berisi master item, transaksi masuk, warnet, perjalanan item, fifo dan user. Basis data yang diperlukan cukup besar, karena banyak item yang harus disimpan dan pada akhirnya di back up.

III.2. Sistem Terkomputerisasi
Sistem inventori lama yang digunakan masih manual, oleh sebab itu pada perancangan sistem inventori yang baru ini digunakan sistem inventori yang terkomputerisasi dan berbasis web. Sistem inventori yang baru ini pada akhirnya akan sangat membantu segala aktivitas perencanaan, pemesanan, dan pengelolaan inventorinya. Dengan adanya sistem yang terkomputerisasi ini diharapkan dapat mengurangi human error dan tidak diperlukan pencatatan untuk menyimpan data.

IV.1 Permasalahan
Beberapa permasalahan yang terjadi pada proses bisnis diantaranya adalah:
• alur penyediaan item panjang dan cukup rumit, sehingga membutuhkan waktu yang relatif lama untuk penyediaan suatu item.
• Pengaturan keluar masuk item di gudang, menggunakan sistem manual sehingga menyebabkan :
- Pengadaan item jadi lambat
- Pengeluaran detail susah dilacak
- Penggunaan item oleh tiap divisi susah dikontrol, mengakibatkan perancanaan penyediaan  item menjadi sulit.
- Kemungkinan terjadinya human error tergolong tinggi
- Laporan kepada bagian manajemen  kurang akurat, sehingga pengambilan keputusannya pun tidak akurat.
• Karena perencanaan yang kurang baik, ada kemungkinan item menumpuk (overstock) sehingga item ada yang kadaluarsa, atau terjadinya kelangkaan item yang sedang dibutuhkan.
• Kurangnya sumber daya manusia yang memadai untuk mendukung Aplikasi yang akan dibuat.

IV.2. Usulan Penyelesaian Masalah
Sistem didesain agar rantai aliran item dapat berjalan dengan baik dan efektif (waktu) melalui perencanaan, pembuatan model, penganalisaan, pengembangan dan pengontrolan.
Untuk masalah yang berkaitan dengan perusahaan X ditawarkan solusi berupa Aplikasi inventori berbasis web, yang bertindak sebagai alat bantu, dalam menangani pengadaan item  untuk memudahkan  dalam hal perencanaan, pemesanan, dan pengelolaan inventorinya, sehingga dapat mempercepat aliran item, pengontrolan penggunaan item lebih baik, dapat membuat laporan yang lebih akurat, dan meminimalkan terjadinya human error.
Aplikasi pengadaan item ini, akan dikembangkan dengan mempelajari histori pengadaan dari waktu-waktu sebelumnya yang dapat memperkirakan waktu pemesanan dan jumlahnya, sehingga dapat menghindari kekurangan ataupun overstock item.
Aplikasi dibuat dengan interface yang user friendly dan mudah digunakan oleh pengguna Aplikasi.

SRS Aplikasi Pembayaran (bagian 2)

Tulisan ini adalah lanjutan dari bagian ini:

http://stanlysk.blogspot.com/2012/10/srs-aplikasi-pembayaran.html

III.4 Behavioral Models : Sequence Diagram

Sequence Diagram digunakan untuk menggambarkan kebiasaan/behavior suatu aplikasi. Selain itu, secara spesifik suatu Sequence Diagram menggambarkan sebuah skenario yang spesifik. Diagram ini menampilkan sejumlah objek dan pesan yang dilewatkan di dalam seuah Use-Case.

Tujuan pembuatan Sequence Diagram, yaitu :

1. menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu.

2. Menggambarkan skenario atau reangkaian langkah-langkah yang dilakukan sebagai respon dari sebuah event untuk menghasilkan output tertentu.

III.5 Flow Models : Data Flow Diagram

Data Flow Diagram (DFD) merupakan suatu alat yang membantu seorang analis untuk menggambarkan interaksi antara proses dan data. Selain itu, DFD juga menggambarkan dimana data akan digunakan (diambil dari data storeage) dan data akan disimpan.

Sebuah DFD merupakan representasi grafis yang menggambarkan aliran informasi dan perubahan yang terjadi sehingga data berubah dari masukan menjadi keluaran. Data Flow Diagram digunakan untuk menggambarkan sebuah sistem atau perangkat lunak pada berbagai tingkatan abstraksi.

III.6 Activity Diagram

Activity diagram membantu seorang analis untuk memodelkan interaksi antara User dan Customer. Sehingga memudahkan Pengembang untuk menentukan proses yang terjadi di dalam suatu proses.

III.7 Entity Relationship Diagram

Entity Relationship Diagram (ERD) awalnya ditujukan sebagai model database relasional. Namun, penggunaan saat ini telah berkembang lebih dari itu.Di dalam ERD terdapat beberapa komponen utama, yaitu : obyek data, atribut, relasi, dan beberapa penentu tipe. Tujuan Utama ERD adalah untuk merepresentasikan obyek data dan relasi-relasinya.

Pemodelan data logika dikembangkan dalam empat tahapan, sebagai berikut :

1. Model Data Konteks

Model data ini digunakan untuk menentukan lingkup proyek yang tidak terlalu detail dalam membahas entitas dan aturan bisnis.

2. Model Data Key-Based

Model data untuk mengidentifikasikan setiap entitas dengan menambahkan entitas asiosiatif dan menyertakan primary key

3. Model Data Fully-Attributed

Model Data yang menyertakan semua atribut deskriptif secara menyeluruh

4. Model Data Ternormalisasi

Model data yang telah melalui proses normalisasi.

Normalisasi adalah sebuah teknik pengorganisasian data ke dalam tabel-tabel untuk memenuhi kebutuhan pengguna. Tujuannya untuk menhilangkan kerangkapan data, mengurangi kompleksitas data dan mempermudah modifikasi data.

SRS Aplikasi Pembayaran

Berikut ini saya berikan contoh tentang Pembuatan Dokumen SRS. Dokumen ini awalnya dikerjakan oleh Kelompok 5 Mata Kuliah RPL, angkatan 2009 Prodi Teknik Elektro Unsrat.

Bab Analisa Kebutuhan.

Analisa Kebutuhan merupakan sebuah tugas atau pekerjaan di dalam ilmu Rekayasa Perangkat Lunak yang menjembatani antara system-level requirement engineering dan software design.

Suatu proses Rekayasa Kebutuhan (Requirement Engineering) akan menghasilkan spesifikasi Perangkat Lunak (mulai dari fungsi/function, data, dan kebiasaan/behavior), mengidentifikasikan antarmuka antara Aplikasi dan elemen sistem lainnya, dan menentukan standarisasi yang harus dipenuhi oleh Perangkat Lunak.

Requirement Analysis mengijinkan Software Engineer/Analyst untuk memperbaiki spesifikasi software dan membuat model dari spesifikasi tersebut. Proses ini memberikan suatu hasil kepada Software Designer, berupa representasi informasi, fungsi, dan kelakuan yang bisa di terjemahkan menjadi data, arsitektur, antarmuka, dan rancangan component.

Dan akhirnya, spesifikasi kebutuhan akan memberikan pengertian kepada pengembang dan pengguna untuk membuat suatu aplikasi yang berkualitas.

II.1 Kebutuhan fungsional dan non fungsional

Kebutuhan fungsional menggambarkan kemampuan utama suatu aplikasi. Seorang Software Engineer akan menentukan fungsi-fungsi utama yang harus ada di dalam aplikasi, dimana fungsi-fungsi tersebut didapatkan dari proses Requirement Gathering yang dilakukan seorang Software Engineer terhadap User/Stakeholders.

Dari fungsi-fungsi utama tersebut, akan diperluas lagi menjadi  fungsi-fungsi yang lebih spesifik melakukan suatu pekerjaan. Pada akhirnya, fungsi-fungsi ini akan menjadi fitur ari aplikasi tersebut.

Kebutuhan Non-Fungsional adalah kebutuhan yang harus dipenuhi agar suatu Perangkat Lunak bisa dijalankan. Kebutuhan ini bukan merupakan fungsi utama, namun akan menentukan kualitas dari suatu Perangkat Lunak.

Kebutuhan Non-Fungsional Aplikasi Pembayaran ( Kasir )

1. Requirement Operasional

1.1 System bisaberjalan di semua platform yang menggunakan JVM

1.2 System bisamembuat Document HTML dan Word

2. Security Requirements

System menggunakan user Authentification untuk mencegah orang-orang yang tidakberhak

Kebutuhan Fungsional Aplikasi Pembayaran ( Kasir )

1. User melakukan LOGIN kedalam System

1.1 User bisa login sebagai admin

1.2 User bisa login sebagai user biasa

2. System bisamenghitungpembayaran

2.1 System bisamencari data berdasarkan ID barang

2.2 System bisamenghitung total pembayaranpelanggan

2.3 System bisamenghitungpembayarandankembalianpelanggan

3. bisamencetakstrukpembayaranpelanggan

4. bisamembuatlaporan (Admin only)

4.1 System bisamembuatlaporanharian

4.2 System bisamembuatlaporanmingguan

4.3 System bisamembuatlaporanbulanan

5. bisa me-manage inventory barang (Admin only)

5.1 System bisamenambah data baru

5.2 System bisamengedit data lama

5.3 System bisamenghapus data

System bisa menambah dan mengurangi jumlah barang

Bab Pemodelan Kebutuhan
Setelah melakukan Analisa kebutuhan dan mendapatkan kebutuhan-kebutuhan Perangkat Lunak baik dalam hal Data, Fungsi, dan Kebiasaan. Maka, kebutuhan-kebutuhan itu perlu dimodelkan, agar mudah dipahami oleh Pengembang dan Pengguna Aplikasi.

Apa itu Pemodelan Kebutuhan?

"Tulisan merupakan sebuah alat yang hebat untuk berkomunikasi, tetapi bukan cara yang tepat untuk merepresentasikan kebutuhan suatu Perangkat Lunak komputer.Pemodelan Analisis menggunakan kombinasi antara teks dan bentuk-bentuk diagram untuk menggambarkan suatu kebutuhan data, fungsi, dan kebiasaan dengan cara yang relatif mudah dimengerti, dan yang lebih penting, berusaha untuk memastikan kebenaran, kesempurnaan, dan konsistensi.”

Cara-cara membuat Pemodelan Analisis :
Data, fungsi, dan kebiasaan digambarkan dalam beberapa diagram yang berbeda. Model Data mendefinisikan object, atribut, dan hubungan. Model Fungsional mengindikasikan bagaimana data berubah di dalam sistem. Model kebiasaan menggambarkan akibat dari suatu kejadian

Pada dasarnya terdapat 4 model utama untuk menggambarkan suatu kebutuhan Aplikasi, yaitu :
• Model berbasis Skenario (contohnya Use-Case dan User Stories)
• Modela Kelas (contohnya Class Diagram dan Collaboration Diagram)
• Model Data (contohnya Data Flow Diagram dan Entity Relationship Diagram)
• Model Perilaku (contohnya State Diagram dan Sequence Diagram)

III.1 Functional Decomposition Diagram

Sebelum memulai Pemodelan Analisis, diawali dulu dengan menentukan fitur-fitur Aplikasi yang akan dibangun. Functional Decompotition Diagram (FDD) adalah sebuah tool yang bisa membantu analis untuk mendefinisikan proses bisnis dimulai dari kegiatan utama dan dilanjutkan dengan kegiatan yang lebih detail atau spesifik.
Pada prinsipnya, dengan membuat FDD, stakeholders dan analis bisa menemukan dambaran umum dari setiap fungsi-fungsi kerja (dari sudut pandang organisasi) dan dapat menempatkan dengan tepat, pada bagian apa dari fungsi-fungsi kerja yang ada, perangkat lunak akan dibangun. Ini disebut model konteks perangkat lunak.
Di dalam FDD, digambarkan semua kemampuan sistem secara umum dan secara spesifik.

III.2 Scenarion Based Models : Use-Case Diagram

Use-Case dibuat untuk menentukan elemen apa yang terdapat di luar sistem dan yang akan berinteraksi dengan sistem, dalam bentuk kegiatan atau aktivitas tertentu.

III.3 Class Models : Class Diagram

Class Diagram bukan hanya merupakan diagram yang paling banyak digunakan, tetapi juga merupakan diagram yang mempunyai jangkauan terbesar dalam Konsep Pemodelan. Bukan hanya elemen dasar yang dibutuhkan setiap orang, bahkan konsep tingkat lanjut yang jarang digunakan.
Sebuah Class Diagram menggambarkan tipe-tipe ibjek di dalam sistem dan berbagai jenis hubungan yang terdapat dalam sistem itu. Class Diagram juga menampilkan properti dan operasi suatu kelas dan prasyarat yang dibutuhkan sebagai cara agar terhubung denga objek-objek;

Tujuan pembuatan Class Diagram adalah :
1. menggambarkan keadaan(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut(fungsi/method).
2. Menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan , asosiasi, dan lain-lain.

Membangun Model Spesifikasi Software

Apa yang dimaksud dengan Membangun Model Spesifikasi Software?

Kita tahu bersama, setelah tim pengembang dan stakeholders selesai melakukan elisitasi dan pendefinisian persyaratan perangkat lunak, maka langkah selanjutnya adalah membangun model spesifikasi perangkat lunak. Model spesifikasi perangkat lunak, merupakan "gambaran" awal dari setiap kebutuhan fungsional (dan non fungsional) yang akan dikembangkan, sebagai fungsi (atau fitur) perangkat lunak tersebut.

Proses membangun model spesifikasi perangkat lunak, tidaklah sulit, namun memerlukan fokus perhatian yang extra dari tim pengembang. Aktivitas ini merupakan tugas system analyst, dengan tujuan, membangun model sistem perangkat lunak dgn "bahasa" yang dapat dipahami oleh tim pengembang dan, tentu saja stajeholders. Membahasakan sistem perangkat lunak dalam "bahasa" teknis, namun harus dapat dipahami oleh stakeholders adalah tantangan terbesar yang harus dihadapi oleh system analyst.

Biasanya, setelah daftar kebutuhan perangkat lunak, disepakati oleh stakeholders dan tim pengembang, maka system analyst akan segera membuat apa yang disebut requirements model. Inilah yang disebut representasi teknis dari sistem perangkat lunak yang akan dibangun. Proses pemodelan teknis dari requirements software ini, akan menggunakan teks dan diagram.

Aturan-aturan pemodelan spesifikasi teknis, ditulis oleh DeMarco, hingga kini masih digunakan dalam disiplin rekayasa perangkat lunak modern. Alan Davis mengatakan bahwa: ... Suatu pandangan kebutuhan dari sudut pandang tertentu tidak memadai untuk memahami atau mendeskripsikan perilaku yang dikehendaki dari suatu sistem yang kompleks ..., atas dasar pertimbangan DeMarco dan Alan Davis tersebut, maka disiplin pemodelan spesifikasi sistem perangkat lunak, dibedakan menjadi beberapa sudut pandang, yakni:
1). Model berbasis Skenario (scenario-based); model ini merupakan model perangkat lunak, dari sudut pandang user atau pengguna;
2). Model Data; yakni merupakan model yang menjelaskan bagaimana data ditransformasikan dalam sistem perangkat lunak yang akan dikembangkan;
3). Model Kelas (class-oriented); yakni merupakan model yang mendefinisikan objects, attributes serta relasi antar kelas yang ada;
4). Model berorientasi aliran (flow-oriented); adalah model yang menjelaskan bagaimana hubungan antara elemen fungsional dan data berinteraksi; bagaimana data dikelola, saat melintasi sistem perangkat lunak;
5). Model Perilaku (behavioral); yakni menggambarkan bagaiman sistem perangkat lunak "berperilaku" terhadap event-event yang datang dari luar sistem.

Jadi, banyak "model" bukan untuk membingungkan tim pengembang terlebih stakeholders. Justru dengan memandang sistem perangkat lunak dari "berbagai" perspektif, maka tim pengembang dan stakeholders akan semakin "memahami" perangkat lunak yang akan dikembangkan. Singkatnya, model membantu "proses pendefinisian" perangkat lunak.

Menurut Pressman, terdapat 3 tujuan dari tahap ini, yaitu:
1). untuk menjelaskan apa yang diinginkan oleh stakeholders;
2). untuk meletakkan dasar2 bagi tahap sottware design berikutnya;
3). untuk menajamkan sekumpulan requirements perangkat lunak, yang dapat divalidasi, saat akan membangun sistem perangkat lunak tersebut.