Situasinya
Sebuah rumah sakit sudah memiliki sistem informasi yang digunakan dalam kegiatan operasional sehari-hari. Sistem tersebut sudah berjalan dan telah mendukung sejumlah proses bisnis yang dibutuhkan oleh pengguna.
Seiring perubahan kebutuhan operasional, ditemukan beberapa bagian proses yang tidak lagi berjalan seefektif sebelumnya. Pengguna juga memiliki kebutuhan baru yang belum sepenuhnya didukung oleh sistem existing.
Sebelum meminta developer melakukan perubahan, pihak rumah sakit sudah melakukan observasi dan wawancara dengan pengguna serta stakeholder terkait. Hasilnya berupa temuan mengenai proses existing, pain point, kebutuhan pengguna, dan beberapa usulan perbaikan.
Masalah sebenarnya: hasil observasi dan wawancara masih berupa informasi bisnis. Informasi tersebut perlu diterjemahkan menjadi requirement dan rancangan yang cukup jelas agar dapat dipahami secara konsisten oleh stakeholder, analyst, designer, maupun developer.
Analisis
Dalam kondisi seperti ini, pekerjaan pertama bukan langsung menulis kode. Yang dibutuhkan adalah requirements engineering untuk menghubungkan masalah operasional dengan perubahan yang harus dilakukan pada sistem.
Hasil observasi dan wawancara perlu dipetakan terhadap proses existing. Dari sana dapat diketahui bagian mana yang masih sesuai, bagian mana yang perlu diperbaiki, dan bagian mana yang membutuhkan use case baru.
1. Memahami proses existing
Proses bisnis yang berjalan perlu dipahami terlebih dahulu sebelum menentukan perubahan. Tujuannya agar perubahan tidak hanya menyelesaikan satu keluhan tetapi justru mengganggu proses lain yang sudah berjalan.
2. Memisahkan masalah dan solusi
Hasil wawancara sering kali sudah mengandung usulan solusi. Misalnya pengguna mengatakan bahwa sistem perlu menambahkan sebuah tombol atau halaman baru. Requirement engineering perlu kembali melihat masalah yang ingin diselesaikan sebelum menentukan bentuk implementasinya.
3. Menentukan use case yang berubah
Tidak semua proses membutuhkan use case baru. Beberapa kebutuhan dapat diselesaikan dengan mengubah alur use case existing, sementara kebutuhan lainnya memang membutuhkan use case baru.
4. Menentukan dampak perubahan
Use case baru dapat memiliki dampak terhadap actor, permission, data, workflow, notification, reporting, integrasi, dan modul lain. Karena itu perubahan perlu dilihat secara menyeluruh.
Dari Observasi dan Wawancara Menjadi Requirement
Observasi dan wawancara merupakan input penting, tetapi hasilnya belum tentu langsung dapat digunakan sebagai spesifikasi pengembangan.
Contoh sederhana: pengguna menyampaikan bahwa proses tertentu membutuhkan persetujuan tambahan. Dari informasi tersebut masih perlu ditentukan siapa yang melakukan persetujuan, kapan proses tersebut terjadi, kondisi apa yang menyebabkan persetujuan diperlukan, data apa yang disimpan, dan apa yang terjadi setelah keputusan dibuat.
| Temuan | Analisis | Output Requirement |
|---|---|---|
| Pengguna melakukan proses secara manual | Identifikasi aktivitas, actor, dan kondisi proses | Automation / workflow requirement |
| Data perlu diperiksa oleh role lain | Identifikasi actor dan authorization | Approval use case |
| Proses memiliki tahapan tambahan | Modelkan state dan activity flow | Updated activity diagram |
| Informasi tertentu belum tersedia | Identifikasi sumber dan kebutuhan data | Data / integration requirement |
Benchmark
Setelah kebutuhan awal dipahami, benchmark dapat digunakan sebagai bahan pembanding. Benchmark bukan berarti menyalin sistem rumah sakit lain, tetapi melihat bagaimana kebutuhan yang serupa dapat diselesaikan pada praktik atau sistem lain.
Benchmark dapat mencakup workflow, pembagian responsibility, approval process, usability, reporting, atau pola interaksi pengguna. Hasilnya kemudian dibandingkan dengan kondisi existing.
Benchmark bukan keputusan final. Keputusan tetap harus mempertimbangkan proses bisnis rumah sakit, kebijakan internal, kebutuhan pengguna, integrasi existing, dan constraint teknis.
Gap Analysis
Hasil observasi, wawancara, kondisi existing, dan benchmark kemudian dapat dipertemukan melalui gap analysis.
| Area | Existing | Target | Gap |
|---|---|---|---|
| Workflow | Proses masih melalui beberapa langkah manual | Workflow terstruktur di sistem | Use case / activity baru |
| Approval | Belum memiliki approval tertentu | Approval dilakukan oleh role terkait | Actor dan permission baru |
| Data | Informasi tersebar pada proses berbeda | Informasi tersedia pada workflow yang relevan | Data requirement / integration |
| Reporting | Informasi belum tersedia secara konsisten | Report sesuai kebutuhan stakeholder | Reporting requirement |
Use Case Baru
Setelah gap diketahui, beberapa kebutuhan dapat diterjemahkan menjadi use case baru. Use case tersebut perlu menjelaskan actor, tujuan, trigger, kondisi awal, alur utama, alternative flow, dan hasil akhir.
Use case diagram kemudian diperbarui agar stakeholder dapat melihat hubungan antara actor dan functionality sistem secara lebih mudah.
Diagram bukan pengganti requirement detail. Diagram membantu memberikan gambaran struktur, sedangkan detail requirement menjelaskan behaviour yang harus dipenuhi sistem.
Activity Diagram
Untuk proses yang memiliki beberapa tahapan, activity diagram dapat digunakan untuk memperjelas workflow. Diagram menunjukkan urutan aktivitas, decision point, kondisi, serta perpindahan proses dari satu actor atau aktivitas ke aktivitas lainnya.
Ini penting terutama ketika hasil wawancara masih menggunakan bahasa operasional seperti "setelah diverifikasi dilanjutkan ke bagian berikutnya". Kalimat tersebut perlu diterjemahkan menjadi alur yang memiliki kondisi dan outcome yang jelas.
SRS — Software Requirements Specification
Setelah requirement cukup matang, kebutuhan dapat dituangkan dalam Software Requirements Specification atau SRS.
SRS menjadi referensi mengenai apa yang harus dilakukan oleh sistem. Dokumen dapat mencakup functional requirements, non-functional requirements, actor, business rules, assumptions, constraint, acceptance criteria, serta kebutuhan integrasi jika relevan.
Contoh isi SRS
Functional Requirement: sistem harus menyediakan proses tertentu sesuai workflow yang disepakati.
Business Rule: proses tertentu hanya dapat dilakukan oleh role yang memiliki kewenangan.
Validation: sistem harus melakukan validasi terhadap data sebelum proses dilanjutkan.
Acceptance Criteria: kondisi keberhasilan requirement ditentukan secara eksplisit sehingga dapat diuji.
SDS — Software Design Specification
SRS menjelaskan apa yang harus dilakukan sistem. Setelah requirement disepakati, SDS dapat digunakan untuk menjelaskan rancangan teknis yang akan digunakan untuk memenuhi requirement tersebut.
Isi SDS dapat mencakup architecture, component, API, data model, integration, sequence, security consideration, deployment impact, serta keputusan desain yang relevan dengan perubahan.
Dengan pemisahan tersebut, stakeholder bisnis tidak harus membaca detail teknis untuk memahami requirement, sementara developer tetap memiliki referensi desain ketika mulai melakukan implementation.
Traceability
Untuk perubahan yang cukup penting, requirement sebaiknya dapat ditelusuri dari sumber kebutuhan sampai implementasi dan testing.
| Sumber | Requirement | Use Case | Test |
|---|---|---|---|
| Wawancara stakeholder | FR-001 | UC-001 | TC-001 |
| Observasi proses | FR-002 | UC-002 | TC-002 |
| Benchmark / gap analysis | FR-003 | UC-003 | TC-003 |
Traceability membantu memastikan bahwa kebutuhan yang ditemukan pada tahap awal tidak hilang ketika masuk ke desain, development, dan testing.
Deliverable
Untuk kasus seperti ini, output pekerjaan dapat disesuaikan dengan tingkat kompleksitas perubahan.
- Technical / business analysis.
- Updated Use Case Diagram.
- Use Case Specification untuk use case yang berubah atau baru.
- Activity Diagram untuk workflow yang terdampak.
- Gap analysis.
- Benchmark analysis.
- SRS — Software Requirements Specification.
- SDS — Software Design Specification.
- Requirement Traceability Matrix jika diperlukan.
- Acceptance criteria dan rekomendasi testing.
Setelah Dokumen Selesai
Dokumen hasil analysis tidak harus mengikat rumah sakit kepada satu vendor tertentu.
SRS dan SDS dapat digunakan sebagai baseline untuk meminta estimasi kepada vendor existing, vendor baru, maupun tim engineering internal. Dengan requirement yang lebih jelas, proposal dari beberapa pihak juga menjadi lebih mudah dibandingkan secara objektif.
Jika dibutuhkan, Deduksi juga dapat melanjutkan pekerjaan ke tahap implementation. Namun development bukan satu-satunya pilihan. Deliverable dapat berdiri sendiri sebagai engineering documentation yang siap diserahkan kepada pihak pengembang lain.
Rekomendasi Deduksi
Mulai dari requirement, bukan dari coding
Validasi temuan terlebih dahulu. Pastikan hasil observasi dan wawancara benar-benar menggambarkan masalah yang ingin diselesaikan.
Modelkan proses existing. Jangan langsung membuat use case baru tanpa memahami workflow yang sudah berjalan.
Gunakan benchmark sebagai pembanding. Praktik lain dapat membantu menemukan alternatif, tetapi keputusan tetap mengikuti kebutuhan dan constraint organisasi.
Dokumentasikan requirement. SRS membuat kebutuhan lebih jelas dan dapat diuji.
Dokumentasikan desain. SDS membantu developer memahami bagaimana requirement akan diwujudkan secara teknis.
Development bisa dipisahkan. Dokumen yang baik memungkinkan organisasi membandingkan vendor atau memilih Deduksi sebagai implementation partner.
Bagaimana dengan biaya?
Pekerjaan requirements engineering tidak sebaiknya dihitung hanya berdasarkan jumlah halaman dokumen. Kompleksitas proses bisnis, jumlah stakeholder, jumlah workflow yang terdampak, integrasi, kebutuhan benchmark, dan kedalaman dokumentasi dapat memengaruhi effort secara signifikan.
Karena itu, pekerjaan dapat dimulai dari assessment atau discovery terlebih dahulu. Setelah scope dan deliverable jelas, barulah effort untuk analysis, documentation, design, maupun implementation dapat diestimasi.
Dokumen bukan tujuan akhirnya. Tujuannya adalah membuat kebutuhan cukup jelas sehingga keputusan bisnis, estimasi vendor, development, dan testing dapat dilakukan dengan risiko yang lebih rendah.
Kesimpulan
Sistem informasi yang sudah berjalan tidak selalu membutuhkan pengembangan langsung ketika masalah baru ditemukan. Dalam banyak kasus, langkah yang lebih tepat adalah memahami masalah terlebih dahulu dan menerjemahkannya menjadi requirement yang dapat dibangun.
Dengan memanfaatkan hasil observasi dan wawancara, kemudian dilengkapi dengan gap analysis dan benchmark, kebutuhan dapat diterjemahkan menjadi use case, activity diagram, SRS, dan SDS.
Hasil akhirnya bukan hanya "dokumen". Organisasi mendapatkan baseline yang dapat digunakan untuk membandingkan vendor, mengurangi ambiguity, memperjelas scope development, dan menjaga agar solusi yang dibangun tetap sesuai dengan masalah awal.