از مدل عملیاتی شروع کنید
پیش از مقایسه صفحه‌ها یا قابلیت‌ها، مشخص کنید چه کسانی از پلتفرم استفاده می‌کنند و باید چه کارهایی انجام دهند. رابط کاربری کارگزاری، صرافی با دفتر سفارش اختصاصی، و داشبورد پرتفوی مسئولیت‌های متفاوتی دارند. بازارهای مدنظر، نقش‌های حساب کاربری، روش‌های تأمین موجودی و اتصال‌های معاملاتی را مکتوب کنید. از تأمین‌کننده بخواهید کنار هر نیازمندی مشخص کند که شامل محصول است، قابل پیکربندی است، به سرویس دیگری وابسته است یا نیاز به کار اختصاصی دارد. همین تفکیک ساده، مقایسه پیشنهادهای مختلف را بسیار آسان‌تر می‌کند.
مسیر کامل یک موجودی را دنبال کنید
یک واریز نمونه را انتخاب کنید و مسیر آن را از شناسایی، تأیید، دفترکل حساب، ثبت سفارش و درخواست برداشت دنبال کنید. بپرسید سیستم چطور موجودی قابل‌استفاده را از مبالغ رزروشده برای سفارش‌های باز جدا می‌کند. سپس همین تمرین را با یک سفارش لغوشده و یک callback با تأخیر تکرار کنید. هدف، به‌دست‌آوردن شواهدی از حسابداری سازگار است. یک کارت موجودی خوش‌ظاهر نمی‌تواند ثابت کند که رویدادهای تکراری، انجام‌های جزئی سفارش یا درخواست‌های قطع‌شده، رکوردهای زیربنایی را درست نگه می‌دارند.
مرزهای نگه‌داری دارایی را شفاف کنید
مشخص کنید کدام مؤلفه می‌تواند آدرس بسازد، به مواد امضای تراکنش دسترسی داشته باشد و انتقال‌ها را مجاز کند. نموداری بخواهید که اپلیکیشن، سرویس‌های کیف پول، ارائه‌دهندگان بلاکچین و کنترل‌های مدیریتی را نشان دهد. روشن کنید خریدار باید چه credentialهایی ارائه کند و این اطلاعات کجا ذخیره می‌شوند. اگر ارائه‌دهنده نگه‌داری دارایی خارجی در کار است، بدانید در صورت خارج‌ازدسترس‌شدن آن چه اتفاقی می‌افتد. فرض نکنید مالکیت سورس اپلیکیشن، خودبه‌خود یک سیستم کامل و مستقل برای نگه‌داری و عملیات دارایی در اختیار تیم شما می‌گذارد.
خرابی‌ها را نمایش دهید، نه فقط مسیر ایده‌آل را
یک دمو مفید شامل سفارش‌های ردشده، timeout ارائه‌دهنده، درخواست‌های تکراری و restart شدن worker در میانه یک کار است. از تیم بخواهید نشان دهد مشتری چه چیزی می‌بیند و اپراتور چه چیزهایی را می‌تواند بررسی کند. به‌دنبال تلاش مجدد محدود، وضعیت‌های شفاف و audit trailی باشید که تغییرات را توضیح می‌دهد. ادعاهای عملکردی باید همراه با شرح workload و محیط تست باشند. نمایش سریع روی داده نمونه، تضمین ظرفیت برای ترافیک مورد انتظار شما نیست.
تحویل واقعی را بررسی کنید
درباره محتوای repository، نسخه dependencyها، migrationهای دیتابیس، دستورالعمل نصب و مسئولیت‌های استقرار توافق کنید. بررسی کنید آیا تحویل شامل ابزارهای مدیریتی، workerهای پس‌زمینه و مؤلفه‌هایی هست که در دمو نمایش داده شده‌اند یا نه. بپرسید کدام دارایی‌ها یا سرویس‌ها به مجوز جداگانه نیاز دارند. از فردی ناآشنا با پروژه بخواهید راهنمای نصب را در یک محیط تمیز دنبال کند. وقتی توسعه‌دهنده اصلی دیگر مراحل را از حافظه خود کامل نمی‌کند، فرضیات پنهان خیلی زود آشکار می‌شوند.
یافته‌ها را به معیارهای پذیرش تبدیل کنید
بررسی را با یک سند پذیرش کوتاه و قابل آزمون به پایان برسانید. مسیرهایی را که باید کار کنند، رکوردهایی را که باید قابل تطبیق باشند و مستندات عملیاتی‌ای را که باید تحویل شوند مشخص کنید. موارد خارج از محدوده و هر بازبینی امنیتی مستقلی را که کسب‌وکار شما پیش از انتشار لازم دارد ثبت کنید. در کدمن، نقطه شروع مؤثر یک دموی دارای محدوده مشخص و گفت‌وگوی مکتوب درباره تحویل است. بسته سورس مناسب، بسته‌ای است که تیم شما بتواند آن را بفهمد، اداره کند و مسئولانه توسعه دهد.