1 Commits

Author SHA1 Message Date
Arshia 1bb03232f0 add activity diagrams for system workflows 2026-10-31 15:49:45 +03:30
3 changed files with 291 additions and 479 deletions
+265
View File
@@ -0,0 +1,265 @@
# نمودارهای فعالیت
این سند جریان‌های کاری اصلی سامانه گزارش و مدیریت خرابی‌های دانشگاه را با استفاده از Mermaid نمایش می‌دهد.
> **نکته:** نمودارها بر اساس بازیگران و ۱۷ داستان کاربری شناسایی‌شده در مستندات تحلیل تهیه شده‌اند. جزئیاتی که در نیازمندی‌ها صریحاً مشخص نشده‌اند، به‌عنوان فرض یا پرسش باز علامت‌گذاری شده‌اند و نباید قانون قطعی سیستم تلقی شوند.
## ۱. بازیگران و مسئولیت‌ها
| بازیگر | مسئولیت‌ها |
|---|---|
| دانشجو (Student) | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
| استاد (Professor) | ثبت و پیگیری گزارش خرابی، ارائه اطلاعات تکمیلی و تأیید یا رد نتیجه تعمیر |
| کارمند تأسیسات (Facilities Staff) | بررسی و فیلتر گزارش‌ها، تعیین اولویت، تخصیص تعمیرکار، به‌روزرسانی وضعیت و مشاهده تاریخچه |
| تعمیرکار (Technician) | مشاهده مأموریت‌های تخصیص‌یافته، شروع تعمیر، ثبت نتیجه و درخواست اطلاعات تکمیلی |
| مدیر (Manager) | مشاهده داشبورد مدیریتی؛ سطح دسترسی دقیق این نقش باید در نیازمندی‌ها مشخص شود |
| کاربر سیستم (System User) | عنوان عمومی کاربر احراز هویت‌شده در داستان‌های ورود و اعلان؛ لزوماً یک نقش انسانی مستقل نیست |
## ۲. نمودار فعالیت احراز هویت (Authentication Activity)
**داستان کاربری مرتبط:** US-15 — ورود به سیستم (Log in).
این نمودار فرایند عمومی ورود کاربر را نشان می‌دهد. روش دقیق احراز هویت، بازیابی رمز عبور و سیاست قفل حساب در این بخش مشخص نشده‌اند.
```mermaid
flowchart TD
A([شروع]) --> B[باز کردن صفحه ورود]
B --> C[وارد کردن نام کاربری و رمز عبور]
C --> D[ارسال فرم ورود]
D --> E{آیا اطلاعات ورود معتبر هستند؟}
E -->|خیر| F[نمایش خطای ورود]
F --> C
E -->|بله| G[احراز هویت کاربر]
G --> H[تشخیص نقش کاربر]
H --> I[نمایش داشبورد متناسب با نقش کاربر]
I --> J([پایان])
```
## ۳. نمودار فعالیت ثبت گزارش خرابی (Fault Reporting Activity)
**داستان‌های کاربری مرتبط:**
- US-01 — دانشجو گزارش خرابی ثبت می‌کند.
- US-02 — استاد گزارش خرابی ثبت می‌کند.
- US-03 — دانشجو یا استاد وضعیت گزارش را پیگیری می‌کند.
- US-04 — دانشجو یا استاد اطلاعات تکمیلی ارائه می‌دهد.
دانشجو و استاد از جریان کاری کلی یکسانی برای گزارش خرابی استفاده می‌کنند؛ بنابراین در یک گروه مسئولیت نمایش داده شده‌اند.
```mermaid
flowchart TD
subgraph Reporter["دانشجو / استاد"]
A([شروع]) --> B[باز کردن صفحه ثبت گزارش خرابی]
B --> C[وارد کردن جزئیات خرابی]
C --> D[ثبت و ارسال گزارش خرابی]
H[اصلاح اطلاعات گزارش]
I[مشاهده وضعیت گزارش]
J[ارائه اطلاعات تکمیلی]
end
subgraph System["سیستم"]
E{آیا اطلاعات واردشده معتبر هستند؟}
F[نمایش خطاهای اعتبارسنجی]
G[ذخیره گزارش خرابی]
K[قرار دادن گزارش در فهرست گزارش‌های قابل بررسی]
L[نمایش وضعیت فعلی گزارش]
end
D --> E
E -->|خیر| F
F --> H
H --> D
E -->|بله| G
G --> K
K --> I
I --> L
L --> M{آیا اطلاعات تکمیلی درخواست شده است؟}
M -->|بله| J
J --> K
M -->|خیر| N([پایان])
```
**نکته مدل‌سازی:** حلقه اصلاح اطلاعات، اعتبارسنجی فرم را نمایش می‌دهد. باید مشخص شود آیا کاربر می‌تواند در هر زمان اطلاعات تکمیلی ارسال کند یا فقط پس از درخواست کارمند تأسیسات یا تعمیرکار مجاز به این کار است.
## ۴. نمودار فعالیت مدیریت گزارش‌ها (Report Management Activity)
**داستان‌های کاربری مرتبط:**
- US-06 — مشاهده و فیلتر گزارش‌های باز.
- US-07 — تعیین اولویت گزارش.
- US-08 — تخصیص تعمیرکار.
- US-09 — به‌روزرسانی وضعیت گزارش.
- US-10 — مشاهده تاریخچه گزارش.
- US-17 — مشاهده داشبورد توسط کارمند تأسیسات یا مدیر.
```mermaid
flowchart TD
subgraph Staff["کارمند تأسیسات"]
A([شروع]) --> B[باز کردن داشبورد مدیریت گزارش‌ها]
B --> C[مشاهده و فیلتر گزارش‌های باز]
C --> D[انتخاب یک گزارش]
E[بررسی جزئیات گزارش]
F[تعیین اولویت گزارش]
G[انتخاب تعمیرکار مناسب]
H[به‌روزرسانی وضعیت گزارش]
I[مشاهده تاریخچه گزارش]
end
subgraph System["سیستم"]
J[نمایش گزارش انتخاب‌شده]
K{آیا گزارش آماده تخصیص است؟}
L[درخواست یا ثبت اطلاعات ناقص]
M[ذخیره اولویت]
N[ذخیره تخصیص تعمیرکار]
O[ذخیره تغییر وضعیت]
P[در دسترس قرار دادن مأموریت برای تعمیرکار]
end
D --> J
J --> E
E --> K
K -->|خیر| L
L --> I
I --> Q([پایان])
K -->|بله| F
F --> M
M --> G
G --> N
N --> P
P --> H
H --> O
O --> I
```
**نکته مدل‌سازی:** تصمیم «آیا گزارش آماده تخصیص است؟» یک مرحله پیشنهادی است. شرایط دقیق تخصیص تعمیرکار و نحوه بازگرداندن گزارش‌های ناقص به گزارش‌دهنده باید در نیازمندی‌ها مشخص شوند.
## ۵. نمودار فعالیت تعمیر خرابی (Repair Activity)
**داستان‌های کاربری مرتبط:**
- US-11 — تعمیرکار کارهای تخصیص‌یافته را مشاهده می‌کند.
- US-12 — تعمیرکار تعمیر را آغاز می‌کند.
- US-13 — تعمیرکار نتیجه تعمیر را ثبت می‌کند.
- US-14 — تعمیرکار درخواست اطلاعات تکمیلی می‌دهد.
```mermaid
flowchart TD
subgraph Technician["تعمیرکار"]
A([شروع]) --> B[باز کردن فهرست کارهای تخصیص‌یافته]
B --> C[انتخاب یک مأموریت]
C --> D[بررسی جزئیات خرابی]
E[شروع فرایند تعمیر]
F[انجام عملیات تعمیر]
G[ثبت نتیجه تعمیر]
H[درخواست اطلاعات تکمیلی]
end
subgraph System["سیستم"]
I[نمایش مأموریت تخصیص‌یافته]
J[به‌روزرسانی وضعیت گزارش]
K{آیا اطلاعات تکمیلی مورد نیاز است؟}
L[ارسال درخواست اطلاعات]
M[ذخیره نتیجه تعمیر]
N[اعلان ثبت نتیجه تعمیر به کاربر مربوطه]
end
C --> I
I --> D
D --> E
E --> J
J --> F
F --> K
K -->|بله| H
H --> L
L --> O[انتظار برای دریافت اطلاعات درخواستی]
O --> F
K -->|خیر| G
G --> M
M --> N
N --> P([پایان])
```
**نکته مدل‌سازی:** در این نمودار، درخواست اطلاعات تکمیلی باعث توقف موقت تعمیر می‌شود. باید مشخص شود چه کسی اطلاعات را ارائه می‌کند، پس از دریافت اطلاعات چگونه به تعمیرکار اطلاع داده می‌شود و آیا هنگام انتظار وضعیت گزارش تغییر می‌کند یا خیر.
## ۶. نمودار فعالیت تأیید تعمیر (Repair Verification Activity)
**داستان کاربری مرتبط:** US-05 — دانشجو یا استاد تکمیل تعمیر را تأیید یا رد می‌کند.
گزارش‌دهنده نتیجه ثبت‌شده تعمیر را بررسی می‌کند و مشخص می‌کند که آیا خرابی برطرف شده است یا خیر.
```mermaid
flowchart TD
subgraph Reporter["دانشجو / استاد"]
A([شروع]) --> B[مشاهده اطلاعات تکمیل تعمیر]
B --> C[بررسی نتیجه تعمیر]
C --> D{آیا خرابی برطرف شده است؟}
E[تأیید تکمیل تعمیر]
F[رد تکمیل تعمیر]
end
subgraph System["سیستم"]
G[ثبت تأیید گزارش‌دهنده]
H[بستن گزارش]
I[ثبت رد نتیجه تعمیر]
J[بازگرداندن گزارش برای پیگیری بیشتر]
end
D -->|بله| E
E --> G
G --> H
H --> K([پایان])
D -->|خیر| F
F --> I
I --> J
J --> L([پایان - نیازمند پیگیری بیشتر])
```
**پرسش باز:** نیازمندی‌ها باید مشخص کنند پس از رد نتیجه تعمیر چه اتفاقی می‌افتد: آیا گزارش به کارمند تأسیسات بازمی‌گردد، دوباره به همان تعمیرکار تخصیص داده می‌شود یا فرایند دیگری اجرا می‌شود؟ این نمودار هیچ‌یک از این سیاست‌ها را به‌عنوان تصمیم قطعی انتخاب نمی‌کند.
## ۷. نمودار کلی چرخه عمر گزارش خرابی (Overall Fault Lifecycle)
این نمودار نمایی کلی از فرایند اصلی سیستم ارائه می‌دهد و مراحل ثبت گزارش، مدیریت، تعمیر و تأیید را به یکدیگر متصل می‌کند.
```mermaid
flowchart TD
A([شروع]) --> B[ثبت گزارش خرابی توسط دانشجو یا استاد]
B --> C{آیا گزارش معتبر است؟}
C -->|خیر| D[اصلاح اطلاعات گزارش توسط گزارش‌دهنده]
D --> B
C -->|بله| E[ذخیره گزارش توسط سیستم]
E --> F[بررسی گزارش توسط کارمند تأسیسات]
F --> G{آیا اطلاعات بیشتری مورد نیاز است؟}
G -->|بله| H[درخواست اطلاعات تکمیلی]
H --> I[ارائه اطلاعات توسط گزارش‌دهنده]
I --> F
G -->|خیر| J[تعیین اولویت توسط کارمند تأسیسات]
J --> K[تخصیص تعمیرکار توسط کارمند تأسیسات]
K --> L[مشاهده مأموریت توسط تعمیرکار]
L --> M[شروع فرایند تعمیر توسط تعمیرکار]
M --> N{آیا تعمیرکار به اطلاعات بیشتری نیاز دارد؟}
N -->|بله| O[درخواست اطلاعات توسط تعمیرکار]
O --> P[ارائه اطلاعات درخواستی]
P --> M
N -->|خیر| Q[ثبت نتیجه تعمیر توسط تعمیرکار]
Q --> R[بررسی نتیجه تعمیر توسط گزارش‌دهنده]
R --> S{آیا گزارش‌دهنده تعمیر را تأیید می‌کند؟}
S -->|بله| T[بستن گزارش توسط سیستم]
T --> U([پایان])
S -->|خیر| V[ثبت عدم تأیید]
V --> W[بازگرداندن گزارش برای پیگیری بیشتر]
W --> F
```
**نکته مدل‌سازی:** بازگشت گزارش ردشده به مرحله بررسی کارمند تأسیسات، یک مسیر پیشنهادی برای پیگیری مجدد است و هنوز سیاست قطعی تخصیص مجدد محسوب نمی‌شود. این مسیر باید با اعضای تیم پروژه بررسی و تأیید شود.
## ۸. پرسش‌ها و ابهام‌های نیازمندی‌ها
موارد زیر باید پیش از نهایی‌شدن نمودارها با اعضای تیم پروژه مشخص شوند:
1. **اعتبارسنجی گزارش:** کدام فیلدها اجباری هستند و چه شرایطی باعث نامعتبر شدن گزارش می‌شود؟
2. **رد گزارش:** آیا کارمند تأسیسات می‌تواند گزارش ثبت‌شده را رد کند؟ در صورت امکان، دلایل و وضعیت‌های مربوط به آن چیست؟
3. **اولویت‌ها:** چه سطوحی برای اولویت وجود دارد و معیار تعیین هر سطح چیست؟
4. **وضعیت‌های گزارش:** فهرست رسمی وضعیت‌ها و انتقال‌های مجاز بین آن‌ها چیست؟
5. **تخصیص تعمیرکار:** آیا یک گزارش می‌تواند به چند تعمیرکار تخصیص داده شود یا در هر لحظه فقط یک تعمیرکار مسئول آن است؟
6. **اطلاعات تکمیلی:** چه افرادی می‌توانند درخواست اطلاعات دریافت کنند و هنگام انتظار برای پاسخ چه اتفاقی می‌افتد؟
7. **تأیید تعمیر:** پس از رد نتیجه تعمیر توسط گزارش‌دهنده، جریان کاری دقیق چیست؟
8. **اعلان‌ها:** کدام رویدادها باعث ارسال اعلان می‌شوند، دریافت‌کنندگان چه کسانی هستند و اعلان‌ها از چه کانالی ارسال می‌شوند؟
9. **دسترسی مدیر:** آیا دسترسی مدیر فقط به مشاهده داشبورد محدود است یا این نقش امکان مدیریت گزارش‌ها را نیز دارد؟
10. **احراز هویت:** آیا قوانین ورود یا کنترل دسترسی برای نقش‌های مختلف متفاوت است؟
+26 -86
View File
@@ -1,103 +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 Stories) و سایر مستندات پروژه تطبیق داده شوند.
---
**وضعیت سند:** نسخهٔ اولیه (Draft) – آمادهٔ بازبینی
این سند نسخهٔ اولیهٔ نیازمندی‌هاست و با تکمیل تحلیل پروژه و دریافت بازخورد اعضای گروه اصلاح خواهد شد.
-393
View File
@@ -1,393 +0,0 @@
# طرح اولیه رابط کاربری (UI Wireframes) – سامانه مدیریت و گزارش خرابی دانشگاهی
**تهیه‌کننده:** رضا آدوسی
**بازبین:** ارشیا همتی‌زاده
**آخرین به‌روزرسانی:** ۱۴۰۵/۰۸/۱۸
**وضعیت سند:** نسخه اولیه (Draft) – آماده بازبینی
---
## ۱. مقدمه
هدف این سند، ارائه طرح اولیه رابط کاربری سامانه مدیریت و گزارش خرابی دانشگاهی (پایا) است. در این طراحی، صفحات اصلی سامانه، اطلاعات قابل مشاهده، ورودی‌های موردنیاز کاربر و پاسخ سیستم به عملیات مختلف مشخص می‌شوند.
تمرکز این مرحله بر روشن بودن مسیر انجام کارها و تعامل کاربران با سامانه است، نه طراحی گرافیکی نهایی. جزئیات ظاهری مانند رنگ‌بندی، فونت و تصاویر در مراحل بعدی توسعه تعیین خواهند شد.
## ۲. نقش‌های کاربری
رابط کاربری سامانه با توجه به نقش و سطح دسترسی کاربران، بخش‌های متفاوتی را نمایش می‌دهد.
| نقش کاربر | وظایف اصلی در سامانه |
|---|---|
| دانشجو | ثبت خرابی، مشاهده و پیگیری گزارش‌ها |
| استاد | ثبت خرابی، مشاهده و پیگیری گزارش‌ها |
| کارمند تأسیسات | بررسی گزارش‌ها، تعیین اولویت و ارجاع به تعمیرکار |
| تعمیرکار | مشاهده وظایف ارجاع‌شده، به‌روزرسانی وضعیت و ثبت نتیجه تعمیر |
| مدیر | مشاهده وضعیت کلی گزارش‌ها و اطلاعات مدیریتی |
## ۳. صفحات اصلی سامانه
### ۳.۱. صفحه ورود (Login)
**کاربران:** تمام نقش‌ها
هدف این صفحه احراز هویت کاربران و ورود به بخش متناسب با سطح دسترسی آن‌هاست.
**طرح اولیه:**
```text
+------------------------------------------+
| سامانه پایا |
| سامانه مدیریت و گزارش خرابی دانشگاه |
| |
| نام کاربری: [________________] |
| |
| رمز عبور: [________________] |
| |
| [ ورود ] |
| |
| پیام خطا: |
| اطلاعات ورود نامعتبر است. |
+------------------------------------------+
```
**ورودی‌ها:**
- نام کاربری
- رمز عبور
**عملیات و پاسخ سیستم:**
- با وارد کردن اطلاعات معتبر، کاربر وارد داشبورد متناسب با نقش خود می‌شود.
- در صورت اشتباه بودن اطلاعات، پیام خطای مناسب نمایش داده می‌شود.
- در صورت خالی بودن فیلدهای ضروری، از ارسال فرم جلوگیری می‌شود.
### ۳.۲. داشبورد دانشجو و استاد
**کاربران:** دانشجو، استاد
این صفحه نقطه شروع فعالیت گزارش‌دهندگان پس از ورود به سامانه است.
**طرح اولیه:**
```text
+------------------------------------------------+
| سامانه پایا [نام کاربر] [خروج] |
+------------------------------------------------+
| منوی اصلی |
| |
| [داشبورد] [ثبت گزارش خرابی] [گزارش‌های من] |
+------------------------------------------------+
| داشبورد |
| |
| تعداد گزارش‌های ثبت‌شده: 5 |
| گزارش‌های در حال بررسی: 2 |
| گزارش‌های در حال تعمیر: 1 |
| گزارش‌های تکمیل‌شده: 2 |
| |
| آخرین گزارش‌ها: |
| +------+-------------+-------------+---------+ |
| | کد | عنوان | تاریخ | وضعیت | |
| +------+-------------+-------------+---------+ |
| | 101 | خرابی پروژکتور| ۱۴۰۵/۰۸/۱۰| در حال بررسی | |
| | 102 | مشکل روشنایی | ۱۴۰۵/۰۸/۱۱| در حال تعمیر | |
| +------+-------------+-------------+---------+ |
| |
| [ ثبت گزارش جدید ] |
+------------------------------------------------+
```
**اطلاعات قابل مشاهده:**
- تعداد گزارش‌های ثبت‌شده توسط کاربر
- تعداد گزارش‌ها بر اساس وضعیت
- فهرست آخرین گزارش‌ها
- شناسه، عنوان، تاریخ و وضعیت هر گزارش
**عملیات:**
- ورود به صفحه ثبت گزارش جدید
- مشاهده فهرست گزارش‌های قبلی
- مشاهده جزئیات و وضعیت هر گزارش
### ۳.۳. صفحه ثبت گزارش خرابی (Create Fault Report)
**کاربران:** دانشجو، استاد
در این صفحه کاربر اطلاعات مربوط به خرابی را وارد و گزارش خود را ثبت می‌کند.
**طرح اولیه:**
```text
+------------------------------------------------+
| ثبت گزارش خرابی |
+------------------------------------------------+
| عنوان خرابی: |
| [________________________________________] |
| |
| توضیحات: |
| [________________________________________] |
| [________________________________________] |
| |
| محل وقوع خرابی: |
| [________________________________________] |
| |
| نوع خرابی: |
| [ انتخاب نوع خرابی ▼ ] |
| |
| اطلاعات تکمیلی / تصویر (اختیاری): |
| [ انتخاب فایل ] |
| |
| [ ثبت گزارش ] |
| [ انصراف ] |
+------------------------------------------------+
```
**ورودی‌ها:**
- عنوان خرابی
- توضیحات خرابی
- محل وقوع خرابی
- نوع خرابی
- فایل یا تصویر مرتبط (اختیاری)
**عملیات و پاسخ سیستم:**
- پس از تکمیل اطلاعات ضروری، کاربر با انتخاب «ثبت گزارش» درخواست خود را ارسال می‌کند.
- سیستم اطلاعات را اعتبارسنجی و گزارش را ذخیره می‌کند.
- در صورت ثبت موفق، پیام تأیید همراه با شناسه گزارش نمایش داده می‌شود.
- در صورت ناقص بودن اطلاعات ضروری، پیام خطای مرتبط نمایش داده می‌شود.
**نمونه پیام موفقیت:**
```text
گزارش خرابی با موفقیت ثبت شد.
شناسه گزارش: 103
وضعیت: ثبت‌شده
```
### ۳.۴. صفحه فهرست و جزئیات گزارش‌ها
**کاربران:** دانشجو، استاد، کارمند تأسیسات، مدیر
این صفحه برای مشاهده گزارش‌ها و بررسی وضعیت آن‌ها استفاده می‌شود. اطلاعات و عملیات قابل دسترس با توجه به نقش کاربر متفاوت خواهد بود.
**طرح اولیه فهرست گزارش‌ها:**
```text
+------------------------------------------------+
| گزارش‌های خرابی |
+------------------------------------------------+
| جست‌وجو: [____________________] |
| وضعیت: [همه وضعیت‌ها ▼] |
| |
| +------+-------------+-------------+----------+|
| | کد | عنوان | محل | وضعیت ||
| +------+-------------+-------------+----------+|
| | 101 | خرابی پروژکتور| کلاس ۱۰۱ | ثبت‌شده ||
| | 102 | مشکل روشنایی | راهرو | در حال تعمیر||
| | 103 | خرابی کولر | کلاس ۲۰۲ | در حال بررسی||
| +------+-------------+-------------+----------+|
| |
| [ مشاهده جزئیات گزارش ] |
+------------------------------------------------+
```
**اطلاعات قابل مشاهده در صفحه جزئیات:**
- شناسه گزارش
- عنوان و توضیحات خرابی
- محل وقوع
- تاریخ ثبت
- وضعیت فعلی
- اولویت (در صورت تعیین)
- مسئول رسیدگی (در صورت ارجاع)
- سوابق تغییر وضعیت و اقدامات انجام‌شده
**عملیات:**
- جست‌وجو و فیلتر گزارش‌ها
- مشاهده جزئیات گزارش
- مشاهده تاریخچه تغییرات، متناسب با سطح دسترسی کاربر
### ۳.۵. داشبورد کارمند تأسیسات
**کاربر:** کارمند تأسیسات
این صفحه برای بررسی گزارش‌های ثبت‌شده، تعیین اولویت و ارجاع آن‌ها به تعمیرکار طراحی می‌شود.
**طرح اولیه:**
```text
+------------------------------------------------+
| داشبورد کارمند تأسیسات [نام کاربر] [خروج]|
+------------------------------------------------+
| [گزارش‌های جدید] [در حال بررسی] [ارجاع‌شده] |
+------------------------------------------------+
| گزارش‌های نیازمند بررسی |
| |
| +------+-------------+------------+-----------+|
| | کد | عنوان | محل | اولویت ||
| +------+-------------+------------+-----------+|
| | 101 | خرابی پروژکتور| کلاس ۱۰۱ | تعیین‌نشده||
| | 103 | خرابی کولر | کلاس ۲۰۲ | تعیین‌نشده||
| +------+-------------+------------+-----------+|
| |
| [ بررسی گزارش ] |
+------------------------------------------------+
```
**عملیات در صفحه بررسی گزارش:**
- مشاهده اطلاعات گزارش
- تعیین اولویت گزارش
- ثبت توضیحات یا درخواست اطلاعات تکمیلی
- انتخاب تعمیرکار و ارجاع گزارش
- مشاهده وضعیت گزارش‌های قبلی
**پاسخ سیستم:**
- پس از تعیین اولویت، اطلاعات گزارش به‌روزرسانی می‌شود.
- پس از ارجاع موفق، گزارش به فهرست وظایف تعمیرکار اضافه می‌شود.
- در صورت نامعتبر بودن ارجاع یا انتخاب نکردن تعمیرکار، پیام خطا نمایش داده می‌شود.
### ۳.۶. داشبورد تعمیرکار
**کاربر:** تعمیرکار
تعمیرکار از این صفحه برای مشاهده وظایف ارجاع‌شده و ثبت پیشرفت کار استفاده می‌کند.
**طرح اولیه:**
```text
+------------------------------------------------+
| داشبورد تعمیرکار [نام کاربر] [خروج]|
+------------------------------------------------+
| وظایف ارجاع‌شده |
| |
| +------+-------------+------------+-----------+|
| | کد | عنوان | محل | وضعیت ||
| +------+-------------+------------+-----------+|
| | 101 | خرابی پروژکتور| کلاس ۱۰۱ | ارجاع‌شده||
| | 102 | مشکل روشنایی | راهرو | در حال تعمیر||
| +------+-------------+------------+-----------+|
| |
| [ مشاهده وظیفه ] |
+------------------------------------------------+
```
**عملیات در صفحه جزئیات وظیفه:**
- مشاهده توضیحات و محل خرابی
- مشاهده اولویت تعیین‌شده
- تغییر وضعیت کار
- ثبت توضیحات مربوط به روند تعمیر
- ثبت نتیجه نهایی تعمیر
**نمونه فرم ثبت نتیجه:**
```text
+------------------------------------------------+
| ثبت نتیجه تعمیر |
+------------------------------------------------+
| گزارش شماره: 101 |
| |
| وضعیت جدید: [تکمیل‌شده ▼] |
| |
| توضیحات اقدامات انجام‌شده: |
| [________________________________________] |
| [________________________________________] |
| |
| [ ثبت نتیجه ] |
+------------------------------------------------+
```
**پاسخ سیستم:**
- پس از ثبت موفق، وضعیت گزارش به‌روزرسانی می‌شود.
- نتیجه تعمیر در سوابق گزارش ذخیره می‌شود.
- در صورت ناموفق بودن عملیات، پیام خطا نمایش داده می‌شود.
### ۳.۷. داشبورد مدیر
**کاربر:** مدیر
این صفحه برای مشاهده وضعیت کلی سامانه و نظارت بر گزارش‌های خرابی طراحی می‌شود.
**طرح اولیه:**
```text
+------------------------------------------------+
| داشبورد مدیریتی [نام کاربر] [خروج]|
+------------------------------------------------+
| گزارش‌های ثبت‌شده: 120 |
| گزارش‌های در حال بررسی: 15 |
| گزارش‌های در حال تعمیر: 20 |
| گزارش‌های تکمیل‌شده: 85 |
+------------------------------------------------+
| |
| گزارش‌ها بر اساس وضعیت |
| |
| [نمایش نمودار یا آمار خلاصه] |
| |
| آخرین گزارش‌های ثبت‌شده |
| [مشاهده فهرست گزارش‌ها] |
+------------------------------------------------+
```
**اطلاعات قابل مشاهده:**
- تعداد کل گزارش‌ها
- تعداد گزارش‌ها بر اساس وضعیت
- آمار کلی عملکرد سامانه
- آخرین گزارش‌های ثبت‌شده
**عملیات:**
- مشاهده گزارش‌های کلی
- بررسی وضعیت گزارش‌ها
- دسترسی به اطلاعات مدیریتی متناسب با سطح دسترسی
## ۴. سناریوی کامل تعامل کاربر با سامانه
برای بررسی ارتباط صفحات و روشن شدن جریان اطلاعات، سناریوی زیر در نظر گرفته شده است.
**سناریو: ثبت و پیگیری خرابی پروژکتور توسط دانشجو**
۱. دانشجو وارد صفحه ورود می‌شود و اطلاعات حساب کاربری خود را وارد می‌کند.
۲. پس از ورود موفق، داشبورد دانشجو نمایش داده می‌شود.
۳. دانشجو گزینه «ثبت گزارش خرابی» را انتخاب می‌کند.
۴. عنوان، توضیحات و محل وقوع خرابی را وارد کرده و گزارش را ثبت می‌کند.
۵. سیستم اطلاعات را اعتبارسنجی می‌کند. در صورت معتبر بودن، گزارش ذخیره شده و یک شناسه یکتا به آن اختصاص داده می‌شود.
۶. کارمند تأسیسات گزارش جدید را در فهرست گزارش‌های نیازمند بررسی مشاهده می‌کند.
۷. کارمند تأسیسات گزارش را بررسی کرده، اولویت آن را تعیین و به یک تعمیرکار ارجاع می‌دهد.
۸. تعمیرکار گزارش را در فهرست وظایف خود مشاهده کرده و پس از شروع کار، وضعیت آن را به‌روزرسانی می‌کند.
۹. پس از انجام تعمیر، تعمیرکار نتیجه اقدامات را ثبت می‌کند.
۱۰. دانشجو می‌تواند با مراجعه به فهرست گزارش‌های خود، وضعیت و نتیجه تعمیر را مشاهده کند.
## ۵. حالت‌های خطا و رفتار مورد انتظار سیستم
| حالت خطا | رفتار مورد انتظار |
|---|---|
| وارد کردن نام کاربری یا رمز عبور اشتباه | نمایش پیام خطای ورود و باقی ماندن در صفحه ورود |
| خالی بودن فیلدهای ضروری هنگام ثبت گزارش | جلوگیری از ثبت و مشخص کردن فیلدهای ناقص |
| بروز خطا هنگام ذخیره گزارش | نمایش پیام عدم موفقیت و امکان تلاش مجدد |
| تلاش کاربر برای مشاهده گزارش غیرمجاز | جلوگیری از دسترسی و نمایش پیام مناسب |
| ارجاع گزارش بدون انتخاب تعمیرکار | جلوگیری از ارجاع و درخواست انتخاب تعمیرکار |
| ثبت نتیجه تعمیر بدون توضیحات ضروری | نمایش خطا و درخواست تکمیل اطلاعات |
## ۶. نکات و تصمیم‌های طراحی
- صفحات بر اساس نقش کاربر طراحی شده‌اند و گزینه‌های قابل مشاهده به سطح دسترسی او وابسته هستند.
- شناسه گزارش پس از ثبت موفق توسط سیستم اختصاص داده می‌شود.
- وضعیت گزارش باید در صفحات مختلف به‌صورت هماهنگ نمایش داده شود.
- اطلاعاتی مانند اولویت، تعمیرکار مسئول و نتیجه تعمیر فقط پس از ثبت توسط کاربران مجاز نمایش داده می‌شوند.
- طراحی فعلی مفهومی است و جزئیات گرافیکی و فنی در مراحل بعدی تکمیل خواهند شد.
- در طراحی نهایی باید از نمایش یا ویرایش اطلاعات توسط کاربران فاقد مجوز جلوگیری شود.
## ۷. نکات و کارهای باقی‌مانده
- بازبینی صفحات توسط اعضای تیم
- تطبیق فیلدهای فرم ثبت خرابی با مستند نیازمندی‌ها و داستان‌های کاربر
- نهایی‌سازی وضعیت‌های ممکن برای گزارش خرابی
- بررسی جزئیات سطح دسترسی هر نقش
- تکمیل طراحی صفحات بر اساس بازخورد تیم و استاد
## ۸. وضعیت سند
نسخه اولیه (Draft) – آماده بازبینی