تیمی را در نظر بگیرید که مشاهدات را در یک محل ثبت می‌کند، در جایی دیگر دربارهٔ آن‌ها گفتگو می‌کند و بعد گزارش مشتری را می‌سازد. نخستین گردش کار نرم‌افزاری مفید، این مراحل را به هم متصل می‌کند. سؤال طراحی فقط محل ثبت یادداشت نیست؛ باید مشخص باشد کدام یادداشت بازبینی شده و کدام اطلاعات به گزارش رسیده است.
وضعیت‌های سابقه را صریح تعریف کنید
در نمونهٔ تحت وب، کاربر تجهیز فرضی را انتخاب می‌کند، موارد چک‌لیست را علامت می‌زند، مشاهده را می‌نویسد و اولویت پیگیری را تعیین می‌کند. ثبت، یک نسخه برای بازبینی می‌سازد. پس از تأیید همان نسخه، گزارش نمونه در دسترس قرار می‌گیرد.
- پیش‌نویس
- ثبت برای بازبینی
- تأیید بازبینی
- گزارش آماده
ویرایش باید بازبینی قبلی را نامعتبر کند
فرض کنید پس از بازبینی، مشاهده را تغییر دهید. اگر تأیید قبلی فعال بماند، گزارش بعدی ممکن است بازبینی‌شده به نظر برسد، در حالی که محتوای جدید بررسی نشده است. در این نمونه، ویرایش ورودی، نسخهٔ ثبت‌شده را پاک می‌کند و گزارش را پنهان می‌سازد. کاربر باید دوباره ثبت و بازبینی کند. برداشتن تأیید بازبینی هم دسترسی به گزارش را حذف می‌کند.
در سامانهٔ عملیاتی، قواعد انتخاب‌شده باید علاوه بر رابط، در سرور هم اجرا شوند. نسخه‌های سابقه، هویت بازبین، مجوزها و تاریخچهٔ نگهداری‌شده به طراحی مستقل نیاز دارند. یک چک‌باکس در تب مرورگر این پاسخ‌گویی را فراهم نمی‌کند.
قاعده را خودتان آزمایش کنید
- دموی گردش کار بازرسی را باز کنید. ↗ یک تجهیز فرضی انتخاب کنید، موردی از چک‌لیست را علامت بزنید و مشاهده‌ای کوتاه بنویسید.
- سابقه را ثبت کنید. تجهیز، مشاهده، تعداد موارد چک‌لیست و اولویت را در بخش بازبینی بررسی کنید.
- بازبینی را تأیید و تکمیل کنید. گزارش متنی را دانلود و با سابقهٔ بازبینی‌شده مقایسه کنید.
- مشاهده را تغییر دهید. گزارش ناپدید می‌شود و ثبت و بازبینی تازه لازم است. فایل قبلاً دانلودشده روی دستگاه شما باقی می‌ماند؛ نمونه نمی‌تواند آن را پس بگیرد.
نخستین نسخهٔ کاربردی را حول تحویل واقعی تعریف کنید
از یک گزارش واقعی و نمایندهٔ کار شروع کنید و ورودی‌های آن را مشخص کنید. توافق کنید چه کسی مشاهده ثبت می‌کند، چه کسی بازبینی می‌کند، پیش از ثبت چه اطلاعاتی الزامی است و درخواست اصلاح چه اثری دارد. مشخص کنید آیا سابقهٔ تکمیل‌شده دوباره باز می‌شود و گزارش قدیمی چگونه شناسایی خواهد شد.
سپس محدودیت‌های محیط کار را روشن کنید: اتصال ناپایدار، عکس و پیوست، شناسهٔ تجهیز، قالب خروجی، نگهداری سوابق و دسترسی. این تصمیم‌ها ذخیره‌سازی، همگام‌سازی و اتصال به سامانه‌های دیگر را شکل می‌دهند. معیار پذیرش می‌تواند مشخص باشد: تغییر مشاهدهٔ بازبینی‌شده نباید اجازه دهد گزارش جدید، تأیید قبلی را با خود حمل کند.
این مثال داده‌های فرضی دارد و مستقل از GridSight است. رفتار رابط را نشان می‌دهد، نه تشخیص فنی یا تأیید واقعی بازرسی. حساب کاربری، ذخیره‌سازی پایدار یا بازبینی سمت سرور ندارد. با بارگذاری مجدد یا بستن تب، وضعیت آن پاک می‌شود.