Standardize analysis docs and add user story features (#25)

Align docs/analysis files on one structure: metadata header, unnumbered
"مقدمه", numbered sections, and a final "نکات و پرسش‌های باز" section.

- user-story.md: add "نیازمندی‌های مرتبط" (FR refs) to each US, number
  the sections, and update the last-updated date
- requirements-specification.md: define "گزارش‌دهنده" and align the
  closing section name
- activity.md: add metadata header and مقدمه, drop English actor labels,
  give each diagram an AD-NN id, and add a status line
- CONTRIBUTING.md: record the analysis docs standard as section ۷
- features/: Gherkin scenarios for US-01, US-05 and US-15
This commit is contained in:
2026-11-02 22:29:14 +03:30
committed by GitHub
parent 8b73b8abd6
commit 407596264f
7 changed files with 355 additions and 153 deletions
+32 -20
View File
@@ -1,23 +1,31 @@
# نمودارهای فعالیت
# نمودارهای فعالیت (Activity Diagrams) – سامانه مدیریت و گزارش خرابی دانشگاهی
**تهیه‌کننده:** ارشیا همتی‌زاده
**بازبین:** رضا آدوسی
**آخرین به‌روزرسانی:** ۱۴۰۵/۰۸/۱۱
---
## مقدمه
این سند جریان‌های کاری اصلی سامانه گزارش و مدیریت خرابی‌های دانشگاه را با استفاده از Mermaid نمایش می‌دهد.
> **نکته:** نمودارها بر اساس بازیگران و ۱۷ داستان کاربری شناسایی‌شده در مستندات تحلیل تهیه شده‌اند. جزئیاتی که در نیازمندی‌ها صریحاً مشخص نشده‌اند، به‌عنوان فرض یا پرسش باز علامت‌گذاری شده‌اند و نباید قانون قطعی سیستم تلقی شوند.
> **نکته:** نمودارها بر اساس بازیگران و ۱۷ داستان کاربر شناسایی‌شده در [user-story.md](user-story.md) تهیه شده‌اند. جزئیاتی که در [نیازمندی‌ها](requirements-specification.md) صریحاً مشخص نشده‌اند، به‌عنوان فرض یا پرسش باز علامت‌گذاری شده‌اند و نباید قانون قطعی سیستم تلقی شوند.
## ۱. بازیگران و مسئولیت‌ها
| بازیگر | مسئولیت‌ها |
|---|---|
| دانشجو (Student) | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
| استاد (Professor) | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
| کارمند تأسیسات (Facilities Staff) | بررسی و فیلتر گزارش‌ها، تعیین اولویت، تخصیص تعمیرکار، به‌روزرسانی وضعیت و مشاهده تاریخچه |
| تعمیرکار (Technician) | مشاهده مأموریت‌های تخصیص‌یافته، شروع تعمیر، ثبت نتیجه و درخواست اطلاعات تکمیلی |
| مدیر (Manager) | مشاهده داشبورد مدیریتی؛ سطح دسترسی دقیق این نقش باید در نیازمندی‌ها مشخص شود |
| کاربر سیستم (System User) | عنوان عمومی کاربر احراز هویت‌شده در داستان‌های ورود و اعلان؛ لزوماً یک نقش انسانی مستقل نیست |
| دانشجو | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
| استاد | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
| کارمند تأسیسات | بررسی و فیلتر گزارش‌ها، تعیین اولویت، تخصیص تعمیرکار، به‌روزرسانی وضعیت و مشاهده تاریخچه |
| تعمیرکار | مشاهده مأموریت‌های تخصیص‌یافته، شروع تعمیر، ثبت نتیجه و درخواست اطلاعات تکمیلی |
| مدیر | مشاهده داشبورد مدیریتی؛ سطح دسترسی دقیق این نقش باید در نیازمندی‌ها مشخص شود |
| کاربر سیستم | عنوان عمومی کاربر احراز هویت‌شده در داستان‌های ورود و اعلان؛ لزوماً یک نقش انسانی مستقل نیست |
## ۲. نمودار فعالیت احراز هویت (Authentication Activity)
## ۲. نمودار فعالیت احراز هویت (AD-01)
**داستان کاربری مرتبط:** US-15 — ورود به سیستم (Log in).
**داستان کاربر مرتبط:** US-15 — ورود به سیستم.
این نمودار فرایند عمومی ورود کاربر را نشان می‌دهد. روش دقیق احراز هویت، بازیابی رمز عبور و سیاست قفل حساب در این بخش مشخص نشده‌اند.
@@ -35,9 +43,9 @@ flowchart TD
I --> J([پایان])
```
## ۳. نمودار فعالیت ثبت گزارش خرابی (Fault Reporting Activity)
## ۳. نمودار فعالیت ثبت گزارش خرابی (AD-02)
**داستان‌های کاربری مرتبط:**
**داستان‌های کاربر مرتبط:**
- US-01 — دانشجو گزارش خرابی ثبت می‌کند.
- US-02 — استاد گزارش خرابی ثبت می‌کند.
- US-03 — دانشجو یا استاد وضعیت گزارش را پیگیری می‌کند.
@@ -80,9 +88,9 @@ flowchart TD
**نکته مدل‌سازی:** حلقه اصلاح اطلاعات، اعتبارسنجی فرم را نمایش می‌دهد. باید مشخص شود آیا کاربر می‌تواند در هر زمان اطلاعات تکمیلی ارسال کند یا فقط پس از درخواست کارمند تأسیسات یا تعمیرکار مجاز به این کار است.
## ۴. نمودار فعالیت مدیریت گزارش‌ها (Report Management Activity)
## ۴. نمودار فعالیت مدیریت گزارش‌ها (AD-03)
**داستان‌های کاربری مرتبط:**
**داستان‌های کاربر مرتبط:**
- US-06 — مشاهده و فیلتر گزارش‌های باز.
- US-07 — تعیین اولویت گزارش.
- US-08 — تخصیص تعمیرکار.
@@ -131,9 +139,9 @@ flowchart TD
**نکته مدل‌سازی:** تصمیم «آیا گزارش آماده تخصیص است؟» یک مرحله پیشنهادی است. شرایط دقیق تخصیص تعمیرکار و نحوه بازگرداندن گزارش‌های ناقص به گزارش‌دهنده باید در نیازمندی‌ها مشخص شوند.
## ۵. نمودار فعالیت تعمیر خرابی (Repair Activity)
## ۵. نمودار فعالیت تعمیر خرابی (AD-04)
**داستان‌های کاربری مرتبط:**
**داستان‌های کاربر مرتبط:**
- US-11 — تعمیرکار کارهای تخصیص‌یافته را مشاهده می‌کند.
- US-12 — تعمیرکار تعمیر را آغاز می‌کند.
- US-13 — تعمیرکار نتیجه تعمیر را ثبت می‌کند.
@@ -178,9 +186,9 @@ flowchart TD
**نکته مدل‌سازی:** در این نمودار، درخواست اطلاعات تکمیلی باعث توقف موقت تعمیر می‌شود. باید مشخص شود چه کسی اطلاعات را ارائه می‌کند، پس از دریافت اطلاعات چگونه به تعمیرکار اطلاع داده می‌شود و آیا هنگام انتظار وضعیت گزارش تغییر می‌کند یا خیر.
## ۶. نمودار فعالیت تأیید تعمیر (Repair Verification Activity)
## ۶. نمودار فعالیت تأیید تعمیر (AD-05)
**داستان کاربری مرتبط:** US-05 — دانشجو یا استاد تکمیل تعمیر را تأیید یا رد می‌کند.
**داستان کاربر مرتبط:** US-05 — دانشجو یا استاد تکمیل تعمیر را تأیید یا رد می‌کند.
گزارش‌دهنده نتیجه ثبت‌شده تعمیر را بررسی می‌کند و مشخص می‌کند که آیا خرابی برطرف شده است یا خیر.
@@ -213,7 +221,7 @@ flowchart TD
**پرسش باز:** نیازمندی‌ها باید مشخص کنند پس از رد نتیجه تعمیر چه اتفاقی می‌افتد: آیا گزارش به کارمند تأسیسات بازمی‌گردد، دوباره به همان تعمیرکار تخصیص داده می‌شود یا فرایند دیگری اجرا می‌شود؟ این نمودار هیچ‌یک از این سیاست‌ها را به‌عنوان تصمیم قطعی انتخاب نمی‌کند.
## ۷. نمودار کلی چرخه عمر گزارش خرابی (Overall Fault Lifecycle)
## ۷. نمودار کلی چرخه عمر گزارش خرابی (AD-06)
این نمودار نمایی کلی از فرایند اصلی سیستم ارائه می‌دهد و مراحل ثبت گزارش، مدیریت، تعمیر و تأیید را به یکدیگر متصل می‌کند.
@@ -249,7 +257,7 @@ flowchart TD
**نکته مدل‌سازی:** بازگشت گزارش ردشده به مرحله بررسی کارمند تأسیسات، یک مسیر پیشنهادی برای پیگیری مجدد است و هنوز سیاست قطعی تخصیص مجدد محسوب نمی‌شود. این مسیر باید با اعضای تیم پروژه بررسی و تأیید شود.
## ۸. پرسش‌ها و ابهام‌های نیازمندی‌ها
## ۸. نکات و پرسش‌های باز
موارد زیر باید پیش از نهایی‌شدن نمودارها با اعضای تیم پروژه مشخص شوند:
@@ -263,3 +271,7 @@ flowchart TD
8. **اعلان‌ها:** کدام رویدادها باعث ارسال اعلان می‌شوند، دریافت‌کنندگان چه کسانی هستند و اعلان‌ها از چه کانالی ارسال می‌شوند؟
9. **دسترسی مدیر:** آیا دسترسی مدیر فقط به مشاهده داشبورد محدود است یا این نقش امکان مدیریت گزارش‌ها را نیز دارد؟
10. **احراز هویت:** آیا قوانین ورود یا کنترل دسترسی برای نقش‌های مختلف متفاوت است؟
---
**وضعیت سند:** نسخه اولیه (Draft) – آماده بازبینی
+3 -2
View File
@@ -28,6 +28,7 @@
- **تعمیرکار:** مشاهدهٔ درخواست‌های تخصیص‌یافته، انجام تعمیرات و ثبت نتیجهٔ اقدامات.
- **مدیر:** نظارت بر عملکرد کلی سامانه و مشاهدهٔ اطلاعات و گزارش‌های مدیریتی.
- **کاربر سیستم:** عنوان عمومی برای اشاره به کاربران دارای حساب کاربری و دسترسی به سامانه.
- **گزارش‌دهنده:** عنوان مشترک دانشجو و استاد در فرایند ثبت و پیگیری گزارش خرابی.
## ۳. نیازمندی‌های کارکردی (Functional Requirements)
@@ -89,14 +90,14 @@
- **NFR-06 — قابلیت نگهداری:** ساختار سامانه باید امکان اصلاح، نگهداری و افزودن قابلیت‌های جدید را در آینده فراهم کند.
## ۵. نکات و کارهای باقی‌مانده
## ۵. نکات و پرسش‌های باز
- این نیازمندی‌ها نسخهٔ اولیه هستند و ممکن است در مراحل بعدی تحلیل و بازبینی تغییر کنند یا نیازمندی‌های جدیدی به آن‌ها اضافه شود.
- محدودهٔ دقیق فضاهای تحت پوشش سامانه، از جمله خوابگاه‌ها و فضاهای اداری، هنوز مشخص نشده است.
- معیارهای دقیق اولویت‌بندی خرابی‌ها و نحوهٔ تشخیص درخواست‌های فوری باید تعیین شوند.
- روش اطلاع‌رسانی به کاربران، مانند اعلان داخل سامانه، پیامک یا ایمیل، هنوز مشخص نشده است.
- جزئیات سطح دسترسی هر نقش و شرایط بسته‌شدن نهایی درخواست‌ها باید در مراحل بعدی مشخص شوند.
- نیازمندی‌های تعریف‌شده باید با داستان‌های کاربر (User Stories) و سایر مستندات پروژه تطبیق داده شوند.
- هر نیازمندی باید حداقل با یک داستان کاربر (User Story) تطبیق داده شود. ارجاع‌ها در فیلد «نیازمندی‌های مرتبط» همان سند [user-story.md](user-story.md) ثبت شده‌اند.
---
+167 -131
View File
@@ -1,131 +1,167 @@
# داستان‌های کاربر (User Stories) – سامانه مدیریت و گزارش خرابی دانشگاهی
**تهیه‌کننده:** امیرحسن عارف اصل
**بازبین:** ارشیا همتی‌زاده
**آخرین به‌روزرسانی:** ۱۴۰۴/۰۸/۰۴
---
## مقدمه
در این سند، نیازمندی‌های اصلی سامانه به صورت **داستان کاربر (User Story)** نوشته شده‌اند.
هر داستان کاربر از دیدگاه یک نقش مشخص بیان می‌شود و هدف آن را نیز مشخص می‌کند.
قالب استاندارد:
> به عنوان یک **<نقش>**
> می‌خواهم **<هدف>**
> تا بتوانم **<مزیت / نتیجه>**
---
## داستان‌های کاربر مرتبط با گزارش‌دهنده (دانشجو / استاد)
### US-01
به عنوان یک **دانشجو**
می‌خواهم **خرابی مشاهده‌شده را به همراه مکان و توضیحات ثبت کنم**
تا بتوانم **مشکل را سریع به بخش تأسیسات اطلاع دهم و پیگیری کنم**.
### US-02
به عنوان یک **استاد**
می‌خواهم **خرابی کلاس یا آزمایشگاه را ثبت کنم**
تا بتوانم **بدون اتلاف وقت، مشکل را به مسئولان مربوطه اعلام کنم**.
### US-03
به عنوان یک **دانشجو یا استاد**
می‌خواهم **وضعیت گزارش‌هایی که خودم ثبت کرده‌ام را مشاهده کنم**
تا بتوانم **از پیشرفت رسیدگی به گزارشم مطلع شوم**.
### US-04
به عنوان یک **دانشجو یا استاد**
می‌خواهم **تصویر یا توضیح بیشتری به گزارش قبلی اضافه کنم**
تا بتوانم **اطلاعات کامل‌تری در اختیار تعمیرکار قرار دهم**.
### US-05
به عنوان یک **دانشجو یا استاد**
می‌خواهم **پس از اعلام رفع خرابی، آن را تأیید یا رد کنم**
تا بتوانم **از بسته شدن صحیح گزارش مطمئن شوم**.
---
## داستان‌های کاربر مرتبط با کارمند تأسیسات
### US-06
به عنوان یک **کارمند تأسیسات**
می‌خواهم **لیست تمام گزارش‌های باز را مشاهده و فیلتر کنم**
تا بتوانم **گزارش‌های مهم و فوری را سریع‌تر پیدا کنم**.
### US-07
به عنوان یک **کارمند تأسیسات**
می‌خواهم **اولویت هر گزارش را تعیین کنم**
تا بتوانم **تعمیرات را بر اساس اهمیت و فوریت مدیریت کنم**.
### US-08
به عنوان یک **کارمند تأسیسات**
می‌خواهم **یک گزارش را به تعمیرکار مناسب تخصیص دهم**
تا بتوانم **کار را به فرد درست ارجاع دهم و پیگیری کنم**.
### US-09
به عنوان یک **کارمند تأسیسات**
می‌خواهم **وضعیت گزارش را تغییر دهم**
تا بتوانم **وضعیت واقعی رسیدگی به هر گزارش را در سیستم منعکس کنم**.
### US-10
به عنوان یک **کارمند تأسیسات**
می‌خواهم **تاریخچه کامل اقدامات انجام‌شده روی یک گزارش را ببینم**
تا بتوانم **روند رسیدگی را بررسی و در صورت نیاز پیگیری کنم**.
---
## داستان‌های کاربر مرتبط با تعمیرکار
### US-11
به عنوان یک **تعمیرکار**
می‌خواهم **لیست کارهای تخصیص‌یافته به خودم را ببینم**
تا بتوانم **بدانم چه کارهایی در انتظار انجام است**.
### US-12
به عنوان یک **تعمیرکار**
می‌خواهم **شروع کار روی یک گزارش را اعلام کنم**
تا بتوانم **وضعیت گزارش را به «در حال تعمیر» تغییر دهم**.
### US-13
به عنوان یک **تعمیرکار**
می‌خواهم **نتیجه تعمیر را همراه با توضیحات ثبت کنم**
تا بتوانم **گزارش را به مرحله بعدی (تأیید یا پیگیری) برسانم**.
### US-14
به عنوان یک **تعمیرکار**
می‌خواهم **در صورت نیاز، اطلاعات بیشتری از گزارش‌دهنده درخواست کنم**
تا بتوانم **تعمیر را با اطلاعات کامل‌تری انجام دهم**.
---
## داستان‌های کاربر مشترک / سیستمی
### US-15
به عنوان یک **کاربر سیستم**
می‌خواهم **با نام کاربری و رمز عبور وارد سامانه شوم**
تا بتوانم **به امکانات مربوط به نقش خودم دسترسی داشته باشم**.
### US-16
به عنوان یک **کاربر سیستم**
می‌خواهم **هنگام تغییر وضعیت گزارش مرتبط با خودم، اعلان دریافت کنم**
تا بتوانم **از آخرین وضعیت مطلع شوم**.
### US-17
به عنوان یک **کارمند تأسیسات یا مدیر**
می‌خواهم **داشبورد خلاصه‌ای از تعداد گزارش‌های باز و فوری ببینم**
تا بتوانم **وضعیت کلی خرابی‌ها را سریع ارزیابی کنم**.
---
## نکات و کارهای باقی‌مانده
- این داستان‌ها نسخه اولیه هستند و ممکن است در بازبینی تغییر کنند یا داستان‌های جدید اضافه شود.
- جزئیات پذیرش (Acceptance Criteria) برای داستان‌های مهم‌تر در مراحل بعدی نوشته خواهد شد.
- ابهام دامنه (آیا خوابگاه‌ها و فضاهای اداری هم شامل می‌شوند؟) هنوز وجود دارد و روی برخی داستان‌ها تأثیر می‌گذارد.
---
**وضعیت سند:** نسخه اولیه (Draft) – آماده بازبینی
# داستان‌های کاربر (User Stories) – سامانه مدیریت و گزارش خرابی دانشگاهی
**تهیه‌کننده:** امیرحسن عارف اصل
**بازبین:** ارشیا همتی‌زاده
**آخرین به‌روزرسانی:** ۱۴۰۵/۰۸/۱۱
---
## مقدمه
در این سند، نیازمندی‌های اصلی سامانه به صورت **داستان کاربر (User Story)** نوشته شده‌اند.
هر داستان کاربر از دیدگاه یک نقش مشخص بیان می‌شود و هدف آن را نیز مشخص می‌کند.
معیارهای پذیرش (Acceptance Criteria) هر داستان در Issue متناظر آن در GitHub ثبت شده‌اند.
قالب استاندارد:
> به عنوان یک **<نقش>**
> می‌خواهم **<هدف>**
> تا بتوانم **<مزیت / نتیجه>**
---
## ۱. داستان‌های کاربر مرتبط با گزارش‌دهنده (دانشجو / استاد)
### US-01
به عنوان یک **دانشجو**
می‌خواهم **خرابی مشاهده‌شده را به همراه مکان و توضیحات ثبت کنم**
تا بتوانم **مشکل را سریع به بخش تأسیسات اطلاع دهم و پیگیری کنم**.
**نیازمندی‌های مرتبط:** FR-03، FR-05
### US-02
به عنوان یک **استاد**
می‌خواهم **خرابی کلاس یا آزمایشگاه را ثبت کنم**
تا بتوانم **بدون اتلاف وقت، مشکل را به مسئولان مربوطه اعلام کنم**.
**نیازمندی‌های مرتبط:** FR-03
### US-03
به عنوان یک **دانشجو یا استاد**
می‌خواهم **وضعیت گزارش‌هایی که خودم ثبت کرده‌ام را مشاهده کنم**
تا بتوانم **از پیشرفت رسیدگی به گزارشم مطلع شوم**.
**نیازمندی‌های مرتبط:** FR-05، FR-16
### US-04
به عنوان یک **دانشجو یا استاد**
می‌خواهم **تصویر یا توضیح بیشتری به گزارش قبلی اضافه کنم**
تا بتوانم **اطلاعات کامل‌تری در اختیار تعمیرکار قرار دهم**.
**نیازمندی‌های مرتبط:** FR-04
### US-05
به عنوان یک **دانشجو یا استاد**
می‌خواهم **پس از اعلام رفع خرابی، آن را تأیید یا رد کنم**
تا بتوانم **از بسته شدن صحیح گزارش مطمئن شوم**.
**نیازمندی‌های مرتبط:** FR-14
---
## ۲. داستان‌های کاربر مرتبط با کارمند تأسیسات
### US-06
به عنوان یک **کارمند تأسیسات**
می‌خواهم **لیست تمام گزارش‌های باز را مشاهده و فیلتر کنم**
تا بتوانم **گزارش‌های مهم و فوری را سریع‌تر پیدا کنم**.
**نیازمندی‌های مرتبط:** FR-06، FR-08
### US-07
به عنوان یک **کارمند تأسیسات**
می‌خواهم **اولویت هر گزارش را تعیین کنم**
تا بتوانم **تعمیرات را بر اساس اهمیت و فوریت مدیریت کنم**.
**نیازمندی‌های مرتبط:** FR-07
### US-08
به عنوان یک **کارمند تأسیسات**
می‌خواهم **یک گزارش را به تعمیرکار مناسب تخصیص دهم**
تا بتوانم **کار را به فرد درست ارجاع دهم و پیگیری کنم**.
**نیازمندی‌های مرتبط:** FR-09
### US-09
به عنوان یک **کارمند تأسیسات**
می‌خواهم **وضعیت گزارش را تغییر دهم**
تا بتوانم **وضعیت واقعی رسیدگی به هر گزارش را در سیستم منعکس کنم**.
**نیازمندی‌های مرتبط:** FR-11
### US-10
به عنوان یک **کارمند تأسیسات**
می‌خواهم **تاریخچه کامل اقدامات انجام‌شده روی یک گزارش را ببینم**
تا بتوانم **روند رسیدگی را بررسی و در صورت نیاز پیگیری کنم**.
**نیازمندی‌های مرتبط:** FR-16
---
## ۳. داستان‌های کاربر مرتبط با تعمیرکار
### US-11
به عنوان یک **تعمیرکار**
می‌خواهم **لیست کارهای تخصیص‌یافته به خودم را ببینم**
تا بتوانم **بدانم چه کارهایی در انتظار انجام است**.
**نیازمندی‌های مرتبط:** FR-10
### US-12
به عنوان یک **تعمیرکار**
می‌خواهم **شروع کار روی یک گزارش را اعلام کنم**
تا بتوانم **وضعیت گزارش را به «در حال تعمیر» تغییر دهم**.
**نیازمندی‌های مرتبط:** FR-11
### US-13
به عنوان یک **تعمیرکار**
می‌خواهم **نتیجه تعمیر را همراه با توضیحات ثبت کنم**
تا بتوانم **گزارش را به مرحله بعدی (تأیید یا پیگیری) برسانم**.
**نیازمندی‌های مرتبط:** FR-12
### US-14
به عنوان یک **تعمیرکار**
می‌خواهم **در صورت نیاز، اطلاعات بیشتری از گزارش‌دهنده درخواست کنم**
تا بتوانم **تعمیر را با اطلاعات کامل‌تری انجام دهم**.
**نیازمندی‌های مرتبط:** FR-13
---
## ۴. داستان‌های کاربر مشترک / سیستمی
### US-15
به عنوان یک **کاربر سیستم**
می‌خواهم **با نام کاربری و رمز عبور وارد سامانه شوم**
تا بتوانم **به امکانات مربوط به نقش خودم دسترسی داشته باشم**.
**نیازمندی‌های مرتبط:** FR-01، FR-02
### US-16
به عنوان یک **کاربر سیستم**
می‌خواهم **هنگام تغییر وضعیت گزارش مرتبط با خودم، اعلان دریافت کنم**
تا بتوانم **از آخرین وضعیت مطلع شوم**.
**نیازمندی‌های مرتبط:** FR-15
### US-17
به عنوان یک **کارمند تأسیسات یا مدیر**
می‌خواهم **داشبورد خلاصه‌ای از تعداد گزارش‌های باز و فوری ببینم**
تا بتوانم **وضعیت کلی خرابی‌ها را سریع ارزیابی کنم**.
**نیازمندی‌های مرتبط:** FR-17
---
## ۵. نکات و پرسش‌های باز
- این داستان‌ها نسخه اولیه هستند و ممکن است در بازبینی تغییر کنند یا داستان‌های جدید اضافه شود.
- معیارهای پذیرش هر داستان در Issue متناظر آن در GitHub ثبت شده‌اند. در مواردی که نیازمندی‌ها هنوز مشخص نیستند، فرض‌های موقت در همان Issue علامت‌گذاری شده‌اند.
- ابهام دامنه (آیا خوابگاه‌ها و فضاهای اداری هم شامل می‌شوند؟) هنوز وجود دارد و روی برخی داستان‌ها تأثیر می‌گذارد.
- پرسش‌های باز دیگر (اولویت‌ها، وضعیت‌ها، اعلان‌ها و ...) در بخش «نکات و پرسش‌های باز» [نمودارهای فعالیت](activity.md) فهرست شده‌اند.
---
**وضعیت سند:** نسخه اولیه (Draft) – آماده بازبینی