راهنمای نگارش RFP وب سایت و اپلیکیشن

گروه های کاربری

کاربران پروژه های نرم افزاری بر اساس نقشی که در سامانه دارند در گروه های مختلف تقسیم بندی می شوند. به طور مثال سامانه تاکسی اینترنتی حداقل به سه گروه کاربری نیاز دارد که شامل 1) تیم مدیریتی، 2) رانندگان و 3) مسافران هستند.

تعداد گروه های کاربری در بودجه و زمان مورد نیاز توسعه نرم افزارهای سفارشی موثر است. به همین جهت لازم است گروه های کاربری مورد نیاز پروژه ی خود را دقیقا شناسایی کنید. اما باید از کجا شروع کنید؟

اگر در حال سفارش اولین پروژه ی نرم افزاری خود باشید شاید شناسایی گروه های کاربری خیلی کار ساده ای نباشد اما نگران نباشید؛ گروه ویرانیک با این مقاله همراه شماست تا با یک مثال ساده گروه های کاربری پروژه تان را شناسایی کنید.

برگردیم به مثال تاکسی اینترنتی؛ با هر سطح از دانش کارفرما قطعا به آنچه که می خواهد در نرم افزارش انجام شود مسلط است. یک کاغذ و قلم بردارید و هر آنچه که باید در نرم افزاری سفارشی شما انجام شود را به زبان ساده بنویسید. برای نمونه، برخی از وظایفی که باید در سامانه تاکسی اینترنتی انجام شوند عبارتند از:

1. ثبت درخواست خودرو
2. پرداخت آنلاین هزینه سفر
3. لغو سفر
4. قبول سفر
5. گزارش رسیدن به مقصد
6. ثبت درخواست تسویه
7. تایید مدارک رانندگان
8. رسیدگی به شکایت های مسافران
9. رسیدگی به درخواست های تسویه ی رانندگان

حالا از خودتون بپرسید چه کسی می تواند کارهای فوق را انجام دهد؟ به طور مثال چه کسی هزینه سفر را باید پرداخت کند؟ پاسخ: مسافران
بنابراین مسافران یکی از گروه های کاربری سامانه تاکسی اینترنتی هستند که قادر به ثبت درخواست خودرو، پرداخت آنلاین هزینه سفر و لغو سفر می باشند. در مقابل مسافران نمی توانند یک سفر را قبول کنند یا به درخواست های تسویه ی رانندگان رسیدگی کنند.

بریم سراغ گروه های کاربری دیگه چون مسافران قادر به انجام کارهای شماره 4 تا 9 نیستند و سامانه به گروه های کاربری دیگر نیاز دارد. چه کسی می تواند یک سفر را قبول کند؟ پاسخ: رانندگانی که پیشتر در سامانه ثبت نام کرده اند.

به همین سادگی دومین گروه کاربری سامانه یعنی رانندگان هم شناسایی کردیم. گروه اول (مسافران) درخواست خودرو را برای سفر خود ثبت می کنند و گروه دوم (رانندگان) سفرهای اطراف را بررسی کرده و در صورت تمایل قبول می کنند.

آیا به گروه کاربری دیگری نیاز است؟ پاسخ: بله. می پرسید چرا؟ چون به یک گروه کاربری دیگر نیاز است که مدارک رانندگان را بررسی و تایید کند. همچنین رسیدگی به شکایت های مسافران و رسیدگی به درخواستهای تسویه ی رانندگان هم توسط گروه های کاربری مسافران و رانندگان قابل انجام نیست.

بنابراین یک گروه کاربری دیگر به نام تیم مدیریتی تعریف می کنیم که در بالاترین سطح سامانه را راهبری نمایند. با اینکه گروه کاربری تیم مدیریتی در بالاترین سطح است اما قادر به ایفای نقش و انجام وظایف سایر گروه های کاربری نیست. به طور مثال، تیم مدیریتی نمی توانند درخواست تسویه ثبت کنند یا یک خودرو برای سفر درخواست کنند.

حالا می تونیم بگیم تمامی گروه های کاربری سامانه را شناسایی کردیم چون تمامی امور و وظایفی که باید در نرم افزار انجام بشه رو به یک گروه کاربری اختصاص دادیم تا ایفای نقش کنند.

خروجی: نام گروه های کاربری شناسایی شده را به عنوان خروجی این بخش یادداشت کنید و با گروه ویرانیک همراه باشید تا به سراغ مرحله بعدی تهیه شرح خدمات بریم.

فعالیت ها

فعالیت ها مجموعه اموری هستند که باید در یک نرم افزار قابل انجام باشند. به طور مثال فعالیت تایید مدارک رانندگان یا فعالیت پرداخت آنلاین هزینه سفر در سامانه تاکسی اینترنتی؛ این بخش به ازای هر یک از فعالیت های سامانه به دنبال پاسخ سوالات زیر است:

• چه پیش شرط هایی برای انجام فعالیت باید رعایت شوند؟
• سناریوی انجام فعالیت چیست؟
• فعالیت چگونه و طی چه مراحلی قابل انجام هستند؟
• برای انجام فعالیت چه فرم هایی باید تکمیل شوند؟ فرم ها چه اطلاعاتی را از کاربران دریافت می کنند؟
• آیا فعالیت دارای محرک است و نیاز است به دنبال فعالیتی دیگر به صورت خودکار اجرا شود؟

خروجی: پیش از مطالعه ی ادامه ی این بخش لطفا لیست کاملی از فعالیت های نرم افزار سفارشی خود تهیه کنید و سپس تا تکمیل اطلاعات مورد نیاز هر فعالیت با گروه ویرانیک همراه باشید.

پیش شرط های لازم

پیش شرط ها مجموعه نکاتی هستند که باید پیش از انجام هر فعالیت لحاظ شوند. پیش شرط ها دو نوع هستند: 1) مجوز دسترسی و 2) شروط منطقی؛ در ادامه به شرح انواع پیش شرط ها می پردازیم.

مجوز دسترسی

آیا کاربر اجازه ی انجام فعالیتی که درخواست کرده را دارد؟ پیش شرط مجوز دسترسی یافتن پاسخ این سوال را دنبال می کند و در صورتی که پاسخ منفی باشد دسترسی کاربر به فعالیت درخواست شده را مسدود خواهد کرد. بنابراین مجوز دسترسی امنیت پروژه را در لایه ی نرم افزار تحت تاثیر قرار می دهد و بسیار حائز اهمیت است که در تهیه ی آن دقت لازم را به خرج دهید.

فعالیت لغو سفر در سامانه تاکسی اینترنتی را در نظر بگیرید. کدام گروه کاربری مجاز به لغو سفارش است؟ در بخش گروه های کاربری گفتیم تنها مسافران قادر به لغو سفر هستند اما مطابق با طرح تجاری شما می توان مجوز لغو سفارش را به رانندگان و حتی تیم مدیریتی اعطا نمود.

به طور مثال، آیا در طرح تجاری شما رانندگان پس از قبول سفر می توانند منصرف شده و سفر را لغو کنند؟ اگر پاسخ مثبت است باید مجوز دسترسی به فعالیت لغو سفر به گروه کاربری رانندگان هم اعطا شود تا رانندگان بتوانند در صورت منصرف شدن از قبول سفر آن را لغو کنند.

در مثالی دیگر، آیا طرح تجاری شما به مسافران خدمات لغو سفر تلفنی را از طریق تماس با تیم مدیریتی ارائه می کند؟ اگر پاسخ مثبت است باید مجوز دسترسی به فعالیت لغو سفر به گروه کاربری تیم مدیریتی هم اعطا شود تا در صورت درخواست تلفنی لغو سفر بتوانند این فعالیت را در سامانه انجام دهند.

خروجی: لطفا یک بند تحت عنوان گروه های کاربری مجاز به توضیحات هر یک از فعالیت های سامانه اضافه کرده و گروه های کاربری مجاز به انجام هر فعالیت را با توجه به مثال های این بخش در آن مشخص نمایید.

شروط منطقی

انجام هر فعالیت تنها در صورت برقراری یک سری شروط منطقی مجاز و ممکن خواهد بود. در پیش شرط مجوز دسترسی گفتیم یک مسافر در صورت تمایل می تواند یک سفر را لغو نماید. اما آیا تنها داشتن مجوز دسترسی کافیست و یک مسافر می تواند سفر مسافر دیگر را لغو کند؟ پاسخ: قطعا خیر!

چنین مشکلاتی علاوه بر نقض امنیت سامانه در لایه نرم افزار ضربه ی جبران ناپذیری را به میزان اعتماد کاربران به سامانه وارد خواهد کرد. بنابراین شروط منطقی سامانه هم بسیار حائز اهمیت هستند و باید به دقت توسط کارفرما تعیین شوند تا توسط گروه ویرانیک در نرم افزار لحاظ گردند.

خروجی: لطفا یک بند تحت عنوان شروط منطقی به توضیحات هر یک از فعالیت های سامانه اضافه کرده و کلیه شرط هایی که باید هنگام انجام فعالیت بررسی شوند را با توجه این بخش در آن مشخص نمایید.

سناریو

این بخش کمی به حوصله نیاز دارد چون به دنبال سناریو و جزئیات مراحل انجام فعالیت هاست اما در مقابل به گروه ویرانیک برای درک ذهنیت و انتظارات شما خیلی خیلی کمک می کند؛ پس با ما همراه باشید. اگر فعالیت پرداخت آنلاین هزینه سفر در سامانه تاکسی اینترنتی را در نظر بگیریم سوالات زیر در این بخش مطرح خواهند شد:

• از ابتدا تا انتهای فعالیت پرداخت آنلاین هزینه سفر دقیقا چه اتفاقاتی خواهد افتاد و چه مراحلی طی می شوند؟
• چند شیوه پرداختی در سامانه وجود دارد؟ فقط پرداخت آنلاین مجاز است یا پرداخت نقدی به راننده هم امکان پذیر است؟
• سامانه از کدام درگاه های پرداخت آنلاین پشتیبانی می کند؟
• آیا نیاز است برای مسافران در سامانه موجودی (کیف پول الکترونیکی) در نظر گرفته شود؟
• آیا قابلیت اعمال کوپن یا کد تخفیف وجود دارد؟

از کجا شروع کنم؟ بریم سراغ نقطه ی شروع فعالیت. واضح است که برای شروع فعالیت پرداخت آنلاین هزینه سفر مسافر باید روی دکمه پرداخت کلیک نماید. بنابراین اولین مرحله از فعالیت پرداخت آنلاین هزینه سفر کلیک روی دکمه پرداخت است؛ این مرحله را در سناریو یا مراحل فعالیت قید کنید. حال بر اساس تعداد شیوه های پرداختی سامانه سناریوهای متفاوتی برای پرداخت آنلاین هزینه سفر خواهیم داشت.

ابتدا باید در رابطه با شیوه های پرداختی سامانه تصمیم گیری کنید. اگر تصمیم شما پشتیبانی سامانه از هر دو شیوه ی پرداخت یعنی 1) پرداخت آنلاین از طریق درگاه پرداخت اینترنتی و 2) پرداخت از کیف پول الکترونیکی است دو سناریوی متفاوت برای فعالیت پرداخت آنلاین هزینه سفر خواهیم داشت و در غیر اینصورت تنها یک سناریو برای پرداخت پیش روی مسافران خواهد بود اما گروه ویرانیک هر دو سناریو را به عنوان نمونه تشریح کرده است.

در صورتی که سامانه بیش از یک شیوه برای پرداخت آنلاین داشته باشد پس از کلیک روی دکمه پرداخت ابتدا در یک دیالوگ شیوه های پرداخت نمایش داده می شوند تا مسافر شیوه ی پرداخت مورد نظر خود را انتخاب کند. پس از آن بر اساس شیوه ی پرداخت انتخابی مسافر فعالیت پرداخت آنلاین هزینه سفر در یکی از سناریوهای زیر ادامه خواهد یافت:

1. سناریوی پرداخت آنلاین از طریق درگاه پرداخت اینترنتی:
   • مسافر شیوه ی پرداخت آنلاین از طریق درگاه پرداخت اینترنتی را انتخاب می کند. در این مرحله اگر بیش از یک درگاه پرداخت اینترنتی در سامانه وجود داشته باشد دیالوگ انتخاب درگاه به مسافر نمایش داده خواهد شد.
     نکته: لطفا برای درگاه های پرداخت اینترنتی داخلی نام شرکت PSP یا پرداخت یار مورد نظر و برای درگاه های پرداخت اینترنتی بین المللی نام پلتفرم بین المللی پرداخت مورد نظر مانند Webmoney، PayPal و... را در سناریو ذکر نمایید.
   • مسافر درگاه پرداخت اینترنتی مورد نظر را انتخاب کرده و پس از چند ثانیه به صفحه پرداخت هدایت خواهد شد.
   • مسافر اطلاعات خود را در صفحه پرداخت درگاه جهت پرداخت آنلاین هزینه سفر وارد می نماید.
   • نتیجه پرداخت توسط درگاه پرداخت اینترنتی به سامانه گزارش می شود و سامانه اطلاعات پرداخت را جهت تسویه و تایید تراکنش به درگاه پرداخت ارسال می کند.
   • در صورت موفق بودن پرداخت مسافر پیغام پرداخت موفقیت آمیز را مشاهده می کند و در غیر اینصورت پیغام خطای مربوطه به مسافر نمایش داده می شود.
   • در صورت موفقیت آمیز بودن پرداخت اطلاعیه (Notification) پرداخت شدن هزینه سفر برای راننده ارسال می گردد و سفر به وضعیت پرداخت شده خواهد رفت.
2. پرداخت از کیف پول الکترونیکی:
   • ابتدا موجودی حساب مسافر بررسی می شود و در صورتی که موجودی کمتر از هزینه سفر باشد پیغام کافی نبودن موجودی به مسافر نمایش داده خواهد شد.
   • در صورتی که موجودی حساب مسافر برابر یا بیشتر از هزینه سفر باشد مسافر پیغام پرداخت موفقیت آمیز را مشاهده می کند.
   • پس از پرداخت موفقیت آمیز اطلاعیه (Notification) پرداخت شدن هزینه سفر برای راننده ارسال می گردد و سفر به وضعیت پرداخت شده خواهد رفت.

نکته: اطلاعیه (Notification) می تواند از طریق پیامک، ایمیل و یا به صورت درون برنامه ای برای راننده ارسال شود. لطفا روش ارسال مورد نظر خود را در سناریو ذکر نمایید.

همچنین اگر برای سامانه قابلیت اعمال کوپن یا کد تخفیف در نظر گرفته اید سناریوی استفاده از آن را لطفا در فعالیتی دیگر تشریح نمایید. با اینکه فعالیت اعمال کوپن یا کد تخفیف از فعالیت پرداخت هزینه سفر جدا می باشد لازم است در دیالوگ شیوه های پرداخت از فعالیت پرداخت هزینه سفر حتما قابلیت اعمال کوپن یا کد تخفیف را قید نمایید تا مورد توجه گروه ویرانیک قرار گیرد.

ممکن است شما برای سامانه قابلیت پرداخت نقدی به راننده را هم در نظر داشته باشید. با توجه به اینکه پرداخت نقدی به راننده خارج از برنامه و به صورت مستقیم اتفاق می افتد نیازی به ایجاد فعالیت مجزا برای آن نیست. اما در صورت تمایل می توانید فعالیت گزارش پرداخت نقدی به راننده را برای گروه کاربری رانندگان تعریف نمایید.

خروجی: در انتهای این بخش انتظار می رود سناریو و مراحل انجام تمامی فعالیت ها به صورت جزئی، دقیق و شفاف مطابق با نمونه در شرح خدمات توسط کارفرما ذکر شده باشد.

محرک ها

در پروژه های نرم افزاری ممکن است لازم باشد یک فعالیت در امتداد فعالیتی دیگر به صورت خودکار انجام شود. باز هم برمی گردیم به مثال سامانه تاکسی اینترنتی؛

فرض کنید که می خواهید درصدی از هزینه سفر را پس از پرداخت هزینه سفر توسط مسافران به عنوان کوپن تخفیف به مسافر مربوطه هدیه دهید. در اینصورت نیاز است فعالیت پرداخت هزینه سفر را به عنوان محرک فعالیت اختصاص کوپن تخفیف به گروه ویرانیک معرفی نمایید.

می پرسید که چرا فعالیت پرداخت هزینه سفر محرک فعالیت اختصاص کوپن تخفیف است؟ چون فعالیت اختصاص کوپن تخفیف بلافاصله پس از فعالیت پرداخت هزینه سفر به صورت خودکار اجرا می شود؛ یعنی فعالیت پرداخت هزینه سفر باعث انجام فعالیت اختصاص کوپن تخفیف می شود.

یا شاید پس از انجام فعالیت گزارش رسیدن به مقصد توسط رانندگان بخواهید مبلغی را به راننده مربوطه پاداش دهید. در اینصورت هم فعالیت گزارش رسیدن به مقصد محرک فعالیت اعطای پاداش به رانندگان خواهد بود.

خروجی: با توجه به مثال های این بخش محرک های هر یک از فعالیت های پروژه ی خود را شناسایی کرده و در شرح خدمات ذکر نمایید.

فرم ها

برای انجام بعضی از فعالیت ها ممکن است نیاز باشد کاربر یک فرم را تکمیل نماید. در این بخش ابتدا فعالیت هایی که نیاز به تکمیل فرم دارند را شناسایی می کنیم و سپس به کشف اطلاعاتی که باید در هر فرم وارد شوند خواهیم پرداخت.

اما باید از کجا شروع کرد؟ چگونه فعالیت هایی که نیازمند تکمیل یک فرم هستند را شناسایی کنیم؟ اصلا نگران نباشید چون گروه ویرانیک همراه شماست؛ کلید طلایی: فرم ها تنها راه دریافت اطلاعات از کاربران هستند. بنابراین در کلیه فعالیت هایی که باید اطلاعاتی از کاربر دریافت شود حداقل یک فرم نیاز است.

عقبگرد بزنیم به مثال سامانه تاکسی اینترنتی؛ در فعالیت ثبت نام رانندگان نیاز است هر راننده اطلاعات و مدارک خود را از طریق یک فرم در سامانه وارد نمایند. همچنین در فعالیت ثبت بازخورد سفر مسافر باید اطلاعاتی که تجربه اش از سفر را منعکس می کند در یک فرم وارد و ارسال نماید.

بنابراین در فعالیت های ثبت نام رانندگان و ثبت بازخورد سفر حداقل یک فرم خواهیم داشت. سوال بعدی اینجاست: چه اطلاعاتی باید از کاربر در هر فرم دریافت شود؟ برای یافتن پاسخ این سوال و تعیین چگونگی و جزئیات دریافت اطلاعات از کاربر بخش فیلدها را دنبال کنید.

فیلدها

پس از شناسایی فرم ها نیاز است اطلاعاتی که باید در هر فرم وارد شوند را تعیین کنیم. به ازای هر اطلاعاتی که باید از کاربر در یک فرم دریافت شود یک فیلد خواهیم داشت. به طور مثال در فعالیت ثبت نام رانندگان سامانه تاکسی اینترنتی اگر بخواهیم اطلاعات زیر را از راننده دریافت کنیم به فرم ثبت نام رانندگان که حاوی پنج فیلد زیر است نیاز داریم:

1. نام و نام خانوادگی
2. کد ملی
3. تاریخ تولد
4. جنسیت
5. تصویر کارت ملی
6. شماره پلاک خودرو

خُب! اطلاعاتی که باید در فرم ثبت نام رانندگان از راننده دریافت شود را شناسایی کردیم، حالا باید جزئیات و چگونگی ورود اطلاعات در فیلدها را تعیین کنیم. برای این کار نیاز است سوالات زیر را به ازای هر یک از 5 فیلد فرم ثبت نام رانندگان پاسخ دهید:

• آیا تکمیل فیلد الزامی است؟
  فیلدهایی که تکمیل آنها در فرم الزامی است معمولا با کاراکتر * نشانه گذاری می شوند. کاربر در صورتی که اطلاعات فیلدهای الزامی را وارد نکرده باشده قادر به ارسال فرم نخواهد بود و پیغام خطا مشاهده خواهد کرد. در فرم ثبت نام رانندگان می توانیم فیلدهای نام و نام خانوادگی، کد ملی، تصویر کارت ملی و شماره پلاک خودرو را به عنوان فیلدهای الزامی در نظر بگیریم.
  خروجی: لطفا فیلدهایی که می خواهید تکمیل آنها الزامی باشد را در شرح خدمات مشخص نمایید.
• آیا اطلاعات واردشده در فیلد نیازمند اعتبارسنجی است؟ اگر پاسخ مثبت است اطلاعات باید از چه الگویی تبعیت کنند؟
  در فرم ثبت نام رانندگان ممکن است یک راننده فیلد کد ملی خود را به طور مثال با مقدار "گروه ویرانیک" تکمیل کند. واضح است که مقدار "گروه ویرانیک" یک کد ملی معتبر نیست چراکه کد ملی 10 رقمی است و تنها می تواند شامل اعداد 0 تا 9 باشد. در حالیکه "گروه ویرانیک" یک عبارت 18 حرفی تشکیل شده از حروف الفبای زبان فارسی است.
  بنابراین فیلد کد ملی در فرم ثبت نام رانندگان نیازمند اعتبارسنجی است و الگوی اعتبارسنجی آن هم یک عدد 10 رقمی متشکل از اعداد 0 تا 9 است. کاربران قادر به وارد کردن اطلاعات غیرمعتبر در فیلدهایی که دارای اعتبارسنجی هستند نخواهند بود و در صورت وارد کردن اطلاعات نامعتبر پیغام خطا مشاهده خواهند کرد.
  خروجی: در شرح خدمات لطفا فیلدهایی که نیازمند اعتبارسنجی هستند را به همراه الگوی اعتبارسنجی مورد نظر مشخص نمایید.
• آیا برای فیلد لازم است انتخاب گر در نظر گرفته شود؟
  برای فیلدهایی که اطلاعات ورودی آنها از جنس موقعیت جغرافیایی، تاریخ، ساعت و یا سایر مقادیر ویژه است معمولا یک انتخاب گر در رابط کاربری نرم افزار در نظر گرفته می شود تا کاربران به آسانی بتوانند مقادیر این فیلدها را تکمیل کنند.
  به طور مثال برای فیلد تاریخ تولد در فرم ثبت نام رانندگان می توان یک انتخاب گر تاریخ در نظر گرفت تا راننده به جای تایپ کردن تاریخ تولد خود با استفاده از انتخاب گر روز تولدش را سریع و ساده انتخاب کند.
  خروجی: لطفا فیلدهایی که نیازمند انتخاب گر را در شرح خدمات مشخص نمایید.
• آیا نیاز است برای فیلد عبارت کمکی یا راهنما در نظر گرفته شود؟
  در برخی از فیلدها جهت رفع ابهام یا راهنمایی کاربران ممکن است لازم باشد عبارتی در زیر فیلد درج شود. به طور مثال برای فیلد تصویر کارت ملی فرم ثبت نام رانندگان می توانیم عبارت "تنها فرمتهای TIFF ،PNG ،JPEG ،JPG و PDF با حداکثر حجم 5 مگابایت قابل قبول است." را به عنوان راهنما ذکر کنیم.
  خروجی: در شرح خدمات لطفا عبارت مورد نظر خود را برای فیلدهایی که می خواهید دارای عبارت کمکی یا راهنما باشند ذکر نمایید.
• آیا نیاز است برای فیلد داده ی نمونه در نظر گرفته شود؟
  تکمیل برخی از فیلدها ممکن است برای کاربران ابهام برانگیز باشد. فرض کنید شماره موبایل کاربر 09351292903 است. کاربر باید شماره موبایل خود را مطابق کدام یک از الگوهای زیر وارد کند تا مقدار واردشده از سوی سامانه معتبر شناخته شود؟
  
  1. 00989351292903
  2. +989351292903
  3. 9351292903
  4. 09351292903
  در چنین شرایطی جهت پیشگیری از سردرگمی کاربر یک داده ی نمونه در فیلد به کاربر نمایش داده می شود تا کاربر پیش از دریافت پیغام خطای اعتبارسنجی بتواند از الگوی قابل قبول سامانه برای فیلد مربوطه مطلع شود. به طور مثال اگر مقدار معتبر گزینه ی شماره 2 باشد داده ی نمونه +989123456789 به کاربر نمایش داده خواهد شد.
  خروجی: در شرح خدمات لطفا فیلدهایی که می خواهید دارای داده ی نمونه باشند را به همراه داده ی نمونه دلخواه مشخص نمایید.
• آیا نیاز است برای فیلد داده ی پیشفرض در نظر گرفته شود؟
  به طور معمول فیلدهای فرم ها بدون مقدار و خالی هستند. گاهی ممکن است نیاز باشد یک مقدار پیشفرض در فرم به کاربر پیشنهاد شود؛ به طور مثال با توجه به اینکه جامعه ی رانندگان را اغلب مردان تشکیل می دهند ممکن است بخواهید مقدار پیشفرض فیلد جنسیت را در فرم ثبت نام رانندگان روی مقدار "مذکر" تنظیم نمایید.
  خروجی: در شرح خدمات لطفا فیلدهایی که می خواهید دارای داده ی پیشفرض باشند را به همراه داده ی پیشفرض دلخواه مشخص نمایید.
• آیا نیاز است برای فیلد پسوند یا پیشوند در نظر گرفته شود؟
  پسوندها اغلب برای درج واحد مقداری که باید از کاربر دریافت شود استفاده می شوند. به طور مثال پسوند فیلدی که باید قیمت توسط کاربر در آن درج شود می تواند یورو (€) باشد تا کاربر متوجه شود که قیمت را باید به یورو در فیلد وارد کند. اگر بخواهیم ارتفاع هم در یک فیلد از کاربر دریافت کنیم می توانیم متر یا سانتیمتر را به عنوان پسوند در نظر بگیریم.
  پیشوندها هم بیشتر جنبه راهنمایی و هدایت دارند. به طور مثال اگر بخواهیم آدرس وب سایت را از کاربر دریافت کنیم می توانیم پیشوند https://www. را به عنوان پیشوند در نظر بگیریم تا کاربر متوجه شود که نیاز به تایپ کردن پروتکل https و www در فیلد وب سایت ندارد.
  خروجی: در شرح خدمات لطفا فیلدهایی که می خواهید با پسوند یا پیشوند نمایش داده شوند را به همراه پسوند یا پیشوند دلخواه مشخص نمایید.
• آیا نیاز است برای نمایش فیلد شرط خاصی در نظر گرفته شود؟
  فرض کنید که در فعالیت ثبت نام پروژه شما قابلیت ثبت نام افراد حقیقی و حقوقی وجود داشته باشد. در اینصورت نیاز است کاربر ابتدا انتخاب کند که یک شخصیت حقیقی است یا یک شخصیت حقوقی و متناسب با آن در بخش اطلاعات هویتی فرم ثبت نام فیلدهای متفاوتی نمایش داده خواهند شد چراکه اطلاعات هویتی افراد حقوقی و حقیقی متفاوت هستند.
  به طور مثال در بخش اطلاعات هویتی فرم ثبت نام افراد حقوقی به فیلدهای نام شرکت، کد ثبت، شناسه ملی و شناسه مالیاتی نیاز دارد. در مقابل بخش اطلاعات هویتی فرم ثبت نام افراد حقیقی به فیلدهای نام و نام خانوادگی، نام پدر و کد ملی نیاز دارد.
  بنابراین نمایش یا عدم نمایش فیلد نام پدر به مقدار انتخاب شده در فیلد نوع شخصیت بستگی دارد. اگر مقدار فیلد نوع شخصیت برابر حقیقی باشد فیلد نام پدر در فرم ثبت نام نمایش داده خواهد شد و در صورتی که برابر حقوقی باشد فیلد نام پدر نمایش داده نمی شود.
  خروجی: لطفا فیلدهایی که نمایش یا عدم نمایش آنها وابسته به برقراری یک شرط است در شرح خدمات مشخص کنید.
• آیا فیلد همیشه فعال و قابل ویرایش است یا برای قابل ویرایش بودنش باید شرط خاصی بررسی شود؟
  گاهی فیلد نمایش داده می شود اما فعال نیست و کاربر قادر به ویرایش مقدارش نخواهد بود. برگردیم به مثال سامانه تاکسی اینترنتی؛ پس از اینکه تیم مدیریتی مدارک یک راننده را تایید کند راننده دیگر قادر نخواهد بود فیلد نام و نام خانوادگی خود را در بخش ویرایش پروفایل تغییر دهد.
  خروجی: لطفا در شرح خدمات فیلدهایی که تنها در شرایط خاص قابل ویرایش هستند را مشخص نمایید.

صفحات

در این بخش به دنبال کشف صفحات مورد نیاز پروژه هستیم. البته منظور صفحات یکتای پروژه مانند صفحه اصلی، صفحه آرشیو مقالات، صفحه جزئیات هر مقاله، صفحه آرشیو محصولات، صفحه جزئیات هر محصول و... هستند.

اما چطور صفحات یکتا از صفحات غیریکتا را تشخیص دهیم؟ فرض کنید پروژه شما فروشگاه اینترنتی است و 5 محصول برای فروش دارید؛ یک صفحه ی یکتا به نام آرشیو محصولات نیاز خواهیم داشت تا خلاصه ای از 5 محصول شما نمایش دهد و تنها یک صفحه ی یکتا نیاز داریم تا جزئیات هر محصول را نشان دهد.

در واقع برای نمایش 5 محصول پروژه ما 5 صفحه با چیدمان و قالب یکسان و محتوای متفاوت خواهیم داشت. بنابراین صفحاتی یکتا هستند که علاوه بر محتوا در قالب و چیدمان هم با هم متفاوت باشند.

خروجی: لطفا صفحات یکتای پروژه خود را شناسایی کنید. در ادامه گروه ویرانیک جهت تعیین بخش های داینامیک، اجزا و اطلاعات، طراحی و چیدمان، مجوز دسترسی و فعالیت های قابل انجام به ازای هر یک از صفحات همراه شماست.

اجزا و اطلاعات

مرحله بعدی پس از شناسایی صفحات یکتا تعیین اجزا و اطلاعاتی است که باید در هر صفحه نمایش داده شوند. علاوه بر این نیاز است نوع و چگونگی نمایش اطلاعات در صفحه ی مربوطه را با جزئیات مطابق آنچه انتظار دارید تشریح نمایید.

اجزا و اطلاعات مورد نیاز هر صفحه را چگونه در شرح خدمات وارد کنم؟ خیلی ساده! به ازای هر صفحه یک لیست تهیه و اجزای آن را مشخص کنید. با گروه ویرانیک همراه باشید. لیست زیر اجزای پیشنهادی صفحه ی جزئیات هر محصول را نشان می دهد:

• نام محصول: نام یا عنوان محصول را در حداکثر 2 سطر نمایش می دهد.
• شرح خلاصه محصول: در یک پاراگراف به صورت خلاصه محصول را معرفی می کند.
• قیمت محصول: قیمت محصول را به همراه واحد ارزی مربوطه نمایش می دهد.
• وضعیت موجودی محصول: یکی از برچسب های "موجود در انبار" یا "اتمام موجودی" را بر اساس موجودی محصول نمایش می دهد.
• دکمه افزودن به سبد خرید: در صورت موجود بودن محصول این دکمه در دسترس خواهد بود تا قابلیت انجام فعالیت افزودن به سبد خرید را فراهم کند.
• گالری تصاویر محصول: در یک اسلایدر تصاویر محصول نمایش داده خواهند شد.
• ویدیوی معرفی محصول: پوستری است که جهت آشنایی بیشتر با محصول مشاهده ی ویدیوی معرفی محصول را به بازدیدکنندگان صفحه پیشنهاد می دهد.
• جدول ویژگی های محصول: یک جدول دو ستونه است که ستون هانیش عنوان و مقدار ویژگی هستند و سطرهای آن ویژگی های محصول می باشد.
• توضیحات تکمیلی محصول: با استفاده از توضیحات متنی، جداول و فایل های چندرسانه ای به نقد و بررسی محصول می پردازد.
• دیدگاه خریداران: دیدگاه های خریداران محصول را نمایش می دهد. هر دیدگاه شامل اطلاعات زیر است:
  • نام خریدار: نام و نام خانوادگی خریدار را نمایش می دهد.
  • امتیاز 5 ستارهای خریدار به محصول: امتیازی که خریدار از 1 تا 5 به محصول داده را نشان می دهد.
  • پاراگراف متنی: متنی که خریدار جهت شرح تجربه اش از خرید محصول نوشته را نشان می دهد.
  • زمان درج دیدگاه: ساعت و تاریخ ثبت دیدگاه توسط خریدار را نشان می دهد.
• پرسش های متداول: در یک منوی آکاردئونی که عنوان هر منو سوال و محتوایش پاسخ سوال است سوالات متداول مرتبط با محصول را نمایش می دهد.
• اسلایدر محصولات مشابه: در یک اسلایدر محصولات مشابه با محصول جاری را نشان می دهد. هر اسلاید نشان دهنده ی یک محصول مشابه است و شامل اطلاعات زیر می باشد:
  • نام: نام یا عنوان محصول مشابه را در حداکثر 2 سطر نمایش می دهد.
  • تصویر شاخص: نشان دهنده ی تصویر شاخص محصول مشابه است.
  • قیمت: قیمت محصول مشابه را نشان می دهد.
  • وضعیت موجودی: یکی از برچسب های "موجود در انبار" یا "اتمام موجودی" را بر اساس موجودی محصول مشابه نمایش می دهد.
  • میانگین 5 ستارهای امتیاز خریداران: میانگینی از امتیازات دریافتی محصول مشابه از خریداران را نشان می دهد.

خروجی: لطفا اجزا و اطلاعاتی که می خواهید در هر یک از صفحات پروژه نمایش داده شوند را مطابق راهنمایی های این بخش در شرح خدمات ذکر نمایید.

طراحی و چیدمان

پس از تعیین اجزا و اطلاعات گام بعدی تهیه یک اتود جهت انتقال نکات مورد نظر کارفرما در رابطه با طراحی هر یک از صفحات پروژه و چگونگی چیدمان اجزای آن به طراح است. این اتود با ایجاد زبان مشترک بین کارفرما و طراح علاوه بر جلوگیری از هدر رفت زمان و هزینه در مرحله طراحی رابط کاربری پروژه، کمک می کند خروجی نهایی پروژه از نظر ظاهری تا حد امکان به ذهنیت و سلیقه کارفرما نزدیک شود.

اما این اتود را چگونه باید تهیه کنید؟ ساده ترین روش استفاده از یک مداد و یک برگ کاغذ است. فارغ از هر محدودیتی آنچه که در ذهن دارید را روی کاغذ بیاورید و محل قرارگیری هر یک از اجزای صفحه را به همراه چگونگی نمایش آن در صفحه ترسیم کنید. کاغذ و مداد ابزار کاملی جهت انتقال ایده شما به طراح است با این حال در صورت دسترسی به ابزارهای پیشرفته تر الکترونیکی یا تسلط به نرم افزارهای گرافیکی می توانید جهت ترسیم اتود از آنها بهره ببرید.

خروجی: پس از رسم اتود صفحات پروژه کافیست یک تصویر از آن با تلفن همراه خود تهیه کرده و به بخش مربوطه در RFP اضافه نمایید.

تعیین بخش های داینامیک

این بخش به دنبال تعیین اطلاعات داینامیک صفحات پروژه است. اما منظور از اطلاعات داینامیک چیست؟ اطلاعاتی که بدون نیاز به مهارت برنامه نویسی و از طریق پنل مدیریتی پروژه قابل تغییر هستند را اطلاعات داینامیک پروژه می نامند.

به طور مثال اطلاعاتی که باید در صفحه جزئیات هر محصول نمایش داده شود را که در بخش اجزا و اطلاعات تشریح شد را در نظر بگیرید؛ آیا می خواهید نام، قیمت، وضعیت موجودی، تصاویر گالری، ویژگی های محصول و پرسش های متداول مرتبط با محصول را بتوانید از طریق پنل مدیریتی و بدون نیاز به تماس با گروه ویرانیک تغییر دهید؟

به جز دیدگاه های کاربران که اطلاعات تعاملی هستند سایر اطلاعات محصولات می توانند به صورت استاتیک و ثابت باشند. داینامیک سازی اطلاعات صفحات نیاز به کار بیشتر روی پروژه دارد که افزایش هزینه اجرای پروژه را برای شما به همراه خواهد داشت. بنابراین در تعیین بخش های داینامیک دقت لازم را داشته باشید.

خروجی: مطابق راهنمایی های این بخش لطفا اطلاعاتی که می خواهید داینامیک شوند را به ازای هر یک از صفحات پروژه در شرح خدمات مشخص نمایید.

فعالیت های قابل انجام

در بخش فعالیت ها گروه ویرانیک به شرح چگونگی شناسایی فعالیت های قابل انجام در پروژه پرداخته است. در این بخش به دنبال فعالیت های قابل انجام در هر صفحه هستیم. به طور مثال فعالیت های زیر می توانند در صفحه جزئیات هر محصول انجام شوند:

• فعالیت افزودن محصول به سبد خرید
• فعالیت ثبت دیدگاه جدید برای محصول
• فعالیت افزودن محصول به علاقه مندی ها
• فعالیت اشتراک گذاری محصول
• فعالیت آگاهی از موجود شدن محصول
• فعالیت آگاهی از فروش ویژه ی محصول

تمامی فعالیت هایی که در صفحات پروژه قابل انجام هستند لازم است مانند آنچه در بخش فعالیت ها توسط گروه ویرانیک توضیح داده شده به طور دقیق و جزئی شرح داده شده باشند. بنابراین لازم است از وجود تشریح و جزئیات فعالیت های قابل انجام هر صفحه از پروژه در شرح خدمات اطمینان حاصل نمایید.

خروجی: مطابق راهنمایی های این بخش لطفا فعالیت هایی را که می خواهید در هر یک از صفحات پروژه قابل انجام باشند در شرح خدمات مشخص نمایید.

محدودیت های دسترسی

در این بخش به دنبال محدودیت هایی هستیم که جهت دسترسی به صفحات پروژه باید در نظر گرفته شوند. آیا صفحه عمومی است و مشاهده ی آن برای تمامی بازدیدکنندگان و تمامی گروه های کاربری آزاد است؟ یا یک صفحه حفاظت شده است و تحت شرایط خاصی قابل مشاهده می باشد؟

به طور مثال صفحه ی جزئیات هر محصول را در نظر بگیرید؛ اگر شما به عنوان ادمین نمایش یک محصول را غیرفعال نمایید گروه کاربری مشتریان و بازدیدکنندگان فروشگاه شما نباید قادر به مشاهده جزئیات آن باشند. بنابراین صفحه ی جزئیات هر محصول برای بازدیدکنندگان و گروه کاربری مشتریان تنها در صورتی قابل مشاهده خواهد بود که نمایش آن توسط ادمین غیرفعال نشده باشد.

در مقابل صفحه ی جزئیات هر محصول می تواند برای ادمین و اعضای گروه کاربری تیم مدیریتی بدون محدودیت دسترسی و به صورت همیشگی قابل مشاهده باشد.

خروجی: مطابق راهنمایی های این بخش لطفا صفحات حفاظت شده ی پروژه را در شرح خدمات مشخص نمایید.

فریم ورک رابط کاربری (فرانت اند)

اگر ظاهر پروژه برای شما حائز اهمیت است انتخاب فریم ورک رابط کاربری یکی از مهمترین انتخاب های شماست چراکه فریم ورک رابط کاربری بیشترین تاثیر را در طرح گرافیکی پروژه ی شما خواهد داشت. فریم ورک های رابط کاربری زیر توسط گروه ویرانیک پشتیبانی می شوند که بر اساس نوع نرم افزار سفارشی گروه بندی شده اند:

• اپلیکیشن های تحت وب: در حال حاضر گروه ویرانیک از دو فریم ورک Vuetify و Bootstrap برای طراحی رابط کاربری اپلیکیشن های تحت وب که شامل وب سایت ها، پرتال ها و اپلیکیشن های PWA هستند پشتیبانی می کند.
• اپلیکیشن های اندروید: در حال حاضر گروه ویرانیک از فریم ورک Flutter برای طراحی رابط کاربری اپلیکیشن های اندروید پشتیبانی می کند.
• اپلیکیشن های iOS: در حال حاضر گروه ویرانیک از فریم ورک Flutter برای طراحی رابط کاربری اپلیکیشن های iOS پشتیبانی می کند.

خروجی: لطفا فریم ورک رابط کاربری مورد نظر خود را در شرح خدمات ذکر نمایید.

فریم ورک بک اند

بک اند پشت صحنه ی نرم افزار است و عملیات ذخیره و بازیابی اطلاعات، انجام محاسبات سمت سرور، احرازهویت کاربران و ایجاد ارتباط بین رابط های کاربری نرم افزار را دور از چشم کاربران بر عهده دارد. امنیت، کارایی، مقیاس پذیری و توسعه پذیری پروژه از پارامترهای مهمی هستند که تحت تاثیر فریم ورک بک اند پروژه قرار دارند.

در حال حاضر گروه ویرانیک از فریم ورک بسیار سریع و قدرتمند Symfony برای پروژه های اختصاصی و بزرگ استفاده می کند. همچنین در پروژه های کوچک و غیراختصاصی جهت کاهش هزینه توسعه بنا به درخواست کارفرما از سیستم مدیریت محتوای Wordpress استفاده می شود.

خروجی: لطفا فریم ورک بک اند مورد نظر خود را در شرح خدمات ذکر نمایید.

زبان ها

پروژه ی شما باید از چند زبان پشتیبانی کند؟ تک زبانه است یا چند زبانه؟ در این بخش نیاز است در رابطه با تعداد زبان های رابط کاربری پروژه تصمیم گیری نمایید. هیچگونه محدودیتی در تعداد زبان هایی که می توانید انتخاب کنید وجود ندارد اما از آنجا که افزایش تعداد زبان ها هزینه شما را افزایش خواهد داد پس در این رابطه دقت نمایید.

خروجی: لطفا زبان هایی که برای پروژه مد نظر دارید را در شرح خدمات مشخص نمایید.

واحدهای ارزی

پروژه باید از کدام واحدهای ارزی پشتیبانی کند؟ واحدهای ارزی تنها هنگامی اهمیت پیدا می کنند که بخواهید نرم افزار سفارشی خود را به قابلیت پرداخت آنلاین مجهز کنید یا در نرم افزار سفارشی خود قیمت خدمات یا محصولاتتان را نمایش دهید. بنابراین اگر نرم افزار سفارشی شما غیرتجاری است می توانید این بخش را نادیده بگیرید.

شما در انتخاب واحدهای ارزی هیچگونه محدودیتی ندارید چراکه گروه ویرانیک می تواند قابلیت پشتیبانی از تمامی ارزها را برای شما در نرم افزار تعبیه کند. اما باید توجه داشته باشید که افزایش تعداد ارزهای قابل پشتیبانی هزینه توسعه نرم افزار را افزایش خواهد داد.

خروجی: لطفا واحدهای ارزی مورد نظر خود برای پروژه را در شرح خدمات مشخص نمایید.

پلتفرم های پشتیبانی کننده

پلتفرم محیطی است که نرم افزار سفارشی شما در آن اجرا می شود. منظور از پلتفرم متناسب با نوع نرم افزار متفاوت است. به طور مثال پلتفرم نرم افزارهای تحت وب مرورگرهای Opera ،Edge ،Firefox ،Chrome و... هستند و پلتفرم اپلیکیشن های اندروید سیستم عامل اندروید است. همچنین پلتفرم اپلیکیشن های iOS هم سیستم عامل iOS است.

برای درک بهتر این بخش با گروه ویرانیک همراه باشید. فرض کنید نرم افزار سفارشی شما یک وب سایت یا پرتال است؛ آیا نیاز است وب سایت یا پرتال شما روی مرورگرهای منسوخ شده ای چون IE نسخه 9 و نسخه های قبل از آن اجرا شود؟ یا اجرا روی مرورگرهای مدرن و به روز مد نظر شماست؟

این مورد برای اپلیکیشن های اندروید و iOS هم مطرح است. قدیمی ترین نسخه از سیستم عامل اندروید یا iOS که باید اپلیکیشن اندروید یا iOS سفارشی شما روی آن قابل نصب باشد کدام است؟

خروجی: لطفا قدیمی ترین نسخه از پلتفرمی که می خواهید از پروژه پشتیبانی کند را در شرح خدمات مشخص نمایید.

واکنشگرایی

در صورتی که نرم افزار سفارشی شما تحت وب نیست می توانید این بخش را نادیده بگیرید. در اپلیکیشن های تحت وب که روی تمامی دستگاه ها با هر رزولیشنی قابل اجرا هستند واکنشگرایی یکی از مهمترین پارامترهای کیفی است. امروزه اکثر وب سایت ها و پرتال ها واکنشگرا یا Responsive هستند. سایزهای واکنشگرایی پیشفرض عبارتند از:

1. Extra Small: مختص حالت عمودی موبایل ها و دستگاه های دارای رزولیشن کوچکتر از 600 پیکسل
2. Small: مختص حالت افقی موبایل ها و حالت عمودی تبلت ها و دستگاه های دارای رزولیشن کوچکتر از 960 پیکسل
3. Medium: تبلت ها، دسکتاپ ها، لپتاپ ها و دستگاه های دارای رزولیشن کوچکتر از HD
4. Large: دسکتاپ ها، لپتاپ ها و دستگاه های دارای رزولیشن بزرگتر از HD
5. Extra Large: دسکتاپ ها، لپتاپ ها و دستگاه های دارای رزولیشن بزرگتر از Full HD

منظور از اعداد ذکرشده در سایزهای فوق اندازه افقی نمایشگر دستگاه ها است. در تمامی پروژه های تحت وب گروه ویرانیک واکنشگرایی در 5 سایز به صورت پیشفرض انجام می شود اما به درخواست کارفرما سایزهای بیشتر نیز قابل تعریف هستند.

همچنین در صورتی که پروژه ی شما به سایزهای واکنشگرایی پیشفرض نیاز ندارد جهت کاهش هزینه می توانید آنها را از شرح خدمات حذف نمایید. به طور مثال، ممکن است کاربران نهایی پروژه ی شما افرادی که با موبایل یا تبلت از وب سایت یا پرتال شما بازدید می کنند نباشند!

خروجی: لطفا سایزهای مورد نظر خود برای واکنشگرایی را در شرح خدمات مشخص نمایید.

معیارهای سئو

در صورتی که نرم افزار سفارشی شما تحت وب نیست می توانید این بخش را نادیده بگیرید. دیگر شاخص کیفی بسیار مهم اپلیکیشن های تحت وب رعایت استانداردهای سئو حین طراحی و توسعه است. گروه ویرانیک تمامی استانداردهای سئو تکنیکال که شامل موارد زیر است را به صورت پیشفرض در پروژه های تحت وب لحاظ می نماید:

• بهبود سرعت و کارایی: بهینه سازی و افزایش سرعت و کارایی صفحات پروژه مطابق با معیارهای موتورهای جستجو
• موبایل دوستی: کسب اطمینان از اجرای صحیح صفحات پروژه در موبایل مطابق با معیارهای موتورهای جستجو
• Site Structure: سازگارسازی و بهینه سازی ساختار صحیح URL های پروژه برای موتورهای جستجو
• Indexability و Crawlability: فراهم سازی قابلیت خزش و نمایه سازی صفحات پروژه بر اساس استانداردهای موتورهای جستجو

میزان استانداردی وب سایت ها و پرتال ها بر اساس معیارهای فوق از مراجع ارزیابی قابل استعلام هستند. مراجع مورد تایید گروه ویرانیک PageSpeed Insights گوگل، woorank و GTmetrix هستند. در این بخش لازم است حداقل امتیازی که باید پروژه از مراجع سئو دریافت کند را به ازای هر مرجع مشخص نمایید.

خروجی: لطفا حداقل امتیاز مد نظر خود برای پروژه را مطابق راهنمایی های این بخش در شرح خدمات مشخص نمایید.