আমরা ইমেজটা একটু দেখি, একজন কাস্টমার একটি ছোট সবুজ কার চায় ! যিনি প্রোডাক্টটার অর্ডার নিয়েছেন অথবা ঐ কাস্টমারের সাথে প্রোডাক্টটি নিয়ে ডিল করেছেন (প্রোডাক্ট ওনার) তিনি বুজেছেন একটা সবুজ ছোট কার। যেহেতু, বিশেষভাবে বলা হচ্ছে ছোট কার(উনি বুঝেছেন একজন মানুষের জন্য) সেহেতু তিনি কারের ছাদকে বাদ দিয়েছেন। আর যিনি বা যারা কারটি তৈরী করেছেন, তারা খুব সুন্দর ভাবে ছোট একটি সবুজ কার তৈরী করেছেন এবং সেটি তেল দ্বারা চালিত। কিনতু কাস্টমার কি এইরকম কিছু চেয়েছিলো ?
-উত্তর, না ! কাস্টমার আসলে গ্রীন বলতে পরিবেশ বান্দব একটি কারকে বুঝিয়েছেন।
এই যে প্রোডাক্ট কাস্টমার এর satisfication কে ঠিকভাবে পূরণ করতে পারলো না কেন ? কারণ, Requirement গুলো ঠিকভাবে এনালাইসিস করা হয়নি। আজকের লেখাজুড়ে এটা নিয়েই আলোচনা করবো।
Requirement এনালাইসিসকে এক কথায় Requirement ইঞ্জিনিয়ারিং বলা হয়। ইহা একটা প্রসেস যার মাধ্যমে ইউজারের চাহিদামত নতুন প্রোডাক্ট তৈরী কিংবা আগের কোনো প্রোডাক্ট কে মোডিফাই করা হয়. . এই ফিচারগুলোই হলো Requirement , ফিচারগুলো অবশ্যই প্রাসঙ্গিক এবং বিস্তারিত হবে। Requirement আমাদেরকে সরাসরি আমাদের সিস্টেম এর যারা ইউজার তাদের সাথে যোগাযোগ করে দেয় , মানে তাদের কি চাহিদা এবং তারা কেমন প্রোডাক্ট চায় সেটা আমরা প্রোডাক্ট এর Requirement এর মাধ্যমেই পেয়ে থাকি। কোনো প্রোজেক্টে যদি সঠিকভাবে Requirement ডিফাইন করা না থাকে, তবে ঐ প্রোজেক্ট এর সফলতা অনেকটাই ক্ষীণ হয়ে যায়।
Requirement ইঞ্জিনীরিংয়ের প্রসেসগুলো দেখি আসি একনজরে :
১) ফিসিবিলিটি স্টাডি: যখন কোন ক্লায়েন্ট তার কোনো প্রোডাক্ট ডেভেলপ করতে চায় কোনো কোম্পানি থেকে , তখন একজন এনালিস্ট কিছু খসড়া ফিচার(ঐ প্রোডাক্ট এ থাকবে) করে থাকেন , তারপর তিনি ওই ফিচারগুলো নিয়ে বিস্তারিত চিন্তাভাবনা করেন। শুরুর এই প্রসেসই ফিসিবিলিটি স্টাডি।
২) Requirement Eliciation যদি ফিসিবিলিটি স্টাডি ঠিকঠাক থাকে তবে পরিবর্তিত ধাপ হচ্ছে Requirement সংগ্রহ করা ইউজারদের কাছ থেকে। এনালিস্ট এবং ইঞ্জিনিয়াররা end ইউজার যারা থাকে তাদের সাথে যোগাযোগ করে প্রোডাক্ট এ কি যোগ এবং বাদ দিতে হবে এবং ইউজারদের কি দরকার এই জন্য।
৩) Requirement Specification
যখন বিভিন্ন স্টেকহোল্ডারদের থেকে সব Requirement সংগ্রহ করা শেষ হয় তখন Requirement স্পেসিফিকেশন ডকুমেন্ট লিখে থাকেন
একজন এনালিস্ট। প্রোডাক্টটিতে কিরকম কাজ করবে ? কোন ফিচারগুলো মাস্ট থাকবে আবার কোনগুলো অপশনাল। প্রোডাক্টটির পারফরম্যান্স কেমন হবে এগুলো Requirement Specification এর আলোচ্য বিষয়।
৪) Requirement Validation
যখন Requirement Specification ডকুমেন্ট তৈরী হয়ে যায়, ওই ডকুমেন্টে যে Requirement আছে সেগুলো ভ্যালিডেড হয়ে যায়। যদি ইউজার/ এক্সপার্ট Requirement ভ্যালিডেড হওয়ার পর কোনো পরিবর্তন করতে চায় তখন খরচ বেড়ে যায়।
আমরা লেখার শুরুতে একটি উদহারণ দেখেছিলাম , এখন একটি খুবই জনপ্রিয় উদহারণ দেখবো।
একজন কাস্টমার একটি গাছের সাথে দোলনা জাতীয় কিছু একটা বানানোর জন্য প্রোডাক্ট লিড এর কাছে আসলো। প্রোডাক্ট লিড সব কিছু শুনে ভাবলো একটি গাছের সাথে দড়ি দিয়ে বেঁধে একটি কাঠ দিয়ে ঝুলিয়ে দিতে হবে। যিনি এনালিস্ট ছিল উনি ভাবলো দোলনাতা চলবে কীভাবে ? তাই তিনি গাছটি মাঝ খান থেকে কেটে দোলনা ঝোলার মতো একটা ডিসাইন করলো। আর যিনি প্রোগ্রামার ছিল উনি কোড করলেন একটি গাছের সাথে দড়ি দিয়ে বাধা একটি কিছু ! কিনতু, বিসনেস এনালিস্ট যিনি তিনি আবার প্রোডাক্টটির মার্কেটিং করা শুরু করলেন দড়ি দিয়ে ছোফা ঝোলানোর। প্রজেক্টটি কি কোনো ডকুমেন্টেশন করা হয়েছিল? না কোনো ডকুমেন্ট নেই।
যখন প্রোডাক্টটি অপারেশন এ গেলো তখন দেখা গেলো জাস্ট একটি দড়ি ঝুলসে , মানে প্রোডাক্ট ডেপ্লয়মেন্ট ফেইল করেছে। আর কাস্টমার আসলে টাকা দিতে দিতে ফুতুর হওয়ার উপক্রম। যেটুকু, সার্ভিস রান হয়েছে তার আবার কোনো সাপোর্ট নেই।
শেষের ইমেজটা দেখলে আমরা বুঝতে পারি, কাস্টমার গাছের সাথে দোল খেতে পারে এমন একটি কিছু জাস্ট চেয়েছিলো। কিনতু, সঠিক requirement এনালাইসিস না করা এবং ডকুমেন্ট না থাকার জন্য পুরো প্রজেক্টটাই সঠিকভাবে সম্পূর্ণ হয়নি।
নেক্সট আর্টিকেল এ আমি আমার নিজের এক্সপেরিয়েন্স শেয়ার করবো। দেখা হবে আবার।
Written By, Raju Ahmed Rony Data Science & Machine Learning Enthusiast Manager, Idea & Innovation, Youth Carnival Dept. of Software Engineering Daffodil International University LinkedIn: https://www.linkedin.com/in/rarony/