mirror of
https://github.com/AmirAref/paya-university-fault-system.git
synced 2026-11-03 14:49:38 +00:00
Update requirements specification document with detailed functional and non-functional requirements, user roles, and system scope.
This commit is contained in:
@@ -1,43 +1,103 @@
|
||||
# سند نیازمندیهای سامانهٔ مدیریت و گزارش خرابی دانشگاهی
|
||||
# سند نیازمندیها (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-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 — داشبورد مدیریتی:** سامانه باید امکان مشاهدهٔ اطلاعات کلی مانند تعداد گزارشهای ثبتشده، گزارشهای باز و درخواستهای فوری را برای مدیر و کارمندان تأسیسات فراهم کند.
|
||||
|
||||
## ۴. نیازمندیهای غیرکارکردی (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) – آمادهٔ بازبینی
|
||||
Reference in New Issue
Block a user