mirror of
https://github.com/AmirAref/paya-university-fault-system.git
synced 2026-11-03 14:49:38 +00:00
Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Arshia
|
1bb03232f0 |
+1
-14
@@ -46,7 +46,7 @@ git commit -m "توضیح کوتاه کار انجام‌شده"
|
||||
```
|
||||
|
||||
مثال پیام کامیت خوب:
|
||||
- `"افزودن بخش بازیگران به user-story.md"`
|
||||
- `"افزودن بخش بازیگران به use-case.md"`
|
||||
- `"اصلاح توضیحات نیازمندی‌های عملکردی"`
|
||||
|
||||
---
|
||||
@@ -110,17 +110,4 @@ classDiagram
|
||||
|
||||
---
|
||||
|
||||
## ۷. استاندارد مستندات تحلیل (`docs/analysis/`)
|
||||
|
||||
همه فایل‌های این پوشه باید ساختار یکسان داشته باشند:
|
||||
|
||||
- **سربرگ:** عنوان `#`، سپس `تهیه‌کننده`، `بازبین` و `آخرین به‌روزرسانی` (تاریخ شمسی با ارقام فارسی)، و بعد خط `---`.
|
||||
- **بخش‌ها:** بخش «مقدمه» بدون شماره؛ بخش‌های اصلی با شماره (`## ۱.`)؛ آخرین بخش همیشه «نکات و پرسش‌های باز» است.
|
||||
- **پایان:** خط `---` و سپس `**وضعیت سند:** ...`.
|
||||
- **شناسه‌ها:** داستان‌ها `US-NN`، نیازمندی‌های کارکردی `FR-NN`، نیازمندی‌های غیرکارکردی `NFR-NN`، نمودارها `AD-NN`.
|
||||
- **نام بازیگران:** فقط نام فارسی؛ دانشجو، استاد، کارمند تأسیسات، تعمیرکار، مدیر، کاربر سیستم. «گزارش‌دهنده» یعنی دانشجو یا استاد.
|
||||
- **ارجاع:** هر داستان فیلد «نیازمندی‌های مرتبط» دارد و هر نمودار به داستان‌های خود ارجاع می‌دهد.
|
||||
|
||||
---
|
||||
|
||||
اگر مرحله‌ای را متوجه نشدید، تو گروه‌مون بپرسید تا سریع حلش کنیم.
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
|
||||
| مستند | مسیر فایل | توضیح کوتاه | تهیه‌کننده | بازبین |
|
||||
|-------|-----------|-------------|----------|--------|
|
||||
| سند User Stories | [`docs/analysis/user-story.md`](docs/analysis/user-story.md) | شناسایی بازیگران و قابلیت‌های اصلی سیستم | امیرحسن عارف اصل | ارشیا همتی‌زاده |
|
||||
| نمودار Use Case | [`docs/analysis/use-case.md`](docs/analysis/use-case.md) | شناسایی بازیگران و قابلیت‌های اصلی سیستم | امیرحسن عارف اصل | ارشیا همتی‌زاده |
|
||||
| نمودار Activity | [`docs/analysis/activity.md`](docs/analysis/activity.md) | مدل‌سازی جریان کامل فرایند گزارش تا رفع خرابی | ارشیا همتی‌زاده | رضا آدوسی |
|
||||
| سند نیازمندی‌ها | [`docs/analysis/requirements-specification.md`](docs/analysis/requirements-specification.md) | نیازمندی‌های عملکردی و غیرعملکردی | رضا آدوسی | امیرحسن عارف اصل |
|
||||
| روش تحقیق و منابع | [`docs/research-and-sources.md`](docs/research-and-sources.md) | نحوهٔ تحقیق و منابع استفاده‌شده | همه اعضا | - |
|
||||
|
||||
+20
-32
@@ -1,31 +1,23 @@
|
||||
# نمودارهای فعالیت (Activity Diagrams) – سامانه مدیریت و گزارش خرابی دانشگاهی
|
||||
|
||||
**تهیه‌کننده:** ارشیا همتی‌زاده
|
||||
**بازبین:** رضا آدوسی
|
||||
**آخرین به‌روزرسانی:** ۱۴۰۵/۰۸/۱۱
|
||||
|
||||
---
|
||||
|
||||
## مقدمه
|
||||
# نمودارهای فعالیت
|
||||
|
||||
این سند جریان‌های کاری اصلی سامانه گزارش و مدیریت خرابی‌های دانشگاه را با استفاده از Mermaid نمایش می‌دهد.
|
||||
|
||||
> **نکته:** نمودارها بر اساس بازیگران و ۱۷ داستان کاربر شناسایی‌شده در [user-story.md](user-story.md) تهیه شده‌اند. جزئیاتی که در [نیازمندی‌ها](requirements-specification.md) صریحاً مشخص نشده‌اند، به‌عنوان فرض یا پرسش باز علامت‌گذاری شده‌اند و نباید قانون قطعی سیستم تلقی شوند.
|
||||
> **نکته:** نمودارها بر اساس بازیگران و ۱۷ داستان کاربری شناسایی‌شده در مستندات تحلیل تهیه شده‌اند. جزئیاتی که در نیازمندی‌ها صریحاً مشخص نشده‌اند، به‌عنوان فرض یا پرسش باز علامت‌گذاری شده‌اند و نباید قانون قطعی سیستم تلقی شوند.
|
||||
|
||||
## ۱. بازیگران و مسئولیت‌ها
|
||||
|
||||
| بازیگر | مسئولیت‌ها |
|
||||
|---|---|
|
||||
| دانشجو | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
|
||||
| استاد | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
|
||||
| کارمند تأسیسات | بررسی و فیلتر گزارش‌ها، تعیین اولویت، تخصیص تعمیرکار، به‌روزرسانی وضعیت و مشاهده تاریخچه |
|
||||
| تعمیرکار | مشاهده مأموریت‌های تخصیص‌یافته، شروع تعمیر، ثبت نتیجه و درخواست اطلاعات تکمیلی |
|
||||
| مدیر | مشاهده داشبورد مدیریتی؛ سطح دسترسی دقیق این نقش باید در نیازمندی‌ها مشخص شود |
|
||||
| کاربر سیستم | عنوان عمومی کاربر احراز هویت‌شده در داستان‌های ورود و اعلان؛ لزوماً یک نقش انسانی مستقل نیست |
|
||||
| دانشجو (Student) | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
|
||||
| استاد (Professor) | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
|
||||
| کارمند تأسیسات (Facilities Staff) | بررسی و فیلتر گزارش‌ها، تعیین اولویت، تخصیص تعمیرکار، به‌روزرسانی وضعیت و مشاهده تاریخچه |
|
||||
| تعمیرکار (Technician) | مشاهده مأموریت‌های تخصیص‌یافته، شروع تعمیر، ثبت نتیجه و درخواست اطلاعات تکمیلی |
|
||||
| مدیر (Manager) | مشاهده داشبورد مدیریتی؛ سطح دسترسی دقیق این نقش باید در نیازمندی‌ها مشخص شود |
|
||||
| کاربر سیستم (System User) | عنوان عمومی کاربر احراز هویت‌شده در داستان‌های ورود و اعلان؛ لزوماً یک نقش انسانی مستقل نیست |
|
||||
|
||||
## ۲. نمودار فعالیت احراز هویت (AD-01)
|
||||
## ۲. نمودار فعالیت احراز هویت (Authentication Activity)
|
||||
|
||||
**داستان کاربر مرتبط:** US-15 — ورود به سیستم.
|
||||
**داستان کاربری مرتبط:** US-15 — ورود به سیستم (Log in).
|
||||
|
||||
این نمودار فرایند عمومی ورود کاربر را نشان می‌دهد. روش دقیق احراز هویت، بازیابی رمز عبور و سیاست قفل حساب در این بخش مشخص نشده‌اند.
|
||||
|
||||
@@ -43,9 +35,9 @@ flowchart TD
|
||||
I --> J([پایان])
|
||||
```
|
||||
|
||||
## ۳. نمودار فعالیت ثبت گزارش خرابی (AD-02)
|
||||
## ۳. نمودار فعالیت ثبت گزارش خرابی (Fault Reporting Activity)
|
||||
|
||||
**داستان‌های کاربر مرتبط:**
|
||||
**داستان‌های کاربری مرتبط:**
|
||||
- US-01 — دانشجو گزارش خرابی ثبت می‌کند.
|
||||
- US-02 — استاد گزارش خرابی ثبت می‌کند.
|
||||
- US-03 — دانشجو یا استاد وضعیت گزارش را پیگیری می‌کند.
|
||||
@@ -88,9 +80,9 @@ flowchart TD
|
||||
|
||||
**نکته مدل‌سازی:** حلقه اصلاح اطلاعات، اعتبارسنجی فرم را نمایش می‌دهد. باید مشخص شود آیا کاربر می‌تواند در هر زمان اطلاعات تکمیلی ارسال کند یا فقط پس از درخواست کارمند تأسیسات یا تعمیرکار مجاز به این کار است.
|
||||
|
||||
## ۴. نمودار فعالیت مدیریت گزارش‌ها (AD-03)
|
||||
## ۴. نمودار فعالیت مدیریت گزارش‌ها (Report Management Activity)
|
||||
|
||||
**داستان‌های کاربر مرتبط:**
|
||||
**داستان‌های کاربری مرتبط:**
|
||||
- US-06 — مشاهده و فیلتر گزارش‌های باز.
|
||||
- US-07 — تعیین اولویت گزارش.
|
||||
- US-08 — تخصیص تعمیرکار.
|
||||
@@ -139,9 +131,9 @@ flowchart TD
|
||||
|
||||
**نکته مدل‌سازی:** تصمیم «آیا گزارش آماده تخصیص است؟» یک مرحله پیشنهادی است. شرایط دقیق تخصیص تعمیرکار و نحوه بازگرداندن گزارش‌های ناقص به گزارش‌دهنده باید در نیازمندی‌ها مشخص شوند.
|
||||
|
||||
## ۵. نمودار فعالیت تعمیر خرابی (AD-04)
|
||||
## ۵. نمودار فعالیت تعمیر خرابی (Repair Activity)
|
||||
|
||||
**داستان‌های کاربر مرتبط:**
|
||||
**داستان‌های کاربری مرتبط:**
|
||||
- US-11 — تعمیرکار کارهای تخصیص‌یافته را مشاهده می‌کند.
|
||||
- US-12 — تعمیرکار تعمیر را آغاز می‌کند.
|
||||
- US-13 — تعمیرکار نتیجه تعمیر را ثبت می‌کند.
|
||||
@@ -186,9 +178,9 @@ flowchart TD
|
||||
|
||||
**نکته مدل‌سازی:** در این نمودار، درخواست اطلاعات تکمیلی باعث توقف موقت تعمیر می‌شود. باید مشخص شود چه کسی اطلاعات را ارائه می‌کند، پس از دریافت اطلاعات چگونه به تعمیرکار اطلاع داده می‌شود و آیا هنگام انتظار وضعیت گزارش تغییر می‌کند یا خیر.
|
||||
|
||||
## ۶. نمودار فعالیت تأیید تعمیر (AD-05)
|
||||
## ۶. نمودار فعالیت تأیید تعمیر (Repair Verification Activity)
|
||||
|
||||
**داستان کاربر مرتبط:** US-05 — دانشجو یا استاد تکمیل تعمیر را تأیید یا رد می‌کند.
|
||||
**داستان کاربری مرتبط:** US-05 — دانشجو یا استاد تکمیل تعمیر را تأیید یا رد می‌کند.
|
||||
|
||||
گزارش‌دهنده نتیجه ثبت‌شده تعمیر را بررسی می‌کند و مشخص می‌کند که آیا خرابی برطرف شده است یا خیر.
|
||||
|
||||
@@ -221,7 +213,7 @@ flowchart TD
|
||||
|
||||
**پرسش باز:** نیازمندی‌ها باید مشخص کنند پس از رد نتیجه تعمیر چه اتفاقی می‌افتد: آیا گزارش به کارمند تأسیسات بازمی‌گردد، دوباره به همان تعمیرکار تخصیص داده می‌شود یا فرایند دیگری اجرا می‌شود؟ این نمودار هیچ‌یک از این سیاست‌ها را به‌عنوان تصمیم قطعی انتخاب نمی‌کند.
|
||||
|
||||
## ۷. نمودار کلی چرخه عمر گزارش خرابی (AD-06)
|
||||
## ۷. نمودار کلی چرخه عمر گزارش خرابی (Overall Fault Lifecycle)
|
||||
|
||||
این نمودار نمایی کلی از فرایند اصلی سیستم ارائه می‌دهد و مراحل ثبت گزارش، مدیریت، تعمیر و تأیید را به یکدیگر متصل می‌کند.
|
||||
|
||||
@@ -257,7 +249,7 @@ flowchart TD
|
||||
|
||||
**نکته مدل‌سازی:** بازگشت گزارش ردشده به مرحله بررسی کارمند تأسیسات، یک مسیر پیشنهادی برای پیگیری مجدد است و هنوز سیاست قطعی تخصیص مجدد محسوب نمی‌شود. این مسیر باید با اعضای تیم پروژه بررسی و تأیید شود.
|
||||
|
||||
## ۸. نکات و پرسش‌های باز
|
||||
## ۸. پرسش‌ها و ابهام‌های نیازمندی‌ها
|
||||
|
||||
موارد زیر باید پیش از نهایی‌شدن نمودارها با اعضای تیم پروژه مشخص شوند:
|
||||
|
||||
@@ -271,7 +263,3 @@ flowchart TD
|
||||
8. **اعلان‌ها:** کدام رویدادها باعث ارسال اعلان می‌شوند، دریافت‌کنندگان چه کسانی هستند و اعلان‌ها از چه کانالی ارسال می‌شوند؟
|
||||
9. **دسترسی مدیر:** آیا دسترسی مدیر فقط به مشاهده داشبورد محدود است یا این نقش امکان مدیریت گزارش‌ها را نیز دارد؟
|
||||
10. **احراز هویت:** آیا قوانین ورود یا کنترل دسترسی برای نقش‌های مختلف متفاوت است؟
|
||||
|
||||
---
|
||||
|
||||
**وضعیت سند:** نسخه اولیه (Draft) – آماده بازبینی
|
||||
|
||||
@@ -1,104 +1,43 @@
|
||||
# سند نیازمندی‌ها (Requirements Specification) – سامانه مدیریت و گزارش خرابی دانشگاهی
|
||||
|
||||
**تهیه‌کننده:** رضا آدوسی
|
||||
**بازبین:** ارشیا همتی‌زاده
|
||||
**آخرین به‌روزرسانی:** ۱۴۰۵/۰۸/۱۱
|
||||
|
||||
---
|
||||
|
||||
## مقدمه
|
||||
|
||||
در این سند، نیازمندی‌های اصلی سامانهٔ مدیریت و گزارش خرابی دانشگاهی در دو دستهٔ **نیازمندی‌های کارکردی (Functional Requirements)** و **نیازمندی‌های غیرکارکردی (Non-functional Requirements)** تعریف شده‌اند.
|
||||
|
||||
نیازمندی‌های کارکردی، قابلیت‌ها و وظایفی را مشخص می‌کنند که سامانه باید ارائه دهد و نیازمندی‌های غیرکارکردی، ویژگی‌های کیفی و محدودیت‌های مورد انتظار از سامانه را بیان می‌کنند.
|
||||
# سند نیازمندی‌های سامانهٔ مدیریت و گزارش خرابی دانشگاهی
|
||||
|
||||
## ۱. هدف و محدودهٔ سامانه
|
||||
|
||||
هدف از توسعهٔ این سامانه، فراهم کردن بستری متمرکز برای ثبت خرابی تجهیزات و فضاهای دانشگاه، پیگیری درخواست‌ها و مدیریت فرایند تعمیر است.
|
||||
هدف این سامانه، فراهم کردن بستری متمرکز برای ثبت خرابی تجهیزات و فضاهای دانشگاه، پیگیری درخواست‌ها و مدیریت فرایند تعمیر است. سامانه به گزارش‌دهندگان امکان می‌دهد خرابی را ثبت و وضعیت آن را پیگیری کنند و به مسئولان تأسیسات کمک می‌کند درخواست‌ها را بررسی و به تعمیرکاران ارجاع دهند.
|
||||
|
||||
سامانه به دانشجویان و استادان امکان می‌دهد خرابی‌های مشاهده‌شده را ثبت و وضعیت رسیدگی به آن‌ها را پیگیری کنند. همچنین کارمندان تأسیسات می‌توانند گزارش‌ها را بررسی، اولویت‌بندی و به تعمیرکاران ارجاع دهند و بر روند رسیدگی نظارت داشته باشند.
|
||||
|
||||
محدودهٔ دقیق فضاهای تحت پوشش سامانه، از جمله کلاس‌ها، آزمایشگاه‌ها، فضاهای عمومی، اداری و خوابگاه‌ها، در مراحل بعدی تحلیل مشخص خواهد شد.
|
||||
در این مرحله، محدودهٔ دقیق سامانه و امکانات نهایی آن هنوز نیازمند بررسی بیشتر است.
|
||||
|
||||
## ۲. کاربران سامانه
|
||||
|
||||
- **دانشجو:** ثبت گزارش خرابی و مشاهده و پیگیری گزارش‌های ثبت‌شده توسط خود.
|
||||
- **استاد:** ثبت خرابی‌های مربوط به کلاس‌ها و آزمایشگاه‌ها و پیگیری وضعیت گزارش‌ها.
|
||||
- **کارمند تأسیسات:** بررسی گزارش‌ها، تعیین اولویت، ارجاع درخواست‌ها و نظارت بر فرایند تعمیر.
|
||||
- **تعمیرکار:** مشاهدهٔ درخواست‌های تخصیص‌یافته، انجام تعمیرات و ثبت نتیجهٔ اقدامات.
|
||||
- **مدیر:** نظارت بر عملکرد کلی سامانه و مشاهدهٔ اطلاعات و گزارش‌های مدیریتی.
|
||||
- **کاربر سیستم:** عنوان عمومی برای اشاره به کاربران دارای حساب کاربری و دسترسی به سامانه.
|
||||
- **گزارش‌دهنده:** عنوان مشترک دانشجو و استاد در فرایند ثبت و پیگیری گزارش خرابی.
|
||||
- **دانشجو و استاد:** ثبت گزارش خرابی و مشاهدهٔ وضعیت درخواست.
|
||||
- **مسئول تأسیسات:** بررسی گزارش‌ها، تعیین اولویت و ارجاع درخواست‌ها.
|
||||
- **تعمیرکار:** مشاهدهٔ درخواست‌های ارجاع‌شده و ثبت نتیجهٔ تعمیر.
|
||||
|
||||
## ۳. نیازمندی‌های کارکردی (Functional Requirements)
|
||||
|
||||
### ۳.۱. مدیریت کاربران و دسترسی
|
||||
|
||||
- **FR-01 — ورود به سامانه:** سامانه باید امکان ورود کاربران از طریق نام کاربری و رمز عبور را فراهم کند.
|
||||
- **FR-02 — کنترل دسترسی:** سامانه باید دسترسی کاربران به امکانات و اطلاعات را بر اساس نقش آن‌ها مدیریت کند.
|
||||
|
||||
### ۳.۲. ثبت و مدیریت گزارش خرابی
|
||||
|
||||
- **FR-03 — ثبت گزارش خرابی:** سامانه باید امکان ثبت گزارش شامل عنوان، توضیحات، محل خرابی و نوع تجهیز را برای دانشجویان و استادان فراهم کند.
|
||||
- **FR-04 — افزودن اطلاعات تکمیلی:** گزارش‌دهنده باید بتواند تصویر یا توضیحات تکمیلی را به گزارش ثبت‌شده اضافه کند.
|
||||
- **FR-05 — مشاهدهٔ گزارش:** گزارش‌دهنده باید بتواند گزارش‌های ثبت‌شده توسط خود و وضعیت فعلی آن‌ها را مشاهده کند.
|
||||
|
||||
### ۳.۳. بررسی و اولویت‌بندی گزارش‌ها
|
||||
|
||||
- **FR-06 — بررسی گزارش‌ها:** کارمند تأسیسات باید بتواند گزارش‌های ثبت‌شده را مشاهده و بررسی کند.
|
||||
- **FR-07 — تعیین اولویت:** کارمند تأسیسات باید بتواند بر اساس اهمیت و فوریت خرابی، اولویت رسیدگی به هر گزارش را تعیین کند.
|
||||
- **FR-08 — جست‌وجو و فیلتر گزارش‌ها:** کارمند تأسیسات باید بتواند گزارش‌ها را بر اساس وضعیت، اولویت و سایر مشخصات مرتبط جست‌وجو و فیلتر کند.
|
||||
|
||||
### ۳.۴. ارجاع و مدیریت فرایند تعمیر
|
||||
|
||||
- **FR-09 — ارجاع به تعمیرکار:** کارمند تأسیسات باید بتواند هر گزارش را به تعمیرکار مناسب تخصیص دهد.
|
||||
- **FR-10 — مشاهدهٔ درخواست‌های تخصیص‌یافته:** تعمیرکار باید بتواند فهرست درخواست‌های ارجاع‌شده به خود را مشاهده کند.
|
||||
- **FR-11 — به‌روزرسانی وضعیت درخواست:** افراد مجاز باید بتوانند وضعیت درخواست را متناسب با مرحلهٔ رسیدگی به‌روزرسانی کنند.
|
||||
- **FR-12 — ثبت نتیجهٔ تعمیر:** تعمیرکار باید بتواند نتیجهٔ بررسی و اقدامات انجام‌شده را همراه با توضیحات ثبت کند.
|
||||
- **FR-13 — درخواست اطلاعات تکمیلی:** تعمیرکار باید بتواند در صورت نیاز، اطلاعات بیشتری از گزارش‌دهنده درخواست کند.
|
||||
|
||||
### ۳.۵. پیگیری و اطلاع‌رسانی
|
||||
|
||||
- **FR-14 — تأیید نتیجهٔ تعمیر:** گزارش‌دهنده باید بتواند پس از اعلام رفع خرابی، نتیجهٔ تعمیر را تأیید یا رد کند.
|
||||
- **FR-15 — اطلاع‌رسانی تغییر وضعیت:** سامانه باید امکان ارسال اعلان به کاربران مرتبط هنگام تغییر وضعیت گزارش را فراهم کند.
|
||||
- **FR-16 — مشاهدهٔ سوابق:** کاربران مجاز باید بتوانند سوابق گزارش‌ها و اقدامات انجام‌شده را متناسب با سطح دسترسی خود مشاهده کنند.
|
||||
|
||||
### ۳.۶. مدیریت و نظارت
|
||||
|
||||
- **FR-17 — داشبورد مدیریتی:** سامانه باید امکان مشاهدهٔ اطلاعات کلی مانند تعداد گزارش‌های ثبت‌شده، گزارش‌های باز و درخواست‌های فوری را برای مدیر و کارمندان تأسیسات فراهم کند.
|
||||
- **FR-01 — ثبت گزارش خرابی:** سامانه باید امکان ثبت گزارش شامل عنوان، توضیحات، محل خرابی و نوع تجهیز را فراهم کند.
|
||||
- **FR-02 — مشاهدهٔ گزارش:** کاربر باید بتواند اطلاعات گزارش ثبت‌شده و وضعیت فعلی آن را مشاهده کند.
|
||||
- **FR-03 — بررسی درخواست:** مسئول تأسیسات باید بتواند گزارش‌های ثبت‌شده را بررسی کند.
|
||||
- **FR-04 — تعیین اولویت:** مسئول تأسیسات باید بتواند اولویت رسیدگی به هر گزارش را مشخص کند.
|
||||
- **FR-05 — ارجاع به تعمیرکار:** مسئول تأسیسات باید بتواند درخواست را به تعمیرکار مربوطه ارجاع دهد.
|
||||
- **FR-06 — به‌روزرسانی وضعیت:** وضعیت درخواست باید در مراحل مختلف رسیدگی قابل به‌روزرسانی باشد.
|
||||
- **FR-07 — ثبت نتیجهٔ تعمیر:** تعمیرکار باید بتواند نتیجهٔ بررسی و اقدامات انجام‌شده را ثبت کند.
|
||||
- **FR-08 — مشاهدهٔ سوابق:** کاربران مجاز باید بتوانند سوابق درخواست‌ها و تعمیرات را متناسب با سطح دسترسی خود مشاهده کنند.
|
||||
|
||||
## ۴. نیازمندی‌های غیرکارکردی (Non-functional Requirements)
|
||||
|
||||
### ۴.۱. امنیت و کنترل دسترسی
|
||||
- **NFR-01 — امنیت:** سامانه باید از دسترسی غیرمجاز به اطلاعات و امکانات مدیریتی جلوگیری کند.
|
||||
- **NFR-02 — کنترل دسترسی:** هر کاربر باید فقط به امکانات متناسب با نقش خود دسترسی داشته باشد.
|
||||
- **NFR-03 — سهولت استفاده:** فرم‌های ثبت و پیگیری گزارش باید ساده و قابل فهم باشند.
|
||||
- **NFR-04 — کارایی:** عملیات معمول مانند ثبت گزارش و مشاهدهٔ وضعیت باید در زمان قابل قبول انجام شوند.
|
||||
- **NFR-05 — قابلیت اطمینان:** سامانه باید اطلاعات ثبت‌شده را به‌درستی نگهداری کند و از حذف یا تغییر ناخواستهٔ آن‌ها جلوگیری کند.
|
||||
- **NFR-06 — قابلیت نگهداری:** ساختار سامانه باید امکان اصلاح و افزودن قابلیت‌های جدید را در آینده فراهم کند.
|
||||
|
||||
- **NFR-01 — امنیت اطلاعات:** سامانه باید از دسترسی غیرمجاز، افشای اطلاعات و تغییرات غیرمجاز در داده‌ها جلوگیری کند.
|
||||
- **NFR-02 — حفظ حریم خصوصی:** اطلاعات کاربران و گزارش‌ها باید متناسب با سطح دسترسی هر نقش در اختیار افراد قرار گیرد.
|
||||
## ۵. فرضیات و ابهامات
|
||||
|
||||
### ۴.۲. سهولت استفاده
|
||||
- هنوز مشخص نشده است که سامانه فقط فضاهای آموزشی و عمومی را پوشش می‌دهد یا خوابگاه‌ها و فضاهای اداری را نیز شامل می‌شود.
|
||||
- نحوهٔ اطلاع‌رسانی دربارهٔ تغییر وضعیت درخواست‌ها هنوز تعیین نشده است.
|
||||
- معیارهای دقیق اولویت‌بندی خرابی‌ها و سطح دسترسی هر نقش باید در مراحل بعدی مشخص شوند.
|
||||
|
||||
- **NFR-03 — کاربردپذیری:** رابط کاربری و فرم‌های ثبت و پیگیری گزارش باید ساده، قابل فهم و متناسب با نیاز کاربران طراحی شوند.
|
||||
## ۶. وضعیت سند
|
||||
|
||||
### ۴.۳. کارایی و عملکرد
|
||||
|
||||
- **NFR-04 — زمان پاسخ‌گویی:** عملیات معمول سامانه، مانند ثبت گزارش و مشاهدهٔ وضعیت، باید در زمان قابل قبول انجام شوند.
|
||||
|
||||
### ۴.۴. قابلیت اطمینان
|
||||
|
||||
- **NFR-05 — صحت و نگهداری اطلاعات:** سامانه باید اطلاعات ثبت‌شده را به‌درستی نگهداری کند و از حذف یا تغییر ناخواستهٔ آن‌ها جلوگیری کند.
|
||||
|
||||
### ۴.۵. قابلیت نگهداری و توسعه
|
||||
|
||||
- **NFR-06 — قابلیت نگهداری:** ساختار سامانه باید امکان اصلاح، نگهداری و افزودن قابلیت‌های جدید را در آینده فراهم کند.
|
||||
|
||||
## ۵. نکات و پرسش‌های باز
|
||||
|
||||
- این نیازمندی‌ها نسخهٔ اولیه هستند و ممکن است در مراحل بعدی تحلیل و بازبینی تغییر کنند یا نیازمندی‌های جدیدی به آن‌ها اضافه شود.
|
||||
- محدودهٔ دقیق فضاهای تحت پوشش سامانه، از جمله خوابگاه‌ها و فضاهای اداری، هنوز مشخص نشده است.
|
||||
- معیارهای دقیق اولویت‌بندی خرابی‌ها و نحوهٔ تشخیص درخواست‌های فوری باید تعیین شوند.
|
||||
- روش اطلاع‌رسانی به کاربران، مانند اعلان داخل سامانه، پیامک یا ایمیل، هنوز مشخص نشده است.
|
||||
- جزئیات سطح دسترسی هر نقش و شرایط بسته‌شدن نهایی درخواست‌ها باید در مراحل بعدی مشخص شوند.
|
||||
- هر نیازمندی باید حداقل با یک داستان کاربر (User Story) تطبیق داده شود. ارجاع‌ها در فیلد «نیازمندی‌های مرتبط» همان سند [user-story.md](user-story.md) ثبت شده‌اند.
|
||||
|
||||
---
|
||||
|
||||
**وضعیت سند:** نسخهٔ اولیه (Draft) – آمادهٔ بازبینی
|
||||
این سند نسخهٔ اولیهٔ نیازمندی‌هاست و با تکمیل تحلیل پروژه و دریافت بازخورد اعضای گروه اصلاح خواهد شد.
|
||||
@@ -1,167 +1,131 @@
|
||||
# داستان‌های کاربر (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) – آماده بازبینی
|
||||
# داستان‌های کاربر (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) – آماده بازبینی
|
||||
@@ -1,42 +0,0 @@
|
||||
# مرجع: US-01 ، FR-03 ، FR-05 ، AD-02
|
||||
Feature: ثبت خرابی توسط دانشجو
|
||||
به عنوان یک دانشجو
|
||||
می‌خواهم خرابی مشاهده‌شده را به همراه مکان و توضیحات ثبت کنم
|
||||
تا بتوانم مشکل را سریع به بخش تأسیسات اطلاع دهم و پیگیری کنم
|
||||
|
||||
Background:
|
||||
Given کاربری با نقش "دانشجو" و نام کاربری "student1" وارد سامانه شده است
|
||||
|
||||
Scenario: ثبت موفق گزارش خرابی با اطلاعات کامل
|
||||
When فرم ثبت گزارش را با عنوان "چراغ کلاس ۱۰۲ روشن نمی‌شود"، توضیحات "کلید برق کار نمی‌کند"، محل "ساختمان الف - کلاس ۱۰۲" و نوع تجهیز "روشنایی" ارسال می‌کند
|
||||
Then گزارش با وضعیت "ثبت‌شده" ذخیره می‌شود
|
||||
And شناسه یکتای گزارش نمایش داده می‌شود
|
||||
And گزارش در فهرست "گزارش‌های من" دانشجو دیده می‌شود
|
||||
|
||||
Scenario Outline: ارسال فرم با یک فیلد اجباری خالی
|
||||
When فرم ثبت گزارش را با فیلد "<فیلد>" خالی ارسال می‌کند
|
||||
Then پیام خطای "این فیلد الزامی است" کنار "<فیلد>" نمایش داده می‌شود
|
||||
And هیچ گزارشی ذخیره نمی‌شود
|
||||
|
||||
Examples:
|
||||
| فیلد |
|
||||
| عنوان |
|
||||
| توضیحات |
|
||||
| محل خرابی |
|
||||
| نوع تجهیز |
|
||||
|
||||
Scenario: عنوان با طول مرزی ۱۵۰ کاراکتر پذیرفته می‌شود
|
||||
When فرم ثبت گزارش را با عنوانی به طول ۱۵۰ کاراکتر و سایر فیلدهای معتبر ارسال می‌کند
|
||||
Then گزارش با وضعیت "ثبت‌شده" ذخیره می‌شود
|
||||
|
||||
Scenario: عنوان با ۱۵۱ کاراکتر رد می‌شود
|
||||
When فرم ثبت گزارش را با عنوانی به طول ۱۵۱ کاراکتر و سایر فیلدهای معتبر ارسال می‌کند
|
||||
Then پیام خطای "حداکثر طول عنوان ۱۵۰ کاراکتر است" نمایش داده می‌شود
|
||||
And هیچ گزارشی ذخیره نمی‌شود
|
||||
|
||||
Scenario: خطای سرور هنگام ذخیره‌سازی
|
||||
Given سرویس ذخیره‌سازی در دسترس نیست
|
||||
When فرم ثبت گزارش را با اطلاعات معتبر ارسال می‌کند
|
||||
Then پیام "خطا در ثبت گزارش؛ لطفاً دوباره تلاش کنید" نمایش داده می‌شود
|
||||
And مقادیر واردشده در فرم حفظ می‌شوند
|
||||
And هیچ گزارش ناقصی ذخیره نمی‌شود
|
||||
@@ -1,51 +0,0 @@
|
||||
# مرجع: US-05 ، FR-14 ، AD-05
|
||||
Feature: تأیید یا رد نتیجه تعمیر توسط گزارش‌دهنده
|
||||
به عنوان یک دانشجو یا استاد
|
||||
می‌خواهم پس از اعلام رفع خرابی، آن را تأیید یا رد کنم
|
||||
تا بتوانم از بسته شدن صحیح گزارش مطمئن شوم
|
||||
|
||||
Background:
|
||||
Given گزارش شماره "R-100" با وضعیت "تعمیر انجام‌شده" و گزارش‌دهنده "student1" وجود دارد
|
||||
|
||||
Scenario: تأیید نتیجه تعمیر توسط گزارش‌دهنده
|
||||
Given کاربر "student1" وارد سامانه شده است
|
||||
When نتیجه تعمیر گزارش "R-100" را تأیید می‌کند
|
||||
Then وضعیت گزارش "R-100" به "بسته‌شده" تغییر می‌کند
|
||||
And تاریخچه گزارش ثبت تأیید گزارش‌دهنده را نشان می‌دهد
|
||||
|
||||
Scenario: رد نتیجه تعمیر بدون ذکر دلیل
|
||||
Given کاربر "student1" وارد سامانه شده است
|
||||
When نتیجه تعمیر گزارش "R-100" را با دلیل خالی رد می‌کند
|
||||
Then پیام خطای "ذکر دلیل رد الزامی است" نمایش داده می‌شود
|
||||
And وضعیت گزارش "R-100" بدون تغییر "تعمیر انجام‌شده" می‌ماند
|
||||
|
||||
Scenario: رد نتیجه تعمیر با ذکر دلیل
|
||||
Given کاربر "student1" وارد سامانه شده است
|
||||
When نتیجه تعمیر گزارش "R-100" را با دلیل "خرابی هنوز برطرف نشده است" رد می‌کند
|
||||
Then دلیل رد در تاریخچه گزارش ثبت می‌شود
|
||||
And گزارش برای پیگیری بیشتر علامت‌گذاری می‌شود
|
||||
|
||||
Scenario: کاربر دیگری نمی‌تواند نتیجه تعمیر را تأیید کند
|
||||
Given کاربر "student2" وارد سامانه شده است
|
||||
When سعی می‌کند نتیجه تعمیر گزارش "R-100" را تأیید کند
|
||||
Then پیام "دسترسی مجاز نیست" نمایش داده می‌شود
|
||||
And وضعیت گزارش "R-100" بدون تغییر "تعمیر انجام‌شده" می‌ماند
|
||||
|
||||
Scenario Outline: تأیید یا رد فقط در وضعیت "تعمیر انجام‌شده" مجاز است
|
||||
Given گزارش "R-101" با وضعیت "<وضعیت>" وجود دارد
|
||||
When کاربر "student1" سعی می‌کند نتیجه تعمیر گزارش "R-101" را تأیید کند
|
||||
Then عملیات انجام نمی‌شود
|
||||
And پیام "این گزارش در وضعیت قابل تأیید نیست" نمایش داده می‌شود
|
||||
|
||||
Examples:
|
||||
| وضعیت |
|
||||
| ثبت‌شده |
|
||||
| ارجاع‌شده |
|
||||
| در حال تعمیر |
|
||||
| بسته‌شده |
|
||||
|
||||
Scenario: کلیک دوباره روی تأیید یک تغییر وضعیت بیشتر ایجاد نمی‌کند
|
||||
Given کاربر "student1" وارد سامانه شده است
|
||||
When دو بار پشت سر هم روی دکمه تأیید کلیک می‌کند
|
||||
Then وضعیت گزارش "R-100" فقط یک بار به "بسته‌شده" تغییر می‌کند
|
||||
And تاریخچه گزارش فقط یک ورودی تأیید دارد
|
||||
@@ -1,47 +0,0 @@
|
||||
# مرجع: US-15 ، FR-01 ، FR-02 ، AD-01
|
||||
Feature: ورود به سامانه
|
||||
به عنوان یک کاربر سیستم
|
||||
می‌خواهم با نام کاربری و رمز عبور وارد سامانه شوم
|
||||
تا بتوانم به امکانات مربوط به نقش خودم دسترسی داشته باشم
|
||||
|
||||
Scenario: ورود موفق و انتقال به داشبورد نقش کاربر
|
||||
Given کاربری با نام کاربری "student1" و رمز عبور معتبر وجود دارد
|
||||
When نام کاربری "student1" و رمز عبور معتبر را وارد و فرم را ارسال می‌کند
|
||||
Then کاربر وارد سامانه می‌شود
|
||||
And صفحه ثبت گزارش خرابی برای نقش "دانشجو" نمایش داده می‌شود
|
||||
|
||||
Scenario: رمز عبور اشتباه
|
||||
Given کاربری با نام کاربری "student1" وجود دارد
|
||||
When نام کاربری "student1" و رمز عبور "اشتباه" را وارد می‌کند
|
||||
Then پیام "نام کاربری یا رمز عبور اشتباه است" نمایش داده می‌شود
|
||||
And پیام مشخص نمی‌کند کدام فیلد اشتباه است
|
||||
And نام کاربری "student1" در فرم باقی می‌ماند
|
||||
And کاربر وارد سامانه نمی‌شود
|
||||
|
||||
Scenario Outline: ارسال فرم ورود با فیلد خالی
|
||||
When فرم ورود را با "<فیلد خالی>" خالی ارسال می‌کند
|
||||
Then ورود انجام نمی‌شود
|
||||
And پیام "این فیلد الزامی است" کنار "<فیلد خالی>" نمایش داده می‌شود
|
||||
|
||||
Examples:
|
||||
| فیلد خالی |
|
||||
| نام کاربری |
|
||||
| رمز عبور |
|
||||
|
||||
Scenario: دسترسی به صفحه نقش دیگر مجاز نیست
|
||||
Given کاربر "student1" با نقش "دانشجو" وارد سامانه شده است
|
||||
When آدرس صفحه داشبورد کارمند تأسیسات را مستقیم باز می‌کند
|
||||
Then پیام "دسترسی مجاز نیست" نمایش داده می‌شود
|
||||
And هیچ اطلاعات گزارش مدیریتی نمایش داده نمی‌شود
|
||||
|
||||
Scenario: خروج از سامانه و محافظت از صفحات
|
||||
Given کاربر "student1" وارد سامانه شده است
|
||||
When از سامانه خارج می‌شود
|
||||
And سپس آدرس صفحه ثبت گزارش را باز می‌کند
|
||||
Then کاربر به صفحه ورود هدایت می‌شود
|
||||
|
||||
Scenario: سرویس احراز هویت در دسترس نیست
|
||||
Given سرویس احراز هویت در دسترس نیست
|
||||
When نام کاربری و رمز عبور معتبر را ارسال می‌کند
|
||||
Then پیام "خطا در ورود؛ لطفاً بعداً تلاش کنید" نمایش داده می‌شود
|
||||
And کاربر وارد سامانه نمی‌شود
|
||||
Reference in New Issue
Block a user