3. সিস্টেম ডিজাইনের ভিত্তি: Functional ও Quality Requirements সহজ ব্যাখ্যা
সিস্টেমের Functional Requirements এবং Quality Attributes Requirements — বিস্তারিত বিশ্লেষণ ও উদাহরণসহ ব্যাখ্যা
যখন কোনো সফটওয়্যার সিস্টেম ডিজাইন করা হয়, তখন সেটি মূলত দুই ধরনের প্রয়োজনীয়তার ওপর দাঁড়িয়ে থাকে — Functional Requirements এবং Quality Attribute (বা Non-Functional) Requirements। এই দুইটি অংশই একে অপরের পরিপূরক এবং একটি শক্তিশালী ও কার্যকরী সিস্টেম গড়ে তুলতে অপরিহার্য।
চলুন ধাপে ধাপে এগুলো বুঝে নেওয়া যাক 👇
১. সিস্টেম রিকোয়ারমেন্টস কী?
যখন আমরা কোনো সফটওয়্যার সিস্টেম ডিজাইন করি, তখন সেটি কী কী করবে, কার জন্য করবে, কেমনভাবে পারফর্ম করবে — এসব নির্ধারণ করাই হলো System Requirements।
এগুলো সাধারণত দুই ভাগে বিভক্ত হয়:
-
Functional Requirements – সিস্টেম কী করবে
-
Non-Functional (Quality Attribute) Requirements – সিস্টেম কেমন হবে
২. Functional Requirements (ফাংশনাল রিকোয়ারমেন্ট)
🔹 সংজ্ঞা:
Functional Requirements হচ্ছে সেইসব নির্দিষ্ট কাজ বা ফিচার যা সিস্টেমকে সম্পন্ন করতে হবে।
অর্থাৎ “সিস্টেম কী করবে” সেটাই এর মূল বিষয়।
🔹 মূল উদ্দেশ্য:
-
ইউজারের প্রয়োজন মেটানো
-
বিজনেস প্রক্রিয়া (process) চালানো
-
সিস্টেমের আচরণ (behavior) নির্ধারণ করা
🔹 উদাহরণ:
ধরো তুমি একটা Online Food Delivery System বানাচ্ছো।
এখন এই সিস্টেমের Functional Requirements হতে পারে 👇
| সিরিয়াল | Functional Requirement | ব্যাখ্যা |
|---|---|---|
| 1 | ইউজার রেজিস্ট্রেশন ও লগইন | নতুন ইউজার রেজিস্টার করতে পারবে এবং পুরোনো ইউজার লগইন করতে পারবে |
| 2 | রেস্টুরেন্ট ব্রাউজিং | ইউজার লোকেশন অনুযায়ী রেস্টুরেন্ট সার্চ করতে পারবে |
| 3 | ফুড অর্ডার | ইউজার পছন্দের খাবার কার্টে যোগ করে অর্ডার দিতে পারবে |
| 4 | পেমেন্ট | ইউজার অনলাইন পেমেন্ট (বিকাশ/কার্ড) দিয়ে অর্ডার সম্পন্ন করতে পারবে |
| 5 | অর্ডার ট্র্যাকিং | ইউজার লাইভ ডেলিভারি স্ট্যাটাস দেখতে পারবে |
| 6 | রিভিউ ও রেটিং | ডেলিভারি শেষে ইউজার ফিডব্যাক দিতে পারবে |
🔹 আরেকটি উদাহরণ: (Banking System)
-
ইউজার অ্যাকাউন্ট তৈরি করতে পারবে
-
টাকা জমা ও উত্তোলন করতে পারবে
-
ব্যালান্স চেক করতে পারবে
-
ট্রান্সফার ইতিহাস দেখতে পারবে
-
পাসওয়ার্ড পরিবর্তন করতে পারবে
🔹 টেকনিক্যাল ডকুমেন্টে লেখার ধরন (Template)
FR1: User Login
Description: User can log in using email and password.
Input: Email, Password
Output: Success message or error
Pre-condition: User must be registered.
Post-condition: Session token generated and user redirected to dashboard.
Priority: High
৩. Quality Attribute Requirements (Non-Functional Requirements)
🔹 সংজ্ঞা:
Quality Attributes (বা Non-Functional Requirements) হলো সেইসব বিষয়, যা সিস্টেমের গুণগত মান, পারফরম্যান্স, বিশ্বস্ততা এবং ইউজার এক্সপেরিয়েন্স নির্ধারণ করে।
👉 এক কথায়, Functional Requirement বলে “সিস্টেম কী করবে”,
আর Non-Functional Requirement বলে “সিস্টেমটা কেমন হবে”।
🔹 Quality Attributes-এর প্রধান ধরন ও উদাহরণসমূহ:
| গুণগত বৈশিষ্ট্য (Attribute) | বর্ণনা | উদাহরণ |
|---|---|---|
| Performance (পারফরম্যান্স) | সিস্টেম কত দ্রুত রেসপন্স দেবে | প্রতি পেজ ২ সেকেন্ডের মধ্যে লোড হবে |
| Scalability (স্কেলেবিলিটি) | ইউজার বা ডেটা বাড়লেও সিস্টেমের পারফরম্যান্স ঠিক থাকবে | ১০০০ থেকে ১০০০০ ইউজার একসাথে হ্যান্ডেল করতে পারবে |
| Availability (উপলভ্যতা) | সিস্টেম কত সময় অনলাইন থাকবে | 99.9% uptime SLA |
| Reliability (বিশ্বস্ততা) | সিস্টেম ত্রুটি ছাড়াই চলবে কিনা | প্রতি মাসে ক্র্যাশ রেট < 0.01% |
| Security (নিরাপত্তা) | ডেটা সুরক্ষা ও অথেন্টিকেশন | সব পাসওয়ার্ড এনক্রিপ্টেড, JWT টোকেন ভিত্তিক লগইন |
| Maintainability (রক্ষণাবেক্ষণযোগ্যতা) | কোড সহজে আপডেট ও ফিক্স করা যায় কিনা | মডুলার আর্কিটেকচার এবং কোড কমেন্টেড |
| Usability (ব্যবহারযোগ্যতা) | ইউজার সহজে ব্যবহার করতে পারবে কিনা | UI তে সব একশন ৩ ক্লিকে শেষ হবে |
| Testability (পরীক্ষাযোগ্যতা) | সিস্টেম কত সহজে টেস্ট করা যায় | API গুলো mock করে টেস্ট করা যাবে |
| Interoperability (সমন্বয়যোগ্যতা) | অন্য সিস্টেমের সঙ্গে কাজ করতে পারবে কিনা | Payment Gateway বা External API এর সাথে ইন্টিগ্রেশন সাপোর্ট |
| Portability (স্থানান্তরযোগ্যতা) | অন্য সার্ভার বা ক্লাউডে সহজে স্থানান্তরযোগ্য | Docker-based deployment |
| Modifiability (পরিবর্তনযোগ্যতা) | কোড পরিবর্তনে সিস্টেমে কম প্রভাব পড়ে | Layered Architecture ব্যবহৃত |
🔹 উদাহরণ: Food Delivery System-এর Quality Attributes
| Attribute | Example Requirement |
|---|---|
| Performance | প্রতিটি API কল ৫০০ মিলিসেকেন্ডের মধ্যে রেসপন্স করবে |
| Security | সকল ডেটা HTTPS দিয়ে এনক্রিপ্টেড থাকবে |
| Scalability | সিস্টেম ১০,০০০ একসাথে ইউজার রিকোয়েস্ট হ্যান্ডেল করবে |
| Availability | ২৪/৭ সার্ভিস উপলভ্য, মাসে সর্বোচ্চ ১ ঘণ্টা ডাউনটাইম অনুমোদিত |
| Usability | ইউজার যেন ৩ ক্লিকের মধ্যে অর্ডার সম্পন্ন করতে পারে |
| Maintainability | নতুন রেস্টুরেন্ট যুক্ত করতে কোড পরিবর্তন ছাড়াই করা যাবে |
| Reliability | প্রতিদিন অন্তত ১০,০০০ অর্ডারে কোনো ত্রুটি হবে না |
৪. Functional vs Non-Functional Requirement তুলনা
| বিষয় | Functional | Non-Functional |
|---|---|---|
| কী বোঝায় | সিস্টেম কী করবে | সিস্টেম কেমনভাবে কাজ করবে |
| উদাহরণ | ইউজার লগইন, অর্ডার ট্র্যাকিং | পারফরম্যান্স, সিকিউরিটি, স্কেলেবিলিটি |
| যাচাই | ফিচার টেস্টিং দ্বারা | পারফরম্যান্স ও লোড টেস্টিং দ্বারা |
| প্রভাব | বিজনেস প্রক্রিয়া | সিস্টেম আর্কিটেকচার ও ইনফ্রাস্ট্রাকচার |
৫. আর্কিটেকচার ডিজাইনে এর ভূমিকা
একজন Software Architect এর প্রথম কাজ হলো —
-
Functional Requirements দেখে বুঝা → কোন সার্ভিস / মডিউল লাগবে
-
Quality Attributes দেখে ঠিক করা → কোন আর্কিটেকচার প্যাটার্ন উপযুক্ত হবে
🔹 উদাহরণ:
ধরো, তোমার সিস্টেমে Scalability আর Performance খুব জরুরি।
👉 তাহলে তুমি Microservices Architecture আর Caching Layer (Redis, CDN) ব্যবহার করবে।
আর যদি Security ও Reliability গুরুত্বপূর্ণ হয়,
👉 তাহলে Zero Trust Policy, Failover Cluster, Backup System ডিজাইন করতে হবে।
৬. ছোট সারসংক্ষেপ (মনে রাখার জন্য)
| Functional Requirement | Quality Attribute Requirement |
|---|---|
| কী কাজ করবে | কেমন কাজ করবে |
| ইউজার-ফোকাসড | সিস্টেম-ফোকাসড |
| টেস্ট করা যায় ফিচার টেস্টে | টেস্ট করা যায় পারফরম্যান্স টেস্টে |
| উদাহরণ: লগইন, অর্ডার, পেমেন্ট | উদাহরণ: পারফরম্যান্স, সিকিউরিটি, স্কেলেবিলিটি |
৭. সংক্ষেপে মনে রাখো:
🧭 Functional Requirement = What the system will do
🏗️ Quality Attribute Requirement = How well the system will do it