Analisis Bisnis - Panduan Cepat
Apa itu Analisis Bisnis?
Analisis Bisnis adalah sekumpulan tugas, pengetahuan, dan teknik yang diperlukan untuk mengidentifikasi kebutuhan bisnis dan menentukan solusi untuk masalah bisnis perusahaan. Meskipun definisi umumnya serupa, praktik dan prosedur dapat berbeda di berbagai industri.
Dalam industri teknologi informasi, solusi sering kali mencakup komponen pengembangan sistem, tetapi dapat juga terdiri dari perbaikan proses atau perubahan organisasi.
Analisis bisnis juga dapat dilakukan untuk memahami keadaan organisasi saat ini atau untuk berfungsi sebagai dasar untuk identifikasi kebutuhan bisnis. Namun, dalam kebanyakan kasus, analisis bisnis dilakukan untuk menentukan dan memvalidasi solusi yang memenuhi kebutuhan, sasaran, atau sasaran bisnis.
Siapa Analis Bisnis?
Seorang analis bisnis adalah seseorang yang menganalisis organisasi atau domain bisnis (nyata atau hipotetis) dan mendokumentasikan bisnis, proses, atau sistemnya, menilai model bisnis atau integrasinya dengan teknologi. Namun, judul organisasi bervariasi seperti analis, analis bisnis, analis sistem bisnis atau mungkin analis sistem.
Mengapa Analis Bisnis?
Organisasi menggunakan analisis bisnis karena alasan berikut -
Untuk memahami struktur dan dinamika organisasi di mana sistem akan digunakan.
Untuk memahami masalah saat ini dalam organisasi target dan mengidentifikasi potensi peningkatan.
Untuk memastikan bahwa pelanggan, pengguna akhir, dan pengembang memiliki pemahaman yang sama tentang organisasi target.
Pada fase awal proyek, ketika persyaratan diinterpretasikan oleh tim solusi dan desain, peran seorang analis bisnis adalah untuk meninjau dokumen solusi, bekerja sama dengan desainer solusi (tim TI) dan manajer proyek untuk memastikan bahwa persyaratannya jelas.
Dalam organisasi TI ukuran besar yang khas, terutama di lingkungan pengembangan, Anda dapat menemukan tim pengiriman di tempat dan luar negeri yang memiliki peran yang disebutkan di atas. Anda dapat menemukan "Analis Bisnis" yang bertindak sebagai orang kunci yang harus menghubungkan kedua tim.
Kadang-kadang, dia akan berinteraksi dengan pengguna Bisnis dan kadang-kadang pengguna teknis dan akhirnya kepada semua pemangku kepentingan dalam proyek untuk mendapatkan persetujuan dan persetujuan akhir sebelum melanjutkan dengan dokumentasi.
Karenanya, peran BA sangat penting dalam jumpstart yang efektif dan sukses untuk proyek apa pun.
Peran Analis Bisnis TI
Peran seorang analis bisnis dimulai dari menentukan dan memeriksa area bisnis organisasi, kemudian memunculkan persyaratan, menganalisis dan mendokumentasikan persyaratan, mengkomunikasikan persyaratan ini kepada pemangku kepentingan yang sesuai, mengidentifikasi solusi yang tepat dan kemudian memvalidasi solusi untuk menemukan apakah persyaratan memenuhi standar yang diharapkan.
Apa bedanya dengan Profesi lain?
Analisis bisnis berbeda dari analisis keuangan, manajemen proyek, jaminan kualitas, pengembangan organisasi, pengujian, pelatihan dan pengembangan dokumentasi. Namun, tergantung pada organisasinya, seorang Analis Bisnis dapat melakukan beberapa atau semua fungsi terkait ini.
Analis bisnis yang bekerja hanya pada pengembangan sistem perangkat lunak dapat disebut analis bisnis TI, analis bisnis teknis, analis bisnis online, analis sistem bisnis, atau analis sistem.
Analisis bisnis juga mencakup pekerjaan penghubung antara pemangku kepentingan, tim pengembangan, tim penguji, dll
Siklus Hidup Pengembangan Perangkat Lunak
Siklus Hidup Pengembangan Perangkat Lunak (SDLC) adalah proses yang diikuti dalam proyek perangkat lunak, dalam organisasi perangkat lunak. Ini terdiri dari rencana terperinci yang menjelaskan cara mengembangkan, memelihara, mengganti, dan mengubah atau meningkatkan perangkat lunak tertentu. Ini mendefinisikan metodologi untuk meningkatkan kualitas perangkat lunak dan proses pengembangan secara keseluruhan.
SDLC adalah proses yang digunakan oleh analis TI untuk mengembangkan atau mendesain ulang sistem perangkat lunak berkualitas tinggi, yang memenuhi kebutuhan pelanggan dan dunia nyata.
Ini mempertimbangkan semua aspek terkait pengujian perangkat lunak, analisis, dan pemeliharaan pasca-proses.
Fase penting SDLC digambarkan dalam ilustrasi berikut -
Tahap Perencanaan
Setiap aktivitas harus dimulai dengan sebuah rencana. Gagal membuat rencana berarti berencana gagal. Tingkat perencanaan berbeda dari satu model ke model lainnya, tetapi sangat penting untuk memiliki pemahaman yang jelas tentang apa yang akan kita bangun dengan membuat spesifikasi sistem.
Tahap Penentuan
Pada tahap ini, kami menganalisis dan menentukan struktur sistem. Kami mendefinisikan arsitektur, komponen, dan bagaimana komponen ini cocok untuk menghasilkan sistem kerja.
Mendesain Panggung
Dalam desain sistem, fungsi dan operasi desain dijelaskan secara rinci, termasuk tata letak layar, aturan bisnis, diagram proses, dan dokumentasi lainnya. Output dari tahapan ini akan menggambarkan sistem baru sebagai kumpulan modul atau subsistem.
Panggung Bangunan
Ini adalah fase pengembangan. Kami memulai pembuatan kode berdasarkan desain sistem menggunakan kompiler, interpreter, debugger untuk menghidupkan sistem.
Penerapan
Implementasi merupakan bagian dari Panggung Bangunan. Dalam fase ini, kita memulai pembuatan kode berdasarkan desain sistem menggunakan kompiler, interpreter, debugger untuk menghidupkan sistem.
Tahap Pengujian
Saat berbagai bagian sistem diselesaikan; mereka menjalani serangkaian tes. itu diuji terhadap persyaratan untuk memastikan bahwa produk tersebut benar-benar menyelesaikan kebutuhan yang ditangani selama fase persyaratan.
Rencana pengujian dan kasus pengujian digunakan untuk mengidentifikasi bug dan untuk memastikan bahwa sistem bekerja sesuai dengan spesifikasi.
Dalam fase ini, berbagai jenis pengujian seperti pengujian unit, pengujian manual, pengujian penerimaan dan pengujian sistem dilakukan.
Pelacakan Cacat dalam Pengujian
Laporan pengujian perangkat lunak digunakan untuk mengkomunikasikan hasil dari rencana pengujian yang dijalankan. Oleh karena itu, laporan harus berisi semua informasi pengujian yang berkaitan dengan sistem saat ini yang sedang diuji. Kelengkapan laporan akan diverifikasi dalam sesi panduan.
Pengujian untuk sebuah proyek berusaha untuk mencapai dua tujuan utama -
Mendeteksi kegagalan dan cacat pada sistem.
Mendeteksi ketidakkonsistenan antara persyaratan dan implementasi.
Diagram alir berikut menggambarkan Defect Tracking Process -
Untuk mencapai tujuan utama, strategi pengujian untuk sistem yang diusulkan biasanya terdiri dari empat level pengujian.
Ini adalah pengujian unit, pengujian integrasi, pengujian penerimaan, dan pengujian regresi. Subbagian berikut menguraikan tingkat pengujian ini, peran tim pengembangan mana yang bertanggung jawab untuk mengembangkan dan melaksanakannya, dan kriteria untuk menentukan kelengkapannya.
Penyebaran
Setelah fase pengujian berakhir, sistem dilepaskan dan memasuki lingkungan produksi. Setelah produk diuji dan siap digunakan, produk itu dirilis secara resmi di pasar yang sesuai. Terkadang penyebaran produk terjadi secara bertahap sesuai dengan strategi bisnis organisasi.
Produk mungkin pertama kali dirilis dalam segmen terbatas dan diuji di lingkungan bisnis nyata (UAT- Pengujian penerimaan pengguna). Kemudian berdasarkan umpan balik tersebut, produk dapat dirilis apa adanya atau dengan peningkatan yang disarankan di segmen pasar sasaran.
Proses Pasca SDLC
Setelah produk dirilis di pasar, pemeliharaannya dilakukan untuk basis pelanggan yang ada.
Setelah berada di lingkungan produksi, sistem akan mengalami modifikasi karena bug yang tidak terdeteksi atau peristiwa tak terduga lainnya. Sistem dievaluasi dan siklus diulangi untuk memelihara sistem.
Peran Analis Bisnis selama Proses SDLC
Seperti yang dapat kita lihat pada diagram di bawah ini, BA terlibat dalam mendorong persyaratan bisnis dan mengubahnya menjadi persyaratan solusi.
Dia terlibat dalam menerjemahkan fitur solusi ke dalam persyaratan perangkat lunak. Kemudian memimpin dalam fase analisis dan perancangan, menentukan dalam pengembangan kode, kemudian mengikuti fase pengujian selama perbaikan bug sebagai agen perubahan dalam tim proyek dan pada akhirnya memenuhi persyaratan pelanggan.
Analisis Bisnis - Peran
Peran seorang analis bisnis dalam Proyek TI bisa berlipat ganda. Anggota tim proyek dapat memiliki banyak peran dan tanggung jawab. Dalam beberapa proyek, BA dapat mengambil peran Business Intelligence Analyst, Database Designer, Software Quality Assurance Specialist, Tester, dan / atau Trainer jika sumber daya yang tersedia terbatas.
Ini juga memungkinkan untuk Koordinator Proyek, atau Pemimpin Pengembangan Aplikasi, atau Pengembang untuk mengambil peran Analis Bisnis dalam proyek tertentu.
Analisis Bisnis sangat tumpang tindih dengan analisis persyaratan bisnis agar berfungsi seperti biasa dan untuk mengoptimalkan fungsinya. Beberapa contoh Analisis Bisnis adalah -
- Menciptakan Arsitektur Bisnis
- Mempersiapkan Kasus Bisnis
- Melakukan penilaian Risiko
- Persyaratan Elicitation
- Analisis Proses Bisnis
- Dokumentasi Persyaratan
Peran Utama dari BA
Peran kunci dari sebagian besar analis bisnis adalah menjadi penghubung antara bisnis dan pengembang teknis. Analis bisnis dapat bekerja sama dengan klien bisnis untuk mengumpulkan / menentukan persyaratan sistem atau proses untuk meningkatkan produktivitas sementara pada saat yang sama bekerja dengan tim teknis untuk merancang dan mengimplementasikan sistem / proses.
Sebagai Kontributor
Tanggung jawab utama BA adalah berkontribusi pada pengembangan pengguna Bisnis / pengguna utama dalam mengidentifikasi masalah bisnis, kebutuhan dan fungsi, memahami kekhawatiran dan persyaratan pemangku kepentingan untuk mengidentifikasi peluang peningkatan, dan memberikan masukan bisnis untuk mengembangkan kasus bisnis untuk TI. proyek pengembangan sistem.
Sebagai Fasilitator
Seorang Analis Bisnis juga diharapkan untuk memfasilitasi / berkoordinasi dalam elisitasi dan analisis persyaratan, berkolaborasi dan berkomunikasi dengan pemangku kepentingan dan untuk mengelola harapan dan kebutuhan mereka, dan memastikan persyaratan lengkap, tidak ambigu dan memetakannya ke kebutuhan bisnis waktu nyata dari sebuah organisasi.
Sebagai Analis
Peran penting lainnya adalah menilai sistem yang diusulkan dan kesiapan organisasi untuk implementasi sistem dan memberikan dukungan kepada pengguna dan berkoordinasi dengan staf TI.
Untuk membantu meninjau dan memberikan masukan untuk desain sistem TI yang diusulkan dari perspektif bisnis, menyelesaikan masalah / konflik di antara para pemangku kepentingan, membantu mengatur UAT yang komprehensif dan berkualitas dengan membantu pengguna dalam mengembangkan kasus uji, dan membantu mengatur pelatihan dengan tujuan memastikan menerapkan sistem TI yang mampu memenuhi kebutuhan dan kebutuhan bisnis serta mewujudkan manfaat yang diharapkan.
Merencanakan dan memantau kegiatan analisis Bisnis untuk pengembangan ruang lingkup, jadwal dan pendekatan untuk melakukan kegiatan yang berkaitan dengan analisis bisnis untuk proyek pengembangan sistem TI, memantau kemajuan, berkoordinasi dengan manajer Proyek Internal dan melaporkan pendapatan, profitabilitas, risiko dan masalah di mana pun sesuai.
Tanggung Jawab Utama dari Analis Bisnis
Tanggung jawab seorang analis bisnis akan mengharuskannya untuk memenuhi tugas yang berbeda dalam fase proyek yang berbeda dan mereka dijelaskan di bawah ini -
Fase Inisiasi
Fase ini akan menandai dimulainya proyek baru dan analis bisnis akan memvariasikan tanggung jawab berikut -
- Membantu dalam melaksanakan analisis biaya-manfaat proyek.
- Pahami kasus bisnis.
- Pastikan kelayakan solusi / proyek / produk.
- Membantu dalam membuat piagam proyek.
- Identifikasi pemangku kepentingan dalam proyek.
Tahap Perencanaan
Fase ini akan melibatkan pengumpulan persyaratan dan perencanaan, bagaimana proyek akan dijalankan dan dikelola. Tanggung jawabnya akan mencakup fungsi di bawah ini -
- Memperoleh persyaratan
- Menganalisis, mengatur, dan mendokumentasikan persyaratan.
- Kelola persyaratan dengan membuat Kasus penggunaan, RTM, BRD, SRS, dll.
- Menilai solusi yang diusulkan.
- Menjadi penghubung dan meningkatkan komunikasi dengan pemangku kepentingan.
- Membantu dalam merumuskan rencana manajemen proyek.
- Membantu menemukan ruang lingkup, kendala, asumsi dan risiko proyek.
- Membantu merancang pengalaman pengguna dari solusi tersebut.
Tahap Pelaksanaan
Fase ini menandai pengembangan solusi sesuai persyaratan yang dikumpulkan. Tanggung jawabnya meliputi -
Jelaskan persyaratan kepada tim TI / pengembangan.
Memperjelas keraguan, kekhawatiran tentang solusi yang diusulkan untuk dikembangkan.
Diskusikan dan prioritaskan perubahan ruang lingkup proyek dan dapatkan kesepakatan.
Buat skrip pengujian beta untuk pengujian awal.
Berbagi modul yang sedang berkembang dengan pemangku kepentingan dan meminta umpan balik mereka.
Mengikuti tenggat waktu dan mengelola harapan pemangku kepentingan.
Menyelesaikan konflik dan mengelola komunikasi dengan tim proyek.
Tahap Pemantauan dan Pengendalian
Dalam fase ini, proyek diukur dan dikontrol untuk setiap penyimpangan dari rencana awal. Fase ini berjalan bersamaan dengan fase eksekusi.
Mengembangkan skrip pengujian dan melakukan pengujian modul dan integrasi yang komprehensif.
Melakukan UAT (menggunakan pengujian penerimaan) dan membuat laporan pengujian.
Dapatkan penerimaan / persetujuan kiriman dari klien.
Jelaskan permintaan perubahan kepada tim pengembangan.
Pantau perkembangan permintaan perubahan dan verifikasi implementasinya sesuai tujuan proyek.
Fase Penutupan
Fase ini menandai penutupan proyek. Tanggung jawabnya adalah -
Mempresentasikan proyek yang telah selesai kepada klien dan mendapatkan penerimaan mereka.
Buat manual pelatihan pengguna, materi fungsional apa pun, dan panduan instruksional lainnya.
Lakukan pengujian integrasi yang rumit dalam lingkungan produksi.
Buat dokumentasi produk akhir, dokumentasikan pelajaran proyek yang dipelajari.
BA Apa yang Diharapkan untuk Disampaikan?
Seorang Analis Bisnis berfungsi sebagai jembatan antara pengguna bisnis dan orang teknis TI. Kehadiran mereka akan memberikan kontribusi yang signifikan bagi keberhasilan proyek TI. Ada banyak keuntungan memiliki analis bisnis yang berdedikasi. Seorang analis bisnis yang berdedikasi dapat -
Memberikan cakupan proyek yang jelas dari sudut pandang bisnis.
Kembangkan kasus bisnis yang sehat dan estimasi sumber daya dan keuntungan bisnis yang lebih realistis.
Mempersiapkan laporan yang lebih baik tentang pelingkupan proyek, perencanaan dan manajemen dalam hal biaya dan jadwal, terutama untuk proyek TI skala besar.
Menghasilkan persyaratan yang jelas dan ringkas, yang pada gilirannya membantu memberikan persyaratan yang lebih jelas dan akurat, jika proyek TI dialihdayakan.
Dapatkan kebutuhan bisnis nyata dari pengguna dan kelola ekspektasi pengguna secara efektif.
Meningkatkan kualitas desain untuk sistem TI yang diusulkan sehingga memenuhi persyaratan pengguna.
Memastikan kualitas sistem yang dikembangkan sebelum diteruskan ke pengguna akhir untuk ditinjau dan diterima.
Mengatur uji kualitas yang komprehensif pada sistem yang dikirimkan dan memberikan umpan balik kepada orang teknis TI.
Analisis Bisnis - Alat dan Teknik
Seorang Analis Bisnis harus terbiasa dengan berbagai alat analisis dan teknologi terkait saat Anda mengenakan topi BA. Maksud saya, jika Anda memegang posisi ini.
Seperti yang telah kita pelajari sebelumnya, analisis bisnis adalah proses di mana Anda mencoba memahami perusahaan bisnis dan mengidentifikasi peluang, area masalah, masalah, dan bertemu dengan berbagai orang yang memiliki berbagai peran dan tanggung jawab seperti CEO, VP, Direktur dan memahami kebutuhan bisnis mereka.
Pada dasarnya, ada 3 jenis analisis Bisnis yang dapat kita kategorikan menjadi -
Strategic Analysis- Analisis bisnis strategis berkaitan dengan pekerjaan pra-proyek. Ini adalah metode atau proses untuk mengidentifikasi masalah bisnis, merancang strategi bisnis, tujuan dan sasaran membantu manajemen puncak. Ini memberikan pelaporan informasi manajemen untuk proses pengambilan keputusan yang efektif.
Tactical Analysis - Ini melibatkan pengetahuan tentang teknik analisis bisnis tertentu untuk diterapkan pada waktu yang tepat dalam proyek yang sesuai.
Operational Analysis- Pada jenis Analisis Bisnis ini, kami memfokuskan pada aspek bisnis dengan memanfaatkan teknologi informasi. Ini juga merupakan proses mempelajari sistem operasional dengan tujuan mengidentifikasi peluang untuk peningkatan bisnis.
Untuk setiap jenis analisis, ada seperangkat alat yang tersedia di pasar dan berdasarkan kebutuhan dan persyaratan organisasi, ini akan digunakan.
Namun, untuk mewujudkan kebutuhan bisnis menjadi informasi yang dapat dipahami, BA yang baik akan memanfaatkan teknik Pencarian Fakta, Wawancara, Review Dokumentasi, Kuisioner, Sampling dan Penelitian dalam aktivitas sehari-hari.
Persyaratan Fungsional dan Non Fungsional
Kami dapat memecah persyaratan menjadi dua jenis utama seperti persyaratan Fungsional dan Nonfungsional.
Untuk semua proyek teknologi, persyaratan fungsional dan non-fungsional harus dipisahkan dan dianalisis secara terpisah.
Untuk menentukan alat yang tepat dan teknik yang tepat mungkin merupakan tantangan yang menakutkan. Apakah Anda sedang membuat aplikasi baru atau membuat perubahan pada aplikasi yang sudah ada. Mempertimbangkan teknik yang tepat untuk proses fungsional adalah seni tersendiri.
Gambaran umum tentang teknik analisis bisnis yang banyak digunakan yang saat ini ada di pasar -
| Proses | Teknik | Process Deliverables (Hasil) |
|---|---|---|
| Untuk Menentukan Kebutuhan Fungsional dan Non Fungsional |
|
Business Requirements Documents -
Common Template -
|
Penerapan Alat dan Proses
Meskipun ada berbagai alat dan prosedur yang tersedia untuk analis bisnis, semuanya tergantung pada praktik organisasi saat ini dan bagaimana mereka ingin menggunakannya.
Sebagai contoh, root-cause analysis digunakan ketika ada kebutuhan untuk masuk lebih dalam ke area atau fungsi penting tertentu.
Namun, dokumen persyaratan bisnis adalah cara yang paling populer dan diterima untuk meletakkan persyaratan dalam format dokumentasi.
Pada bab-bab selanjutnya, kita akan membahas beberapa teknik di atas secara mendalam.
Analisis Bisnis - Sesi JAD
Joint Application Development (JAD) adalah proses yang digunakan untuk mengumpulkan kebutuhan bisnis sambil mengembangkan sistem informasi baru untuk perusahaan. Proses JAD juga dapat mencakup pendekatan untuk meningkatkan partisipasi pengguna, mempercepat pengembangan dan meningkatkan kualitas spesifikasi. Tujuan sesi JAD adalah untuk mengumpulkan pakar materi pelajaran / Analis bisnis atau spesialis TI untuk memberikan solusi.
Seorang analis bisnis adalah orang yang berinteraksi dengan seluruh grup dan mengumpulkan informasi, menganalisisnya, dan mengeluarkan dokumen. Ia memainkan peran yang sangat penting dalam sesi JAD.
Penggunaan Sesi JAD
Sesi JAD sangat terstruktur, lokakarya yang difasilitasi yang mempertemukan pengambil keputusan pelanggan dan staf TI untuk menghasilkan kiriman berkualitas tinggi dalam waktu singkat.
Dengan kata lain, Sesi JAD memungkinkan pelanggan dan pengembang untuk segera mencapai kesepakatan tentang ruang lingkup dasar, tujuan dan spesifikasi proyek atau dalam kasus, tidak mencapai kesepakatan yang berarti proyek perlu dievaluasi ulang.
Sederhananya, sesi JAD bisa
Simplify - Ini menggabungkan pertemuan berbulan-bulan dan panggilan telepon menjadi lokakarya terstruktur.
Identify - Masalah dan peserta
Quantify - Informasi dan kebutuhan pemrosesan
Clarify - Mengkristal dan mengklarifikasi semua persyaratan yang disepakati dalam sesi.
Unify - Output dari satu fase pengembangan adalah input ke fase berikutnya.
Satisfy- Pelanggan menentukan sistem; oleh karena itu, itu adalah sistem mereka. Partisipasi bersama membawa bagian dalam hasil; mereka berkomitmen pada kesuksesan sistem.
Peserta dalam Sesi JAD
Peserta yang terlibat dalam sesi JAD adalah sebagai berikut -
Sponsor eksekutif
Sponsor eksekutif adalah orang yang menjalankan proyek ─ pemilik sistem. Mereka biasanya berasal dari posisi yang lebih tinggi dan mampu membuat keputusan dan menyediakan strategi, perencanaan, dan arahan yang diperlukan.
Ahli Subjek
Ini adalah pengguna bisnis dan pakar luar yang dibutuhkan untuk lokakarya yang sukses. Pakar materi pelajaran adalah tulang punggung sesi JAD. Mereka akan mendorong perubahan.
Penyedia
Dia memimpin rapat; ia mengidentifikasi masalah yang dapat diselesaikan sebagai bagian dari rapat. Fasilitator tidak memberikan informasi pada pertemuan tersebut.
Pengguna Utama
Pengguna kunci atau juga disebut sebagai pengguna super dalam beberapa kasus telah digunakan secara bergantian dan masih berbeda dari satu perusahaan ke perusahaan lainnya. Pengguna utama umumnya adalah pengguna bisnis yang lebih selaras dengan proyek TI dan bertanggung jawab atas konfigurasi profil anggota tim mereka selama proyek berlangsung.
Sebagai Contoh: Misalkan John adalah pengguna kunci dan Nancy, Evan adalah pengguna sistem SAP. Dalam hal ini, Nancy dan Evan tidak memiliki akses untuk mengubah fungsionalitas dan profil sedangkan John sebagai pengguna Key memiliki akses untuk mengedit profil dengan lebih banyak otorisasi.
Pendekatan JAD, dibandingkan dengan praktik yang lebih tradisional, dianggap mengarah pada waktu pengembangan yang lebih cepat dan kepuasan klien yang lebih besar, karena klien dilibatkan selama proses pengembangan. Sebagai perbandingan, dalam pendekatan tradisional untuk pengembangan sistem, pengembang menyelidiki persyaratan sistem dan mengembangkan aplikasi, dengan masukan klien yang terdiri dari serangkaian wawancara.
Teknik Pengumpulan Kebutuhan
Teknik menggambarkan bagaimana tugas dilakukan dalam keadaan tertentu. Sebuah tugas mungkin tidak memiliki satu atau lebih teknik terkait. Suatu teknik harus terkait dengan setidaknya satu tugas.
Berikut ini adalah beberapa teknik pengumpulan persyaratan yang terkenal -
Brainstorming
Brainstorming digunakan dalam pengumpulan kebutuhan untuk mendapatkan ide sebanyak mungkin dari sekelompok orang. Umumnya digunakan untuk mengidentifikasi solusi yang mungkin untuk masalah, dan memperjelas detail peluang.
Analisis Dokumen
Meninjau dokumentasi dari sistem yang ada dapat membantu saat membuat dokumen proses AS-IS, serta mendorong analisis kesenjangan untuk pelingkupan proyek migrasi. Di dunia yang ideal, kami bahkan akan meninjau persyaratan yang mendorong pembuatan sistem yang ada - titik awal untuk mendokumentasikan persyaratan saat ini. Kumpulan informasi sering kali terkubur dalam dokumen yang ada yang membantu kami mengajukan pertanyaan sebagai bagian dari validasi kelengkapan persyaratan.
Kelompok yang terfokus
Grup fokus adalah kumpulan orang-orang yang mewakili pengguna atau pelanggan suatu produk untuk mendapatkan umpan balik. Umpan balik dapat dikumpulkan tentang kebutuhan / peluang / masalah untuk mengidentifikasi persyaratan, atau dapat dikumpulkan untuk memvalidasi dan menyempurnakan persyaratan yang telah diperoleh. Bentuk riset pasar ini berbeda dari brainstorming karena merupakan proses yang dikelola dengan peserta tertentu.
Analisis antarmuka
Antarmuka untuk produk perangkat lunak dapat berupa manusia atau mesin. Integrasi dengan sistem dan perangkat eksternal hanyalah antarmuka lain. Pendekatan desain yang berpusat pada pengguna sangat efektif dalam memastikan bahwa kami membuat perangkat lunak yang dapat digunakan. Analisis antarmuka - meninjau titik kontak dengan sistem eksternal lain penting dilakukan untuk memastikan kami tidak mengabaikan persyaratan yang tidak langsung terlihat oleh pengguna.
Wawancara
Wawancara pemangku kepentingan dan pengguna sangat penting untuk menciptakan perangkat lunak yang hebat. Tanpa memahami tujuan dan harapan pengguna dan pemangku kepentingan, kami sangat tidak mungkin dapat memuaskan mereka. Kami juga harus mengenali perspektif setiap orang yang diwawancarai, sehingga kami dapat menimbang dan menanggapi masukan mereka dengan baik. Mendengarkan adalah keterampilan yang membantu analis hebat mendapatkan nilai lebih dari wawancara daripada analis biasa.
Pengamatan
Dengan mengamati pengguna, seorang analis dapat mengidentifikasi aliran proses, langkah-langkah, titik nyeri, dan peluang untuk perbaikan. Pengamatan bisa pasif atau aktif (mengajukan pertanyaan sambil mengamati). Pengamatan pasif lebih baik untuk mendapatkan umpan balik pada prototipe (untuk menyempurnakan persyaratan), di mana pengamatan aktif lebih efektif untuk mendapatkan pemahaman tentang proses bisnis yang ada. Salah satu pendekatan dapat digunakan.
Pembuatan prototipe
Pembuatan prototipe adalah teknik yang relatif modern untuk mengumpulkan persyaratan. Dalam pendekatan ini, Anda mengumpulkan persyaratan awal yang Anda gunakan untuk membuat versi awal solusi - prototipe. Anda menunjukkan ini kepada klien, yang kemudian memberi Anda persyaratan tambahan. Anda mengubah aplikasi dan berputar-putar dengan klien lagi. Proses berulang ini berlanjut hingga produk memenuhi kebutuhan bisnis massa kritis atau untuk jumlah iterasi yang disepakati.
Lokakarya Persyaratan
Lokakarya bisa sangat efektif untuk mengumpulkan persyaratan. Lebih terstruktur daripada sesi curah pendapat, pihak yang terlibat berkolaborasi untuk mendokumentasikan persyaratan. Salah satu cara untuk menangkap kolaborasi tersebut adalah dengan membuat artefak model domain (seperti diagram statis, diagram aktivitas). Sebuah lokakarya akan lebih efektif dengan dua analis dibandingkan dengan satu orang.
Rekayasa Terbalik
Ketika proyek migrasi tidak memiliki akses ke dokumentasi yang memadai dari sistem yang ada, rekayasa balik akan mengidentifikasi apa yang dilakukan sistem. Ini tidak akan mengidentifikasi apa yang harus dilakukan sistem, dan tidak akan mengidentifikasi kapan sistem melakukan hal yang salah.
Survei / Kuesioner
Saat mengumpulkan informasi dari banyak orang - terlalu banyak untuk diwawancarai dengan keterbatasan anggaran dan waktu - survei atau kuesioner dapat digunakan. Survei dapat memaksa pengguna untuk memilih dari pilihan, menilai sesuatu ("Setuju Sangat, setuju ..."), atau memiliki pertanyaan terbuka yang memungkinkan tanggapan bentuk bebas. Desain survei sulit - pertanyaan dapat membuat responden bias.
Dokumen Persyaratan Fungsional
Dokumen Persyaratan Fungsional (FRD) adalah pernyataan formal dari persyaratan fungsional aplikasi. Ini melayani tujuan yang sama sebagai kontrak. Di sini, pengembang setuju untuk memberikan kemampuan yang ditentukan. Klien setuju untuk menemukan produk yang memuaskan jika menyediakan kemampuan yang ditentukan dalam FRD.
Persyaratan fungsional menangkap perilaku yang diinginkan dari sistem. Perilaku ini dapat diekspresikan sebagai layanan, tugas, atau fungsi yang harus dilakukan sistem. Dokumen tersebut harus disesuaikan agar sesuai dengan kebutuhan proyek tertentu. Mereka mendefinisikan hal-hal seperti kalkulasi sistem, manipulasi dan pemrosesan data, antarmuka pengguna dan interaksi dengan aplikasi.
Dokumen Persyaratan Fungsional (FRD) memiliki karakteristik sebagai berikut -
Ini menunjukkan bahwa aplikasi memberikan nilai dalam hal tujuan bisnis dan proses bisnis dalam beberapa tahun mendatang.
Ini berisi satu set lengkap persyaratan untuk aplikasi. Tidak ada ruang bagi siapa pun untuk mengasumsikan apa pun yang tidak tercantum dalam FRD.
Ini adalah solusi independen. ERD adalah pernyataan tentang apa yang harus dilakukan aplikasi — bukan cara kerjanya. FRD tidak mengikat pengembang ke desain. Oleh karena itu, referensi apa pun ke penggunaan teknologi tertentu sama sekali tidak sesuai dalam FRD.
Persyaratan fungsional harus mencakup yang berikut -
Deskripsi data untuk dimasukkan ke dalam sistem
Deskripsi operations dilakukan oleh setiap layar
Deskripsi work-flows dilakukan oleh sistem
Deskripsi system reports atau keluaran lainnya
Siapa yang bisa masuk ke data ke dalam sistem?
Bagaimana sistem memenuhi berlaku regulatory requirements?
Spesifikasi fungsional dirancang untuk dibaca oleh khalayak umum. Pembaca harus memahami sistem, tetapi tidak diperlukan pengetahuan teknis untuk memahami dokumen ini.
Kiriman Persyaratan Fungsional
Dokumen Persyaratan Bisnis (BRD) terdiri dari -
Functional Requirements- Dokumen yang berisi persyaratan rinci untuk sistem yang sedang dikembangkan. Persyaratan ini menentukan fitur dan kapabilitas fungsional yang harus dimiliki sistem. Pastikan bahwa asumsi dan kendala yang diidentifikasi selama Kasus Bisnis masih akurat dan mutakhir.
Business Process Model - Model keadaan saat ini dari proses (model "sebagaimana adanya") atau konsep tentang apa proses seharusnya menjadi (model "menjadi")
System Context Diagram - Diagram Konteks menunjukkan batasan sistem, entitas eksternal dan internal yang berinteraksi dengan sistem, dan aliran data yang relevan antara entitas eksternal dan internal ini.
Flow Diagrams (as-is or to-be)- Diagram secara grafis menggambarkan urutan operasi atau pergerakan data untuk proses bisnis. Satu atau lebih diagram alir disertakan tergantung pada kompleksitas model.
Business Rules and Data Requirements - Aturan bisnis menentukan atau membatasi beberapa aspek bisnis dan digunakan untuk menentukan batasan data, nilai default, rentang nilai, kardinalitas, tipe data, perhitungan, pengecualian, elemen yang diperlukan dan integritas relasional dari data.
Data Models - Diagram Relasi Entitas, Deskripsi Entitas, Diagram Kelas
Conceptual Model - Tampilan tingkat tinggi dari berbagai entitas untuk fungsi bisnis dan bagaimana keterkaitannya satu sama lain.
Logical Model - Mengilustrasikan entitas, atribut, dan hubungan spesifik yang terlibat dalam fungsi bisnis dan mewakili semua definisi, karakteristik, dan hubungan data dalam lingkungan bisnis, teknis, atau konseptual.
Data Dictionary and Glossary - Kumpulan informasi rinci tentang elemen data, bidang, tabel, dan entitas lain yang terdiri dari model data yang mendasari database atau sistem manajemen data serupa.
Stakeholder Map- Mengidentifikasi semua pemangku kepentingan yang terpengaruh oleh perubahan yang diusulkan dan tingkat pengaruh / otoritas mereka untuk persyaratan. Dokumen ini dikembangkan dalam fase awal Metodologi Manajemen Proyek (PMM) dan dimiliki oleh Manajer Proyek tetapi perlu diperbarui oleh tim proyek karena Pemangku Kepentingan baru / yang berubah diidentifikasi selama proses.
Requirements Traceability Matrix - Tabel yang mengilustrasikan hubungan logis antara persyaratan fungsional individu dan jenis artefak sistem lainnya, termasuk Persyaratan Fungsional lainnya, Kasus Penggunaan / Kisah Pengguna, Elemen Arsitektur dan Desain, Modul Kode, Kasus Uji, dan Aturan Bisnis.
Spesifikasi Kebutuhan Perangkat Lunak
Software Requirements Specification (SRS) adalah dokumen yang digunakan sebagai media komunikasi antar pelanggan. Spesifikasi kebutuhan perangkat lunak dalam bentuk paling dasar adalah dokumen formal yang digunakan dalam mengkomunikasikan kebutuhan perangkat lunak antara pelanggan dan pengembang.
Dokumen SRS berkonsentrasi pada WHAT perlu dilakukan dan dengan hati-hati menghindari solusinya (how to do). Ini berfungsi sebagai kontrak antara tim pengembangan dan pelanggan. Persyaratan pada tahap ini ditulis menggunakan terminologi pengguna akhir. Jika perlu, nantinya akan dikembangkan spesifikasi kebutuhan formal darinya.
SRS adalah gambaran lengkap tentang perilaku suatu sistem yang akan dikembangkan dan dapat mencakup sekumpulan kasus penggunaan yang menggambarkan interaksi yang akan dimiliki pengguna dengan perangkat lunak.
Tujuan SRS
SRS adalah alat komunikasi antara Pelanggan / Klien, Analis Bisnis, Pengembang Sistem, tim Pemeliharaan. Ini juga bisa menjadi kontrak antara pembeli dan pemasok.
- Ini akan memberikan fondasi yang kokoh untuk fase desain
- Mendukung manajemen dan kontrol proyek
- Membantu dalam pengendalian dan evolusi sistem
Spesifikasi Kebutuhan perangkat lunak harus Lengkap, Konsisten, Dapat Dilacak, Tidak Meragukan, dan Dapat Diverifikasi.
Berikut ini harus dibahas dalam spesifikasi sistem -
- Tentukan fungsi sistem
- Tentukan Partisi Fungsional Perangkat Keras / Perangkat Lunak
- Tentukan Spesifikasi Performa
- Tentukan Partisi Kinerja Perangkat Keras / Perangkat Lunak
- Tentukan Persyaratan Keselamatan
- Tentukan Antarmuka Pengguna (manual pengguna)
- Berikan Gambar / Instruksi Instalasi
- Templat spesifikasi Kebutuhan Perangkat Lunak
Sejarah Revisi
| Tanggal | Deskripsi | Penulis | Komentar |
|---|---|---|---|
| <tanggal> | <Versi 1> | <Nama Anda> | <Revisi Pertama> |
Persetujuan Dokumen
Spesifikasi persyaratan perangkat lunak berikut telah diterima dan disetujui oleh yang berikut -
| Tanda tangan | Nama yang dicetak | Judul | Tanggal |
|---|---|---|---|
| <Nama Anda> | Lead Software Eng. | ||
| David | Pengajar | ||
Analisis Bisnis - Kasus Penggunaan
Salah satu dari sembilan diagram UML adalah Use-case Diagram. Ini tidak hanya penting tetapi juga persyaratan yang diperlukan untuk proyek perangkat lunak. Ini pada dasarnya digunakan dalam siklus hidup Perangkat Lunak. Seperti yang kita ketahui, ada berbagai fase dalam siklus pengembangan dan fase yang paling banyak digunakan untuk Kasus penggunaan adalah selama fase pengumpulan persyaratan.
Apa itu Use-Case?
Kasus penggunaan menggambarkan urutan tindakan, yang dilakukan oleh sistem yang memberikan nilai bagi seorang aktor. Kasus penggunaan menggambarkan perilaku sistem dalam berbagai kondisi karena menanggapi permintaan dari salah satu pemangku kepentingan, yang disebutprimary actor.
Aktornya adalah Siapa dari sistem, dengan kata lain dia pengguna akhir.
Dalam rekayasa perangkat lunak dan sistem, kasus penggunaan adalah daftar langkah-langkah, biasanya mendefinisikan interaksi antara peran (dikenal dalam UML sebagai "aktor") dan sistem, untuk mencapai tujuan. Aktornya bisa manusia atau sistem eksternal.
Kasus penggunaan menentukan aliran peristiwa dalam sistem. Ini lebih mementingkan apa yang dilakukan oleh sistem untuk melakukan urutan tindakan.
Manfaat Use-Case
Kasus penggunaan memberikan manfaat berikut -
Ini adalah cara mudah untuk menangkap kebutuhan fungsional dengan fokus pada nilai tambah bagi pengguna.
Kasus penggunaan relatif mudah untuk ditulis dan dibaca dibandingkan dengan metode persyaratan tradisional.
Kasus penggunaan memaksa pengembang untuk berpikir dari perspektif pengguna akhir.
Kasus penggunaan melibatkan pengguna dalam proses persyaratan.
Anatomi Kasus Penggunaan
Nama : Nama deskriptif yang menggambarkan tujuan kasus penggunaan.
Deskripsi : Menjelaskan apa yang dilakukan use case dalam beberapa kalimat.
Aktor : Buat daftar aktor yang berpartisipasi dalam use case.
Prekondisi : Kondisi yang harus dipenuhi sebelum memulai kasus penggunaan.
Arus peristiwa : Deskripsi interaksi antara sistem dan aktor.
Kondisi Posting : Jelaskan status sistem setelah kasus penggunaan berjalan dengan sendirinya.
Panduan untuk Template Use-Case
Dokumentasikan setiap kasus penggunaan menggunakan templat yang diberikan di akhir bab ini. Bagian ini memberikan deskripsi setiap bagian dalam template kasus penggunaan.
Identifikasi Kasus Penggunaan
Use-Case ID- Beri setiap kasus penggunaan pengenal numerik unik, dalam bentuk hierarki: XY Kasus penggunaan terkait dapat dikelompokkan dalam hierarki. Persyaratan fungsional dapat ditelusuri kembali ke kasus penggunaan berlabel.
Use-Case Name- Sebutkan nama yang ringkas dan berorientasi pada hasil untuk kasus penggunaan. Ini mencerminkan tugas-tugas yang harus diselesaikan pengguna menggunakan sistem. Sertakan kata kerja tindakan dan kata benda. Beberapa contoh -
Lihat informasi nomor bagian.
Tandai sumber hypertext secara manual dan buat tautan ke target.
Lakukan pemesanan CD dengan versi perangkat lunak yang diperbarui.
Riwayat Kasus Penggunaan
Di sini, kami menyebutkan nama-nama orang yang merupakan pemangku kepentingan dari dokumen Usecase.
Created By - Cantumkan nama orang yang pertama kali mendokumentasikan kasus penggunaan ini.
Date Created - Masukkan tanggal kasus penggunaan pertama kali didokumentasikan.
Last Updated By - Berikan nama orang yang melakukan pembaruan terbaru ke deskripsi kasus penggunaan.
Date Last Updated - Masukkan tanggal kasus penggunaan terakhir diperbarui.
Definisi Use-Case
Berikut ini adalah definisi dari konsep utama Use-Case -
Aktor
Aktor adalah orang atau entitas lain di luar sistem perangkat lunak yang ditentukan yang berinteraksi dengan sistem dan melakukan kasus penggunaan untuk menyelesaikan tugas. Aktor yang berbeda sering kali sesuai dengan kelas pengguna yang berbeda, atau peran, yang diidentifikasi dari komunitas pelanggan yang akan menggunakan produk. Sebutkan aktor yang akan melakukan usecase ini.
Deskripsi
Berikan penjelasan singkat tentang alasan dan hasil kasus penggunaan ini, atau deskripsi tingkat tinggi tentang urutan tindakan dan hasil pelaksanaan kasus penggunaan.
Prasyarat
Buat daftar aktivitas apa pun yang harus dilakukan, atau ketentuan apa pun yang harus benar, sebelum kasus penggunaan dapat dimulai. Beri nomor pada setiap prasyarat.
Examples
- Identitas pengguna telah diautentikasi.
- User’s computer has sufficient free memory available to launch task.
Post Conditions
Describe the state of the system at the conclusion of the use-case execution. Number each post condition.
Examples
- Document contains only valid SGML tags.
- Price of item in database has been updated with new value.
Priority
Indicate the relative priority of implementing the functionality required to allow this usecase to be executed. The priority scheme used must be the same as that used in the software requirements specification.
Frequency of Use
Estimate the number of times this use-case will be performed by the actors per some appropriate unit of time.
Normal Course of Events
Provide a detailed description of the user actions and system responses that will take place during execution of the use-case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use-case name and description. This description may be written as an answer to the hypothetical question, “How do I <accomplish the task stated in the use-case name>?” This is best done as a numbered list of actions performed by the actor, alternating with responses provided by the system.
Alternative Courses
Document other, legitimate usage scenarios that can take place within this use-case separately in this section. State the alternative course, and describe any differences in the sequence of steps that take place. Number each alternative course using the Use-case ID as a prefix, followed by “AC” to indicate “Alternative Course”. Example: X.Y.AC.1.
Exceptions
Describe any anticipated error conditions that could occur during execution of the usecase, and define how the system is to respond to those conditions. Also, describe how the system is to respond if the use-case execution fails for some unanticipated reason. Number each exception using the Use-case ID as a prefix, followed by “EX” to indicate “Exception”. Example: X.Y.EX.1.
Includes
List any other use-cases that are included (“called”) by this use-case. Common functionality that appears in multiple use-cases can be split out into a separate use-case that is included by the ones that need that common functionality.
Special Requirements
Identify any additional requirements, such as nonfunctional requirements, for the usecase that may need to be addressed during design or implementation. These may include performance requirements or other quality attributes.
Assumptions
List any assumptions that were made in the analysis that led to accepting this use-case into the product description and writing the use-case description.
Notes and Issues
List any additional comments about this use-case or any remaining open issues or TBDs (To Be Determined) that must be resolved. Identify who will resolve each issue, the due date, and what the resolution ultimately is.
Change Management and Version control
Version control is the management of changes to documents, large websites, and other collection of information. Changes are usually identified by a number or letter code, termed as revision number or revision level. Each revision is associated with a timestamp and person making the change.
Use-Case Diagrams
An important part of the Unified Modeling Language (UML) is the facilities for drawing usecase diagrams. Use-cases are used during the analysis phase of a project to identify and partition system functionality. They separate the system into actors and use-cases. Actors represent roles that can are played by users of the system.
Those users can be humans, other computers, pieces of hardware, or even other software systems. The only criterion is that they must be external to the part of the system being partitioned into use-cases. They must supply stimuli to that part of the system, and the must receive outputs from it.
Use-cases represents the activities that actors perform with the help of your system in the pursuit of a goal. We need to define what those users (actors) need from the system. Use-case should reflect user needs and goals, and should be initiated by an actor. Business, actors, Customers participating in the business use-case should be connected to the use-case by association.
Drawing Use-Case Diagrams
The Figure below shows, what a use-case might look like UML schematic form. The usecase itself looks like an oval. The actors are drawn as little stick figures. The actors are connected to the use-case with lines.
Use-case 1 − Sales Clerk checks out an item
- Customer sets item on counter.
- «uses» Swipe UPC Reader.
- System looks up UPC code in database procuring item description and price
- System emits audible beep.
- System announces item description and price over voice output.
- System adds price and item type to current invoice.
- System adds price to correct tax subtotal
So, the «uses» relationship is very much like a function call or a subroutine.
The use-case being used in this fashion is called an abstract use-case because it cannot exist on its own but must be used by other uses cases.
Example ─ Withdrawal Use-Case
The goal of a customer in relation to our money vending machine (ATM) is to withdraw money. So, we are adding Withdrawal use-case. Withdrawing money from the vending machine might involve a bank for the transactions to be made. So, we are also adding another actor – Bank. Both actors participating in the use-case should be connected to the use-case by association.
Money vending machine provides Withdrawal use-case for the customer and Bank actors.
Relationships between Actors and Use-Cases
Use-cases could be organized using following relationships −
- Generalization
- Association
- Extend
- Include
Generalization between Use-Cases
There may be instances where actors are associated with similar use-cases. In such case a Child use-case inherits the properties and behavior of the parent use. Hence we need to generalize the actor to show the inheritance of functions. They are represented by a solid line with a large hollow triangle arrowhead.
Association between Use-Cases
Associations between actors and use-cases are indicated in use-case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use-case.
Extend
There are some functions that are triggered optionally. In such cases the extend relationship is used and the extension rule is attached to it. Thing to remember is that the base use-case should be able to perform a function on its own even if the extending usecase is not called.
Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use-case to the extended (base) use-case. The arrow is labeled with the keyword «extend».
Include
It is used to extract use-case fragments that are duplicated in multiple use-cases. It is also used to simplify large use-case by splitting it into several use-cases and to extract common parts of the behaviors of two or more use-cases.
Include relationship between use-cases which is shown by a dashed arrow with an open arrowhead from the base use-case to the included use-case. The arrow is labeled with the keyword «include».
Use-cases deal only in the functional requirements for a system. Other requirements such as business rules, quality of service requirements, and implementation constraints must be represented separately.
The diagram shown below is an example of a simple use-case diagram with all the elements marked.
Basic Principles for Successful Application of Use-cases
- Keep it simple by telling stories
- Be productive without perfection
- Understand the big picture
- Identify reuse opportunity for use-cases
- Focus on value
- Build the system in slices
- Deliver the system in increments
- Adapt to meet the team’s needs
Use-Case Template
Here, we have shown a sample template of a Use-Case which a Business Analyst can fill so that the information can be useful for the technical team to ascertain information about the project.
| Use-case ID: | |||
| Use-case Name: | |||
| Created By: | Last Updated By | ||
| Date Created: | Date Last Updated | ||
| Actor: | |||
| Description: | |||
| Preconditions: | |||
| Post conditions: | |||
| Priority: | |||
| Frequency of Use: | |||
| Normal Course of Events: | |||
| Alternative Courses: | |||
| Exceptions: | |||
| Includes: | |||
| Special Requirements: | |||
| Assumptions: | |||
| Notes and Issues: | |||
Business Analysis - Requirements Mngmt
Gathering software requirements is the foundation of the entire software development project. Soliciting and gathering business requirements is a critical first step for every project. In-order to bridge the gap between business and technical requirements, the business analysts must fully understand the business needs within the given context, align these needs with the business objectives, and properly communicate the needs to both the stakeholders and development team.
The key stakeholders wish that someone could explain customer / client requirements in plain English. Will this benefit them from understanding the value at a high-level? This will be the main-focus area, as they will try to map the documentation with the requirements and how BA could communicate in the best possible way.
Why Projects Fail
There are many reasons why projects fail but some of the common areas include the below −
- Market and Strategy Failure
- Organizational and Planning Failures
- Quality Failures
- Leadership and Governance failures
- Skills, Knowledge and competency failures
- Engagement, team work and communication failures
At the core of the issue is that projects are increasingly complex, changes occur and communication is challenging.
Why Successful Teams do Requirements Management
Requirements management is about keeping your team in-sync and providing visibility to what is going on within a project.
It is critical to the success of your projects for your whole team to understand what you are building and why – that’s how we define requirements management. The “why” is important because it provides context to the goals, feedback and decisions being made about the requirements.
This increases predictability of future success and potential problems, allowing your team to quickly course correct any issues and successfully complete your project on time and within budget. As a starting point, it’s valuable for everyone involved to have a basic understanding of what requirements are, and how to manage them.
Let’s Start with the Basics
A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a system or system. Component to satisfy a contract, standard, specification, or other formally imposed documents.
A requirement can be expressed with text, sketches, detailed mockups or models, whatever information best communicates to an engineer what to build, and to a QA manager what to test. Depending on your development process, you might use different terminology to capture requirements.
High-level requirements are sometimes referred to simply as needs or goals. Within software development practices, requirements might be referred to as “use-cases”, “features” or “functional requirements”. Even more specifically within agile development methodologies, requirements are often captured as epics and stories.
Regardless of what your team calls them or what process you use; requirements are essential to the development of all products. Without clearly defining requirements you could produce an incomplete or defective product. Throughout the process there can be many people involved in defining requirements.
A stakeholder might request a feature that describes how the product will provide value in solving a problem. A designer might define a requirement based on how the final product should look or perform from a usability or user interface standpoint.
A business analyst might create a system requirement that adheres to specific technical or organizational constraints. For today’s sophisticated products and software applications being built, it often takes hundreds or thousands of requirements to sufficiently define the scope of a project or a release. Thus, it’s imperative that the team be able to access, collaborate, update, and test each requirement through to completion, as requirements naturally change and evolve over time during the development process.
Now that we’ve defined the value of requirements management at a high-level, let’s go deeper into the four fundamentals that every team member and stakeholder can benefit from understanding −
- Planning good requirements: “What the heck are we building?”
- Collaboration and buy-in: “Just approve the spec, already!”
- Traceability & change management: “Wait, do the developers know that changed?”
- Quality assurance: “Hello, did anyone test this thing?”
Does everyone know what we’re building and why? That’s the value of requirements management.
Collaboration and Buy- In from Stakeholders
Is everyone in the loop? Do we have approval on the requirements to move forward? These questions come up during development cycles. It would be great if everyone could agree on requirements, but for large projects with many stakeholders, this does not usually happen. Trying to get everyone in agreement can cause decisions to be delayed, or worse, not made at all. Gaining consensus on every decision is not always easy.
In practice, you don’t necessarily want “consensus,” you want “buy-in” from the group and approval from those in control so you can move the project forward. With consensus, you are trying to get everyone to compromise and agree on the decision. With buy-in, you are trying to get people to back the best solution, make a smart decision and do what is necessary to move forward.
You don’t need everyone to agree that the decision is the best. You need everyone to support the decision. Team collaboration can help in receiving support on decisions and in planning good requirements.
Collaborative teams work hard to make sure everyone has a stake in projects and provides feedback. Collaborative teams continuously share ideas, typically have better communication and tend to support decisions made because there is a shared sense of commitment and understanding of the goals of the project.
It’s when developers, testers, or other stakeholders feel “out of the loop” that communication issues arise, people get frustrated and projects get delayed. Once everyone has bought-in to the scope of work, it is imperative for requirements to be clear and well documented. Keeping track of all the requirements is where things get tricky.
Imagine having a to-do list a mile long that involves collaborating with multiple people to complete. How would you keep all those items straight? How would you track how one change to an item would affect the rest of the project? This is where traceability and change management add value.
Planning Good Requirements
So, what makes a good requirement? A good requirement should be valuable and actionable; it should define a need as well as provide a pathway to a solution. Everyone on the team should understand what it means. Requirements vary in complexity.
A good Requirements Document can be part of a group with high-level requirements broken down into subrequirements.
They may also include very detailed specifications that include a set of functional requirements describing the behavior or components of the endproduct.
Good requirements need to be concise and specific, and should answer the question, “what do we need?” Rather than, “how do we fulfil a need?”
Good requirements ensure that all stakeholders understand their part of the plan; if parts are unclear or misinterpreted the final product could be defective or fail.
Preventing failure or misinterpretation of requirements can be aided by receiving feedback from the team continuously throughout the process as requirements evolve. Continuous collaboration and buy-in with everyone is a key to success.
Requirement Gathering and Analysis
A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an organizational objective; a condition or capability that must be met or possessed by a system.
Requirement analysis in software engineering covers those tasks that go into determining the needs or conditions to meet for a new or altered product taking account of the possible conflicting requirements of various stakeholders, analyzing, documenting, validating and managing software or system requirements.
The requirements should be −
- Documented
- Actionable
- Measurable
- Testable
- Traceable
Requirements should be related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
A Business analyst gathers information through observing the existing systems, studying the existing procedures, discussions with the customers and the end users. The analyst should also have imaginative and creative skills in absence of a working System. Analyzing the gathered requirement to find the missing links is requirement analysis.
Eliciting Approach
To elicit the objectives, ask the business expert, the development manager, and the project sponsor the following questions −
What business objectives of the company will this project help achieve?
Why are we doing this project now?
What will happen if we do it later?
What if we do not do it at all?
Who will benefit from this project?
Do the people who will benefit from it consider it the most important improvement that can possibly be made at this time?
Should we be doing a different project instead?
Possible objectives might be reducing costs, improving the customer service, simplifying the work flow, replacing obsolete technology, piloting a new technology, and many others. Also, make sure you understand exactly how the proposed project will help accomplish the stated objective.
Different Types of Requirements
The most common types of requirement which a Business analyst is interested would be the following −
Business Requirements
Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objectives while remaining solution independent. A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations.
User Requirements
User requirements should specify the specific requirements which the user expects/wants from software to be constructed from the software project. A user requirement should be Verifiable, Clear and concise, Complete, Consistent, Traceable, Viable.
The user requirements document (URD) or user requirements specification is a document usually used in software engineering that specifies what the user expects the software to be able to do.
System Requirements
System requirements deal with defining software resources requirements and prerequisites that needs to be installed on a computer to provide optimal functioning of an application.
Functional Requirements
Functional requirements capture and specify specific intended behavior of the system being developed. They define things such as system calculations, data manipulation and processing, user interface and interaction with the application, and other specific functionality that show how user requirements are satisfied. Assign a unique ID number to each requirement.
Non-Functional Requirements
Non-functional requirement is the one which specifies criteria that can be used to judge the operation of a system rather than specific behaviors. System architecture speaks on the plan for implementing non-functional requirements.
Non-functional requirements speak on how the system should look like or it can be mentioned like “system shall be”. Non-functional requirements are called as qualities of the system.
Transition Requirements
Transition Requirements describe capabilities that the solution must fulfill in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete.
They are differentiated from other requirements types, because they are always temporary in nature and because they cannot be developed until both an existing and new solution is defined. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation.
Traceability and Change Management
Requirements traceability is a way to organize, document and keep track of all your requirements from initial idea generation through to the testing phase.
The requirements trace ability matrix (RTM) provides a method for tracking the functional requirements and their implementation through the development process. Each requirement is included in the matrix along with its associated section number.
As the project progresses, the RIM is updated to reflect each requirement’s status. When the product is ready for system testing, the matrix lists each requirement, what product component addresses it, and what test verifies that it is correctly implemented
Include columns for each of the following in the RTM −
- Requirement description
- Requirement reference in FRD
- Verification Method
- Requirement reference in Test Plan
Example − Connecting the dots to identify the relationships between items within your project. It is a connector of common downstream flow.
Idea Requirements Design Test Business Objectives
You should be able to trace each of your requirements back to its original business objective.
By tracing requirements, you are able to identify the ripple effect changes have, see if a requirement has been completed and whether it’s being tested properly. Traceability and change management provides managers peace of mind and the visibility needed to anticipate issues and ensure continuous quality.
Quality Assurance
Getting requirements delivered right the first time can mean better quality, faster development cycles and higher customer satisfaction with the product. Requirements management not only helps you get it right, but also helps your team save money and many headaches throughout the development process.
Concise, specific requirements can help you detect and fix problems early, rather than later when it is much more expensive to fix. In addition, it can cost up to 100 times more to correct a defect later in the development process after it’s been coded, than it is to correct early on while a requirement.
By integrating requirements management into your quality assurance process, you can help your team increase efficiency and eliminate rework. Moreover, rework is where most of the cost issues occur.
In other words, development teams are wasting majority of their budgets on efforts that are not performed correctly the first time. For example, a developer codes a feature based on an old specification document, only to learn later, that the requirements for that feature changed. These types of issues can be avoided with effective requirements management best practices.
In summary, requirements management can sound like a complex discipline, but when you boil it down to a simple concept – it’s about helping teams answer the question, “Does everyone understand what we’re building and why?” From the business analysts, product managers and project leaders to the developers, QA managers and testers, along with the stakeholders and customers involved – so often the root cause of project failure is a misunderstanding of the scope of the project.
When everyone is collaborating, and has full context and visibility to the discussions, decisions and changes involved with the requirements throughout the lifecycle of the project, that is when success happens consistently and you maintain continuous quality. In addition, the process is smoother with less friction and frustration along the way for everyone involved.
Note − Research has shown that project teams can eliminate 50-80% of project defects by effectively managing requirements. According to the Carnegie Mellon software engineering institute, “60-80 percent of the cost of software development is in rework.”
Obtaining Requirements Signoff
Requirements signoff formalizes agreement by project stakeholders that the content and presentation of the requirements, as documented, are accurate and complete. Formal agreement reduces the risk that, during or subsequent to implementation, a stakeholder will introduce a new (previously unencountered) requirement.
Obtaining requirements signoff typically involves a face-to-face final review of requirements, as documented, with each project stakeholder. At the end each review, the stakeholder is asked to formally approve the reviewed requirements document. This approval may be recorded either physically or electronically.
Obtaining requirements signoff is typically the final task within Requirements Communication. The Business Analyst will require the output from the Formal Requirements Review(s), including accommodation of any comments or objections which were raised during the review process.
Business Analysis - Modelling
A Business Model can be defined as a representation of a business or solution that often include a graphic component along with supporting text and relationships to other components. For example, if we have to understand a company’s business model, then we would like to study the following areas like −
- Core values of the company
- What it serves?
- What is sets apart?
- Its key resources
- Major relationships
- Its delivery channels
With the help of modelling techniques, we can create a complete description of existing and proposed organizational structures, processes, and information used by the enterprise.
Business Model is a structured model, just like a blueprint for the final product to be developed. It gives structure and dynamics for planning. It also provides the foundation for the final product.
Purpose of Business Modelling
Business modelling is used to design current and future state of an enterprise. This model is used by the Business Analyst and the stakeholders to ensure that they have an accurate understanding of the current “As-Is” model of the enterprise.
It is used to verify if, stakeholders have a shared understanding of the proposed “To-be of the solution.
Analyzing requirements is a part of business modelling process and it forms the core focus area. Functional Requirements are gathered during the “Current state”. These requirements are provided by the stakeholders regarding the business processes, data, and business rules that describe the desired functionality which will be designed in the Future State.
Performing GAP Analysis
After defining the business needs, the current state (e.g. current business processes, business functions, features of a current system and services/products offered and events that the system must respond to) must be identified to understand how people, processes and technology, structure and architecture are supporting the business by seeking input from IT staff and other related stakeholders including business owners.
A gap analysis is then performed to assess, if there is any gap that prevents from achieving business needs by comparing the identified current state with the desired outcomes.
If there is no gap (i.e. the current state is adequate to meet the business needs and desired outcomes), it will probably not be necessary to launch the IT project. Otherwise, the problems/issues required to be addressed in order to bridge the gap should be identified.
Techniques such as SWOT (Strengths, Weaknesses, Opportunities and Threats) Analysis and document analysis can be used.
To Assess Proposed System
BA should assist the IT project team in assessing the proposed IT system to ensure that it meets the business needs and maximizes the values delivered to stakeholders. BA should also review the organization readiness for supporting the transition to the proposed IT system to ensure a smooth System Implementation.
BA should help the IT project team to determine whether the proposed system option and the high-level system design could meet the business needs and deliver enough business value to justify the investment. If there are more than one system options, BA should work with the IT staff to help to identify the pros and cons of each option and select the option that delivers the greatest business value.
Guiding Principles for Business Modelling
The primary role of business modelling is mostly during inception stage and elaboration stages of project and it fades during the construction and transitioning stage. It is mostly to do with analytical aspects of business combined with technical mapping of the application or software solution.
Domain and User variation − Developing a business model will frequently reveal areas of disagreement or confusion between stakeholders. The Business Analyst will need to document the following variations in the as-is model.
Multiple work units perform the same function − Document the variances in the AS-IS model. This may be different divisions or geographies.
Multiples users perform the same work − Different stakeholders may do similar work differently. The variation may be the result of different skill sets and approaches of different business units or the result of differing needs of external stakeholders serviced by the enterprise. Document the variances in the AS-IS model.
Resolution Mechanism − The Business Analyst should document whether the ToBe solution will accommodate the inconsistencies in the current business model or whether the solution will require standardization. Stakeholders need to determine which approach to follow. The To-Be model will reflect their decision.
Example of BA role in Modelling ERP Systems
A Business analyst is supposed to define a standard business process and set up into an ERP system which is of key importance for efficient implementation. It is also the duty of a BA to define the language of the developers in understandable language before the implementation and then, utilize best practices and map them based on the system capabilities.
A requirement to the system is the GAAP fit analysis, which has to balance between −
The need for the technical changes, which are the enhancements in order to achieve identity with the existing practice.
Effective changes, which are related to re-engineering of existing business processes to allow for implementation of the standard functionality and application of process models.
Functional Business Analyst
Domain expertise is generally acquired over a period by being in the “business” of doing things. For example,
A banking associate gains knowledge of various types of accounts that a customer (individual and business) can operate along with detailed business process flow.
An insurance sales representative can understand the various stages involved in procuring of an Insurance policy.
A marketing analyst has more chances of understanding the key stakeholders and business processes involved in a Customer Relationship Management system.
A Business Analyst involved in capital markets project is supposed to have subject matter expertise and strong knowledge of Equities, Fixed Income and Derivatives. Also, he is expected to have handled back office, front office, practical exposure in applying risk management models.
A Healthcare Business Analyst is required to have basic understanding of US Healthcare Financial and Utilization metrics, Technical experience and understanding of EDI 837/835/834, HIPAA guidelines, ICD codification – 9/10 and CPT codes, LOINC, SNOMED knowledge.
Some business analysts acquire domain knowledge by testing business applications and working with the business users. They create a conducive learning environment though their interpersonal and analytical skills. In some cases, they supplement their domain knowledge with a few domain certifications offered by AICPCU/IIA and LOMA in the field of Insurance and financial services. There are other institutes that offer certification in other domains.
Other Major Activities
Following a thorough examination of current business processes, you can offer highly professional assistance in identifying the optimal approach of modelling the system.
Organizing the preparation of a formalized and uniform description of business processes in a manner ensuring efficient automation in the system.
Assistance to your teams in filling out standard questionnaires for the relevant system as may be furnished by the developers.
Participation in working meetings requirements towards the developers are defined.
Check and control as to whether the requirements set by you have been properly “reproduced” and recorded in the documents describing the future model in the system (Blueprints).
Preparation of data and assisting for prototyping the system.
Assistance in preparation of data for migration of lists and balances in the format required by the system.
Review of the set-up prototype for compliance with the requirements defined by the business process owners.
Acting as a support resource to your IT teams in preparing data and actual performance of functional and integration tests in the system.
In the next section, we will discuss briefly about some of the popular Business Modelling Tools used by large organizations in IT environments.
Tool 1: Microsoft Visio
MS-Visio is a drawing and diagramming software that helps transform concepts into a visual representation. Visio provides you with pre-defined shapes, symbols, backgrounds, and borders. Just drag and drop elements into your diagram to create a professional communication tool.
Step 1 − To open a new Visio drawing, go to the Start Menu and select Programs → Visio.
Step 2 − Move your cursor over “Business Process” and select “Basic Flowchart”.
The following screenshot shows the major sections of MS-Visio application.
Let us now discuss the basic utility of each component −
A − the toolbars across the top of the screen are like other Microsoft programs such as Word and PowerPoint. If you have used these programs before, you may notice a few different functionalities, which we will explore later.
Selecting Help Diagram Gallery is a good way to become familiar with the types of drawings and diagrams that can be created in Visio.
B − The left side of the screen shows the menus specific to the type of diagram you are creating. In this case, we see −
- Arrow Shapes
- Backgrounds
- Basic Flowchart Shapes
- Borders and Titles
C − The center of the screen shows the diagram workspace, which includes the actual diagram page as well as some blank space adjacent to the page.
D − The right side of the screen shows some help functions. Some people may choose to close this window to increase the area for diagram workspace, and re-open the help functions when necessary.
Tool 2: Enterprise Architect
Enterprise architect is a visual modeling and design tool based on UML. The platform supports the design and construction of software systems, modeling business processes and modeling industry based domains. It is used by business and organizations to not only model the architecture of their systems. But to process the implementation of these models across the full application development life cycle.
The intent of Enterprise architect is to determine how an organization can most effectively achieve its current and future objectives.
Enterprise architect has four points of view which are as follows −
Business perspective − The Business perspective defines the processes and standards by which the business operates on day to day basis.
Application Perspective − The application perspective defines the interactions among the processes and standards used by the organization.
Information Perspective − This defines and classifies the raw data like document files, databases, images, presentations and spreadsheets that organization requires in order to efficiency operate.
Technology Prospective − This defines the hardware, operating systems, programming and networking solutions used by organization.
Tool 3: Rational Requisite Pro
The process of eliciting, documenting organizing tracking and changing Requirements and communicating this information across the project teams to ensure that iterative and unanticipated changes are maintained throughout the project life cycle.
Monitoring status and controlling changes to the requirement baseline. The Primary elements are Change control and Traceability.
Requisite Pro is used for the above activities and project administration purposes, the tool is used for querying and searching, Viewing the discussion that were part of the requirement.
In Requisite Pro, the user can work on the requirement document. The document is a MS-Word file created in Reqpro application and integrated with the project database. Requirements created outside Requisite pro can be imported or copied into the document.
In Requisite Pro, we can also work with traceability, here it is a dependency relationship between two requirements. Traceability is a methodical approach to managing change by linking requirements that are related to each other.
Requisite Pro makes it easy to track changes to a requirement throughout the development cycle, so it is not necessary to review all your documents individually to determine which elements need updating. You can view and manage suspect relationships using a Traceability Matrix or a Traceability Tree view.
Requisite Pro projects enable us to create a project framework in which the project artifacts are organized and managed. In each project the following are included.
- General project information
- Packages
- General document information
- Document types
- Requirement types
- Requirement attributes
- Attribute values
- Cross-project traceability
Requisite Pro allows multiple user to access the same project documents and database simultaneously hence the project security aspect is to very crucial. Security prevents the system use, potential harm, or data loss from unauthorized user access to a project document.
It is recommended that the security is enabled for all RequisitePro projects. Doing so ensures that all changes to the project are associated with the proper username of the Individual who made the change, thereby ensuring that you have a complete audit trail for all changes.