پرش به محتویات

استاندارد تدوین هدف، محدوده و سناریوهای ماژول

۱. هدف راهنما

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

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

۲. جایگاه در فرایند طراحی ماژول

ترتیب استاندارد:

  1. هدف، محدوده و سناریوها
  2. User Flow
  3. Workflow و وضعیت‌ها
  4. دسترسی‌ها
  5. اعلان‌ها
  6. خطاها و موارد خاص
  7. Wireframe

تا زمانی که هدف، مرزها و سناریوهای اصلی تأیید نشده‌اند، User Flow نباید نهایی شود.

۳. مرزبندی با خروجی‌های دیگر

Domain Model

موجودیت‌ها، رابطه‌ها و مفاهیم پایدار مشترک محصول را تعریف می‌کند.

هدف، محدوده و سناریوها

رفتار مورد انتظار یک ماژول، مرز مسئولیت آن، قواعد کسب‌وکار و موقعیت‌های استفاده را تعریف می‌کند.

User Flow

مسیر یک Actor برای رسیدن به یک هدف مشخص را نشان می‌دهد.

Workflow

چرخه عمر Entity، وضعیت‌ها، Transitionها و Actor مالک تغییر را تعریف می‌کند.

Wireframe

ساختار صفحه، اجزای رابط و حالت‌های بصری را نمایش می‌دهد.

در سند هدف و سناریو نباید درباره محل دکمه، چیدمان صفحه، رنگ، Component یا جزئیات پیاده‌سازی تصمیم‌گیری شود.

۴. ورودی‌های لازم

پیش از شروع، این منابع بررسی می‌شوند:

  • فرضیات محصول
  • Domain Modelهای مرتبط
  • نقش‌ها و قواعد دسترسی مشترک
  • تصمیم‌های قبلی پروژه
  • ماژول‌های وابسته
  • محدودیت‌های تجاری، حقوقی و عملیاتی
  • صورت‌جلسه‌ها یا تصمیم‌های ثبت‌شده

اگر منبعی ناقص یا متناقض باشد، ابهام آن ثبت می‌شود و نباید با فرض پنهان جایگزین شود.

۵. اصول ثابت

  1. هر تصمیم فقط یک منبع حقیقت دارد.
  2. تصمیم قطعی از فرض و پیشنهاد جدا نوشته می‌شود.
  3. موارد خارج از محدوده حذف نمی‌شوند؛ صریح ثبت می‌شوند.
  4. هر Scenario به حداقل یک هدف ماژول متصل است.
  5. هر Business Rule شناسه پایدار دارد.
  6. Scenarioها یکی‌یکی Review و تأیید می‌شوند.
  7. فهرست Scenario به معنی تکمیل جزئیات آن‌ها نیست.
  8. اصطلاحات با Domain Model یکسان نگه داشته می‌شوند.
  9. رفتار محصول نوشته می‌شود، نه راه‌حل فنی.
  10. تصمیم پرریسک حقوقی یا مالی با Warning مشخص می‌شود.

۶. ساختار استاندارد سند

سند هر ماژول باید بخش‌های زیر را به همین ترتیب داشته باشد:

  1. وضعیت سند
  2. خلاصه تصمیم
  3. مشخصات سند
  4. هدف ماژول
  5. نتیجه موفق
  6. داخل محدوده
  7. خارج از محدوده
  8. قواعد مرزبندی
  9. Business Rules
  10. فهرست و وضعیت Scenarioها
  11. Scenarioهای تفصیلی
  12. Audit و گزارش‌پذیری
  13. ریسک‌ها و نیازهای بررسی
  14. سؤال‌ها و تصمیم‌های باز
  15. معیار آمادگی برای User Flow

۷. وضعیت سند

وضعیت کلی سند یکی از این مقادیر است:

  • Draft
  • In Review
  • Approved
  • Needs Revision

وضعیت کلی نباید جای وضعیت مستقل Scenarioها را بگیرد.

نمونه:

> [!info] وضعیت سند
> هدف و محدوده تأیید شده‌اند. Scenarioها به‌ترتیب در حال Review هستند.

۸. خلاصه تصمیم

خلاصه تصمیم حداکثر در چند پاراگراف، مهم‌ترین رفتار و مرز ماژول را بیان می‌کند.

خلاصه باید:

  • تصمیم قطعی را بیان کند؛
  • از جزئیات اجرایی پرهیز کند؛
  • تناقض یا استثنای مهم را پنهان نکند؛
  • با متن تفصیلی سند سازگار باشد.

۹. مشخصات سند

فیلد مقدار
ماژول نام ماژول
وضعیت Draft / In Review / Approved
مالک محتوا تیم یا نقش مالک
مرحله فعلی هدف، محدوده و سناریوها
آخرین بازبینی YYYY-MM-DD

۱۰. هدف ماژول

هدف باید نتیجه‌ای را بیان کند که برای Actor یا کسب‌وکار ایجاد می‌شود، نه فهرست صفحه‌ها و Featureها.

الگوی پیشنهادی

هدف این ماژول آن است که [Actor] بتواند [Outcome] را با [محدودیت یا اصل مهم] انجام دهد.

معیار هدف مناسب

  • Actor یا مخاطب روشن است.
  • مسئله یا Outcome مشخص است.
  • قابل اتصال به نتیجه موفق است.
  • درباره UI تصمیم‌گیری نمی‌کند.
  • بیش از محدوده ماژول وعده نمی‌دهد.

۱۱. نتیجه موفق

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

برای هر Outcome مشخص شود:

  • چه Entity یا رابطه‌ای ایجاد یا تغییر کرده است؟
  • چه Actorی به نتیجه رسیده است؟
  • چه دسترسی یا Scopeای فعال شده است؟
  • چه چیزی هنوز ایجاد یا فعال نشده است؟
  • چه رویدادی باید قابل Audit باشد؟

در ماژول دارای چند Outcome، نتیجه‌ها جدا شوند؛ برای نمونه:

  • نتیجه موفق راه‌اندازی
  • نتیجه موفق عضویت
  • نتیجه موفق پرداخت

۱۲. داخل محدوده

داخل محدوده قابلیت‌هایی هستند که این ماژول مسئول تصمیم‌گیری یا اجرای رفتار آن‌ها است.

برای خوانایی می‌توان محدوده را بر اساس نوع مسئولیت گروه‌بندی کرد:

  • رفتار کاربر
  • رفتار سیستمی
  • عملیات تجاری
  • مدیریت و پشتیبانی
  • داده و Audit

هر مورد باید با فعل روشن نوشته شود.

۱۳. خارج از محدوده

موارد نزدیک به موضوع که در این ماژول طراحی یا اجرا نمی‌شوند، صریح ثبت می‌شوند.

برای هر مورد خارج از محدوده، در صورت امکان مالک یا مقصد آن مشخص شود:

محاسبه تفصیلی شارژ در این ماژول انجام نمی‌شود و به ماژول مالی تعلق دارد.

خارج از محدوده نباید به معنی «بی‌اهمیت» یا «حذف‌شده از محصول» تلقی شود.

۱۴. قواعد مرزبندی

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

نمونه موضوع‌ها:

  • چه چیزی خودکار انجام می‌شود؟
  • چه چیزی به تأیید نیاز دارد؟
  • حداقل یا حداکثر مجاز چیست؟
  • کدام Entity مستقل است؟
  • چه اطلاعاتی در این مرحله دریافت نمی‌شود؟
  • کدام وضعیت باعث شروع Scenario بعدی می‌شود؟
  • چه چیزی نباید Permission ایجاد کند؟

۱۵. Business Rules

Business Rule باید دارای شرط، اقدام سیستم و نتیجه باشد.

شناسه شرط اقدام سیستم نتیجه
BR-[MODULE]-01 شرط قابل ارزیابی رفتار دقیق سیستم وضعیت یا خروجی

قواعد شناسه‌گذاری

  • شناسه پس از انتشار تغییر نمی‌کند.
  • Rule حذف‌شده با شماره دیگری جایگزین نمی‌شود.
  • Ruleهای مرتبط می‌توانند پسوند داشته باشند:
  • BR-SET-02A
  • BR-SET-02B
  • یک Rule فقط یک تصمیم اصلی را پوشش می‌دهد.

Rule نامناسب

سیستم اطلاعات را بررسی می‌کند.

Rule مناسب

اگر مجموع واحدها کمتر از حداقل مجاز باشد، ادامه خرید متوقف و دلیل آن نمایش داده می‌شود.

۱۶. فهرست و وضعیت Scenarioها

ابتدا فهرست Scenarioها استخراج و وضعیت هرکدام جدا ثبت می‌شود.

شناسه عنوان Actor اصلی وضعیت
[MOD]-01 عنوان Scenario Actor Draft
[MOD]-02 عنوان Scenario Actor Not Started

وضعیت Scenario:

  • Not Started
  • Draft
  • In Review
  • Approved
  • Needs Revision

Warning

وجود نام Scenario در فهرست به معنی بررسی یا تأیید آن نیست.

۱۷. واحد استاندارد Scenario

هر Scenario باید:

  • یک هدف اصلی داشته باشد؛
  • نقطه شروع مشخص داشته باشد؛
  • پیش‌شرط‌ها را از اولین Action جدا کند؛
  • مسیر اصلی کامل داشته باشد؛
  • مسیرهای جایگزین را پوشش دهد؛
  • خطا و Recovery را مشخص کند؛
  • نتیجه نهایی قابل مشاهده داشته باشد.

اگر هدف یا Actor اصلی به‌طور معنادار عوض شود، Scenario مستقل بررسی می‌شود.

۱۸. قالب تفصیلی Scenario

## سناریوی `[ID]` — [عنوان]

### وضعیت

- وضعیت:
- آخرین Review:

### هدف

- ...

### بازیگران

- Actor اصلی:
- Actorهای فرعی:

### نقطه شروع

- ...

### پیش‌شرط‌ها

- ...

### مسیر اصلی

1. Actor ...
2. سامانه ...
3. ...

### قواعد اختصاصی

- ...

### مسیرهای جایگزین

#### `[ALT-ID]` — [عنوان]

1. ...
2. ...

### خطاها و استثناها

| شناسه | خطا | رفتار سیستم | بازیابی |
| --- | --- | --- | --- |
| `[ERR-ID]` | ... | ... | ... |

### نتیجه نهایی

- ...

### تصمیم‌های باز

- ...

۱۹. مسیر اصلی

مسیر اصلی رایج‌ترین مسیر معتبر برای رسیدن به Outcome است.

قواعد نگارش:

  • هر گام فقط یک Action اصلی داشته باشد.
  • Actor یا سامانه انجام‌دهنده روشن باشد.
  • نتیجه Action مشخص باشد.
  • از نام صفحه و دکمه فقط در صورت وجود الزام محصولی استفاده شود.
  • پیاده‌سازی فنی مانند API، Queue یا Database وارد Scenario نشود.

۲۰. مسیرهای جایگزین

مسیر جایگزین خطا نیست. این مسیر یک انتخاب یا وضعیت معتبر دیگر است که می‌تواند به Outcome قابل قبول برسد.

الگوی شناسه:

ALT-[SCENARIO-ID][SUFFIX]

نمونه:

ALT-SET-01A

۲۱. خطاها و Recovery

برای هر خطا باید چهار مورد روشن باشد:

  1. علت چیست؟
  2. سامانه چه رفتاری دارد؟
  3. چه داده‌ای حفظ یا Rollback می‌شود؟
  4. کاربر چگونه ادامه می‌دهد؟

الگوی شناسه:

ERR-[MODULE]-[NUMBER]

خطای بدون Recovery فقط زمانی قابل قبول است که پایان قطعی Scenario باشد.

۲۲. Audit و گزارش‌پذیری

رویدادهایی که بر پول، دسترسی، عضویت، مالکیت، قرارداد یا مسئولیت اثر دارند باید قابل Audit باشند.

حداقل مشخص شود:

  • چه Actionی انجام شده است؟
  • Actor چه کسی بوده است؟
  • چه زمانی انجام شده است؟
  • وضعیت قبل و بعد چه بوده است؟
  • دلیل یا مدرک، در صورت نیاز، چیست؟

نمایش گزارش نهایی می‌تواند خارج از محدوده ماژول باشد، اما تولید Event و Audit نباید فراموش شود.

۲۳. ریسک و نیاز به بررسی

موضوع‌های حقوقی، مالی، امنیتی یا عملیاتی با Callout مشخص شوند:

> [!warning] نیازمند بررسی حقوقی
> این تصمیم محصولی پیش از اجرا باید با قوانین و اسناد مرتبط بررسی شود.

Warning جایگزین تصمیم نیست؛ مشخص می‌کند تصمیم فعلی نیازمند Validation تخصصی است.

۲۴. سؤال‌ها و تصمیم‌های باز

تصمیم باز در متن قطعی پنهان نمی‌شود.

شناسه موضوع وضعیت مالک تصمیم
OPEN-[MODULE]-01 موضوع Open Product

اگر سؤال مانع ادامه نیست، Scenario می‌تواند با فرض موقت ادامه یابد؛ فرض باید صریح ثبت شود.

اگر پاسخ، هدف، Actor، قیمت، دسترسی یا مسئولیت را تغییر می‌دهد، سؤال Blocker محسوب می‌شود.

۲۵. Traceability

هر Scenario باید به این موارد قابل اتصال باشد:

  • هدف ماژول
  • Business Ruleهای مرتبط
  • Domain Modelهای مرجع
  • User Flow بعدی
  • Workflow یا State Machine بعدی

ماتریس پیشنهادی:

Scenario هدف Business Rules Domain Reference وضعیت
[ID] [GOAL] [BR-ID] [Document] Approved

۲۶. کنترل تناقض

پیش از تأیید سند بررسی شود:

  • آیا نتیجه موفق با داخل محدوده سازگار است؟
  • آیا Scenario خارج از محدوده ایجاد شده است؟
  • آیا Rule با Domain Model تناقض دارد؟
  • آیا یک مفهوم با چند نام استفاده شده است؟
  • آیا ثبت رکورد با ایجاد Account یا Permission اشتباه شده است؟
  • آیا وضعیت داخلی Entity به‌جای Action نوشته شده است؟
  • آیا Scenario تأییدنشده قطعی نمایش داده شده است؟
  • آیا تصمیم جدید، سند مرجع دیگری را نیازمند اصلاح می‌کند؟

۲۷. معیار آمادگی برای User Flow

مرحله هدف، محدوده و سناریوها زمانی آماده ورود به User Flow است که:

  • هدف ماژول تأیید شده است.
  • نتیجه موفق قابل سنجش است.
  • داخل و خارج محدوده روشن‌اند.
  • Actorهای اصلی مشخص‌اند.
  • Business Ruleهای مؤثر شناسه دارند.
  • تمام Scenarioهای موردنیاز فهرست شده‌اند.
  • Scenarioهای داخل Release هدف به‌صورت تفصیلی Review شده‌اند.
  • مسیر اصلی، جایگزین، خطا و Recovery پوشش داده شده‌اند.
  • تصمیم‌های باز از تصمیم‌های قطعی جدا هستند.
  • تناقض مؤثر با Domain Model باقی نمانده است.
  • تصمیم‌های حقوقی، مالی و امنیتی علامت‌گذاری شده‌اند.
  • وضعیت Scenarioها در جدول به‌روز است.

اگر فقط فهرست Scenarioها کامل شده ولی جزئیات آن‌ها Review نشده است، مرحله هنوز آماده User Flow نیست.

۲۸. قواعد نگارشی

  • متن فارسی، رسمی و مستقیم باشد.
  • جمله با Actor و فعل روشن نوشته شود.
  • برای اصطلاحات پایدار فنی از نام یکسان استفاده شود.
  • دقیقاً یک H1 در فایل وجود داشته باشد.
  • Headingها از H2 به بعد بدون پرش استفاده شوند.
  • جدول فقط برای مقایسه یا داده ساختاری استفاده شود.
  • پاراگراف طولانی به Rule یا List قابل بررسی تبدیل شود.
  • از عبارت‌های مبهم مانند «در صورت نیاز» بدون تعریف شرط پرهیز شود.
  • از واژه‌های «احتمالاً»، «شاید» و «فعلاً» در تصمیم قطعی استفاده نشود؛ این موارد در فرض یا سؤال باز ثبت شوند.

۲۹. روش اجرای استاندارد برای هر ماژول

  1. منابع مرجع خوانده می‌شوند.
  2. هدف و Outcome پیشنهادی نوشته می‌شوند.
  3. داخل و خارج محدوده Review می‌شوند.
  4. قواعد مرزبندی استخراج می‌شوند.
  5. Business Ruleها شناسه‌گذاری می‌شوند.
  6. فهرست Scenarioها بر اساس Actor و Goal ساخته می‌شود.
  7. Scenarioها به‌ترتیب اولویت یکی‌یکی بررسی می‌شوند.
  8. پس از هر Review، وضعیت همان Scenario به‌روزرسانی می‌شود.
  9. تصمیم‌های جدید با Domain Modelها تطبیق داده می‌شوند.
  10. پس از تأیید همه Scenarioهای Release، معیار آمادگی User Flow بررسی می‌شود.