এজ কেসগুলির জন্য স্বীকৃতি মানদণ্ড

Question

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

আমার প্রতিরক্ষার জন্য আমি গল্পটির জন্য তার নকশাটি প্রয়োগ না করা পর্যন্ত জানি না, সুতরাং সমস্ত সম্ভাবনার মধ্য দিয়ে পুনরাবৃত্তি করা শক্ত (কোনও ডিবি বা বৈশিষ্ট্য ফাইলে কনফিগার হবে?)। সরলতার স্বার্থে, যাক আমাদের ক্যালকুলেটর অ্যাপে বিভাগ যুক্ত করার জন্য একটি গল্প আছে। আদর্শ এসসিআরইউম বিশ্বে, গ্রহণের মানদণ্ডে "শূন্য দৃশ্যের দ্বারা হ্যান্ডেল বিভাজন" যুক্ত করা কি আমার উপর নির্ভর করবে বা অ্যাপটি 5/০২ এ প্রবিষ্ট না হওয়ার ফলে সে কীভাবে বিকাশ করবে সে ক্ষেত্রে সে কাজ করা উচিত? স্পষ্টতই, এই ক্ষেত্রে আমি 5/09-তে অ্যাপ্লিকেশানটি শক্তভাবে ক্র্যাশ করলে আমি গ্রহণ করব না, তবে আমি লগ করে ফেললে, ডিআইভি0 প্রিন্ট করে, বা ত্রুটিটি হ্যান্ডেল করার জন্য অন্য কোনও উপায় ... যদি না হয় ততক্ষণ ক্রাশ হবে না

Comments

কেন আপনি গল্পের প্রান্তে মামলা রাখতে নোট করেন না?

— জেফো

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

— rszalski

Answer 1

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

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

আমার মনে হয় যে গুরুত্বপূর্ণ বার্তাটি আপনার কাছে পৌঁছে দেওয়া দরকার এবং আপনার পক্ষে সমস্ত দলের সদস্যদের কাছ থেকে গ্রহণযোগ্যতা রয়েছে তা হ'ল আপনি সবাই একই দলে রয়েছেন। পণ্যটি সম্পূর্ণ না হলে পণ্যটি সম্পূর্ণ না হয় এবং দলটিকে দোষ দেওয়া হয়, কোনও প্রদত্ত সদস্য নয়।

Answer 2

"আমার কাজ নয়, আমার দায়িত্ব নয়" ধরণের মনোভাব / মন্ত্রের বিপরীতে দলটির একসাথে কাজ করা দরকার।

স্বীকৃতি মানদণ্ড আকারে আসে:

• ব্যবসায় স্বীকৃতি
• গুণগত মান গ্রহণ

সাধারণত ব্যবসায়িক গ্রহণযোগ্যতা সাধারণত প্রশ্নের উত্তর দেয়:

• যে বৈশিষ্ট্যটি প্রয়োগ করা হয়েছে তা কি আমি এটি করতে চাই তা করতে পারে?

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

প্রত্যাশিত যে ব্যবসায়ের প্রয়োজনীয়তা একটি পুনরাবৃত্তির আগে সংজ্ঞায়িত করা উচিত যাতে মানের নিশ্চয়তা অ-ব্যবসায়িক প্রয়োজনীয়তার উপর কোনও প্রযুক্তিগত বিকাশ করতে পারে। গুণমানের নিশ্চয়তার ফলে ধ্বংসাত্মক কেসগুলির পাশাপাশি প্রবণতাগুলি যেমন প্রয়োজন তেমন বিকাশ করা উচিত।

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

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

যে কোনও নতুন অনুসন্ধান ত্রুটিযুক্ত বা অতিরিক্ত গল্প স্পাইক হিসাবে লগ ইন করা যেতে পারে। নিখুঁত বিশ্বে এটি কখনই ঘটবে না, তবে বাস্তবে কোনও বৈশিষ্ট্য / গল্পে কাজ করার সময় সাধারণত কিছু পরিমাণ "আবিষ্কার" হয়। এটাই স্বাভাবিক।

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

QA তে:

"আরে, বিকাশকারী আমাদের এই বিশেষ দৃশ্যটি পরিচালনা করতে হবে I've আমি আবিষ্কার করেছি যে আমি যদি এই ডেটাটি ইনপুট করি তবে আমি একটি ত্রুটি পাই।"

DEV:

"এটি কোনও প্রয়োজনের আওতায় আনা হয়নি, তবে আমরা এটি আওতায় কিছু অতিরিক্ত কার্যকারিতা যুক্ত করতে পারি OK

ব্যবসা:

"আসুন আমাদের স্ট্যান্ডার্ড ত্রুটি বার্তাটি দেখি এবং ব্যবহারকারীকে এই দৃশ্যের জন্য আবার চেষ্টা করতে দিন then তারপরে আরও কত বেশি প্রচেষ্টা করা হবে?"

DEV:

"এটি সহজ হবে, কেবল একটি অতিরিক্ত ঘন্টা বা দুই ঘন্টা I আমি এই পুনরাবৃত্তির জন্য প্রতিশ্রুতি দিতে পারি Q

বা এটি যদি অনেক বেশি কাজ হয় তবে ব্যাকলগে একটি নতুন গল্প যুক্ত হয়। দলটি মূল কাহিনীটি সমস্ত আসল প্রয়োজনীয়তা পূরণের কারণে গ্রহণ করতে পারে এবং তারপরে পরবর্তী পুনরাবৃত্তিতে স্পাইক গল্পটি বেছে নিতে পারে।

Answer 3

ভুল বা অস্পষ্ট ইনপুটের মুখে শক্তিশালী আচরণ করে এমন সফ্টওয়্যার রচনা করা একটি সফ্টওয়্যার বিকাশকারীের কাজের একটি প্রয়োজনীয় অংশ।

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

স্বীকৃতি পরীক্ষা যাইহোক যে কোনও প্রয়োজনীয়তার নথির একটি গুরুত্বপূর্ণ অংশ হওয়া উচিত। যদি কোনও প্রয়োজনীয়তা গ্রহণযোগ্যতার জন্য তার মানদণ্ডও না জানায় তবে এটি সত্যই কোনও প্রয়োজন নয়; এটা একটা ইচ্ছা

Comments

প্রয়োজনীয়তা অনুমান করা সফ্টওয়্যার বিকাশকারী কাজের অংশ নয়। কোনও বিকাশকারী কীভাবে ভুল বা দ্ব্যর্থহীন ইনপুট কী তা সুনির্দিষ্টভাবে উল্লেখ না করা উচিত? এবং দেখে মনে হচ্ছে এটি উপরের ক্ষেত্রে।

— BЈовић

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

— রবার্ট হার্ভে

গ্রহণযোগ্যতা পরীক্ষা প্রয়োজনীয়তা থেকে আসছে। যদি তাদের উপস্থিত না থাকে ...

— BЈовић

আমার উত্তরের শেষ অনুচ্ছেদটি দেখুন।

— রবার্ট হার্ভে

... তাহলে এটি একটি ইচ্ছা। আমার প্রিয় একটি সফ্টওয়্যার কথা বলার।

— রাবারডাক

Answer 4

এখানে যা ঘটেছে তা হ'ল আপনি মানটি আবিষ্কার করেছেন । গল্পটি (এবং স্বীকৃতির মানদণ্ড) কখন রচনা করা হয়েছিল বা কোডটি কখন লেখা হয়েছিল সে সম্পর্কে ইনপুট মানটি ভাবা হয়নি। যদি এটি গ্রহণযোগ্যতার মানদণ্ডের অংশ না হয় তবে আপনার কাছে গল্পটি প্রত্যাখ্যান করার কোনও ভিত্তি নেই।

আমাদের দলে আমরা কী করব তা হ'ল:

1. প্রত্যাশিত এবং প্রকৃত আচরণের বিশদ বিবরণী একটি বাগ তৈরি করুন।
2. গ্রহণের মানদণ্ড আপডেট করুন যাতে নতুন পাওয়া প্রয়োজনীয়তা নথিভুক্ত হয়।
3. পরবর্তী পুনরাবৃত্তিতে অন্যান্য সমস্ত গল্প এবং বাগ সহ বাগটিকে অগ্রাধিকার দিন।

এখানে সুবিধাটি হ'ল আপনি এই বাগটি ঠিক করা পরবর্তী গুরুত্বপূর্ণ কাজটি কিনা তা বিবেচনা করতে বাধ্য হন। এটি ঠিক করার জন্য যথেষ্ট গুরুত্বপূর্ণ বা নাও হতে পারে তবে এটির মূল্য বিবেচনা করা গুরুত্বপূর্ণ।

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

Answer 5

কিছু পর্যবেক্ষণ:

... যখন আমি তার গল্পগুলি প্রত্যাখ্যান করি

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

তিনি এটিকে অন্যায় বলেছেন যেহেতু আমি প্রান্তের মামলাগুলি নির্দিষ্ট না করি।

আপনি সমস্ত প্রান্তের কেসগুলি জানতে পারবেন এমন প্রত্যাশা করা তার পক্ষে অন্যায্য। তবে একই সাথে আপনার কাছে তার কাছ থেকে এটি আশা করাও অন্যায়। প্রতিটি পরিবর্তনের ঝুঁকি থাকে এবং সমস্যাগুলি আবিষ্কার হওয়ার সাথে সাথে তাদের সমাধান করার জন্য আপনার সকলের একসাথে কাজ করা দরকার।

গল্পটির জন্য তার নকশাটি প্রয়োগ না করা পর্যন্ত আমি জানি না

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

---

দেখে মনে হচ্ছে আপনার ছেলেরা প্রক্রিয়া উন্নতিতে কাজ করা উচিত এবং কিছু টিম বিল্ডিং করা উচিত। প্রক্রিয়াটির জন্য আমি প্রস্তাবিত কিছু জিনিস:

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

Comments

ব্যক্তির ডিজাইনটি জানা উচিত নয় এমন প্রয়োজনীয়তাগুলি সম্পর্কে আমি সেই অংশের সাথে একমত। যদি ডিজাইনটি আপনার প্রয়োজনীয়তা পরিবর্তন করে তবে আপনার প্রয়োজনীয়তাগুলি ভুল।

— ডঙ্ক

Answer 6

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

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

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

Comments

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

— রবার্ট হার্ভে

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

— BЈовић

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

— রবার্ট হার্ভে

@ রবার্টহারভে ওয়েল, বিভাগটি আইইইই 754 তে বেশ ভালভাবে সংজ্ঞায়িত হয়েছে OP সেখানে প্রয়োজনীয়তাগুলি হ'ল একজন ম্যানেজার আপনার ডেস্কে আসছেন এবং তিনি যা চান তা বলছেন। অবশ্যই, তারা কোথাও লিখিত এবং ভাল ব্যাখ্যা করা হয় না। সুতরাং, যখন আপনি অ-বিদ্যমান বা ছায়াময় প্রয়োজনীয়তা নিয়ে কাজ করেন, ফলাফল কিছু হতে পারে।

— BЈовић

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

— ফিফ