شرح نیازمندی نرم‌افزار قابل‌تخمین: الگو و چک‌لیست

«برآورد دقیق بدهید» وقتی ممکن است که چیزی دقیق تعریف شده باشد. این مقاله ساختاری برای شرح نیازمندی می‌دهد که تیم فنی بتواند روی آن سؤال بپرسد و برآورد کند. هیچ استاندارد واحدی را تقلید نمی‌کند؛ الگو توصیهٔ نویسنده است و فقط ادعاهای مربوط به برآورد و داستان‌ها از منابع نقل شده‌اند.

چرا تعریف مبهم، برآورد مبهم می‌دهد؟

Steve McConnell در توضیح «مخروط عدم‌قطعیت» می‌نویسد دقت برآورد به میزان پالایش تعریف نرم‌افزار بستگی دارد: هر چه تعریف دقیق‌تر، برآورد دقیق‌تر. او می‌گوید تغییرپذیری برآورد از تغییرپذیری خود پروژه می‌آید و تنها راه کم‌کردنش کم‌کردن همان تغییرپذیری است. یعنی یک هفتهٔ بیشتر وقت دادن به تیم برآوردکننده، بدون روشن‌تر شدن تعریف، دقت را بالا نمی‌برد. برای مرحلهٔ پیش از نوشتن نیازمندی‌ها هم برنامه‌ریزی پروژهٔ نرم‌افزاری پیش از نوشتن کد مفید است.

الگوی هفت‌بخشی (توصیهٔ نویسنده)

1. مسئله و هدف: چه چیزی امروز خوب کار نمی‌کند و موفقیت را چگونه می‌فهمیم؟
2. کاربران و نقش‌ها: چه کسانی، با چه سطح دسترسی؟
3. جریان‌های اصلی: هر جریان از شروع تا پایان، شامل مسیرهای خطای مهم.
4. محدودیت‌ها: سیستم‌های بیرونی، قوانین، مهلت، فناوری‌های الزامی.
5. معیار پذیرش: برای هر جریان اصلی چند سناریوی قابل‌آزمون.
6. خارج از محدوده: چیزهایی که صریحاً قرار نیست ساخته شوند.
7. سؤال‌های باز: ندانسته‌ها، با مسئول و موعد پاسخ.

مثال فرضی: ثبت درخواست مرخصی

مثال زیر کاملاً فرضی است و فقط ساختار را نشان می‌دهد.

• مسئله: درخواست‌ها از طریق پیام‌رسان جمع می‌شود و پیگیری وضعیت سخت است.
• کاربران: کارمند، مدیر مستقیم، مسئول منابع انسانی.
• جریان: کارمند درخواست می‌دهد؛ مدیر تأیید یا رد می‌کند؛ منابع انسانی وضعیت را ثبت می‌کند.
• محدودیت: فهرست کارمندان از سامانهٔ موجود منابع انسانی خوانده شود.
• پذیرش (Given-When-Then، طبق توضیح Fowler): با فرض اینکه کارمند وارد شده و مدیر مستقیم دارد، وقتی درخواست را ثبت کند، آنگاه مدیر مستقیم او آن را در فهرست «در انتظار» ببیند.
• خارج از محدوده: محاسبهٔ حقوق، سامانهٔ حضور و غیاب.
• سؤال باز: اگر مدیر در دسترس نباشد، تأییدکنندهٔ جانشین کیست؟ (مسئول: منابع انسانی)

چک‌لیست قابل‌تخمین‌بودن

Bill Wake در توضیح مخفف INVEST می‌گوید داستان خوب باید «قابل‌تخمین» باشد: لازم نیست برآورد دقیق باشد، ولی قابل‌برآوردبودن به مذاکره‌شدن داستان، اندازهٔ آن و تجربهٔ تیم بستگی دارد، و گاهی باید بخشی را به یک spike زمان‌محدود برای کسب اطلاعات جدا کرد. او همچنین می‌گوید داستان خوب «قابل‌مذاکره» است، یعنی قرارداد صریح برای ویژگی‌ها نیست و جزئیات در حین کار شکل می‌گیرد، و «کوچک» است (معمولاً حداکثر چند نفر-هفته کار). این‌ها دیدگاه‌هایی از دنیای چابک‌اند؛ برای قرارداد ثابت‌قیمت باید جزئیات بیشتری مکتوب شود. Scrum Guide هم می‌گوید آیتم‌هایی که در یک اسپرینت Done می‌شوند برای انتخاب آماده‌اند و معمولاً بعد از refinement، یعنی شکستن به آیتم‌های کوچک‌تر و دقیق‌تر با توضیح، ترتیب و اندازه، به این حالت می‌رسند. اندازه‌دادن با کسانی است که کار را انجام می‌دهند.

• هر جریان به قطعه‌هایی شکسته شده که هر کدام قابل‌نمایش به کاربر است.
• هر قطعه دست‌کم یک معیار پذیرش دارد.
• ورودی‌های ناشناخته با spike یا سؤال باز مشخص شده‌اند، نه حدس.
• برای نوشتن داستان‌ها از قالب مناسب استفاده شده؛ برای آن User Story چیست؟ را ببینید.

سؤال‌های باز را پنهان نکنید

بخش «سؤال‌های باز» به برآورد صادق‌تر کمک می‌کند: هر ندانسته یا پاسخ می‌خواهد یا در برآورد به‌صورت بازه و فرض ثبت می‌شود. اگر برآورد اولیه می‌خواهید، برآوردگر پروژه نقطهٔ شروع است، نه قول قطعی.

اشتباه‌های رایج

• فهرست ویژگی‌ها بدون هدف و بدون معیار پذیرش.
• نوشتن راه‌حل فنی به‌جای مسئله، که فضای طراحی را می‌بندد.
• نبود بخش «خارج از محدوده»؛ هر طرف چیز دیگری فرض می‌کند.
• اینکه ندانسته‌ها «بعداً مشخص می‌شود» و در قیمت نمی‌آید.

اگر می‌خواهید پیش‌نویس شرح نیازمندی خودتان را با یک تیم بررسی کنید، می‌توانید آن را در صفحهٔ شروع پروژه توضیح دهید؛ ارسال فرم تعهدی ایجاد نمی‌کند.

منابع و مراجع

• Software Development's Cone of Uncertainty — Steve McConnell، Construx Software، White Paper، Version 1، January 2010.
• INVEST in Good Stories, and SMART Tasks — Bill Wake (XP123).
• The Scrum Guide — Ken Schwaber و Jeff Sutherland، نسخهٔ نوامبر ۲۰۲۰.
• Given When Then — Martin Fowler، ۲۱ اوت ۲۰۱۳.