ফাংশনাল বনাম নন-ফাংশনাল রিকোয়ারমেন্ট
এই পাঠে যা শিখবেন
- ফাংশনাল ও নন-ফাংশনাল রিকোয়ারমেন্টের সংজ্ঞা ও পার্থক্য নির্ভুলভাবে বলতে পারবেন
- কেন নন-ফাংশনাল রিকোয়ারমেন্টে একটি সংখ্যা/থ্রেশহোল্ড থাকা জরুরি তা বুঝবেন
- L03-এর কোয়ালিটি অ্যাট্রিবিউটের সাথে নন-ফাংশনাল রিকোয়ারমেন্টের সরাসরি সংযোগ চিনবেন
- Python দিয়ে কীওয়ার্ড-ভিত্তিক রিকোয়ারমেন্ট শ্রেণীবিভাগ ও measurability-চেকার বাস্তবায়ন করবেন
১ · ফাংশনাল রিকোয়ারমেন্ট — সিস্টেম কী করবে
ফাংশনাল রিকোয়ারমেন্টFunctional Requirementসিস্টেম কী করবে তা বর্ণনা করে -- একটি নির্দিষ্ট আচরণ বা ফিচার। বর্ণনা করে সিস্টেম কী করবে — একটি নির্দিষ্ট আচরণ বা ফিচার। উদাহরণ: "সিস্টেম ব্যবহারকারীকে ইমেইলের মাধ্যমে পাসওয়ার্ড রিসেট করার অনুমতি দেবে।" এই ধরনের বিবৃতি একটি সুনির্দিষ্ট, পর্যবেক্ষণযোগ্য কাজ বর্ণনা করে — সিস্টেম হয় এটি করে, নয়তো করে না।
২ · নন-ফাংশনাল রিকোয়ারমেন্ট — সিস্টেম কতটা ভালো পারফর্ম করবে
নন-ফাংশনাল রিকোয়ারমেন্টNon-Functional Requirementসিস্টেম কতটা ভালো পারফর্ম করবে তা বর্ণনা করে -- L03-এর কোয়ালিটি অ্যাট্রিবিউটকে সীমাবদ্ধ করে, নির্দিষ্ট আচরণ নয়। — L03-এ আলোচিত কোয়ালিটি অ্যাট্রিবিউটের সরাসরি ফরমালাইজেশন, এই সংযোগটি স্পষ্টভাবে উল্লেখ করা দরকার — বর্ণনা করে সিস্টেম কতটা ভালো পারফর্ম করবে, নির্দিষ্ট আচরণের বদলে কোয়ালিটি অ্যাট্রিবিউটকে সীমাবদ্ধ করে। উদাহরণ: "সিস্টেম ৯৫% রিকোয়েস্টের জন্য একটি সার্চ কোয়েরির উত্তর ২ সেকেন্ডের মধ্যে দেবে" — এটি একটি পারফরম্যান্স/এফিশিয়েন্সি নন-ফাংশনাল রিকোয়ারমেন্ট, L03-এর এফিশিয়েন্সি অ্যাট্রিবিউটের সরাসরি পুনর্ব্যবহার।
৩ · এই পার্থক্য কেন গুরুত্বপূর্ণ — টেস্টযোগ্যতা
ফাংশনাল রিকোয়ারমেন্ট সাধারণত সরাসরি টেস্টযোগ্য — নির্দিষ্ট টেস্ট কেস দিয়ে যাচাই করা যায় পাসওয়ার্ড রিসেট সত্যিই কাজ করলো কি না। কিন্তু নন-ফাংশনাল রিকোয়ারমেন্ট টেস্টযোগ্য হতে হলে প্রায়ই পরিমাপযোগ্য, সুনির্দিষ্ট থ্রেশহোল্ড সহকারে বলা দরকার — একটি অস্পষ্ট নন-ফাংশনাল রিকোয়ারমেন্ট যেমন "সিস্টেম দ্রুত হওয়া উচিত" প্রায় অকেজো (দ্রুত মানে কী? ১ সেকেন্ড? ১০ সেকেন্ড?) — উপরের সুনির্দিষ্ট, পরিমাপযোগ্য "২ সেকেন্ড/৯৫%" উদাহরণের সাথে সরাসরি, স্পষ্ট বৈসাদৃশ্য।
সবসময় একটি সংখ্যা বা পরিমাপযোগ্য থ্রেশহোল্ড যোগ করুন যখনই একটি নন-ফাংশনাল রিকোয়ারমেন্ট লিখছেন — "দ্রুত", "নির্ভরযোগ্য", "ব্যবহারবান্ধব"-এর মতো বিশেষণ একা কখনোই যথেষ্ট নয়। এই একটি অভ্যাসই একটি নন-ফাংশনাল রিকোয়ারমেন্টকে অস্পষ্ট আকাঙ্ক্ষা থেকে বাস্তবসম্মত, টেস্টযোগ্য চুক্তিতে রূপান্তরিত করে।
৪ · শ্রেণীবিভাগ ও measurability যাচাই
নিচের কোড সেলে দুটো ফাংশন বাস্তবায়ন করা হয়েছে — classify_requirement() একটি সাধারণ
কীওয়ার্ড-ভিত্তিক হিউরিস্টিক দিয়ে রিকোয়ারমেন্ট শ্রেণীবদ্ধ করে, এবং is_measurable() একটি
নন-ফাংশনাল রিকোয়ারমেন্টে সংখ্যা/থ্রেশহোল্ড আছে কি না তা পরীক্ষা করে।
# কীওয়ার্ড-ভিত্তিক রিকোয়ারমেন্ট শ্রেণীবিভাগ ও measurability যাচাই
import re
def classify_requirement(requirement_text):
text_lower = requirement_text.lower()
non_functional_keywords = ["shall respond within", "shall support", "uptime", "shall be compatible with"]
functional_keywords = ["shall allow the user to", "the system shall display"]
for kw in non_functional_keywords:
if kw in text_lower:
return "non-functional"
for kw in functional_keywords:
if kw in text_lower:
return "functional"
return "unclassified"
def is_measurable(non_functional_requirement_text):
# অন্তত একটি সংখ্যা থাকলেই একে পরিমাপযোগ্য থ্রেশহোল্ড হিসেবে ধরা হচ্ছে
return bool(re.search(r"\d", non_functional_requirement_text))
requirements = [
"The system shall allow the user to reset their password via email.",
"The system shall respond within 2 seconds for 95% of search queries.",
"The system shall support 500 concurrent users.",
"The system shall display the user's order history.",
"The system shall maintain 99.9% uptime.",
"The system should be fast.",
]
print("রিকোয়ারমেন্ট শ্রেণীবিভাগ:")
for req in requirements:
print(f" [{classify_requirement(req):>13}] {req}")
print("\nনন-ফাংশনাল রিকোয়ারমেন্টের measurability পরীক্ষা:")
precise = "The system shall respond within 2 seconds for 95% of search queries."
vague = "The system should be fast."
print(f" measurable={is_measurable(precise)} \"{precise}\"")
print(f" measurable={is_measurable(vague)} \"{vague}\"")
classify_requirement() একে "unclassified" হিসেবে চিহ্নিত করে — নিজেই একটি বাস্তব শিক্ষা:
কীওয়ার্ড-ভিত্তিক হিউরিস্টিক নিখুঁত নয়, এবং এই ধরনের অস্পষ্ট বিবৃতি স্বয়ংক্রিয় শ্রেণীবিভাগের জন্যও সমস্যাযুক্ত।
আরও গুরুত্বপূর্ণভাবে, is_measurable() সরাসরি প্রমাণ করে এটি পরিমাপযোগ্য নয় (False),
কারণ এতে কোনো সংখ্যা নেই — যেখানে সুনির্দিষ্ট সংস্করণে "2" ও "95" উভয়ই থাকায় তা True হয়।
ফাংশনাল রিকোয়ারমেন্ট সিস্টেমের আচরণ বর্ণনা করে, নন-ফাংশনাল রিকোয়ারমেন্ট তার কোয়ালিটি সীমাবদ্ধ করে — এবং দ্বিতীয়টিকে সত্যিকারের কার্যকর করতে হলে সবসময় একটি সংখ্যা বা পরিমাপযোগ্য থ্রেশহোল্ড যোগ করতে হবে। এই শৃঙ্খলা M10-এর টেস্টিং মডিউলে সরাসরি ফলপ্রসূ হয় — একটি অস্পষ্ট রিকোয়ারমেন্ট কখনোই সরাসরি টেস্ট কেসে রূপ নিতে পারে না।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ "সিস্টেম নিরাপদ হওয়া উচিত" — এটি কি একটি ভালো নন-ফাংশনাল রিকোয়ারমেন্ট? কেন বা কেন নয়?
না, এটি খুবই অস্পষ্ট। "নিরাপদ" শব্দটির কোনো পরিমাপযোগ্য থ্রেশহোল্ড নেই — কোনো টেস্ট কেস লেখা সম্ভব নয় যা সরাসরি "নিরাপদ কি না" যাচাই করে। একটি ভালো সংস্করণ হবে "সিস্টেম OWASP Top 10-এর সব দুর্বলতা থেকে মুক্ত থাকবে, প্রতি রিলিজে একটি স্বয়ংক্রিয় নিরাপত্তা স্ক্যান পাস করে" অথবা "সব পাসওয়ার্ড bcrypt দিয়ে হ্যাশ করা থাকবে, ন্যূনতম ১২ কস্ট ফ্যাক্টর সহ" — উভয়ই সুনির্দিষ্ট, যাচাইযোগ্য শর্ত।
প্র ০২ L03-এর কোয়ালিটি অ্যাট্রিবিউটের সাথে এই পাঠের নন-ফাংশনাল রিকোয়ারমেন্টের সম্পর্ক কী?
L03-এ কোয়ালিটি অ্যাট্রিবিউট (নির্ভরযোগ্যতা, ব্যবহারযোগ্যতা, রক্ষণাবেক্ষণযোগ্যতা, দক্ষতা, বহনযোগ্যতা) বিমূর্তভাবে আলোচিত হয়েছিল — "সিস্টেমের কোন কোন দিক গুরুত্বপূর্ণ" তার একটি তালিকা হিসেবে। নন-ফাংশনাল রিকোয়ারমেন্ট এই একই অ্যাট্রিবিউটগুলোকে সুনির্দিষ্ট, পরিমাপযোগ্য চুক্তিতে রূপান্তরিত করে — যেমন "দক্ষতা" থেকে "৯৫% রিকোয়েস্টে ২ সেকেন্ডের মধ্যে সাড়া"। একটি বিমূর্ত ধারণা, অন্যটি তার প্রয়োগযোগ্য রূপ।
প্র ০৩ কোড সেলে "The system shall maintain 99.9% uptime." কেন non-functional হিসেবে শ্রেণীবদ্ধ হলো, functional নয়?
কারণ এতে non_functional_keywords তালিকার "uptime" শব্দটি আছে, এবং
classify_requirement() প্রথমে নন-ফাংশনাল কীওয়ার্ড তালিকা পরীক্ষা করে। বাস্তবেও এটি
যুক্তিসঙ্গত — "৯৯.৯% আপটাইম বজায় রাখা" কোনো নির্দিষ্ট ফিচার আচরণ বর্ণনা করে না, বরং সিস্টেম সময়ের সাথে
কতটা নির্ভরযোগ্যভাবে কাজ করবে (L03-এর নির্ভরযোগ্যতা অ্যাট্রিবিউট) তা সীমাবদ্ধ করে — যা ঠিক
নন-ফাংশনাল রিকোয়ারমেন্টের সংজ্ঞা।
অনুশীলন
-
চিন্তা করুন: "সিস্টেম ব্যবহারকারী-বান্ধব হওয়া উচিত" এই অস্পষ্ট নন-ফাংশনাল রিকোয়ারমেন্টকে
একটি সুনির্দিষ্ট, পরিমাপযোগ্য সংস্করণে পুনর্লিখন করুন।
একটি সম্ভাব্য সুনির্দিষ্ট সংস্করণ: "একটি নতুন ব্যবহারকারী কোনো প্রশিক্ষণ ছাড়াই ৩ মিনিটের মধ্যে একটি অ্যাকাউন্ট তৈরি করে প্রথম অর্ডার সম্পন্ন করতে পারবে, ব্যবহারযোগ্যতা টেস্টে অংশগ্রহণকারীদের অন্তত ৯০%-এর জন্য।" এখানে "ব্যবহারবান্ধব" একটি বিমূর্ত বিশেষণ থেকে একটি নির্দিষ্ট সময়সীমা ও সফলতার হার নিয়ে একটি টেস্টযোগ্য চুক্তিতে রূপান্তরিত হয়েছে।
-
পরীক্ষা করুন: কোড সেলে
requirementsতালিকায় একটি নতুন স্ট্রিং"The system shall be compatible with Chrome, Firefox, and Safari."যোগ করে Run চেপে দেখুন এটি কীভাবে শ্রেণীবদ্ধ হয় এবং কেন।এটি "non-functional" হিসেবে শ্রেণীবদ্ধ হবে, কারণ এতে
non_functional_keywordsতালিকার "shall be compatible with" বাক্যাংশটি রয়েছে। এটিও যুক্তিসঙ্গত — L03-এর বহনযোগ্যতা (portability) অ্যাট্রিবিউটের একটি সরাসরি প্রয়োগ, একটি নির্দিষ্ট ফিচার আচরণ নয়, বরং সিস্টেম কোন কোন পরিবেশে চলবে তার একটি সীমাবদ্ধতা।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৮টি পাঠ পরবর্তী পাঠগুলো — ইউজ কেস, ইউজার স্টোরি, সফটওয়্যার ডিজাইন প্রিন্সিপল ও আরও অনেক কিছু।
- সফটওয়্যার কোয়ালিটি অ্যাট্রিবিউট পাঠ ০৩ নন-ফাংশনাল রিকোয়ারমেন্টের বিমূর্ত ভিত্তি — এই পাঠে যা সুনির্দিষ্ট, পরিমাপযোগ্য চুক্তিতে রূপ নিলো।
- ইউজ কেস ও ইউজ কেস ডায়াগ্রাম পরের পাঠ ফাংশনাল রিকোয়ারমেন্টকে একটি সম্পূর্ণ, কাঠামোবদ্ধ ন্যারেটিভে বিস্তৃত করা।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design ও Software Engineering & Git — সব এক জায়গায়।