برای سفارش نرم‌افزار اختصاصی، ابتدا مسئله کسب‌وکار، کاربران، مراحل کار و نتیجه‌ای را که از سیستم انتظار دارید بنویسید. سپس امکانات ضروری، اطلاعات ورودی، گزارش‌ها و شرایط تحویل را مشخص کنید. شرح نیازمندی نرم‌افزار کمک می‌کند شرکت توسعه‌دهنده بداند چه چیزی باید برآورد و ساخته شود و شما هنگام تحویل چه چیزی را بررسی کنید.
جمله «یک سامانه برای مدیریت شرکت می‌خواهیم» می‌تواند به یک فرم ثبت درخواست یا محصولی با چند شعبه، سطح دسترسی و اتصال به حسابداری اشاره کند. یک شرح روشن، این تفاوت را پیش از پیشنهاد قیمت مشخص می‌کند. برای شروع، می‌توانید از همان فرم‌ها، فایل‌های اکسل و مراحل کاری استفاده کنید که کارکنان امروز با آن‌ها سروکار دارند.
۱. مشکل فعلی و نتیجه مورد انتظار را بنویسید
به‌جای «سامانه جامع و هوشمند»، یک مشکل قابل مشاهده را توصیف کنید؛ مثلاً درخواست‌های مشتریان در پیام‌رسان ثبت می‌شوند، بعضی از آن‌ها مسئول مشخصی ندارند و مدیر نمی‌تواند موارد در انتظار رسیدگی را ببیند.
بعد نتیجه مطلوب را بنویسید: هر درخواست شناسه داشته باشد، مسئول آن معلوم باشد و مدیر فهرست درخواست‌های باز را مشاهده کند. اگر هدف عددی دارید، وضعیت فعلی را اندازه بگیرید و مبنای سنجش را ثبت کنید. عبارت «کاهش زمان رسیدگی» بدون مشخص‌کردن شروع و پایان این زمان، برای ارزیابی نتیجه کافی نیست.
نظر کسی را بپرسید که کار را انجام می‌دهد؛ ممکن است بخشی از فرایند خارج از نرم‌افزار و با تماس تلفنی انجام شود. راهنمای شناخت کاربران در مرحله کشف GOV.UK نیز بر بررسی روش فعلی انجام کار و مشکلات کاربران پیش از طراحی تأکید دارد.
۲. نقش کاربران و حدود دسترسی را جدا کنید
برای هر نقش، مشخص کنید چه اطلاعاتی را می‌بیند و چه چیزی را می‌تواند تغییر دهد. نام افراد را به‌جای نقش ننویسید؛ ممکن است کارشناس جابه‌جا شود، اما حدود اختیار کارشناس در سیستم باقی می‌ماند.
- مشتری درخواست خود را ثبت کند و وضعیت همان درخواست را ببیند.
- کارشناس به درخواست‌های ارجاع‌شده به خودش پاسخ دهد.
- سرپرست درخواست‌ها را بین کارشناسان توزیع و گزارش تیم را مشاهده کند.
- مدیر سیستم کاربران و دسترسی‌ها را مدیریت کند.
اگر مجموعه چند شعبه دارد، روشن کنید کارشناس یک شعبه به اطلاعات شعبه دیگر دسترسی دارد یا خیر. درباره جانشین فرد غایب، غیرفعال‌شدن حساب و دسترسی کارکنان پشتیبانی هم تصمیم بگیرید. این موارد را با حساب‌های کاربری جداگانه هنگام تحویل آزمایش کنید.
۳. گردش کار را همراه با حالت‌های استثنا شرح دهید
یک فرایند پرتکرار را انتخاب کنید و مراحل آن را به ترتیب بنویسید: ثبت درخواست، بررسی اولیه، ارجاع، رسیدگی و بستن پرونده. برای هر مرحله، مسئول انجام کار، اطلاعات لازم و شرط رفتن به مرحله بعد را مشخص کنید.
مسیر عادی را با چند حالت واقعی تکمیل کنید: اطلاعات ناقص باشد، مشتری درخواست را لغو کند، کارشناس در دسترس نباشد یا پرونده پس از بسته‌شدن دوباره نیاز به رسیدگی داشته باشد. تعیین تکلیف این موارد، از برداشت متفاوت تیم‌ها درباره رفتار سامانه جلوگیری می‌کند.
نیاز کاربر را می‌توان در یک جمله نوشت: «به‌عنوان سرپرست، می‌خواهم درخواست‌های بدون مسئول را ببینم تا آن‌ها را بین کارشناسان تقسیم کنم.» در این جمله، نقش، کار موردنیاز و دلیل آن روشن است؛ همان اجزایی که در راهنمای نوشتن داستان کاربر GOV.UK توضیح داده شده‌اند.
۴. فرم‌ها، داده‌های قبلی و گزارش‌ها را مشخص کنید
از فرم فعلی یا یک فایل نمونه شروع کنید. برای ثبت درخواست، ممکن است موضوع، شرح، شماره تماس و فایل پیوست لازم باشد. مشخص کنید کدام فیلد اجباری است، چه کسی آن را تغییر می‌دهد و برای اطلاعات تکراری یا ناقص چه اتفاقی می‌افتد.
اگر داده‌های قبلی باید منتقل شوند، تعداد تقریبی رکوردها، نوع فایل‌ها و مشکلات شناخته‌شده را بنویسید؛ مانند مشتری تکراری، تاریخ نامعتبر یا فایل پیوست گم‌شده. برای بررسی اولیه، یک نمونه با حذف مشخصات شخصی و اطلاعات محرمانه آماده کنید.
گزارش را هم با کاربردش توصیف کنید. به‌جای «داشبورد کامل»، بنویسید مدیر درخواست‌های باز هر کارشناس را با فیلتر شعبه و بازه تاریخ ببیند و خروجی اکسل بگیرد. روشن کنید درخواست لغوشده در آمار محاسبه می‌شود یا نه و مبنای تاریخ، زمان ثبت است یا زمان رسیدگی.
۵. اتصال‌ها و شرایط استفاده از سامانه را ثبت کنید
نام سامانه‌های مرتبط، مانند حسابداری، سایت، پیامک یا درگاه پرداخت را بنویسید. اگر رابط برنامه‌نویسی یا API دارند، مستندات و مسئول هماهنگی را معرفی کنید. موارد نامعلوم را «نیازمند بررسی» علامت بزنید؛ امکان اتصال باید پیش از برآورد قطعی تأیید شود.
شرایط استفاده را هم توضیح دهید: کاربران با گوشی کار می‌کنند یا رایانه؟ چند نفر هم‌زمان وارد می‌شوند؟ حجم اطلاعات چقدر است و قطعی اینترنت چه اثری بر کار دارد؟ برای سرعت، حجم فایل و بازیابی اطلاعات، عدد هدف و روش اندازه‌گیری باید با تیم فنی توافق شود.
ورود کاربران، ثبت سوابق تغییرات، پشتیبان‌گیری و بازیابی را در شرح نیاز بیاورید. مشخص کنید چه کسی مسئول نگهداری است و هنگام بروز مشکل از چه مسیری پیگیری می‌کنید. لازم نیست در این مرحله فناوری خاصی انتخاب کنید؛ محدودیت‌های عملیاتی و سامانه‌های فعلی را توضیح دهید.
۶. محدوده نسخه اول و موارد خارج از آن را روشن کنید
امکاناتی را که برای شروع کار ضروری‌اند از توسعه‌های بعدی جدا کنید. در مثال ثبت درخواست، ممکن است ثبت، ارجاع و نمایش وضعیت برای نسخه اول کافی باشد و اپلیکیشن مستقل یا گزارش‌های تحلیلی به مرحله بعد برود.
موارد خارج از نسخه اول را هم بنویسید تا نبود آن‌ها هنگام تحویل غافلگیرکننده نباشد. برای تصمیم‌گیری، بپرسید بدون هر قابلیت کدام کار اصلی متوقف می‌شود و آیا راه موقت قابل‌قبولی وجود دارد.
زمان مطلوب، دلیل این زمان و بودجه تقریبی را اعلام کنید. پیشنهاد زمان‌بندی باید به همین محدوده وصل باشد؛ جزئیات بیشتر را در مقاله زمان ساخت نرم‌افزار اختصاصی بخوانید. تغییر محدوده بعد از شروع نیز باید همراه با اثر آن بر هزینه و زمان بررسی شود.
نمونه خلاصه شرح نیازمندی نرم‌افزار
فرض کنید یک شرکت خدماتی می‌خواهد ثبت و پیگیری درخواست‌ها را از پیام‌رسان به سامانه منتقل کند. جدول زیر نمونه‌ای از اطلاعات شروع بررسی است؛ پاسخ هر ردیف را با وضعیت کسب‌وکار خود جایگزین کنید.
| بخش | چه چیزی بنویسید؟ | نمونه شرکت خدماتی |
|---|---|---|
| مسئله | مشکل قابل مشاهده در روش فعلی | بعضی درخواست‌ها بدون مسئول باقی می‌مانند. |
| کاربران | نقش‌ها و محدوده اطلاعات هر نقش | مشتری، کارشناس و سرپرست؛ مشتری فقط پرونده خود را ببیند. |
| گردش کار | مراحل، مسئول هر مرحله و استثناها | ثبت، بررسی اولیه، ارجاع و رسیدگی؛ اطلاعات ناقص برای تکمیل برگردد. |
| داده و گزارش | اطلاعات ثبت‌شونده و خروجی موردنیاز | موضوع، شرح و پیوست؛ گزارش درخواست‌های باز به تفکیک کارشناس. |
| اتصال‌ها | سامانه مقابل و وضعیت بررسی ارتباط | اعلان پیامکی؛ هزینه و روش اتصال نیازمند بررسی است. |
| نسخه اول | امکانات ضروری و موارد قابل تعویق | ثبت و پیگیری تحت وب؛ اپلیکیشن مستقل در نسخه اول نیست. |
| پذیرش | رفتاری که در جلسه تحویل آزمایش می‌شود | درخواست کامل کد یکتا بگیرد و در فهرست سرپرست ظاهر شود. |
۷. برای هر قابلیت، معیار پذیرش قابل آزمون بنویسید
معیار پذیرش می‌گوید در چه شرایطی، چه نتیجه‌ای را برای تأیید آن قابلیت بررسی می‌کنید. برای «ثبت درخواست مشتری»، ابتدا یک حساب مجاز و داده آزمایشی آماده کنید؛ سپس این حالت‌ها را اجرا کنید:
- فرم کامل ارسال شود؛ یک شناسه یکتا ایجاد شود و درخواست در پنل مشتری و فهرست سرپرست دیده شود.
- موضوع اجباری خالی باشد؛ فرم ثبت نشود و دلیل خطا کنار همان ورودی نمایش داده شود.
- مشتری دیگری وارد شود؛ نتواند جزئیات یا پیوست درخواست اول را مشاهده کند.
- سرپرست درخواست را ارجاع دهد؛ کارشناس مجاز آن را ببیند و زمان و عامل تغییر در سابقه ثبت شود.
تفاوت این معیارها با عبارت «فرم درست کار کند» در نتیجه قابل بررسی آن‌هاست. ثبت موفق، ورودی نامعتبر و دسترسی غیرمجاز جدا آزمایش می‌شوند. برای گزارش‌ها، اتصال‌ها و بازیابی نسخه پشتیبان هم معیار متناسب با همان کار تعریف کنید.
چه چیزهایی را همراه شرح نیازمندی ارسال کنید؟
- نام و نسخه سند و فردی که پاسخ پرسش‌ها و تأیید تغییرات را بر عهده دارد؛
- نمونه فرم، گزارش و فایل داده با حذف اطلاعات محرمانه؛
- یک گردش کار عادی همراه با حالت‌های نقص، لغو یا بازگشت؛
- فهرست امکانات ضروری، موارد خارج از نسخه اول و پرسش‌های باز؛
- سامانه‌های متصل، محدودیت‌های استفاده و معیارهای پذیرش اولیه؛
- انتظار از آموزش، مستندات، نگهداری و دسترسی به داده‌ها پس از تحویل.
از همه شرکت‌ها بخواهید پیشنهادشان را بر اساس یک نسخه از همین شرح بدهند و فرض‌ها و موارد مستثنا را مشخص کنند. اگر تغییر تازه‌ای مطرح شد، آن را در نسخه بعدی ثبت کنید تا مبنای مقایسه پیشنهادها یکسان بماند.
این بررسی ممکن است نشان دهد یک محصول آماده یا سفارشی‌سازی، نیاز شما را پوشش می‌دهد. برای مقایسه گزینه‌ها، مقاله نرم‌افزار آماده یا اختصاصی؟ را ببینید. اگر دامنه هنوز روشن نیست، نمونه فرایند و فایل‌های فعلی را برای مشاوره و تحلیل نیاز نرم‌افزاری داپا آماده کنید؛ مسیر اجرا نیز در صفحه توسعه نرم‌افزار اختصاصی آمده است.
پرسش‌های متداول
برای نوشتن شرح نیازمندی باید برنامه‌نویسی بدانیم؟
شناخت کار روزمره و کاربران برای شروع مهم‌تر است. مسئله، نمونه داده و نتیجه مورد انتظار را توضیح دهید؛ انتخاب معماری و فناوری در بررسی فنی انجام می‌شود.
شرح نیازمندی نرم‌افزار چند صفحه باشد؟
تعداد صفحه معیار مناسبی نیست. سند اولیه باید نقش‌ها، جریان کار، محدوده نسخه اول و چند نمونه قابل آزمون را روشن کند. پیچیدگی فرایند تعیین می‌کند چه جزئیاتی باید اضافه شود.
اگر بخشی از نیازها هنوز مشخص نیست چه کنیم؟
آن را در فهرست پرسش‌های باز بنویسید و مسئول بررسی را تعیین کنید. برای ابهام‌های مهم، مانند امکان اتصال به یک سامانه، پیش از قیمت و زمان قطعی بررسی جداگانه لازم است.
آیا می‌توان بعد از شروع پروژه نیازها را تغییر داد؟
تغییر قابل بررسی است، اما باید ثبت و تأیید شود. تأثیر آن بر قابلیت‌های قبلی، معیارهای پذیرش، هزینه و زمان را پیش از اجرای تغییر مشخص کنید.
