Langsung ke konten utama

Input dan Output Requirement Enginering Process

sumber : https://raw.githubusercontent.com/wiki/hlmkmilah/rekayasakebutuhan/SKPL-RK.docx

Dalam input Requirements Enginering Process terdapat beberapa aspek yang perlu di penuhi. Dalam analisis kali ini saya menggunakan studi kasus dokumen SKPL "Point of Sales Minimarket". 

# INPUT

Existing System Information

Dalam industri digital seperti saat ini, diperlukan penyesuaina pada setiap bidang kehidupan salah satunya adalah digitalisasi market. Dalam hal ini adalah Pencatatan transaksi penjualan secara digital dan otomatis. Dengan adanya POSku ini diharapkan semua transaksi dan pemantauan penjualan dapat lebih rapi dan teratur, demi efektifnya peningkatan target penjualan barang di minimarket. 

Stakeholder Needs

Dalam dokumen tersebut stakeholder merupakan Manager yang memerlukan kebutuhan "Memantau Transaksi penjualan dan Kondisi keuangan yang ada". Namun dalam sistem ini melibatkan beberapa user yang memiliki kebutuhan sebagai berikut :

  1. Kasir:
    1. Dapat melakukan login
    2. Dapat melakukan transaksi dengan aplikasi POS
  2. Gudang:
    1. Dapat melihat stok barang
    2. Melakukan pencatatan barang
    3. Melakukan restock suatu barang
  3. Manager:
    1. Melihat kondisi keuangan seperti pemasukkan
    2. Melihat kondisi pengeluaran
    3. Melihat transaksi yang ada
  4. HR:
    1. Melihat pegawai
    2. Melihat status absensi pegawai
    3. Melihat kinerja pegawai dari jam login-logout
    4. Mengatur kepegawaian dan menonaktifkan pegawai
    5. Mengatur gaji pegawa

Organisational Standards

Dalam dokumen tidak dijelaskan organisasi apa yang akan menggunakan sistem ini. Namun jika dapat disimpulkan dari jenis sistem yang akan dibangun, sistem ini merupakan sistem marketing yang pada umumnya seperti pada gambar berikut

Namun pada dokumen tersebut disebutkan standar yang harus dipenuhi oleh sistem yang tercantum dalam kebutuhan Non Fungsional sebagai berikut.


Regulations

Regulation yang digunakan pada sistem ini tercantum pada Batasan pada dokumen SKPL tersebut. Batasan tersebut dapat dipaparkan sebagai berikut.

  1. Aplikasi POSku dibuat dengan menggunakan Bahasa Pemrograman PHP, dengan framework Codeigniter. 
  2. Antarmuka hanya berupa tampilan menu sederhana.
  3. Keterbatasan dari sisi perangkat keras yang digunakan, contohnya kapasitas storage yang terbatas, dan input hanya berupa text dan angka, serta beberapa karakter.
  4. Software pendukung yang digunakan adalah DBMS SQL-Server, Notepad++ dan Sublime text 3, PHP Storm

Domain Information

Sistem ini merupakan kategori Web Aplication pada bidang marketing dan akuntansi. Informasi tersebut akan berguna bagi developer untuk dapat membantu menganalisis kebutuhan stakeholder sehingga domain pengerjaan dapat dipersempit dan lebih terfokus ke arah tersebut.

# OUTPUT 

Agreed Requirements

Berdasarkan studi kasus yang saya ambil, yang dapat diuraikan sebagai berikut :

    1. (SKPL-F1) Dapat melakukan transaksi penjualan.

    2. (SKPL-F2) Dapat mengelola seluruh data barang.

    3. (SKPL-F3) Dapat melihat track record penjualan.

    4. (SKPL-F4) Dapat mengelola transaksi dan barang.

System Spesification

Untuk spesifikasi rincinya sebagai berikut :

    Platform sistem operasi : Microsoft Windows

    Versi sistem operasi : Windows XP/Vista/7/8/10

    DBMS : SQL-Server

    Kerangka kerja : HTML dan PHP

    Framework : Codeigniter

System Model

Berikut adalah flowchart dari sistem informasi:


Nama : Mohammad Faderik 'izzul Haq

NRP : 05111940000023

Kelas : Rekayasa Kebutuhan B


Komentar

Posting Komentar

Postingan populer dari blog ini

Rekayasa Kebutuhan - Sistem Informasi Penyewaan Mobil AutoRent

  sumber : https://www.assarent.co.id/upload/image/jasa-sewa-mobil-jogja.jpg Kebutuhan Funsional dan Non Fungsional aplikasi AutoRent Deadline : Selasa, 08 Juni 2022 : 10.00 WIB AutoRent merupakan sebuah perusahaan penyewa mobil di Kota Surabaya. Sistem penyewaan yang berjalan pada AutoRent belum terkomputerisasi. Pada proses yang berjalan terdapat beberapa masalah seperti proses penyewaan mobil dan pembuatan laporan yang tidak terintegrasi, sehingga menyebabkan kesalahan seperti redudansi data pada proses pembuatan laporan. Berdasarkan masalah tersebut AutoRent berencana membuat sistem yang bisa mempermudah proses penyewaan serta memberikan informasi penyewaan secara online. Berdasarkan informasi permasalahan yang ada dapat didefinisikan beberapa kebutuhan fungsional dan non-fungsional dari aplikasi yang akan dibangun sebagai berikut Kebutuhan Fungsional Functional Requirements merupakan kebutuhan yang mendeskripsikan kelakuan sistem yang mendukung tujuan dari sistem. Kebutuhan
Posting Komentar
Baca selengkapnya

Tahapan Rekayasa Kebutuhan (RE)

     Tahapan Rekayasa Kebutuhan         Dalam bahasan kali ini saya akan membahas mengenai tahapan yang dilakukan seorang developer dalam melakukan Rekayasa Kebutuhan, dalam hal ini saya menggunakan studi kasus Spesifikasi Kebutuhan Perangkat Lunak (SKPL) "Sistem Informasi Survei Kepuasan Pelanggan Its Secara Terpadu". Sistem ini memungkinkan user mengisi survey yang telah dibuat oleh admin yang bertujuan untuk menilai layanan yang dimiliki ITS terhadap para pelanggannya sebagai bahan evaluasi kedepannya. Berikut dokumen SKPL yang saya gunakan.  Elicitation Elicitation merupakan salah satu proses yang fokus untuk memahami keperluan dari stakeholder maupun dari user. Berikut hasil analisis kebutuhan Sistem Informasi Survei Pelanggan ITS. Pengguna Sistem yang dapat menyampaikan penilaian dan pendapatnya terkait layanan yang dimiliki ITS Admin Sistem yang dapat menerima dan mengumpulkan data dari para pelanggan ITS  Sistem yang dapat menampilkan rangkuman dan grafik perkembangan
Posting Komentar
Baca selengkapnya

Analisis Aplikasi Transaksi Parkir Non Tunai

sumber :  https://inugo.com/wp-content/uploads/2018/03/iso-enter-parking.png Analisis Aplikasi Transaksi Parkir Non Tunai           Pada proses Rekayasa Kebutuhan suatu sistem diperlukan analisis terhadap sistem yang akan dibangun. Berikut merupakan contoh studi kasus mengenai Aplikasi Transaksi Parkir Non Tunai. Berikut beberapa aspek yang akan di analisis. 1. Deskripsikan aplikasi Parkir  2. Identifikasi User dan Stakeholder 3. Tulis/ Gambarkan kebutuhan dari masing-masing user/ stakeholder 4. Tentukan aspek lain yang penting supaya aplikasi berjalan lancar Hasil Analisis : 1. Deskripsi Parkir meupakan hal fundamental yang sering dilakukan dalm kehidupan sehari-hari. Sejak dulu dikena; metode parkir konvensional dengan uang, mulai di pasar yang langsung diserahkan pada bapak-bapak tukang parkir, hingga di mall yang diserahkan kepada petugas jaga portal. Hal ini sudah lama menjadi budaya di Indonesia, namun hal ini memiliki beberapa kelemahan yakni efisiensi proses pembayaran yang kur
Posting Komentar
Baca selengkapnya