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

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

Requirements gathering & elicitation
৭ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

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

  • চারটি প্রমিত রিকোয়ারমেন্ট এলিসিটেশন কৌশল ও কোনটি কখন উপযোগী তা বুঝবেন
  • স্টেকহোল্ডার আইডেন্টিফিকেশনের গুরুত্ব ও পরস্পরবিরোধী চাহিদার বাস্তব চ্যালেঞ্জ চিনবেন
  • "রিকোয়ারমেন্ট গ্যাপ" ও "৫ Whys" টেকনিক ব্যাখ্যা করতে পারবেন
  • Python দিয়ে একাধিক স্টেকহোল্ডারের রিকোয়ারমেন্ট থেকে শেয়ার্ড বনাম কনফ্লিক্টিং আইটেম চিহ্নিত করবেন

১ · রিকোয়ারমেন্ট গ্যাদারিং কী

রিকোয়ারমেন্ট গ্যাদারিংRequirements Gathering / Elicitationএকটি সফটওয়্যার সিস্টেম আসলে কী করা দরকার তা আবিষ্কার করার প্রক্রিয়া — SDLC-এর প্রথম, ভিত্তি ধাপ। (একে "এলিসিটেশন"-ও বলা হয়) হলো একটি সফটওয়্যার সিস্টেম আসলে কী করা দরকার তা আবিষ্কার করার প্রক্রিয়া — L04-এর SDLC মানচিত্রের সরাসরি প্রথম ধাপ, এবং L05-L09-এ আলোচিত প্রতিটি SDLC মডেল — বাকি প্রসেস যেভাবেই সংগঠিত হোক না কেন — এই প্রথম ধাপ ভাগ করে নেয়।

২ · প্রমিত এলিসিটেশন কৌশল

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

৩ · স্টেকহোল্ডার আইডেন্টিফিকেশন ও পরস্পরবিরোধী চাহিদা

একটি গুরুত্বপূর্ণ, প্রায়ই উপেক্ষিত ব্যবহারিক ধাপ — বিভিন্ন স্টেকহোল্ডার গ্রুপের (end user, ব্যবসায়িক স্পনসর, সিস্টেম অ্যাডমিনিস্ট্রেটর, নিয়ন্ত্রক/কমপ্লায়েন্স সংস্থা) প্রায়ই ভিন্ন এবং কখনো কখনো পরস্পরবিরোধী চাহিদা থাকে — এটি একটি বাস্তব, প্রকৃত চ্যালেঞ্জ যা রিকোয়ারমেন্ট ইঞ্জিনিয়ারিংকে অবশ্যই মোকাবিলা করতে হয়, এড়িয়ে যাওয়া যায় না।

"রিকোয়ারমেন্ট গ্যাপ" সমস্যা

একটি সুপরিচিত, বাস্তব ঝুঁকি: স্টেকহোল্ডার কী বলে, তারা আসলে কী বোঝায়, এবং তাদের প্রকৃতপক্ষে কী দরকার — এই তিনটি ভিন্ন হতে পারে। দক্ষ এলিসিটেশন এই ফাঁক কমানোর চেষ্টা করে "৫ Whys" (৫টি "কেন" প্রশ্ন বারবার জিজ্ঞাসা করা) এর মতো কৌশলের মাধ্যমে — একটি বলা চাহিদার পেছনের প্রকৃত প্রয়োজন উন্মোচন করার জন্য।

৪ · শেয়ার্ড বনাম কনফ্লিক্টিং রিকোয়ারমেন্ট চিহ্নিতকরণ

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

Python
# একাধিক স্টেকহোল্ডার গ্রুপের রিকোয়ারমেন্ট থেকে শেয়ার্ড ও কনফ্লিক্টিং আইটেম চিহ্নিতকরণ

def consolidate_stakeholder_requirements(stakeholder_requirements):
    # প্রতিটি রিকোয়ারমেন্ট স্ট্রিং ঠিক কোন কোন স্টেকহোল্ডার থেকে এসেছে তার একটি ম্যাপ তৈরি করা
    requirement_sources = {}
    for stakeholder, reqs in stakeholder_requirements.items():
        for req in reqs:
            requirement_sources.setdefault(req, []).append(stakeholder)

    shared = {req: sources for req, sources in requirement_sources.items() if len(sources) > 1}

    # বাস্তবে ডোমেইন এক্সপার্টরা এই কনফ্লিক্ট-কিওয়ার্ড জোড়াগুলো চিহ্নিত করেন
    conflict_keyword_pairs = [("লগ", "প্রাইভেসি"), ("ট্র্যাকিং", "প্রাইভেসি")]
    conflicts = []
    all_reqs = list(requirement_sources.items())
    for i in range(len(all_reqs)):
        for j in range(i + 1, len(all_reqs)):
            req_a, sources_a = all_reqs[i]
            req_b, sources_b = all_reqs[j]
            for kw_a, kw_b in conflict_keyword_pairs:
                if (kw_a in req_a and kw_b in req_b) or (kw_b in req_a and kw_a in req_b):
                    conflicts.append((req_a, sources_a, req_b, sources_b))

    print("শেয়ার্ড রিকোয়ারমেন্ট (একাধিক স্টেকহোল্ডার সমর্থন করে):")
    for req, sources in shared.items():
        print(f"  - \"{req}\" <- {', '.join(sources)}")

    print("\nকনফ্লিক্টিং রিকোয়ারমেন্ট (স্পষ্ট সমাধান প্রয়োজন):")
    for req_a, sources_a, req_b, sources_b in conflicts:
        print(f"  - \"{req_a}\" ({', '.join(sources_a)})")
        print(f"    <-> \"{req_b}\" ({', '.join(sources_b)})")

    return shared, conflicts

stakeholder_requirements = {
    "admin": ["প্রতিটি ব্যবহারকারীর কার্যকলাপের বিস্তারিত লগ রাখা", "দ্রুত রিপোর্ট জেনারেট করা"],
    "end_user": ["সর্বোচ্চ প্রাইভেসি ও ন্যূনতম ট্র্যাকিং", "দ্রুত রিপোর্ট জেনারেট করা"],
    "compliance": ["প্রতিটি ব্যবহারকারীর কার্যকলাপের বিস্তারিত লগ রাখা"],
}

consolidate_stakeholder_requirements(stakeholder_requirements)

    
"প্রতিটি ব্যবহারকারীর কার্যকলাপের বিস্তারিত লগ রাখা" (admin ও compliance থেকে) এবং "দ্রুত রিপোর্ট জেনারেট করা" (admin ও end_user থেকে) — দুটোই একাধিক উৎস থেকে আসায় শেয়ার্ড হিসেবে চিহ্নিত হয়। কিন্তু "প্রতিটি ব্যবহারকারীর কার্যকলাপের বিস্তারিত লগ রাখা" (যাতে "লগ" শব্দ আছে) এবং "সর্বোচ্চ প্রাইভেসি ও ন্যূনতম ট্র্যাকিং" (যাতে "প্রাইভেসি" শব্দ আছে) — এই দুটো conflict_keyword_pairs-এর সাথে মিলে যায়, তাই সরাসরি কনফ্লিক্ট হিসেবে ফ্ল্যাগ হয় — ডিজাইন শুরুর আগে এই দ্বন্দ্ব স্পষ্টভাবে সমাধান করতে হবে (উদাহরণস্বরূপ, লগ রাখা হবে কিন্তু নির্দিষ্ট সময় পর মুছে ফেলা হবে, অথবা অ্যানোনিমাইজ করা হবে)।
মূল কথা · Key takeaway

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

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

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

প্র ০১ একজন ব্যবহারকারী বলেন "আমার একটি এক্সপোর্ট বাটন দরকার" — "৫ Whys" কৌশল কীভাবে এই বলা চাহিদার পেছনের প্রকৃত প্রয়োজন উন্মোচন করতে সাহায্য করতে পারে?

"কেন এক্সপোর্ট বাটন দরকার?" জিজ্ঞাসা করলে হয়তো উত্তর আসবে "ডেটা এক্সেলে নিতে চাই" — "কেন এক্সেলে নিতে চান?" জিজ্ঞাসা করলে হয়তো আসল উত্তর বেরিয়ে আসবে "ম্যানেজারকে মাসিক রিপোর্ট পাঠাতে হয়"। শেষ পর্যন্ত হয়তো দেখা যাবে প্রকৃত প্রয়োজন একটি এক্সপোর্ট বাটন নয়, বরং একটি স্বয়ংক্রিয় মাসিক রিপোর্ট ফিচার — যা এক্সপোর্ট বাটনের চেয়ে ভালোভাবে আসল সমস্যা সমাধান করে।

প্র ০২ শুধু একটি স্টেকহোল্ডার গ্রুপের (যেমন শুধু end user) সাথে কথা বলে রিকোয়ারমেন্ট সংগ্রহ করলে কী ঝুঁকি থাকে?

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

প্র ০৩ কোড সেলে কনফ্লিক্ট শনাক্তকরণ শুধু নির্দিষ্ট কিওয়ার্ড জোড়ার (conflict_keyword_pairs) উপর ভিত্তি করে কাজ করে। এই পদ্ধতির একটি সীমাবদ্ধতা কী?

কিওয়ার্ড-ভিত্তিক পদ্ধতি শুধু আগে থেকে সংজ্ঞায়িত শব্দজোড়া চিনতে পারে — একই কনফ্লিক্ট ভিন্ন শব্দে প্রকাশ করা হলে (যেমন "প্রাইভেসি"-র বদলে "ব্যক্তিগত তথ্য সুরক্ষা") এটি ধরা পড়বে না। বাস্তব রিকোয়ারমেন্ট ইঞ্জিনিয়ারিংয়ে এই ধরনের স্বয়ংক্রিয় চেক শুধু একটি প্রাথমিক সহায়ক টুল — চূড়ান্ত সিদ্ধান্ত সবসময় একজন দক্ষ বিশ্লেষকের মানবিক বিচারের উপর নির্ভর করে।

অনুশীলন

  1. চিন্তা করুন: একটি হাসপাতাল সফটওয়্যার প্রজেক্টে অন্তত ৪টি ভিন্ন স্টেকহোল্ডার গ্রুপ চিহ্নিত করুন (যেমন ডাক্তার, রোগী, বীমা কোম্পানি) এবং প্রতিটির অন্তত একটি সম্ভাব্য পরস্পরবিরোধী চাহিদা কল্পনা করুন।

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

  2. পরীক্ষা করুন: কোড সেলে stakeholder_requirements-এ একটি নতুন "end_user"-এর রিকোয়ারমেন্ট "দ্রুত রিপোর্ট জেনারেট করা" মুছে ফেলে দেখুন শেয়ার্ড তালিকা কীভাবে বদলায়।

    সেই রিকোয়ারমেন্টটি তখন শুধু admin থেকে আসবে (একটি মাত্র উৎস), তাই len(sources) > 1 শর্ত আর সত্য হবে না, এবং এটি শেয়ার্ড তালিকা থেকে বাদ পড়বে — শুধু "প্রতিটি ব্যবহারকারীর কার্যকলাপের বিস্তারিত লগ রাখা" (admin + compliance) শেয়ার্ড হিসেবে থেকে যাবে। কনফ্লিক্ট তালিকা অপরিবর্তিত থাকবে, কারণ কনফ্লিক্ট শনাক্তকরণ উৎস সংখ্যার উপর নির্ভর করে না।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
স্ক্রাম ও কানবান ফ্রেমওয়ার্ক