انجمن علمی برنامه‌نویسی
🚀از کدنویس تا مهندس نرم‌افزار
⚠️نیازمندی مبهم = پروژه شکست‌خورده
بیشتر پروژه‌ها در مرحله طراحی خراب نمی‌شوند؛
در مرحله «تعریف نیازمندی» خراب می‌شوند.
اگر مسئله دقیق تعریف نشود،
هیچ طراحی و هیچ کدی آن را نجات نمی‌دهد.
🔹سه خطای مرگبار در نیازمندی‌ها:
1️⃣ابهام
❌«سیستم باید سریع باشد.»
سریع یعنی چه؟
✅«زمان پاسخ کمتر از ۲ ثانیه برای ۹۵٪ درخواست‌ها.»
◀️نیازمندی باید قابل اندازه‌گیری باشد.
2️⃣فرضیات پنهان
❌«کاربران همیشه اینترنت پایدار دارند.»
❌«تعداد کاربران زیاد نخواهد شد.»
◀️هر فرضی که نوشته نشود، بعداً تبدیل به باگ یا بحران می‌شود.
🔤تغییرات کنترل‌نشده
هر هفته یک قابلیت جدید بدون بازتعریف دامنه و زمان‌بندی
◀️این همان مسیری است که پروژه را فرسایشی می‌کند.
نگاه مهندسی
❌کدنویس می‌پرسد: «چی بسازم؟»
✅مهندس می‌پرسد: «دقیقاً چه چیزی تعریف شده و چگونه موفقیت آن سنجیده می‌شود؟»
💡یک تکنیک عملی:
🔹هر نیازمندی را با این سه سؤال تست کنید:
🔹قابل اندازه‌گیری است؟
🔹قابل تست است؟
🔹بدون ابهام است؟
اگر یکی از این سه جوابش «نه» باشد،
هنوز نیازمندی مهندسی نشده است.
📝تمرین
یکی از پروژه‌های اخیر خود را بردارید.
سه نیازمندی آن را بازنویسی کنید به شکلی که کاملاً قابل اندازه‌گیری باشد.
اگر نتوانستید، مشکل در کدنویسی نیست؛
مشکل در تحلیل است.
📚منبع: کتاب Beginning To Software Engineering
👨💻در کانال انجمن علمی برنامه‌نویسی با ما همراه باشید…
| @Programming_Association |
22 · 2.3K ·