পাঠ ১১ · ৫৮-এর মধ্যে · মডিউল ৩
Home / Courses / Software Engineering Principles & Git / রিকোয়ারমেন্ট ইঞ্জিনিয়ারিং

ফাংশনাল বনাম নন-ফাংশনাল রিকোয়ারমেন্ট

Functional vs non-functional requirements
৭ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • ফাংশনাল ও নন-ফাংশনাল রিকোয়ারমেন্টের সংজ্ঞা ও পার্থক্য নির্ভুলভাবে বলতে পারবেন
  • কেন নন-ফাংশনাল রিকোয়ারমেন্টে একটি সংখ্যা/থ্রেশহোল্ড থাকা জরুরি তা বুঝবেন
  • L03-এর কোয়ালিটি অ্যাট্রিবিউটের সাথে নন-ফাংশনাল রিকোয়ারমেন্টের সরাসরি সংযোগ চিনবেন
  • Python দিয়ে কীওয়ার্ড-ভিত্তিক রিকোয়ারমেন্ট শ্রেণীবিভাগ ও measurability-চেকার বাস্তবায়ন করবেন

১ · ফাংশনাল রিকোয়ারমেন্ট — সিস্টেম কী করবে

ফাংশনাল রিকোয়ারমেন্টFunctional Requirementসিস্টেম কী করবে তা বর্ণনা করে -- একটি নির্দিষ্ট আচরণ বা ফিচার। বর্ণনা করে সিস্টেম কী করবে — একটি নির্দিষ্ট আচরণ বা ফিচার। উদাহরণ: "সিস্টেম ব্যবহারকারীকে ইমেইলের মাধ্যমে পাসওয়ার্ড রিসেট করার অনুমতি দেবে।" এই ধরনের বিবৃতি একটি সুনির্দিষ্ট, পর্যবেক্ষণযোগ্য কাজ বর্ণনা করে — সিস্টেম হয় এটি করে, নয়তো করে না।

২ · নন-ফাংশনাল রিকোয়ারমেন্ট — সিস্টেম কতটা ভালো পারফর্ম করবে

নন-ফাংশনাল রিকোয়ারমেন্টNon-Functional Requirementসিস্টেম কতটা ভালো পারফর্ম করবে তা বর্ণনা করে -- L03-এর কোয়ালিটি অ্যাট্রিবিউটকে সীমাবদ্ধ করে, নির্দিষ্ট আচরণ নয়। — L03-এ আলোচিত কোয়ালিটি অ্যাট্রিবিউটের সরাসরি ফরমালাইজেশন, এই সংযোগটি স্পষ্টভাবে উল্লেখ করা দরকার — বর্ণনা করে সিস্টেম কতটা ভালো পারফর্ম করবে, নির্দিষ্ট আচরণের বদলে কোয়ালিটি অ্যাট্রিবিউটকে সীমাবদ্ধ করে। উদাহরণ: "সিস্টেম ৯৫% রিকোয়েস্টের জন্য একটি সার্চ কোয়েরির উত্তর ২ সেকেন্ডের মধ্যে দেবে" — এটি একটি পারফরম্যান্স/এফিশিয়েন্সি নন-ফাংশনাল রিকোয়ারমেন্ট, L03-এর এফিশিয়েন্সি অ্যাট্রিবিউটের সরাসরি পুনর্ব্যবহার।

৩ · এই পার্থক্য কেন গুরুত্বপূর্ণ — টেস্টযোগ্যতা

ফাংশনাল রিকোয়ারমেন্ট সাধারণত সরাসরি টেস্টযোগ্য — নির্দিষ্ট টেস্ট কেস দিয়ে যাচাই করা যায় পাসওয়ার্ড রিসেট সত্যিই কাজ করলো কি না। কিন্তু নন-ফাংশনাল রিকোয়ারমেন্ট টেস্টযোগ্য হতে হলে প্রায়ই পরিমাপযোগ্য, সুনির্দিষ্ট থ্রেশহোল্ড সহকারে বলা দরকার — একটি অস্পষ্ট নন-ফাংশনাল রিকোয়ারমেন্ট যেমন "সিস্টেম দ্রুত হওয়া উচিত" প্রায় অকেজো (দ্রুত মানে কী? ১ সেকেন্ড? ১০ সেকেন্ড?) — উপরের সুনির্দিষ্ট, পরিমাপযোগ্য "২ সেকেন্ড/৯৫%" উদাহরণের সাথে সরাসরি, স্পষ্ট বৈসাদৃশ্য।

একটি গুরুত্বপূর্ণ রিকোয়ারমেন্ট-লেখার শৃঙ্খলা

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

৪ · শ্রেণীবিভাগ ও measurability যাচাই

নিচের কোড সেলে দুটো ফাংশন বাস্তবায়ন করা হয়েছে — classify_requirement() একটি সাধারণ কীওয়ার্ড-ভিত্তিক হিউরিস্টিক দিয়ে রিকোয়ারমেন্ট শ্রেণীবদ্ধ করে, এবং is_measurable() একটি নন-ফাংশনাল রিকোয়ারমেন্টে সংখ্যা/থ্রেশহোল্ড আছে কি না তা পরীক্ষা করে।

Python
# কীওয়ার্ড-ভিত্তিক রিকোয়ারমেন্ট শ্রেণীবিভাগ ও 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}\"")

    
লক্ষ্য করুন শেষ রিকোয়ারমেন্ট "The system should be fast." কোনো পূর্ব-সংজ্ঞায়িত কীওয়ার্ডের সাথে মেলে না, তাই classify_requirement() একে "unclassified" হিসেবে চিহ্নিত করে — নিজেই একটি বাস্তব শিক্ষা: কীওয়ার্ড-ভিত্তিক হিউরিস্টিক নিখুঁত নয়, এবং এই ধরনের অস্পষ্ট বিবৃতি স্বয়ংক্রিয় শ্রেণীবিভাগের জন্যও সমস্যাযুক্ত। আরও গুরুত্বপূর্ণভাবে, is_measurable() সরাসরি প্রমাণ করে এটি পরিমাপযোগ্য নয় (False), কারণ এতে কোনো সংখ্যা নেই — যেখানে সুনির্দিষ্ট সংস্করণে "2" ও "95" উভয়ই থাকায় তা True হয়।
মূল কথা · Key takeaway

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

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ "সিস্টেম নিরাপদ হওয়া উচিত" — এটি কি একটি ভালো নন-ফাংশনাল রিকোয়ারমেন্ট? কেন বা কেন নয়?

না, এটি খুবই অস্পষ্ট। "নিরাপদ" শব্দটির কোনো পরিমাপযোগ্য থ্রেশহোল্ড নেই — কোনো টেস্ট কেস লেখা সম্ভব নয় যা সরাসরি "নিরাপদ কি না" যাচাই করে। একটি ভালো সংস্করণ হবে "সিস্টেম OWASP Top 10-এর সব দুর্বলতা থেকে মুক্ত থাকবে, প্রতি রিলিজে একটি স্বয়ংক্রিয় নিরাপত্তা স্ক্যান পাস করে" অথবা "সব পাসওয়ার্ড bcrypt দিয়ে হ্যাশ করা থাকবে, ন্যূনতম ১২ কস্ট ফ্যাক্টর সহ" — উভয়ই সুনির্দিষ্ট, যাচাইযোগ্য শর্ত।

প্র ০২ L03-এর কোয়ালিটি অ্যাট্রিবিউটের সাথে এই পাঠের নন-ফাংশনাল রিকোয়ারমেন্টের সম্পর্ক কী?

L03-এ কোয়ালিটি অ্যাট্রিবিউট (নির্ভরযোগ্যতা, ব্যবহারযোগ্যতা, রক্ষণাবেক্ষণযোগ্যতা, দক্ষতা, বহনযোগ্যতা) বিমূর্তভাবে আলোচিত হয়েছিল — "সিস্টেমের কোন কোন দিক গুরুত্বপূর্ণ" তার একটি তালিকা হিসেবে। নন-ফাংশনাল রিকোয়ারমেন্ট এই একই অ্যাট্রিবিউটগুলোকে সুনির্দিষ্ট, পরিমাপযোগ্য চুক্তিতে রূপান্তরিত করে — যেমন "দক্ষতা" থেকে "৯৫% রিকোয়েস্টে ২ সেকেন্ডের মধ্যে সাড়া"। একটি বিমূর্ত ধারণা, অন্যটি তার প্রয়োগযোগ্য রূপ।

প্র ০৩ কোড সেলে "The system shall maintain 99.9% uptime." কেন non-functional হিসেবে শ্রেণীবদ্ধ হলো, functional নয়?

কারণ এতে non_functional_keywords তালিকার "uptime" শব্দটি আছে, এবং classify_requirement() প্রথমে নন-ফাংশনাল কীওয়ার্ড তালিকা পরীক্ষা করে। বাস্তবেও এটি যুক্তিসঙ্গত — "৯৯.৯% আপটাইম বজায় রাখা" কোনো নির্দিষ্ট ফিচার আচরণ বর্ণনা করে না, বরং সিস্টেম সময়ের সাথে কতটা নির্ভরযোগ্যভাবে কাজ করবে (L03-এর নির্ভরযোগ্যতা অ্যাট্রিবিউট) তা সীমাবদ্ধ করে — যা ঠিক নন-ফাংশনাল রিকোয়ারমেন্টের সংজ্ঞা।

অনুশীলন

  1. চিন্তা করুন: "সিস্টেম ব্যবহারকারী-বান্ধব হওয়া উচিত" এই অস্পষ্ট নন-ফাংশনাল রিকোয়ারমেন্টকে একটি সুনির্দিষ্ট, পরিমাপযোগ্য সংস্করণে পুনর্লিখন করুন।

    একটি সম্ভাব্য সুনির্দিষ্ট সংস্করণ: "একটি নতুন ব্যবহারকারী কোনো প্রশিক্ষণ ছাড়াই ৩ মিনিটের মধ্যে একটি অ্যাকাউন্ট তৈরি করে প্রথম অর্ডার সম্পন্ন করতে পারবে, ব্যবহারযোগ্যতা টেস্টে অংশগ্রহণকারীদের অন্তত ৯০%-এর জন্য।" এখানে "ব্যবহারবান্ধব" একটি বিমূর্ত বিশেষণ থেকে একটি নির্দিষ্ট সময়সীমা ও সফলতার হার নিয়ে একটি টেস্টযোগ্য চুক্তিতে রূপান্তরিত হয়েছে।

  2. পরীক্ষা করুন: কোড সেলে 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-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
রিকোয়ারমেন্ট গ্যাদারিং ও এলিসিটেশন