１. تفاوت بین نیازمندی کارکردی و غیرکارکردی را توضیح دهید.
نیازمندی کارکردی رفتار سیستم را توصیف میکند (چه کاری انجام میدهد)، مانند «ثبتنام کاربر». نیازمندی غیرکارکردی کیفیت یا محدودیتهای سیستم را مشخص میکند (چطور انجام دهد)، مانند عملکرد، امنیت یا در دسترس بودن. تحلیلگر باید هر دو را جدا و سپس بهم نگاشت کند تا طراحی و تست قابلپیگیری شود.
２. یک گزاره NFR «خوب» چه ویژگیهایی باید داشته باشد؟
پاسخ: مشخص، قابلسنجش (SLI)، قابلتست، دارای دامنه/استثناها، و قابلردگیری به آیتمهای طراحی و تست. مثال: «p95 latency مسیر پرداخت ≤ 300ms در ساعات اوج (9–23)».
３. SLI، SLO و SLA را تعریف کنید و رابطهشان را توضیح دهید.
پاسخ: SLI (Service Level Indicator) یک شاخص اندازهگیر است (مثلاً latency). SLO (Service Level Objective) هدف داخلی قابلپذیرش برای SLI است (مثلاً p95 ≤ 300ms). SLA (Service Level Agreement) تعهد قراردادی به مشتری است که معمولاً تبعات حقوقی دارد. تحلیلگر باید SLI/SLO را بهشکل دادهمحور تعریف کند تا SLAها منطقی و قابلپشتیبانی شوند.
４. بودجه خطا (Error Budget) چیست و در تصمیمگیری انتشار کجا کاربرد دارد؟
پاسخ: اختلاف بین SLO و عملکرد واقعی که نشان میدهد چهمیزان خطا/اختلال مجاز است. اگر بودجه مصرف شود، اولویت به پایداری و رفع باگ میرود و انتشار فیچرهای پرریسک متوقف میشود.
５. چگونه NFRهای عملکرد را بر مبنای سنجههای توزیعشده (p50/p95/p99) تعریف میکنید؟
پاسخ: با آنالیز توزیع تأخیر از لاگها، تعیین آستانههایی که تجربه کاربر را تضمین میکنند (مثلاً p95 را هدف قرار دهید)، و سپس SLO برای هر شاخص تعیین کنید؛ p99 برای سناریوهای پیک/نگهداری استفاده میشود.
６. سه روش برای تست NFR امنیتی یک API نام ببرید.
پاسخ: اسکن نفوذ (Penetration Testing)، تست اعتبارسنجی دسترسی (Authorization fuzzing / RBAC checks)، و ارزیابی رمزنگاری و نگهداری کلید (کشف اطلاعات حساس در لاگ/پایگاه داده).
７. چگونه NFR مربوط به ظرفیت را برای سرویس با رشد کاربران پیشبینی میکنید؟
پاسخ: تحلیل الگوی رشد تاریخی، تخمین تراکنشهای همزمان در پیک، ظرفیت فعلی سرورها و محاسبه نرخ رشد. سپس طرح مقیاسپذیری (افقی/عمودی) و هزینهٔ نگهداری بین سالهای آتی تدوین میشود.
８. Observability چه تفاوتی با Monitoring دارد و چرا برای اثبات انطباق NFR لازم است؟
پاسخ: Monitoring وضعیت کنونی را گزارش میدهد (متریکها، هشدارها)، Observability امکان درک چرایی رفتار را فراهم میکند (تراسیگ، لاگ ساختاری، مترکهای دلخواه). برای اثبات NFR نیاز به تریس و لاگ است تا انحرافها قابلردگیری و بازتولید باشند.
９. تعریف RTO و RPO و نقش آنها در NFRهای قابلاحیا (Recovery) چیست؟
پاسخ: RTO (Recovery Time Objective) زمان مجاز برای بازیابی سرویس و RPO (Recovery Point Objective) حداکثر دادهای که مجاز به از دست رفتن است. هر دو پارامتر برای طراحی DR و برنامهٔ پشتیبانگیری حیاتیاند و باید با نیاز کسبوکار همراستا شوند.
１０. چه معیاری برای تعیین SLO دسترسپذیری مناسب است؟
پاسخ: تحلیل تاثیری که اختلال هر دقیقه بر کسبوکار دارد، هزینهٔ خاموشی، و حساسیت ذینفعان؛ سپس تعیین درصد در دسترس بودن که اقتصادی و عملیاتی است (مثلاً 99.9% یا 99.99%).
１１. ضدالگوهای رایج در تعریف NFR را نام ببرید و توضیح دهید چرا مخرباند.
پاسخ: بیان مبهم («سریع»، «ایمن» بدون عدد)، عدم امکان تست، و تضاد با بودجه یا اهداف کسبوکار. اینها باعث اختلاف تفسیر، تستناپذیری و شکست در تحویل میشوند.
１２. چگونه NFRهای امنیتی را به نیازمندیهای فنی قابلاجرا ترجمه میکنید؟
پاسخ: از نیاز کسبوکار (مثلاً «حفظ محرمانگی پرداخت») شروع، سپس مکانیزمها را (TLS، رمزنگاری در حالت سکون، سختسازی دسترسی، لاگ امن) مشخص و معیارهای پذیرش را تعیین میکنید.
１３. نمونهای از NFR قابلیت نگهداری (maintainability) و چگونگی سنجش آن را بیان کنید.
پاسخ: «زمان متوسط برای پیادهسازی یک تغییر کوچک ≤ 3 روز» را میتوان با ردیابی زمانهای پیادهسازی و تعداد خطوط تغییر (code churn) سنجید. شاخصهای کد مانند پوشش تست و پیچیدگی حلقوی نیز کمک میکنند.
１４. چه زمانی باید NFR را بازنگری کنید؟
پاسخ: هنگام تغییرات بازار/قانونی، افزایش/کاهش بار، معماری بازطراحی، یا پس از incidentهای مکرر؛ بازنگری بر پایه داده و درسهای یادگرفته شده انجام شود.
１５. چطور NFRهای مقیاسپذیری را برای سرویس میکروسرویسی مشخص میکنید؟
پاسخ: تعیین حد تراکنش/ثانیه، مشخص کردن الگوی مقیاس (افقی/عمودی)، تعیین Latency هدف در بارهای مختلف و تعریف هزینه/زمان افزودن ظرفیت.
１６. چه معیارهایی برای NFRهای امنیتی که با قوانین GDPR تداخل دارند باید لحاظ شود؟
پاسخ: حداقلسازی دادهها، نگهداری محدود، حقوق بازیابی/حذف، رمزنگاری، و مستندسازی پردازش؛ همچنین تضمین انتقال امن دادههای شخصی و ارزیابی خطر.
１７. توضیح دهید چگونه NFR را در Definition of Done (DoD) تیم وارد میکنید.
پاسخ: DoD باید شامل چک لیستی از NFRهای مرتبط با فیچر باشد (مثلاً پوشش تست، متریکهای عملکرد، اسکن امنیتی) تا هر آیتم قبل از بستهشدن تسک تأیید شود.
１８. برای اطمینان از رعایت NFRهای دسترسی، چه تستهایی لازم است؟
پاسخ: تستهای بار (Load/Stress), تست failover و DR, chaos testing برای سناریوهای خرابی، و تستهای smoke برای صحت ابتدایی سرویس.
１９. چطور NFRهای مربوط به حریم خصوصی را در فاز طراحی اعمال میکنید؟
پاسخ: با اعمال اصل Privacy by Design: حداقلسازی داده، رمزنگاری، کنترل دسترسی سطحباریک، و مستندسازی دادهها و پردازش آنها؛ همچنین تحلیل خطر حریم خصوصی (PIA).
２０. نمونهای از متضاد شدن دو NFR و نحوه حل آن را شرح دهید.
پاسخ: امنیت بالا (رمزنگاری و کامل کردن تسجیل) میتواند عملکرد را کاهش دهد. حل: تعیین سطح رمزنگاری بر اساس حساسیت دادهها، استفاده از کش امن، و پیشسنجهگذاری برای حفظ تعادل.
２１. چگونه نمرهی اولویت NFRها را تعیین میکنید؟
پاسخ: با ارزیابی تأثیر بر مشتری، هزینهٔ عدم رعایت، احتمال وقوع، و نیاز کسبوکار؛ معمولاً از ماتریس ریسک (Impact × Probability) استفاده میشود.
２２. شرح دهید NFR «قابلیت مشاهدهپذیری» را چگونه قابلسنجش میکنید.
پاسخ: تعریف SLIهای مرتبط (درصد درخواستهای دارای Correlation-ID، درصد ترِیسیگ فعال) و داشتن داشبوردهایی که این SLIها را گزارش کنند و هشدارهای آستانهای برای افت را تعریف کنند.
２３. مثال یک سناریوی تست رگرسیون NFR را بنویسید.
پاسخ: اجرای تست بار استاندارد پس از تغییر در لایه پایگاهداده و مقایسه p95 latency و نرخ خطا با نسخهٔ قبلی؛ در صورت افزایش بیش از 10%، بازبینی لازم است.
２４. نقش تحلیلگر سیستم در تعیین سیاست Timeout و Retry چیست؟
پاسخ: تحلیلگر باید پیشفرضهای عملکردی و هزینههای Retry را محاسبه کند، تا سیاستی تعیین شود که از stormهای Retry جلوگیری کند و Idempotency حفظ شود.
２５. چه اطلاعاتی باید در سند NFR ثبت شود تا برای توسعه و تست کافی باشد؟
پاسخ: هدف/معیار (SLO/SLI)، دامنه/مرز، روش تست، پیامدهای نقض، وابستگیها، و مالک مسئول؛ همراه با مثالهای مقادیر آستانه.
２６. چگونه NFRهای یک سرویس را به رگههای (traces) توزیعشده نگاشت میکنید؟
پاسخ: با طراحی تراسینگ در نقاط مرزی عملیات حساس، اضافهکردن spanها برای IO/DB/HTTP و اتصال آنها به SLIها (مثلاً latency مسیر کامل) تا مقادیر NFR از تراسها استخراج شوند.
２７. چه شاخصهایی را برای NFR قابلیتاطمینان (reliability) پیشنهاد میکنید؟
پاسخ: MTBF (میانگین زمان بین خرابیها)، MTTR (میانگین زمان بازیابی)، نرخ خطا بر میلیون تراکنش، و در دسترس بودن درصدی (uptime).
２８. چگونه NFR مربوط به نگهداری (operability) را مشخص میکنید؟
پاسخ: تعریف شاخصهایی مثل زمان لازم برای بررسی لاگها، زمان راهاندازی سرویس، ابزارهای لازم برای اپراتور و SLAs داخلی برای واکنش به incidentها.
２９. در پروژهای با چند سامانه، چگونه NFRهای بین سامانهای (cross-system) را هماهنگ میکنید؟
پاسخ: با قراردادهای بینسرویسی (API contracts)، تعریف SLAهای بین سرویسها، و جلسات CCB برای بازنگری تأثیر تغییرات بر NFR کل سیستم.
３０. چه فرمت و ساختاری برای نوشتن یک گزاره NFR پیشنهاد میکنید؟
پاسخ: قالب «در موقعیت X، معیار Y باید ≤/≥ Z در بازهٔ T، تحت شرایط C، و با روش تست D قابلاثبات باشد.» — این قالب قابلفهم و تستپذیر است.
بخش B — معماری و یکپارچهسازی برای تحلیلگران — ۲۵ سؤال
３１. معیارهای انتخاب بین integration styleهای اصلی (Batch vs. Message vs. API) را فهرست کنید.
پاسخ: نیاز به تاخیر، حجم داده، ترتیبپذیری، تحمل خطا، نیاز تراکنشی، هزینه عملیاتی، و تطبیقپذیری با معماری موجود؛ هر کدام برای سناریوهای متفاوت مناسباند.
３２. مزایا و معایب استفاده از Event Streaming (مثل Kafka) برای یک سامانه مالی چیست؟
پاسخ: مزایا: تاخیر پایین، مقیاسپذیری، بازپخش رویدادها؛ معایب: پیچیدگی عملیاتی، نیاز به مدیریت حالت مصرفکننده و ترتیببندی، خطرات سازگاری داده.
３３. چه الگوهایی برای تامین Idempotency در یک API توزیعشده پیشنهاد میدهید؟
پاسخ: استفاده از کلید Idempotency در هدر، ذخیرهسازی نتیجه در دیتااستور با TTL، و طراحی عملیاتها بهصورت غیرتغییری (stateless) تا دوبار اجرا مشکلی ایجاد نکند.
３４. تفاوتهای اصلی REST و gRPC در زمینه طراحی API را توضیح دهید.
پاسخ: REST مبتنی بر HTTP/JSON است، سادگی و سازگاری با وب دارد؛ gRPC از HTTP/2 و protobuf استفاده میکند، برای ارتباطات با کارایی بالا و دوطرفه مناسبتر است. انتخاب بستگی به نیازهای تأخیر و نوع مصرفکننده دارد.
３５. چگونه قرارداد API را طوری طراحی میکنید که قابلتکامل (evolvable) باشد؟
پاسخ: نسخهگذاری، افزودن فیلدهای اختیاری، رعایت سازگاری پسرو، ارائه راهکارهای Deprecation و مستندسازی واضح برای مصرفکنندگان.
３６. الگوی Outbox چیست و چرا در معماری رویدادمحور مهم است؟
پاسخ: Outbox الگوی ذخیرهسازی رویدادها در همان تراکنش دیتابیس تغییرات است تا تضمین اتمی انتشار رویداد فراهم شود؛ از از دست رفتن همگامسازی بین DB و رویدادها جلوگیری میکند.
３７. چه سناریویی باعث میشود از synchronous API به asynchronous messaging مهاجرت کنید؟
پاسخ: نیاز به مقیاس بالا، تحمل خطا، حذف وابستگی زمانی بین سرویسها، یا وقتی که تاخیر کم اما قطعی لازم نیست و باید بار را صفبندی کنید.
３８. Circuit Breaker چه مشکلی را حل میکند و کجا باید گذاشته شود؟
پاسخ: از فروپاشی cascade جلوگیری میکند وقتی یک سرویس downstream دچار مشکل است. در نقاط مرزی بین سرویسها و قبل از هر تماس پرهزینه یا ناپایدار قرار میگیرد.
３９. چگونه تراکنش توزیعشده را در محیط میکروسرویسها مدیریت میکنید؟
پاسخ: ترجیح الگوهای SAGA (choreography یا orchestration) برای حفظ سازگاری در دامنههای مختلف بهجای ۲PC که پیچیدگی و قفل منابع را افزایش میدهد.
４０. مزایا و معایب استفاده از API Gateway را بیان کنید.
پاسخ: مزایا: نقطه مرکزی احراز هویت، rate limiting، نگاشت مسیرها، A/B routing. معایب: نقطهی بالقوه شکست، پیچیدگی پیکربندی و نیاز به مانیتورینگ.
４１. چگونه تضمین ترتیب پیامها را در یک سامانه event-streaming فراهم میکنید؟
پاسخ: پارتیشنبندی منطقی بر اساس کلید ترتیب (مثلاً accountId)، تضمین ترتیب در پارتیشن واحد، و طراحی مصرفکنندگان با همگامسازی مناسب.
４２. برای تبادل فایل دستهای (batch), چه مکانیزمهایی برای اطمینان از یکپارچگی فایل پیشنهاد میکنید؟
پاسخ: checksum (SHA256)، تایماستمپ، نامگذاری اتمیک (upload to temp then move), فایل manifest، و مکانیزم بازگشت در صورت خطا.
４３. الگوی Bulkhead چیست و چرا در طراحی مقاوم سیستم کاربرد دارد؟
پاسخ: جداکردن منابع و اجزا به محفظههای مستقل تا خرابی در یک بخش، دیگر بخشها را تحتتأثیر قرار ندهد؛ مثال: poolهای مجزا برای انواع درخواستها.
４４. چه معیارهایی برای انتخاب بین REST و GraphQL برای یک محصول باید در نظر گرفته شود؟
پاسخ: نیاز مصرفکننده به گرفتن دادههای متغیر/کمحجم، کشینگ، سادگی پیادهسازی، پیچیدگی سرور و توانایی سمتسرور در کنترل Queryها.
４５. شرحی کوتاه از الگوی Adapter/Anti-Corruption Layer در مهاجرت سیستمها بدهید.
پاسخ: لایهای که قراردادهای خارجی را به مدل داخلی ترجمه میکند و از انتقال مفاهیم ناسازگار به داخل سیستم جلوگیری میکند؛ بهخصوص در ادغام با سیستمهای قدیمی مفید است.
４６. چه ملاحظاتی در طراحی API برای عملیات مالی (حساس، تراکنشی) باید رعایت شود؟
پاسخ: Idempotency، اعتبارسنجی قوی، auditing و لاگ کامل، رمزنگاری انتقال و سکون، و سطوح دسترسی دقیق.
４７. مزایا و معایب استفاده از قالب پیام JSON vs. Protobuf را مقایسه کنید.
پاسخ: JSON: انسانخوان و انعطافپذیر، اما حجیم و کندتر. Protobuf: فشرده، سریع، اما نیاز به schema و ابزار تولید کد دارد؛ برای ارتباطات با عملکرد بالا مناسبتر است.
４８. الگوی Saga (choreography) را با یک مثال عملی توضیح دهید.
پاسخ: در SAGA choreography هر سرویس پس از انجام کار خود رویدادی منتشر میکند که سرویسهای دیگر بر اساس آن عمل میکنند؛ مثال: در پرداخت، سرویس پرداخت رویداد «پرداخت انجام شد» را منتشر میکند که سرویس سفارش را بهروزرسانی میکند.
４９. چگونه از قابلیت مشاهدهپذیری برای دنبالکردن یک تراکنش پیچیده در چند سرویس استفاده میکنید؟
پاسخ: استفاده از Correlation-ID شروع شده در Gateway، قراردادن آن در لاگها و spanهای تریس توزیعشده تا مسیر کامل تراکنش قابلردیابی و زمانبندی شود.
５０. در معماری کشمحور، چه استراتژیهای invalidation وجود دارد؟
پاسخ: TTL (زمان انقضا)، Cache-aside (اپلیکیشن مسئول کش کردن/پاکسازی)، Write-through/Write-back، و event-based invalidation برای هماهنگی تغییرات.
５１. الگوی «backpressure» در طراحی سیستم چه مسئلهای را حل میکند؟
پاسخ: از فشار بیشازحد به مصرفکننده جلوگیری میکند، با مکانیسمهایی که تولیدکننده را کند میکند یا درخواستها را صفبندی میکند تا از پر شدن منابع جلوگیری شود.
５２. چگونه در یک اکوسیستم چندتیمی، مسئولیتهای معماری و طراحی را توزیع میکنید؟
پاسخ: تعریف مرزهای واضح، استانداردهای مشترک (contract tests), ownership مشخص برای سرویسها، و جلسات معماری منظم (Architecture Review Board).
５３. چه شاخصهایی را برای سنجش هزینهٔ عملیاتی (operational cost) یک گزینه معماری پیشنهاد میکنید؟
پاسخ: نیاز منابع (CPU/RAM/Storage)، هزینهٔ نگهداری، پیچیدگیِ نیروی انسانی، نیاز به تخصص، و اثر بر SLAs.
５４. چه زمانی باید از database per service استفاده کرد و خطرات آن چیست؟
پاسخ: وقتی هر سرویس نیاز مدل داده مستقل و آزادی توسعه دارد؛ خطرات شامل پیچیدگی تراکنش توزیعشده، سازگاری داده و هزینه نگهداری چند DB است.
５５. چگونه یک مطالعه موردی ساده برای انتخاب بین Message Queue و HTTP API طراحی میکنید؟
پاسخ: تعریف نیاز (تاخیر مجاز، حجم، ترتیب)، شبیهسازی بار با پارامترهای واقعی، بررسی سناریوهای خطا و هزینه عملیاتی، و جمعبندی نتایج با معیارهای تصمیمگیری.
بخش C — مدیریت پیشرفته نیازمندیها — ۲۵ سؤال
５６. ADR (Architecture Decision Record) چیست و چه اجزایی باید داشته باشد؟
پاسخ: مستندی که تصمیم معماری، گزینههای بررسیشده، دلایل انتخاب و پیامدها را ثبت میکند. اجزا: عنوان/تاریخ، زمینه، گزینهها، تصمیم نهایی، پیامدها و وضعیت (تجربه/Deprecated).
５７. ماتریس ردیابی نیازمندیها (Traceability Matrix) چه وظیفهای دارد؟
پاسخ: پیوند بین نیازمندیها، طراحی، تست و انتشار را برقرار میکند تا پوشش بررسی و اثرگذاری تغییر قابل پیگیری باشد.
５８. تکنیکهای اولویتبندی نیازمندیها را نام ببرید و یکی را تشریح کنید.
پاسخ: MoSCoW، Kano، Weighted Shortest Job First (WSJF). مثلاً WSJF با محاسبه نسبت ارزش به هزینهٔ تاخیر، اولویتهایی که بیشترین ارزش زمانی را دارند بالا میبرد.
５９. چگونه تضاد بین ذینفعان را در مورد یک نیاز حیاتی حل میکنید؟
پاسخ: جمعآوری دادههای تأثیر (cost/benefit), اجرای پروتوتایپ یا تحلیل ریسک، برگزاری CCB و تصمیمگیری بر اساس معیارهای کمی (تأثیر، ریسک، اولویت کسبوکار).
６０. چه نقشی برای assumptions log در مدیریت نیازمندیها قائلید؟
پاسخ: ثبت مفروضات بهمنظور شفافسازی ریسکها و تسهیل بازنگری هنگام تغییر واقعیت؛ هر فرض باید اعتبارسنجی/تاریخ انقضا داشته باشد.
６１. تعریف «مفروضهٔ منقضیشده» و چگونگی مواجهه با آن را توضیح دهید.
پاسخ: مفروضهای که دیگر صادق نیست (مثلاً نرخ رشد اشتباه پیشبینی شده). باید مجدداً تحلیل، تأثیر آن روی نیازمندیها مشخص و تصمیم اصلاحی (بازنگری طراحی/اضافه/حذف نیازمندی) اتخاذ شود.
６２. چه معیارهای کیفی و کمی برای پذیرش یک نیازمندی (Acceptance Criteria) لازم است؟
پاسخ: معیارهای کمی: اعداد SLO/حداکثر/حداقل؛ کیفی: رفتار سیستم در شرایط خاص، سناریوهای تست قابلتکرار و دادههای آزمون.
６３. نحوه مدیریت تغییر نیازمندی در چرخهٔ زندگی محصول (change control) را شرح دهید.
پاسخ: ثبت درخواست تغییر، تحلیل اثر، ارزیابی ریسک/هزینه، تصمیم CCB، بهروزرسانی ماتریس ردیابی و اطلاعرسانی به ذینفعان؛ تغییرات پس از تصویب اجرا شوند.
６４. چگونه تضمین میکنید که نیازمندیهای قانونی و مقرراتی در محصول رعایت شدهاند؟
پاسخ: شناسایی قوانین مرتبط، افزودن نیازمندیهای الزامآور به SRS، ارزیابی تطابق توسط تیم حقوق/Compliance و پیگیری اثبات رعایت در تستها و مستندسازی.
６５. چه ساختاری برای مستندسازی نیازمندیهای غیرکارکردی پیشنهاد میکنید؟
پاسخ: جدولی که برای هر NFR: شناسه، متن صریح، SLI/SLO، روش تست، مالک و وابستگیها را داشته باشد تا قابل پیگیری و تست شود.
６６. توضیح دهید چگونه از تست معیار پذیرش برای جلوگیری از scope creep استفاده میکنید.
پاسخ: تعریف Acceptance Criteria دقیق برای هر آیتم و امضای ذینفعان؛ هر تغییر باید بر اساس معیارهای قابلسنجش پذیرفته یا رد شود تا محدوده کنترل شود.
６７. چه ابزاری برای مدیریت نیازمندیها در پروژههای بزرگ توصیه میکنید و چرا؟
پاسخ: ابزارهایی مانند JIRA/Confluence برای ردیابی، AD tool برای ADRها، و ابزارهای traceability (ReqIF-compatible) برای نگهداشتن لینک بین نیازمندی، طراحی و تست؛ چون قابلیت گزارشگیری، تاریخچه و همکاری تیمی را دارند.
６８. چگونه نیازمندیهای ناشی از عملیات (Ops-driven) را در backlog وارد میکنید؟
پاسخ: با تبدیل incidentها و الگوهای خطا به user story/technical debt، اولویتبندی بر مبنای ریسک و هزینه و ثبت معیار پذیرش برای اطمینان از حل مشکل.
６９. مفهوم «پذیرش مبتنی بر ریسک» (Risk-based acceptance) را توضیح دهید.
پاسخ: تصمیمگیری درباره پذیرش یا عدم پذیرش یک آیتم براساس سطح ریسک باقیمانده؛ برای ریسکهای کمتر شاید پذیرش سریعتر و برای ریسک بالا نیاز به تست/هاردن بیشتر است.
７０. چگونه نیازمندیهای بینابخشی (cross-cutting concerns) مانند logging یا auth را مدیریت میکنید؟
پاسخ: تعریف نیازمندیهای سطح پایه/پلتفرم که توسط همه سرویسها الزامیاند، تعریف patterns/shared libraries و تضمین رعایت از طریق code review و automated checks.
７１. نحوه مستندسازی و ردیابی فرضیات عملکردی (performance assumptions) را بیان کنید.
پاسخ: ثبت مقادیر فرضشده (TPS، payload sizes)، تعیین تستهای تأیید و بازنگری مرتب فرضها پس از نتایج عملیاتی.
７２. برای یک نیازمندی دادهای که باید backward-compatible باشد، چه نکاتی باید رعایت شود؟
پاسخ: افزودن فیلدهای اختیاری، نسخهگذاری schema، نگهداری mapping برای خواندن دادههای قدیمی، و ارائه راهنمای Deprecation برای مصرفکنندگان.
７３. چگونه نیازمندیهای وابسته به سوم-طرف (third-party) را در برنامه مدیریت میکنید؟
پاسخ: ثبت قراردادها/SLAs، تعریف fallback/timeout، ارزیابی ریسک و درج وابستگیها در ماتریس ردیابی؛ همچنین تستسازی با شبیهساز (mock) تا تاثیر تغییرات ثالث ارزیابی شود.
７４. چطور اثربخشی جلسات جمعآوری نیازمندی را بهبود میدهید؟
پاسخ: استفاده از نمونهوظایف، پرسونا، سناریوها، پروتوتایپهای سریع و آمادهسازی مدرک پیش از جلسه تا ذینفعان بتوانند بازخورد هدفمند دهند.
７５. چه شاخصهایی برای ارزیابی کیفیت نیازمندیها پیشنهاد میکنید؟
پاسخ: درصد نیازمندیهای با Acceptance Criteria، تعداد تغییرات پس از تعریف اولیه، پوشش تست بر اساس نیازمندی، و میانگین زمان حل اختلاف ذینفعان.
بخش D — طراحی نرمافزار، رهگیری کد و تحلیل لاگ (بخشهای مقدماتی) — ۱۰ سؤال
７６. سه اصل لاگنویسی قابلمصرف برای عملیات را نام ببرید.
پاسخ: ساختیافته بودن (JSON)، درج Correlation/Request Ids، و سطوح لاگ منطقی؛ این امر جستوجو، فیلتر و تحلیل خودکار را ممکن میسازد.
７７. Correlation ID چیست و چگونه به تحلیلگر کمک میکند؟
پاسخ: یک شناسه یکتا که یک درخواست را در سراسر سرویسها دنبال میکند؛ امکان ردیابی مسیر کامل پردازش و تحلیل تأخیر یا خطا را فراهم میکند.
７８. چه اطلاعاتی نباید در لاگها ثبت شود؟
پاسخ: اطلاعات حساس/شخصی (مانند PAN کارت، رمز عبور) مگر اینکه ماسک/رمزنگاری شده باشند؛ همچنین لاگ بیشازحد (noise) که کارایی جستوجو را کاهش میدهد.
７９. نحوهٔ تحلیل یک spike در نرخ خطا با استفاده از لاگ را شرح دهید.
پاسخ: فیلتر لاگها بر اساس بازه زمانی spike و correlation-id، دستهبندی بر اساس نوع خطا و origin instance، بررسی تغییرات اخیر در کد/پیکربندی و cross-check با metrics و tracing.
８０. چه معیارهایی برای خوانش سریع کد توسط یک تحلیلگر پیشنهاد میکنید؟
پاسخ: استاندارد نامگذاری، مستندسازی توابع مهم، README ماژولها، و نمودارهای سطح بالا (sequence/flow) تا تحلیلگر مسیرها و وابستگیها را سریع درک کند.
８１. چگونه log sampling را طوری اعمال میکنید که اطلاعات کافی برای دیباگ داشته باشید ولی هزینه ذخیره کاهش یابد؟
پاسخ: نمونهبرداری مبتنی بر نرخ عادی و نمونهبرداری کامل در شرایط خطا (error-trace sampling)، و ذخیرهسازی کامل برای نمونههای هشدارزده.
８２. ابزار یا رویکردی برای پیدا کردن memory leak در کد سرویس توصیف کنید.
پاسخ: مانیتورینگ heap usage و GC metrics، پروفایلینگ در محیط staging، و بررسی الگوهای افزایش مصرف با timeline تا مکان نشت شناسایی شود.
８３. چه زمانی باید از structured logging استفاده کنید؟
پاسخ: همیشه؛ مخصوصاً در محیط توزیعشده که پردازش خودکار، جستوجو و مانیتورینگ لازم است. ساختاردهی به تحلیل و correlation کمک میکند.
８４. چگونه لاگها را برای تحلیل امنیتی آماده میکنید؟
پاسخ: ثبت رخدادهای auth/authorization، تغییرات حساس، تلاشهای ناموفق، نگهداری لاگ امن با retention policy، و امکان ارسال به SIEM برای تحلیل تهدید.
８５. چه نقشی برای feature flags در فرآیند تست و انتشار قائلید؟
پاسخ: امکان فعال/غیرفعالسازی فیچر بهصورت runtime، کنترل انتشار مرحلهای، اجرای A/B و rollback سریع بدون deploy؛ ابزارهای مدیریت flag ضروریاند.
８６. چگونه یک خطا را که فقط در محیط تولید ظاهر میشود، debug میکنید؟
پاسخ: جمعآوری context با correlation Ids، فعالسازی tracing/extra logging برای مسیر مورد نظر، استفاده از replay یا shadow traffic و مقایسه با رفتار محیط staging.
８７. مفهوم tracing sampling و trade-off آن را توضیح دهید.
پاسخ: بهجای ارسال همهٔ تراسها، نمونهبرداری میکنیم تا هزینه ارسال و ذخیره کاهش یابد. trade-off بین پوشش کامل و هزینه/پرفورمنس است؛ لازم است قوانین نمونهبرداری هوشمند (مثلاً نمونهبرداری کامل برای خطاها) تعیین شود.
８８. چگونه لاگها را بهنحو GDPR-compliant نگه میدارید؟
پاسخ: حذف/ماسک دادههای PII، تعریف retention policy کوتاهمدت، ایجاد مکانیزم حذف لاگ on-request، و رمزنگاری لاگ در حالت سکون و انتقال.
８９. چه اطلاعاتی را در یک incident postmortem باید ثبت کنید؟
پاسخ: شرح حادثه، timeline، root cause، اقدامات اصلاحی و پیشگیری، اثر بر مشتری و lessons learned؛ همراه با owner مسئول اجرای اقدامات اصلاحی.
９０. چگونه تحلیل لاگ میتواند به بهبود NFRها کمک کند؟
پاسخ: استخراج الگوهای عملکردی و خطا که منجر به تنظیم SLO/SLA منطقیتر، بهینهسازی پیکربندی، و شناسایی نقاط بار/گلوگاه میشود.
بخش E — مبانی ضروری مالک محصول (Handbook) — ۱۰ سؤال
９１. تفاوت Outcome و Output در بکلاگ چیست و چرا مهم است؟
پاسخ: Output محصول نهایی (feature deliverable) است؛ Outcome تغییر رفتار یا ارزش حاصل برای کاربر/کسبوکار است. تمرکز بر Outcome از اتلاف منابع جلوگیری و تصمیمگیری ارزشمحور را ممکن میسازد.
９２. Definition of Done (DoD) چیست و چه عناصری باید داشته باشد؟
پاسخ: معیارهای لازم برای اعلان اتمام یک آیتم: کد مرجشده، تستهای خودکار/دستی گذرانده، مستندسازی، بررسی امنیت و روشن بودن معیارهای NFR مرتبط.
９３. چگونه اولویتبندی backlog را با استفاده از معیار ارزش و ریسک انجام میدهید؟
پاسخ: محاسبه ارزش کسبوکار، هزینهٔ تاخیر، و ریسک؛ استفاده از WSJF یا ماتریس ارزش/ریسک برای تصمیمگیری و همراستا کردن تیم با اهداف استراتژیک.
９４. چه KPIهایی برای سنجش موفقیت یک فیچر پیشنهاد میکنید؟
پاسخ: نرخ استفاده، نرخ نگهداری (retention)، conversion مرتبط با فیچر، Net Promoter Score (NPS) تغییر یافته و معیارهای عملکرد (latency/uptime) در صورت حساس بودن.
９５. نقش MVP در فرآیند توسعه محصول چیست؟
پاسخ: کمینه محصول پذیرفتنی برای اعتبارسنجی فرضیات بازار با کمترین هزینه؛ هدف کاهش ریسک با جمعآوری بازخورد واقعی و تنظیم مسیر توسعه است.
９６. چگونه باید ذینفعان را در چرخهٔ تعریف نیازمندی درگیر کنید؟
پاسخ: جلسات مصاحبه/ورکشاپ هدفمند، نمایش پروتوتایپ، شفافسازی معیارهای موفقیت و بهروزرسانی منظم با شواهد دادهای برای تصمیمگیری.
９７. چه تکنیکی برای کشف نیازهای پنهان کاربران پیشنهاد میکنید؟
پاسخ: مشاهده کاربر در محیط واقعی، مصاحبه با سناریو، تحلیل رفتار (analytics) و تست قابلاستفادهپذیری با پروتوتایپ.
９８. چگونه برآورد ریسک بازار برای یک تغییر محصول را انجام میدهید؟
پاسخ: تحلیل رقبا، بررسی فرضیات محصول، مصاحبه با مشتریان هدف، و طراحی آزمایشات کوچک برای اعتبارسنجی فرضها (Smoke tests / Pilot).
９９. نقش Product Owner در هماهنگی NFRها و backlog چیست؟
پاسخ: تعیین اولویت NFRها در backlog، تضمین اینکه Definition of Done شامل NFRها است، و تأیید وابستگیها بین فیچرها و نیازهای غیرکاری؛ PO باید تضمین کند ارزش با کیفیت مطلوب تحویل میشود.
１００. چه فرآیندی برای همراستاسازی roadmap فنی و محصولی پیشنهاد میکنید؟
پاسخ: جلسات مشترک بین معماری و PO، تعیین epics مشترک با معیارهای ارزش و NFR مشخص، انعطافپذیری در زمانبندی براساس بودجه خطا و نتایج آزمایشها، و بازنگریهای منظم roadmap بر پایه داده.
