ক্রিয়ামূলক এবং অ-কার্যকারিতা প্রয়োজনীয়তার মধ্যে পার্থক্য কেন বিরক্ত করবেন?


12

আমি উভয়ের মধ্যে পার্থক্য বুঝতে পারি, তবে আমি আমার সহকর্মীদের দ্বারা কার্যকরী বা অ-কার্যকরী (বা ক্রান্তিকাল) হিসাবে লেবেলিং প্রয়োজনীয়তার সুবিধা নিয়ে প্রশ্নবিদ্ধ হই। কেন এত বিরক্ত করবেন? তিনি যা বলেছিলেন তার দু'দিন ব্যয় হয়েছে একটি প্রকল্পের প্রয়োজনীয়তার তালিকার মধ্য দিয়ে এবং এতে তার কোনও লাভ হয়নি, কারণ শেষ ফলাফলটি ছিল "সমস্ত কিছু করুন" এই আদেশের সাথে নথিটি অন্য ব্যবসায়িক প্রতিষ্ঠানের কাছে জমা দেওয়া।

যা আমি ভয় করি তা হ'ল প্রয়োজনীয়তাগুলি একটি নথিতে একসাথে লম্পট করা। আমি ব্যবহারিক দিক দিয়ে সুবিধাটি ব্যাখ্যা করার চেষ্টা করেছি, তবে এটি বিক্রি করতে পারিনি। কোন প্রয়োজনীয়তাগুলি কার্যকরী এবং কোনটি অকার্যকর তা নথিভুক্ত করার সুবিধাটি আমি কীভাবে বিক্রি করব।


C2.com/cgi/wiki?NonFunctionalRequirements এ একটি আকর্ষণীয় আলোচনা আছে তবে আমি এমন কোনও সন্ধান পাই নি যা একটি নির্দিষ্ট উত্তর দেয়।
থমাস ওয়ানস

কার্যকরী এবং অ-কার্যকরী প্রয়োজনীয়তাগুলি তালিকাভুক্তকরণগুলি 'প্রয়োজনীয়তা-সন্ধানের ক্ষমতা' সহজতর করে তোলে easier আমার অভিজ্ঞতায় কিছু ব্যাচ-প্রক্রিয়া হয়েছে যার কার্যকরী প্রভাব ছিল না তবে কেবল অ-কার্যকরী প্রয়োজনীয়তা রয়েছে such এই জাতীয় ক্ষেত্রে এই স্পষ্ট সীমাবদ্ধতা অনেক সহায়তা করেছে। প্রয়োজনের মসৃণ যাচাইকরণ এবং বৈধতা নিশ্চিত করতে প্রত্যেকটির সাথে আলাদা আলাদা শনাক্তকারী যুক্ত হওয়া উচিত।
আবী

উত্তর:


6

স্পষ্টভাবে পৃথক করে প্রয়োজনীয়তা সঠিক সিস্টেমের নকশা করা আরও সহজ করে তুলবে।

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

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

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

যদি এটি আমার দল হয়, তবে আমি তাদের বলব যে আর্কিটেকচারে কোনও গুরুত্বপূর্ণ বিষয় আমরা মিস করছি না তা নিশ্চিত করার জন্য প্রয়োজনীয়তাগুলি স্পষ্টভাবে বর্ণিত হওয়া উচিত। কেবল কার্যকারিতা নয়, স্থাপত্যবিদদের সম্পর্কে চিন্তা করুন।

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


আর্কিটেকচারে আবদ্ধ NFR- এর জন্য +1। আপনি যদি সামগ্রিকভাবে সিস্টেমটির দিকে না যান তবে এগুলি ঘটানো আরও শক্ত। পারফরম্যান্স এবং ফল্ট সহনশীলতা এনএফআরগুলির দুর্দান্ত উদাহরণ যা প্রায়শই সিস্টেম পর্যায়ে ডিজাইন করা প্রয়োজন।
ফুহরম্যানেটর

5

যখন প্রতিটি প্রয়োজনের সমান অগ্রাধিকার / ওজন থাকে (বিশেষত "বাধ্যতামূলক") তবে আপনার সম্ভবত কেবলমাত্র কার্যকরী এবং অ-কার্যকারী প্রয়োজনগুলি বিভক্ত করার চেয়ে আরও বেশি চিন্তা করার দরকার রয়েছে।

তবুও, প্রয়োজনীয়তার দুটি বিভাগটি পৃথক করার বিভিন্ন কারণ রয়েছে:

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

পরীক্ষার জন্য দায়বদ্ধতা যে সুরক্ষা, ফল্ট সহনশীলতা, সুরক্ষা এবং নির্ভরযোগ্যতা প্রয়োজনীয়তা পূরণ করা হয় তা যাচাই করার ক্ষেত্রে ব্যবহারকারী বা কিউএ টিম কতটা দক্ষ?

নিজেকে পুনরাবৃত্তি করবেন না ডকুমেন্টেশন কোড হিসাবে একই DRY নীতি অনুসরণ করা উচিত। সাধারণ ইউআই স্টাইলিংয়ের প্রয়োজনীয়তাগুলি একত্রে গোষ্ঠীভুক্ত করা উচিত। প্রয়োজনীয়তার জন্য দায়ী ব্যক্তি যদি সত্যিই চান তবে তারা কার্যকরী প্রয়োজনীয়তায় অ-কার্যকরী প্রয়োজনীয়তা (স্বতন্ত্রভাবে বা একটি গোষ্ঠী হিসাবে) উল্লেখ করতে পারেন।

সংস্করণ আপনি যদি প্রচুর "স্ট্যান্ডার্ড" সহ কর্পোরেট পরিবেশে থাকেন - আপনি নির্দিষ্ট ইউআই বা সুরক্ষা (কোনও দম্পতির নাম রাখতে) প্রয়োজনীয় কাগজপত্র লিখতে পারেন যা সংস্করণ করা যেতে পারে। এইভাবে আপনি অ্যাপ্লিকেশনটির নির্দিষ্ট প্রয়োজনীয়তাগুলিতে (বেশিরভাগ কার্যকরী প্রয়োজনীয়তা) লিখতে পারেন: "অ্যাপ্লিকেশনটি অবশ্যই XYZ-Company-SecReq-DocumnentNamingStandard.docx এ সংজ্ঞায়িত সুরক্ষা প্রয়োজনীয়তার V2.3 মেনে চলতে হবে"।


1

ক্রিয়ামূলক এবং অ-কার্যকারিতা প্রয়োজনীয়তার মধ্যে পার্থক্য কেন বিরক্ত করবেন?

পার্থক্যের এক কারণ হ'ল দুটি ধরণের মধ্যে বিমূর্তির স্তর। অকার্যকর প্রয়োজনীয়তাগুলি সিস্টেমের স্তরে রয়েছে এবং বলুন সামগ্রিকভাবে সিস্টেমকে কীভাবে আচরণ করা উচিত। কার্যকরী প্রয়োজনীয়তাগুলি একটি নির্দিষ্ট বৈশিষ্ট্য এবং ক্লায়েন্টদের কী কী বৈশিষ্ট্য এবং কার্যকারিতা সরবরাহ করতে হবে তা উল্লেখ করে।

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

যা আমি ভয় করি তা হ'ল প্রয়োজনীয়তাগুলি একটি নথিতে একসাথে লম্পট করা। আমি ব্যবহারিক দিক দিয়ে সুবিধাটি ব্যাখ্যা করার চেষ্টা করেছি, তবে এটি বিক্রি করতে পারিনি। কোন প্রয়োজনীয়তাগুলি কার্যকরী এবং কোনটি অকার্যকর তা নথিভুক্ত করার সুবিধাটি আমি কীভাবে বিক্রি করব।

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


1

সাধারণত, আপনি দলকে তাদের বিরুদ্ধে বিতরণ করতে সহায়তা করার জন্য প্রয়োজনীয়তাগুলি শ্রেণিবদ্ধ করেন। যদি কোনও স্থাপত্যের প্রয়োজনে নির্দিষ্টভাবে লক্ষ্যযুক্ত কোনও প্রয়োজন হয়, একে "আর্কিটেকচার" প্রয়োজন হিসাবে আর্কিটেকচারে কাজ করার সময় দলটিকে সহায়তা করা উচিত।

সমস্ত প্রয়োজনীয়তার একটি বৃহত একক দস্তাবেজ অগত্যা কোনও খারাপ জিনিস নয় ... এটি পর্যালোচনা করতে 2 দিন ব্যয় করাও খারাপ নয়। সমস্যাটি সাধারণত হ'ল একবার কোনও ব্যক্তি প্রয়োজনীয়তাগুলি পর্যালোচনা করে, সেগুলি বোঝে, তবে অন্য কারও পক্ষে এটি করা সহজ নয়। মেটাডাটা দিয়ে লেবেলিং প্রয়োজনীয়তা শুরু করতে এটি বড় সাহায্য হতে পারে যা এই প্রকল্পে যোগদানকারী অন্যান্য ব্যক্তিদের সহায়তা করবে।

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


-3

বিচ্ছেদের একাধিক সুবিধা রয়েছে।

  1. পরীক্ষার সময় সাশ্রয় করুন (যেমন কেবল কার্যকরী প্রয়োজনীয়তা পরীক্ষা করুন)
  2. প্রয়োজনীয়তার ভবিষ্যতে পরিবর্তনগুলির উপর সময় সাশ্রয় করে (অর্থাত্ অ-কার্যকরী প্রয়োজনীয়তা পর্যালোচনা / অনুমোদন / প্রয়োগ / পরীক্ষার জন্য কম সময় নেয়)
  3. নিয়ন্ত্রিত (অর্থাত্ এফডিএ, ইত্যাদি) বিশ্বে, অ-কার্যকরী প্রয়োজনীয়তার জন্য কার্যকরী প্রয়োজনের পরিমাণের পরিমাণের 1/10 তম প্রয়োজন।
  4. দলকে সিনিয়র (ক্রিয়ামূলক) এবং জুনিয়র (অ-কার্যকরী) দলের সদস্যদের মধ্যে কাজ ভাগ করার দক্ষতা দেয়।

আমি যেতে পারে ...

পৃষ্ঠতলে দুটি দিন অনেকটা দীর্ঘ সময়ের মতো মনে হয়, দীর্ঘমেয়াদে এটি কয়েক সপ্তাহ বা এমনকি কয়েক মাস এমনকি ভবিষ্যতের কাজ বাঁচাতে পারে।


অ-কার্যক্ষম প্রয়োজনের উদাহরণটি হ'ল "10 সেকেন্ডেরও কম সময়ে লোড"। এটি সিস্টেমকে কী করা দরকার তা বর্ণনা করে না (এটি একটি কার্যকরী রেকর্ড হবে), এটি সিস্টেমের আরও কিছু দিক বর্ণনা করে। আমি জুনিয়র দলের সদস্যদের এই প্রয়োজনীয়তাটি দেব না :)
gbjbaanb

"কেবলমাত্র কার্যকরী প্রয়োজনীয়তাগুলি পরীক্ষা করুন" - কীভাবে একটি অ-কার্যকরী প্রয়োজনীয়তা সম্পর্কে বলা হয় যে "সিস্টেমের ডাটাবেস ব্যর্থতা সহ্য করা উচিত" (শুভেচ্ছা এটি পরীক্ষা করে না এবং দেখুন যে আপনার ক্লায়েন্ট কীভাবে এটি পছন্দ করে)। আমি @gbjbaanb এর সাথে একমত যে ননফাংশনাল প্রয়োজনীয়তা (যা সাধারণত কোনও স্থাপত্য স্তরে পরিচালিত হয়!) জুনিয়র দলের সদস্যদের দেওয়া হবে না। আপনি কি বুঝতে পারছেন যে এনএফআর আসলে কি?
ফুহরম্যানেটর
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.