# قبل از سفارش نرم‌افزار اختصاصی چه اطلاعاتی آماده کنیم؟

Canonical: https://geek-web.ir/custom-software-requirements-brief/
Last modified: 2026-10-07T10:09:37+00:00

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

## Related questions