2.8 সফটওয়্যার প্রয়োজনীয়তা

পরিচিতি ও প্রেরণা

একটি সফটওয়্যার প্রয়োজনীয়তা হলো এমন একটি সক্ষমতা বা শর্তের বিবৃতি, যা অংশীজনদের কাছে গ্রহণযোগ্য হতে একটি সিস্টেমকে প্রদান করতে, পূরণ করতে বা ধারণ করতে হবে। প্রয়োজনীয়তা প্রকৌশল, সেই বিবৃতিগুলো সংগ্রহ, বিশ্লেষণ, নির্দিষ্টকরণ, যাচাই ও পরিচালনার শৃঙ্খলাবদ্ধ কাজ, মূল্য-শৃঙ্খলের একেবারে সামনে বসে। স্থাপত্য থেকে কোড থেকে গ্রহণযোগ্যতা পরীক্ষা পর্যন্ত পরবর্তী সবকিছুই প্রয়োজনীয়তা পূরণের চেষ্টা। তাই প্রয়োজনীয়তা ভুল, অসম্পূর্ণ বা অস্পষ্ট হলে ভুল জিনিস সঠিকভাবে গড়তে ব্যয় হওয়া সব পরিশ্রম নিখাদ অপচয়, এবং এটি সবচেয়ে ব্যয়বহুল অপচয়, কারণ আপনি তা আবিষ্কার করেন সবচেয়ে দেরিতে। সফটওয়্যার ইঞ্জিনিয়ারিং বডি অফ নলেজ (SWEBOK)-এর সফটওয়্যার প্রয়োজনীয়তা জ্ঞান-ক্ষেত্র এটিকে প্রকৃত প্রকৌশল শৃঙ্খলা হিসেবে দেখে, আসল কাজের করণিকসুলভ ভূমিকা হিসেবে নয়।

বড় দলের জন্য প্রয়োজনীয়তা হলো সেই ভাগ করা বোঝাপড়া, যা বহু মানুষকে একটি সুসংহত সিস্টেম গড়তে দেয়। একজন ডেভেলপার অভিপ্রায় মাথায় ধরতে পারেন; বহু দল জুড়ে শত শত মানুষ পারেন না। প্রয়োজনীয়তা হয়ে ওঠে যাঁদের সক্ষমতা দরকার আর যাঁরা তা গড়েন তাঁদের মধ্যে চুক্তি, দলগুলোর মধ্যে কাজ ভাগ করার ভিত্তি, এবং কখন কিছু “সম্পন্ন” তা বিচারের মাপকাঠি। এটি সরাসরি আবিষ্কার (অধ্যায় 11.1), যেখানে সমস্যা ও সুযোগ সামনে আসে; UX ভিত্তি (অধ্যায় 5.1), যেখানে আপনি ব্যবহারকারীর প্রয়োজন বোঝেন; API ও ইন্টারফেস নকশা (অধ্যায় 2.3), যেখানে ইন্টারফেসের বাধ্যবাধকতা ঠিক হয়; স্থাপত্য ও গুণমান বৈশিষ্ট্য (অধ্যায় 3.1), যেখানে অ-কার্যকরী প্রয়োজনীয়তা কাঠামো চালায়; এবং প্রকল্প ব্যবস্থাপনার (অধ্যায় 10.6) সঙ্গে যুক্ত, যেখানে পরিসর, খরচ ও সময়সূচি এগুলো ঘিরে পরিকল্পিত হয়।

এন্টারপ্রাইজ ও সরকারি পরিবেশে প্রয়োজনীয়তা আইনি, চুক্তিগত ও নিরাপত্তার ওজন বহন করে। একটি নিয়ন্ত্রিত সিস্টেমকে দেখাতে হয় যে প্রতিটি বাধ্যতামূলক বাধ্যবাধকতা (অভিগম্যতা, গোপনীয়তা, নিরাপত্তা, নথি সংরক্ষণ, আর্থিক নিয়ন্ত্রণ) একটি প্রয়োজনীয়তা হিসেবে ধরা, বাস্তবায়িত এবং প্রমাণসহ যাচাই করা হয়েছে। সরকারি ক্রয় প্রায়ই একটি প্রয়োজনীয়তা স্পেসিফিকেশনকে ঘিরে গড়া, আর অর্থ প্রদান, অডিট ও সনদ নির্ভর করে প্রতিটি প্রয়োজনীয়তাকে তা পূরণের প্রমাণে ফিরে অনুসরণ করার ওপর। এখানে প্রয়োজনীয়তা ভালো চর্চার চেয়েও বেশি: এগুলো জবাবদিহির মেরুদণ্ড।

মূল নীতিসমূহ

• একটি প্রয়োজনীয়তা একটি চাহিদা বা সীমাবদ্ধতা প্রকাশ করে, সমাধান নয়; এটি কী ও কেন বলে, কীভাবে নয়।
• প্রতিটি প্রয়োজনীয়তা হতে হবে প্রয়োজনীয়, দ্ব্যর্থহীন, যাচাইযোগ্য, সম্ভাব্য ও অনুসরণযোগ্য।
• প্রয়োজনীয়তা অংশীজনদের সঙ্গে আবিষ্কৃত ও আলোচিত হয়, বিচ্ছিন্নভাবে উদ্ভাবিত হয় না।
• অ-কার্যকরী প্রয়োজনীয়তা ও সীমাবদ্ধতা কার্যকারিতার মতোই স্থাপত্যকে আকার দেয়।
• প্রয়োজনীয়তা বিবর্তিত হয়; পরিবর্তনকে জমাট বাঁধানো বা উপেক্ষা না করে সুচিন্তিতভাবে পরিচালনা করুন।
• চাহিদা থেকে প্রয়োজনীয়তা, নকশা, টেস্ট থেকে প্রমাণ পর্যন্ত অনুসরণযোগ্যতা জবাবদিহির সংযোগী কলা।
• ঝুঁকি, পরিসর ও নিয়ন্ত্রক প্রেক্ষাপটের ভিত্তিতে, অভ্যাসে নয়, আনুষ্ঠানিকতার সঠিক স্তর নির্ভর করে।

সুপারিশ

প্রয়োজনীয়তা স্পষ্টভাবে সংজ্ঞায়িত করুন এবং শ্রেণিবদ্ধ করুন

শ্রেণিগুলোর সুচিন্তিতভাবে নাম দিন। কার্যকরী প্রয়োজনীয়তা বলে সিস্টেমকে কী করতে হবে: যে আচরণ, রূপান্তর ও সেবা সে দেয়। অ-কার্যকরী প্রয়োজনীয়তা (গুণমান বৈশিষ্ট্য) বলে সেগুলো কতটা ভালোভাবে করতে হবে: পারফরম্যান্স, প্রাপ্যতা, নিরাপত্তা, ব্যবহারযোগ্যতা, অভিগম্যতা, রক্ষণাবেক্ষণযোগ্যতা ও আরও; এগুলো স্থাপত্যের সঙ্গে আঁটসাঁটভাবে বাঁধা (অধ্যায় 3.1)। সীমাবদ্ধতা সমাধানের ওপর অনমনীয় সীমানা: বাধ্যতামূলক প্রযুক্তি, মান, বাজেট, আইনি নিয়ম, বা বিদ্যমান সিস্টেমের ইন্টারফেস। এবং ব্যবসায়িক প্রয়োজনীয়তা (প্রতিষ্ঠান কেন সিস্টেমটি চায়) ব্যবহারকারীর প্রয়োজনীয়তা (ব্যবহারকারীরা কী সম্পন্ন করতে চান) থেকে এবং সিস্টেমের প্রয়োজনীয়তা (সফটওয়্যারকে তাই কী করতে হবে) থেকে আলাদা করুন। এই স্তরগুলো মিশিয়ে ফেললে শিগগির পরিসরের বিভ্রান্তি আসে।

অনুমান নয়, প্রকৃত উৎস থেকে সংগ্রহ করুন

সংগ্রহ সক্রিয় আবিষ্কার। সাক্ষাৎকার, কর্মশালা, পর্যবেক্ষণ, প্রোটোটাইপ এবং বিদ্যমান সিস্টেম ও নথি বিশ্লেষণের মাধ্যমে অংশীজনদের কাছ থেকে প্রয়োজনীয়তা টানুন। প্রতিটি প্রাসঙ্গিক অংশীজনকে খুঁজে বের করুন, যাঁদের উপেক্ষা করা সহজ তাঁদেরও: অপারেটর, নিরীক্ষক, সাপোর্ট কর্মী এবং সিস্টেমে প্রভাবিত কিন্তু সরাসরি ব্যবহার না করা মানুষ। সংগ্রহকে আবিষ্কার পাইপলাইন (অধ্যায় 11.1) ও UX গবেষণার (অধ্যায় 5.1) সঙ্গে বাঁধুন, যাতে ঘোষিত চাহিদা নিচের প্রকৃত প্রয়োজনে ফিরে অনুসরণযোগ্য হয়। প্রতিটি প্রয়োজনীয়তার উৎস ও যুক্তি লিপিবদ্ধ করুন, কারণ একটি প্রয়োজনীয়তা কেন আছে জানাই আপনাকে পরে নিরাপদে তা বদলাতে দেয়।

বিশ্লেষণ, আলোচনা ও অগ্রাধিকার ঠিক করুন

কাঁচা সংগৃহীত চাহিদা সংঘাত করে, ওভারল্যাপ করে এবং সম্ভাব্যের চেয়ে বেশি দাঁড়ায়। বিশ্লেষণ হলো সেগুলো মেলানোর উপায়: প্রয়োজনীয়তা শ্রেণিবদ্ধ করা, সংঘাত চিহ্নিত করা, সম্ভাব্যতা ও ঝুঁকি ওজন করা এবং অংশীজনদের সঙ্গে অগ্রাধিকার নিয়ে আলাপ করা। খোলাখুলি অগ্রাধিকার ঠিক করুন, যেমন অবশ্যই/উচিত/পারে ভেদাভেদ বা মূল্য-বনাম-খরচ ক্রমে, যাতে সময় ফুরালে আপনি সঠিক পরিসর কাটেন। এবং যেখানে মডেল স্পষ্টতা যোগ করে সেখানে প্রয়োজনীয়তা মডেল করুন: প্রক্রিয়ার প্রবাহ, অবস্থা চিত্র, ডেটা মডেল ও ইন্টারফেস সংজ্ঞা সেই ফাঁক সামনে আনে যা গদ্য লুকায়।

সঠিক আনুষ্ঠানিকতার স্তরে নির্দিষ্ট করুন

ঝুঁকি ও পাঠকের সঙ্গে খাপ খাওয়া রূপে প্রয়োজনীয়তা লিখুন। একটি উচ্চ-নিশ্চয়তার সরকারি সিস্টেমে IEEE 29148-এর মতো কোনো মানে কাঠামোবদ্ধ আনুষ্ঠানিক স্পেসিফিকেশন যুক্তিসঙ্গত হতে পারে; একটি দ্রুতগতির পণ্য দল ব্যাকলগে গ্রহণযোগ্যতার মানদণ্ডসহ ইউজার স্টোরি হিসেবে প্রয়োজনীয়তা ধরতে পারে। যেভাবেই হোক, প্রতিটি প্রয়োজনীয়তা হওয়া উচিত পারমাণবিক, যাচাইযোগ্য এবং “দ্রুত”, “ব্যবহারকারী-বান্ধব”, বা “ইত্যাদি”-র মতো পিচ্ছিল শব্দ মুক্ত। গ্রহণযোগ্যতার মানদণ্ড জুড়ুন, যাতে প্রয়োজনীয়তা লেখার একই মুহূর্তে কীভাবে তা যাচাই করবেন তা সংজ্ঞায়িত হয়। এবং ইমেল, টিকেট ও স্লাইডে প্রয়োজনীয়তা ছড়াতে না দিয়ে একটি প্রামাণ্য উৎস রাখুন।

গড়ার আগে যাচাই করুন

যাচাই নিশ্চিত করে যে আপনার নির্দিষ্ট করা প্রয়োজনীয়তাগুলো সঠিক এবং পরস্পরের সঙ্গে সংগতিপূর্ণ। অংশীজনদের সঙ্গে সেগুলো পর্যালোচনা করুন, পরিস্থিতির মধ্য দিয়ে হাঁটুন, এবং যেখানে পারেন বিমূর্ত বিবৃতিকে সুনির্দিষ্ট করতে প্রোটোটাইপ ব্যবহার করুন। যাচাই যেকোনো পরবর্তী সংশোধনের চেয়ে সস্তা: প্রয়োজনীয়তা পর্যালোচনায় ধরা ত্রুটি প্রোডাকশনে ধরা একই ত্রুটির খরচের ভগ্নাংশ।

প্রয়োজনীয়তা পরিচালনা করুন এবং অনুসরণযোগ্যতা বজায় রাখুন

প্রয়োজনীয়তা বদলায়। আপনার কাজ সেই পরিবর্তন নিয়ন্ত্রণ করা, তাকে প্রতিরোধ করা নয়। একটি পরিবর্তন প্রক্রিয়া গড়ুন: গ্রহণের আগে প্রতিটি প্রস্তাবিত পরিবর্তনের প্রভাব, খরচ ও পরবর্তী প্রভাব ওজন করুন। সম্মত বিন্দুতে প্রয়োজনীয়তার ভিত্তিরেখা ঠিক করুন এবং ভার্সন করুন। দ্বিমুখী অনুসরণযোগ্যতা রাখুন, যা প্রতিটি প্রয়োজনীয়তাকে এগিয়ে নকশা, কোড ও টেস্টে এবং পিছিয়ে যে চাহিদা থেকে এসেছে তাতে যুক্ত করে। অনুসরণযোগ্যতা সেই দুটি প্রশ্নের উত্তর দেয়, যার ওপর বড় দল বাঁচে: এই চাহিদা বদলালে কী প্রভাবিত হবে; এবং এই সরবরাহ করা ফিচারের জন্য কোন চাহিদা যুক্তি দিয়েছিল? নিয়ন্ত্রিত প্রেক্ষাপটে অনুসরণযোগ্যতাকে গ্রহণযোগ্যতার প্রমাণ (টেস্টের ফল, অডিট নথি, স্বাক্ষর) পর্যন্ত প্রসারিত করুন, যাতে আপনি কেবল দাবি না করে মান্যতা প্রদর্শন করতে পারেন।

এজাইল ও পরিকল্পনা-চালিত প্রেক্ষাপটে খাপ খাওয়ান

পরিকল্পনা-চালিত ও নিয়ন্ত্রিত কর্মসূচিতে আপনি আনুষ্ঠানিক পরিবর্তন নিয়ন্ত্রণসহ প্রয়োজনীয়তা বেশ আগে নির্দিষ্ট করেন ও ভিত্তিরেখা ঠিক করেন। এজাইল প্রেক্ষাপটে প্রয়োজনীয়তা একটি অগ্রাধিকারযুক্ত, বিবর্তনশীল ব্যাকলগ হিসেবে থাকে, বাস্তবায়নের ঠিক আগে বিস্তৃত হয়, এবং কার্যকর সফটওয়্যারের মাধ্যমে নিরন্তর যাচাই হয়। অন্তর্নিহিত কার্যকলাপ উভয়ে একই; কেবল সময়, আনুষ্ঠানিকতা ও সামগ্রী ভিন্ন। বড় প্রতিষ্ঠান প্রায়ই দুটি মেশায়: তারা স্থিতিশীল, উচ্চ-নিশ্চয়তার বাধ্যবাধকতা আনুষ্ঠানিকভাবে নির্দিষ্ট ও অনুসরণ করে, আর পণ্যের আচরণ পুনরাবৃত্তিমূলকভাবে বিস্তৃত করে। ভারসাম্য বেছে নিন ঝুঁকির ভিত্তিতে, মতাদর্শে নয়।

ট্রেড-অফ: সুবিধা ও অসুবিধা

পদ্ধতি	সবচেয়ে উপযুক্ত	সুবিধা	অসুবিধা
আনুষ্ঠানিক অগ্রিম স্পেসিফিকেশন	উচ্চ-নিশ্চয়তার, নিয়ন্ত্রিত, স্থির-পরিসর চুক্তি	দৃঢ় অনুসরণযোগ্যতা; স্পষ্ট গ্রহণযোগ্যতার ভিত্তি; নিরীক্ষণযোগ্য	বদলাতে ধীর; শেখার আগে অতি-নির্দিষ্টকরণের ঝুঁকি
এজাইল ব্যাকলগ	নিযুক্ত অংশীজনসহ বিবর্তনশীল পণ্য	দ্রুত ফিডব্যাক; শেখার সঙ্গে খাপ খায়; না-গড়া পরিসরে কম অপচয়	দুর্বল দীর্ঘমেয়াদি অনুসরণযোগ্যতা; নিরীক্ষণ ও চুক্তি করা কঠিনতর
হাইব্রিড (আনুষ্ঠানিক সীমাবদ্ধতা + এজাইল আচরণ)	মিশ্র বাধ্যবাধকতার এন্টারপ্রাইজ	যেখানে গুরুত্বপূর্ণ সেখানে কঠোরতা, অন্যত্র নমনীয়তা	কোন অংশ কোনটি তা নিয়ে বিচারবুদ্ধি লাগে

কেন্দ্রীয় টানাপোড়েন স্থিতিশীলতা ও শেখার মধ্যে। আগে প্রয়োজনীয়তা ঠিক করা একটি দৃঢ় গ্রহণযোগ্যতার ভিত্তি ও নিরীক্ষণযোগ্যতা কেনে, কিন্তু গড়ার সময় আপনি যা শেখেন তার সঙ্গে খাপ খাওয়ার সামর্থ্য খরচ করে। পিছিয়ে দেওয়া অভিযোজনযোগ্যতা কেনে, কিন্তু দীর্ঘমেয়াদি অনুসরণযোগ্যতা ও চুক্তিগত স্পষ্টতা খরচ করে। প্রয়োজনীয়তা প্রকৌশলে বেশি বিনিয়োগও পরে কম পুনঃকাজের বিনিময়ে নিকট-মেয়াদি গতি বিনিময় করে: সিস্টেমের পরিসর, দীর্ঘস্থায়িত্ব ও ব্যর্থতার পরিণতি বাড়লে তা প্রতিদান দেয়। সবচেয়ে বড় প্রকল্প এবং সবচেয়ে নিয়ন্ত্রিতগুলো দৃঢ়ভাবে উচ্চ-বিনিয়োগ পাশে। একটি কম-ঝুঁকির অভ্যন্তরীণ টুল নয়।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. আমাদের সর্বোচ্চ-ঝুঁকির সিস্টেমের জন্য কে অংশীজন হিসেবে গণ্য, এবং কাদের আমরা গ্রহণযোগ্যতা পর্যন্ত বাদ রেখে দিই? একটি বড় কর্মসূচিতে যাঁদের বাদ দেওয়া হয় তাঁরা সাধারণত স্পষ্ট ব্যবহারকারী নন: তাঁরা ভোর ৩টায় সিস্টেম চালানো অপারেটর, যাঁদের এটি সনদ দিতে হয় সেই নিরীক্ষক, ব্যর্থতা সামলানো সাপোর্ট কর্মী, এবং কখনো লগইন না করা কিন্তু যাঁদের ডেটা আপনি ধরে রাখেন সেই প্রভাবিত অ-ব্যবহারকারী। তাঁদের বাদ দিলে আপনি তাঁদের প্রয়োজনীয়তা আবিষ্কার করেন সবচেয়ে ব্যয়বহুল মুহূর্তে, গ্রহণযোগ্যতার সময় বা নিয়ন্ত্রক জিজ্ঞেস করার পর। সভায় একটি সুনির্দিষ্ট অংশীজন মানচিত্র আনুন এবং তাতে চাপ দিন: প্রতিটি বাধ্যতামূলক বাধ্যবাধকতার (অভিগম্যতা, গোপনীয়তা, নথি সংরক্ষণ, নিরাপত্তা) জন্য যিনি তার মালিক এবং যে প্রয়োজনীয়তা তা ধরে তার নাম দিন। মালিকের নাম দিতে না পারলে আপনি একটি ফাঁক খুঁজে পেয়েছেন, আর সমাধান হলো সেই অংশীজনকে এখনই সংগ্রহে যোগ করা, পরে স্থির স্থাপত্যে তাঁদের প্রয়োজন জোড়া দেওয়ার বদলে।

2. একটি প্রয়োজনীয়তা বদলালে, পরিবর্তন অনুমোদনের আগে কি আমরা বলতে পারি তা কী প্রভাবিত করে? এটি আপনার দ্বিমুখী অনুসরণযোগ্যতা প্রকৃত নাকি সাজসজ্জা তার ব্যবহারিক পরীক্ষা। একটি বড় বা নিয়ন্ত্রিত সিস্টেমে একটি নিয়ম-পরিবর্তন নকশা, কোড, টেস্ট ও গ্রহণযোগ্যতার প্রমাণে ঢেউ তুলতে পারে, আর অন্ধভাবে অনুমোদন করা মানে এমন একটি বিধি-মান্য-দেখতে সিস্টেম পাঠানো যা নিঃশব্দে এমন নিয়ম লঙ্ঘন করে যা সে আগে পূরণ করত। সভায় একটি সাম্প্রতিক পরিবর্তন অনুরোধ আনুন এবং তা এগিয়ে অনুসরণ করে দেখুন: তাতে একটি বিকেলের প্রত্নতত্ত্ব লাগলে আপনার অনুসরণযোগ্যতা নিজের কাজ করছে না। উত্তর আপনার পরিবর্তন প্রক্রিয়াকে নতুন আকার দেবে, যাতে প্রভাব মূল্যায়ন হাতে-খোঁজার বদলে জীবন্ত অনুসরণের বিপরীতে দ্রুত অনুসন্ধান হয়, এবং ভিত্তিরেখা ও ভার্সনিং আপনাকে বদলানোর জন্য একটি স্থিতিশীল বিন্দু দেয়।

3. আমাদের প্রয়োজনীয়তার একক প্রামাণ্য উৎস কোথায় থাকে, এবং এর বাইরে কতটা সত্য ছড়ানো? প্রয়োজনীয়তার ছড়াছড়ি, প্রকৃত স্পেস ইমেল, টিকেট, স্লাইড ও কারও স্মৃতিতে ছড়িয়ে থাকা, বড় দলের সবচেয়ে সাধারণ ব্যর্থতার একটি, এবং নিরীক্ষিত সিস্টেমে মারাত্মক যেখানে আপনাকে দেখাতে হয় কী সম্মত হয়েছিল। জোরে ঠিক করুন কোন নথি-ব্যবস্থা প্রামাণ্য, এবং অন্য কোথাও বলা যেকোনো কিছুকে খসড়া গণ্য করুন যতক্ষণ না তা উৎস ও যুক্তিসহ সেখানে পৌঁছায়। প্রমাণ আনুন: সাম্প্রতিক কতগুলো পরিসর-বিতর্ক দুই ব্যক্তির ভিন্ন “চূড়ান্ত” সংস্করণ উদ্ধৃত করায় এসে ঠেকেছিল গুনুন। সংখ্যা শূন্যের বেশি হলে পদক্ষেপ হলো একটি উৎসে একত্র করা এবং প্রতিটি প্রয়োজনীয়তার যুক্তি লিখে রাখা, কারণ একটি প্রয়োজনীয়তা কেন আছে জানাই আপনাকে পরে নিরাপদে তা বদলাতে বা বাদ দিতে দেয়।

4. আমাদের অ-কার্যকরী প্রয়োজনীয়তা কি স্থাপত্যকে চালানোর মতো যথেষ্ট আগে ধরা হয়, নাকি কাঠামো ঠিক হওয়ার পরেও আমরা সেগুলো আবিষ্কার করতে থাকি? পারফরম্যান্স, প্রাপ্যতা, নিরাপত্তা ও অভিগম্যতার বাধ্যবাধকতা বেশিরভাগ ফিচারের চেয়ে স্থাপত্যকে বেশি আকার দেয়, এবং একটি বড় কর্মসূচিতে সেগুলোই প্রয়োজনীয়তার মধ্যে সবচেয়ে প্রায়ই দেরিতে সামনে আসে, যখন তা পূরণ করতে হবে এমন কাঠামো ইতিমধ্যে কংক্রিটে ঢালাই হয়ে গেছে। প্রতিদ্বন্দ্বী টান প্রকৃত: কার্যকরী আচরণ অংশীজনরা জোরে চান এবং ভালো ডেমো হয়, আর “শীর্ষ লোডে এক সেকেন্ডের কম সাড়া” বা “WCAG অভিগম্যতা মান্যতা” প্রয়োজনীয়তা লঙ্ঘিত না হওয়া পর্যন্ত অদৃশ্য। আপনার সর্বোচ্চ-ঝুঁকির সিস্টেমের অ-কার্যকরী প্রয়োজনীয়তার বর্তমান তালিকা, প্রতিটি সময়রেখার কোন বিন্দুতে লেখা হয়েছিল, এবং স্থাপত্য (অধ্যায় 3.1) সেগুলো সুস্পষ্ট চালক হিসেবে পেয়েছে নাকি অনুমান করেছে তা আনুন। এন্টারপ্রাইজ ও সরকারি পরিবেশে বাধ্যতামূলক গুণমান বাধ্যবাধকতা (এনক্রিপশন, নথি সংরক্ষণ, অভিগম্যতা আইন) যোগ করুন এবং যাচাই করুন প্রতিটি একটি লিখিত, পরিমাপযোগ্য প্রয়োজনীয়তা যা নকশায় হস্তান্তরিত, অনুমান নয়, কারণ গ্রহণযোগ্যতার পরে গুণমান বৈশিষ্ট্য জুড়ে দেওয়াই সেই জায়গা যেখানে বাজেট ও সময়সূচি নিঃশব্দে মরে।

5. আমাদের মালিকানাধীন প্রতিটি সিস্টেমের জন্য আনুষ্ঠানিকতার সঠিক স্তর কী, এবং আমরা কি তা ঝুঁকি দিয়ে বাছি, নাকি অভ্যাসে? একটি বড় প্রতিষ্ঠান সাধারণত একটি ছড়ানো সিস্টেম চালায়, ফেলনা অভ্যন্তরীণ টুল থেকে জীবন-বা-নিরাপত্তা নিয়ন্ত্রিত প্ল্যাটফর্ম পর্যন্ত, আর সবার জন্য একটি আনুষ্ঠানিকতা প্রয়োগ হয় নিম্ন-ঝুঁকির কাজকে কাগজপত্রে ডুবিয়ে দেয়, নয়তো উচ্চ-ঝুঁকির কাজকে কম-নির্দিষ্ট রাখে। টানাপোড়েন আনুষ্ঠানিক অগ্রিম স্পেসিফিকেশনের নিরীক্ষণযোগ্যতা ও দৃঢ় গ্রহণযোগ্যতার ভিত্তি আর বিবর্তনশীল ব্যাকলগের দ্রুত ফিডব্যাক ও কম অপচয়ের মধ্যে, এবং বেশিরভাগ এন্টারপ্রাইজের জন্য সৎ উত্তর সুচিন্তিত মিশ্রণ: স্থিতিশীল, উচ্চ-নিশ্চয়তার বাধ্যবাধকতা আনুষ্ঠানিকভাবে নির্দিষ্ট ও অনুসরণ করুন, আর পণ্যের আচরণ পুনরাবৃত্তিমূলকভাবে বিস্তৃত করুন। আপনার সিস্টেমের একটি সংক্ষিপ্ত তালিকা আনুন ব্যর্থতার পরিণতি, নিয়ন্ত্রক ঝুঁকি ও পরিবর্তনের হার দিয়ে ক্রমবদ্ধ করে, এবং প্রতিটির জন্য আপনি আসলে যে আনুষ্ঠানিকতা ব্যবহার করেন বনাম ঝুঁকি যে আনুষ্ঠানিকতা দাবি করে তার নাম দিন। একটি সরকারি কর্মসূচি, যা একটি দরপত্র ও IEEE 29148-এর মতো মানের সঙ্গে নোঙর করা, সেখানে আনুষ্ঠানিকতা আংশিকভাবে চুক্তি দ্বারা নির্ধারিত, তাই আলোচনা হলো কোথায় আপনি অডিট যে অনুসরণযোগ্যতার ওপর নির্ভর করে তা না ভেঙে ওপরে এজাইল বিস্তার স্তরবদ্ধ করতে পারেন।

6. আমাদের সর্বোচ্চ-ঝুঁকির সিস্টেমের প্রতিটি প্রয়োজনীয়তা কি যাচাই করা যায়, এবং প্রতিটির কি প্রয়োজনীয়তা লেখার মুহূর্তেই লেখা গ্রহণযোগ্যতার মানদণ্ড আছে? যে প্রয়োজনীয়তা আপনি যাচাই করতে পারেন না তা প্রয়োজনীয়তা নয়, ইচ্ছা, আর “দ্রুত”, “নিরাপদ”, বা “ব্যবহারকারী-বান্ধব”-র মতো পিচ্ছিল শব্দ রিভিউ পার হয় ঠিক কারণ কেউ সেগুলো ব্যর্থ করতে পারে না। বড় দলের জন্য এটি দুবার গুরুত্বপূর্ণ: যাচাই-অযোগ্য প্রয়োজনীয়তা গ্রহণযোগ্যতার সময় পরিসর-বিতর্ক তৈরি করে, এবং একটি ফিচার সত্যিই কখন সম্পন্ন তা বলা অসম্ভব করে। প্রতিদ্বন্দ্বী বিবেচনা গতি, কারণ প্রতিটি প্রয়োজনীয়তায় একটি পরিমাপযোগ্য মানদণ্ড ও যাচাই পদ্ধতি জোড়া গদ্যের চেয়ে অগ্রিম ধীর, কিন্তু এটিই সবচেয়ে ব্যয়বহুল দেরির পুনঃকাজের বিরুদ্ধে সবচেয়ে সস্তা প্রতিরক্ষা। সাম্প্রতিক প্রয়োজনীয়তার একটি নমুনা আনুন এবং প্রতিটিকে একটি সরল মানদণ্ডে পরীক্ষা করুন: এটি কি পারমাণবিক, মাপযোগ্য, এবং কীভাবে যাচাই হবে তার নাম দেয়? নিয়ন্ত্রিত ও সরকারি প্রেক্ষাপটে পরীক্ষাটি প্রমাণ পর্যন্ত বাড়ান: অনুসরণযোগ্য, উত্তীর্ণ গ্রহণযোগ্যতার প্রমাণ ছাড়া একটি প্রয়োজনীয়তা সরবরাহ হয়েছে বলে গণ্য নয়, সফটওয়্যার যা-ই করুক, তাই গ্রহণযোগ্যতার মানদণ্ড সেই বিধি-মান্যতার নথির বীজ, যা আপনাকে শেষ পর্যন্ত তৈরি করতে হবে।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। ক্ষুদ্র দল ও অল্প রানওয়ে নিয়ে প্রয়োজনীয়তা যতটা পারেন হালকা রাখুন: স্পেসিফিকেশন দলিলের বদলে একটি ভাগ করা ব্যাকলগে গ্রহণযোগ্যতার মানদণ্ডসহ ইউজার স্টোরি। এখানেও যে শৃঙ্খলা ফল দেয় তা হলো গড়ার আগে প্রকৃত ব্যবহারকারীদের সঙ্গে কথা বলা এবং প্রতিটি স্টোরির উৎস ও যুক্তি লিপিবদ্ধ করা, যাতে ভুল ফিচার গড়ে যে সপ্তাহ নষ্ট হতো সেই সপ্তাহ বাঁচে। আনুষ্ঠানিক অনুসরণযোগ্যতা এড়িয়ে যান, কিন্তু প্রকৃত চাহিদা কী তা বলে দেওয়া আলাপ কখনো এড়াবেন না।

ছোট ব্যবসা। আপনার সম্ভবত কোনো ব্যবসা বিশ্লেষক বা প্রয়োজনীয়তা বিশেষজ্ঞ নেই, তাই কাজটি গ্রাহকের সবচেয়ে কাছের মানুষের ঘাড়ে পড়ে, এবং কেনা-বনাম-বানানোর প্রশ্ন প্রধান। প্রয়োজনীয়তাকে আপনার দরকারি ফলাফলের একটি সংক্ষিপ্ত, অগ্রাধিকারযুক্ত তালিকা হিসেবে সাজান, তারপর কাস্টম নির্মাণ নির্দিষ্ট করার বদলে তৈরি টুল মূল্যায়নে ব্যবহার করুন। অন্তর্নিহিত চাহিদা ও বিক্রেতার ফিচার তালিকা আলাদা করার ব্যাপারে কঠোর হন, কারণ “আমাদের পণ্য X দরকার” হিসেবে লেখা প্রয়োজনীয়তা নিঃশব্দে সস্তা বিকল্পগুলো বন্ধ করে, যা প্রকৃত চাহিদা মেটাত।

এন্টারপ্রাইজ। পরিসর প্রয়োজনীয়তাকে সেই চুক্তিতে পরিণত করে যা বহু দলকে একটি সুসংহত সিস্টেম গড়তে দেয়, তাই অগ্রাধিকার সামঞ্জস্যপূর্ণভাবে প্রযুক্ত একটি প্রমিত প্রক্রিয়া: সংজ্ঞায়িত শ্রেণি, চাহিদা থেকে টেস্ট পর্যন্ত দ্বিমুখী অনুসরণযোগ্যতা, একটি প্রামাণ্য উৎস, এবং ভিত্তিরেখাসহ নিয়ন্ত্রিত পরিবর্তন। ব্যবসা, ব্যবহারকারী ও সিস্টেমের প্রয়োজনীয়তা সুস্পষ্টভাবে আলাদা করুন এবং অ-কার্যকরী প্রয়োজনীয়তা চালক হিসেবে স্থাপত্যে হস্তান্তর করুন, যাতে পরিসর ও গুণমানের বাধ্যবাধকতা দলগুলোতে ছড়িয়ে না যায়। স্থিতিশীল, উচ্চ-নিশ্চয়তার বাধ্যবাধকতার জন্য আনুষ্ঠানিক স্পেসিফিকেশন এবং পণ্যের আচরণের এজাইল বিস্তার মেশান, আর ভারসাম্য নিয়ন্ত্রণ করুন ঝুঁকির ভিত্তিতে, কোনো একটি দলের পছন্দে নয়।

সরকার। ক্রয়-বিধি প্রায়ই পুরো চুক্তিকে একটি প্রয়োজনীয়তা স্পেসিফিকেশনকে ঘিরে গড়ে, প্রায়ই IEEE 29148-এর মতো মানে কাঠামোবদ্ধ, তাই নির্ভুলতা ও সম্পূর্ণতা চুক্তিগত, ঐচ্ছিক নয়। একটি প্রয়োজনীয়তা অনুসরণযোগ্যতা ম্যাট্রিক্স রক্ষণাবেক্ষণ করুন যা প্রতিটি প্রয়োজনীয়তাকে নকশা, টেস্ট কেস ও গ্রহণযোগ্যতার প্রমাণে যুক্ত করে, কারণ বিক্রেতার অর্থ প্রদান, অডিট এবং অপারেট করার কর্তৃত্ব সবই প্রমাণিত আওতার ওপর নির্ভর করে। স্বচ্ছতা ও জনগণের কাছে জবাবদিহি মানদণ্ড আরও বাড়ায়: অভিগম্যতা, গোপনীয়তা ও নথি সংরক্ষণের বাধ্যতামূলক বাধ্যবাধকতা প্রতিটি সুস্পষ্ট, যাচাইযোগ্য প্রয়োজনীয়তা হিসেবে দেখা দিতে হবে, এবং অনুসরণযোগ্য, উত্তীর্ণ প্রমাণ ছাড়া একটি প্রয়োজনীয়তা সহজভাবে সরবরাহ হয়নি।

উদাহরণ

স্টার্টআপ। একটি সময়সূচি অ্যাপ গড়া চারজনের স্টার্টআপ আনুষ্ঠানিক স্পেসিফিকেশনের বদলে একটি ভাগ করা ব্যাকলগে গ্রহণযোগ্যতার মানদণ্ডসহ ইউজার স্টোরি হিসেবে প্রয়োজনীয়তা ধরে। ক্যালেন্ডার-সিঙ্ক ফিচার লেখার আগে প্রতিষ্ঠাতা পাঁচজন সম্ভাব্য গ্রাহকের সঙ্গে কথা বলে একটি বিকেল কাটান এবং জানতে পারেন প্রকৃত চাহিদা দুটি টুলে দ্বিগুণ-বুকিং এড়ানো, তাঁরা যে সিঙ্ক ধরে নিয়েছিলেন তা নয়। সেই একটি আলাপ স্টোরিটি নতুন করে সাজায় এবং ভুল জিনিস গড়ার এক সপ্তাহ বাঁচায়। এই আকারেও তাঁরা প্রতিটি স্টোরির উৎস ও যুক্তি লিখে রাখেন, তাই অগ্রাধিকার সরলে তা কেন ছিল তা নিয়ে আবার তর্ক ছাড়াই পরিসর বাদ বা পুনরায় কাজ করতে পারেন।

এন্টারপ্রাইজ। একটি বহুজাতিক ব্যাংক তার ঋণ-সূচনা প্ল্যাটফর্ম প্রতিস্থাপন করে। প্রয়োজনীয়তা দল ব্যবসায়িক প্রয়োজনীয়তা (অনুমোদনের সময় কমানো, ঋণ নিয়ম মানা), ব্যবহারকারীর প্রয়োজনীয়তা (ঋণ কর্মকর্তাদের এক দৃশ্যে প্রস্তাব তুলনা করতে হবে) এবং সিস্টেমের প্রয়োজনীয়তা (প্ল্যাটফর্মকে তিনটি মূল সিস্টেমের সঙ্গে ইন্টিগ্রেট করতে হবে) আলাদা করে। অ-কার্যকরী প্রয়োজনীয়তা (সাধারণ কোয়েরিতে এক সেকেন্ডের কম সাড়া, ৯৯.৯৫% প্রাপ্যতা, ব্যক্তিগত ডেটার এনক্রিপশন) সুস্পষ্টভাবে ধরা হয় এবং চালক হিসেবে স্থাপত্যে (অধ্যায় 3.1) হস্তান্তর করা হয়। প্রতিটি প্রয়োজনীয়তা ব্যাকলগের মধ্য দিয়ে স্বয়ংক্রিয় গ্রহণযোগ্যতা টেস্টে অনুসরণ করা হয়। তাই একজন নিয়ন্ত্রক জিজ্ঞেস করলে একটি নির্দিষ্ট ঋণ নিয়ম কীভাবে বলবৎ হয়, দল সহজভাবে নিয়ম থেকে তা যাচাই করা টেস্টে ট্রেইল অনুসরণ করে।

সরকার। একটি জাতীয় সংস্থা আনুষ্ঠানিক দরপত্রের মাধ্যমে একটি সুবিধা-যোগ্যতা সিস্টেম ক্রয় করে। চুক্তি IEEE 29148-এ কাঠামোবদ্ধ একটি প্রয়োজনীয়তা স্পেসিফিকেশনে নোঙর করা, যা কার্যকরী যোগ্যতার নিয়ম, বাধ্যতামূলক অভিগম্যতা মান্যতা, গোপনীয়তা ও নথি-সংরক্ষণের সীমাবদ্ধতা এবং নিরাপত্তা নিয়ন্ত্রণ আচ্ছাদন করে। একটি প্রয়োজনীয়তা অনুসরণযোগ্যতা ম্যাট্রিক্স প্রতিটি প্রয়োজনীয়তাকে নকশা উপাদান, টেস্ট কেস ও গ্রহণযোগ্যতার প্রমাণে যুক্ত করে। বিক্রেতার অর্থ প্রদান এবং অপারেট করার কর্তৃত্ব (প্রোডাকশনে সিস্টেম চালানোর আনুষ্ঠানিক অনুমোদন) উভয়ই প্রমাণিত আওতার ওপর নির্ভর করে। অনুসরণযোগ্য, উত্তীর্ণ গ্রহণযোগ্যতার প্রমাণ ছাড়া একটি প্রয়োজনীয়তা সহজভাবে সরবরাহ হয়েছে বলে গণ্য হয় না, সফটওয়্যার যা-ই করছে মনে হোক।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

প্রয়োজনীয়তা প্রকৌশলের অর্থনৈতিক যুক্তি দাঁড়িয়ে ত্রুটি দেরিতে সারানোর খরচের ওপর। শিল্প গবেষণা ধারাবাহিকভাবে পায় যে প্রয়োজনীয়তার ত্রুটি প্রকল্প ব্যর্থতার সবচেয়ে সাধারণ ও সবচেয়ে ব্যয়বহুল কারণের মধ্যে, এবং ত্রুটি সারানোর খরচ প্রয়োজনীয়তা পর্যায় থেকে প্রোডাকশন পর্যন্ত কয়েক মাত্রা বাড়ে। তাই প্রয়োজনীয়তা পরিষ্কার ও যাচাই করতে ব্যয় হওয়া অর্থ আসলে লিভারেজ: আগের সামান্য বিনিয়োগ আপনাকে ভুল জিনিস গড়া, পরীক্ষা ও পরিচালনা থেকে বাঁচায়।

প্রয়োজনীয়তার মালিকানার মোট খরচে সিস্টেমের পুরো জীবন জুড়ে সংগ্রহ, নির্দিষ্টকরণ, টুলিং ও পরিবর্তন ব্যবস্থাপনার চলমান পরিশ্রম আছে; তা এককালীন খরচ নয়। এর বিপরীতে আছে দুর্বল প্রয়োজনীয়তার খরচ: পুনঃকাজ, পরিসর-বিতর্ক, সময়সূচি অতিক্রম, ব্যর্থ গ্রহণযোগ্যতা, চুক্তিগত জরিমানা, এবং নিয়ন্ত্রিত পরিবেশে জরিমানা বা অনুমোদন হারানো। নেতৃত্বের জন্য প্রয়োজনীয়তার পরিপক্বতাকে ঝুঁকি হ্রাস ও পূর্বানুমেয়তা হিসেবে উপস্থাপন করুন। প্রয়োজনীয়তার অস্থিরতা, ত্রুটির উৎস এবং যাচাই-করা চাহিদায় অনুসরণযোগ্য সরবরাহ-করা কাজের অংশ অনুসরণ করুন, এবং এগুলো প্রকল্প ব্যবস্থাপনার পূর্বাভাসের (অধ্যায় 10.6) সঙ্গে যুক্ত করুন। প্রতিদান একটি ফিচার হিসেবে দেখা দেয় না। তা দেখা দেয় যে ব্যর্থতা ও পুনঃকাজ কখনো ঘটেনি তার মধ্যে।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• প্রয়োজনীয়তার ছদ্মবেশে সমাধান: অন্তর্নিহিত চাহিদার বদলে একটি বাছা প্রযুক্তি বা স্ক্রিন বিন্যাস নির্দিষ্ট করা, ভালো বিকল্প বন্ধ করা।
• অস্পষ্ট ভাষা: কোনো পরিমাপযোগ্য মানদণ্ড ছাড়া “দ্রুত”, “নিরাপদ”, “স্বজ্ঞাত”, প্রয়োজনীয়তাকে যাচাই-অযোগ্য করে।
• গোল্ড-প্লেটিং: কোনো অংশীজনের আসলে দরকার নেই এমন প্রয়োজনীয়তা ধরা, পরিসর ও খরচ ফোলানো।
• অনুপস্থিত অ-কার্যকরী প্রয়োজনীয়তা: স্থাপত্য ঠিক হওয়ার পরেই পারফরম্যান্স, নিরাপত্তা বা অভিগম্যতার বাধ্যবাধকতা আবিষ্কার।
• প্রয়োজনীয়তার ছড়াছড়ি: প্রামাণ্য উৎস ছাড়া ইমেল, টিকেট ও স্লাইডে ছড়ানো সত্য।
• জমাট বা অনিয়ন্ত্রিত পরিবর্তন: হয় সব পরিবর্তন প্রত্যাখ্যান, নয়তো প্রভাব মূল্যায়ন ছাড়াই প্রতিটি পরিবর্তন গ্রহণ।
• অনুসরণযোগ্যতা নেই: একটি পরিবর্তন কী প্রভাবিত করে বা কেন একটি ফিচার আছে তার উত্তর দিতে না পারা, নিরীক্ষিত সিস্টেমে মারাত্মক।
• বিশ্লেষণ-পক্ষাঘাত: অন্তহীন নির্দিষ্টকরণ, যা কার্যকর সফটওয়্যার থেকে শেখা বিলম্বিত করে।
• উপেক্ষিত অংশীজন: অপারেটর, নিরীক্ষক ও প্রভাবিত অ-ব্যবহারকারীকে গ্রহণযোগ্যতা পর্যন্ত বাদ রাখা।

পরিপক্বতা মডেল

• স্তর ১, সূচনা। প্রয়োজনীয়তা অন্তর্নিহিত বা মৌখিক, অসঙ্গতভাবে ও প্রতিক্রিয়াশীলভাবে ধরা। পরিসর-বিতর্ক ও পুনঃকাজ সাধারণ; কোনো অনুসরণযোগ্যতা নেই, কোনো গ্রহণযোগ্যতার মানদণ্ড নেই, এবং কোনো সংজ্ঞায়িত প্রক্রিয়া নেই।
• স্তর ২, বিকাশ। কিছু দল প্রয়োজনীয়তা লিখে রাখে এবং প্রতি প্রকল্পে অনুসরণ করে, মৌলিক অগ্রাধিকার ও তাৎক্ষণিক পরিবর্তন সামলানোসহ। চর্চা আছে কিন্তু ব্যক্তি ও দল ভেদে ভিন্ন, তাই শ্রেণি, আনুষ্ঠানিকতা ও গুণমান প্রতিষ্ঠান জুড়ে অসঙ্গত।
• স্তর ৩, মানসম্মতকরণ। একটি প্রমিত প্রয়োজনীয়তা প্রক্রিয়া নথিবদ্ধ এবং প্রতিষ্ঠানজুড়ে বলবৎ: সংজ্ঞায়িত শ্রেণি, সংগ্রহ ও যাচাই চর্চা, লেখার সময় যুক্ত গ্রহণযোগ্যতার মানদণ্ড, একটি প্রামাণ্য উৎস, এবং চাহিদা থেকে টেস্ট পর্যন্ত দ্বিমুখী অনুসরণযোগ্যতা, এজাইল বা পরিকল্পনা-চালিত প্রেক্ষাপটে সামঞ্জস্যপূর্ণভাবে মানিয়ে।
• স্তর ৪, ব্যবস্থাপনা। প্রক্রিয়া তথ্য দিয়ে মাপা ও নিয়ন্ত্রিত। প্রয়োজনীয়তার অস্থিরতা, ত্রুটির উৎস, অনুসরণযোগ্যতার আওতা, এবং যাচাই-করা চাহিদায় অনুসরণযোগ্য সরবরাহ-করা কাজের অংশ ভিত্তিরেখার বিপরীতে অনুসরণ করা হয়; অনুসরণযোগ্যতা গ্রহণযোগ্যতার প্রমাণ ও বিধি-মান্যতা পর্যন্ত বাড়ে; এবং প্রয়োজনীয়তার মেট্রিক প্রকল্প পূর্বাভাসে (অধ্যায় 10.6) জোগান দেয়, তাই পরিবর্তন ও গুণমানের সিদ্ধান্ত মতামতের বদলে প্রমাণে দাঁড়ায়।
• স্তর ৫, সমন্বয়। প্রয়োজনীয়তা চর্চা নিরন্তর উন্নত এবং প্রতিষ্ঠান জুড়ে একীভূত। আনুষ্ঠানিকতা ঝুঁকি ও ফলাফলে অভিযোজিতভাবে সুর বাঁধা হয়, সংগ্রহ ও অনুসরণযোগ্যতা টুলিং আবিষ্কার, স্থাপত্য ও সরবরাহের সঙ্গে যুক্ত, এবং প্রতিষ্ঠান নিজের মাপার ইতিহাস ব্যবহার করে পুনরাবৃত্ত প্রয়োজনীয়তার ত্রুটি কোডে পৌঁছানোর আগেই প্রতিরোধ করে।

আলোচনার ভাবনা

• একজন জ্যেষ্ঠ অংশীজন যখন কিছু সমাধান হিসেবে বলেন, তখন প্রকৃত প্রয়োজনীয়তা আর অকালপক্ব সমাধানের পার্থক্য কীভাবে বুঝবেন?
• আপনার সর্বোচ্চ-ঝুঁকির সিস্টেম বনাম সর্বনিম্ন-ঝুঁকির সিস্টেমের জন্য প্রয়োজনীয়তার আনুষ্ঠানিকতার সঠিক স্তর কী, এবং কে তা ঠিক করে?
• দ্রুতগতির এজাইল ব্যাকলগে আমলাতান্ত্রিক বাড়তি বোঝা না হয়েও দ্বিমুখী অনুসরণযোগ্যতা হালনাগাদ রাখবেন কীভাবে?
• আপনার প্রতিষ্ঠানে কোন অ-কার্যকরী প্রয়োজনীয়তা সবচেয়ে প্রায়ই দেরিতে আবিষ্কৃত হয়, এবং কেন?
• একটি নিয়ন্ত্রিত কর্মসূচিতে প্রয়োজনীয়তা পূরণ হয়েছে তার জন্য যথেষ্ট গ্রহণযোগ্যতার প্রমাণ কী?
• AI-সহায়ক সংগ্রহ ও নির্দিষ্টকরণ টুল আপনার প্রয়োজনীয়তা চর্চা কীভাবে বদলানো উচিত, এবং কী নতুন ঝুঁকি আনে?

প্রধান শিক্ষা

• প্রয়োজনীয়তা চাহিদা ও সীমাবদ্ধতা প্রকাশ করে, সমাধান নয়; সেগুলো প্রয়োজনীয়, দ্ব্যর্থহীন, যাচাইযোগ্য ও অনুসরণযোগ্য হতে হবে।
• কার্যকরী, অ-কার্যকরী ও সীমাবদ্ধতার প্রয়োজনীয়তা, এবং ব্যবসা, ব্যবহারকারী ও সিস্টেম স্তর আলাদা করুন।
• প্রকৃত অংশীজনদের কাছ থেকে সংগ্রহ করুন, বিশ্লেষণ ও অগ্রাধিকার ঠিক করুন, উপযুক্ত আনুষ্ঠানিকতায় নির্দিষ্ট করুন, গড়ার আগে যাচাই করুন এবং পরিবর্তন পরিচালনা করুন।
• চাহিদা থেকে গ্রহণযোগ্যতার প্রমাণ পর্যন্ত দ্বিমুখী অনুসরণযোগ্যতা জবাবদিহির মেরুদণ্ড, বিশেষত নিয়ন্ত্রিত পরিবেশে।
• এজাইল ও পরিকল্পনা-চালিত প্রেক্ষাপট একই কার্যকলাপ ভাগ করে; তারা সময়, আনুষ্ঠানিকতা ও সামগ্রীতে ভিন্ন, তাই ঝুঁকি দিয়ে বাছুন।
• দুর্বল প্রয়োজনীয়তার খরচ দেরিতে দেওয়া হয় এবং গুণ হয়; আগে বিনিয়োগ পুনঃকাজ ও ব্যর্থ গ্রহণযোগ্যতার বিরুদ্ধে লিভারেজ।

তথ্যসূত্র ও আরও পড়ার জন্য

• IEEE ও ISO/IEC, Guide to the Software Engineering Body of Knowledge (SWEBOK), সফটওয়্যার প্রয়োজনীয়তা জ্ঞান-ক্ষেত্র
• Karl Wiegers ও Joy Beatty, Software Requirements
• ISO/IEC/IEEE 29148, Systems and software engineering: Life cycle processes: Requirements engineering
• Suzanne Robertson ও James Robertson, Mastering the Requirements Process
• Dean Leffingwell, Agile Software Requirements
• Mike Cohn, User Stories Applied
• Ian Sommerville, Software Engineering (প্রয়োজনীয়তা প্রকৌশল অধ্যায়)