Reza requirements (#5)

* Add initial requirements specification document for university fault management system

* Update requirements specification document with detailed functional and non-functional requirements, user roles, and system scope.
This commit is contained in:
Reza Adousi
2026-11-02 15:30:10 +03:30
committed by GitHub
parent 700378f5aa
commit 35b295eb50
+86 -26
View File
@@ -1,43 +1,103 @@
# سند نیازمندی‌های سامانهٔ مدیریت و گزارش خرابی دانشگاهی # سند نیازمندی‌ها (Requirements Specification) – سامانه مدیریت و گزارش خرابی دانشگاهی
**تهیه‌کننده:** رضا آدوسی
**بازبین:** ارشیا همتی‌زاده
**آخرین به‌روزرسانی:** ۱۴۰۵/۰۸/۱۱
---
## مقدمه
در این سند، نیازمندی‌های اصلی سامانهٔ مدیریت و گزارش خرابی دانشگاهی در دو دستهٔ **نیازمندی‌های کارکردی (Functional Requirements)** و **نیازمندی‌های غیرکارکردی (Non-functional Requirements)** تعریف شده‌اند.
نیازمندی‌های کارکردی، قابلیت‌ها و وظایفی را مشخص می‌کنند که سامانه باید ارائه دهد و نیازمندی‌های غیرکارکردی، ویژگی‌های کیفی و محدودیت‌های مورد انتظار از سامانه را بیان می‌کنند.
## ۱. هدف و محدودهٔ سامانه ## ۱. هدف و محدودهٔ سامانه
هدف این سامانه، فراهم کردن بستری متمرکز برای ثبت خرابی تجهیزات و فضاهای دانشگاه، پیگیری درخواست‌ها و مدیریت فرایند تعمیر است. سامانه به گزارش‌دهندگان امکان می‌دهد خرابی را ثبت و وضعیت آن را پیگیری کنند و به مسئولان تأسیسات کمک می‌کند درخواست‌ها را بررسی و به تعمیرکاران ارجاع دهند. هدف از توسعهٔ این سامانه، فراهم کردن بستری متمرکز برای ثبت خرابی تجهیزات و فضاهای دانشگاه، پیگیری درخواست‌ها و مدیریت فرایند تعمیر است.
در این مرحله، محدودهٔ دقیق سامانه و امکانات نهایی آن هنوز نیازمند بررسی بیشتر است. سامانه به دانشجویان و استادان امکان می‌دهد خرابی‌های مشاهده‌شده را ثبت و وضعیت رسیدگی به آن‌ها را پیگیری کنند. همچنین کارمندان تأسیسات می‌توانند گزارش‌ها را بررسی، اولویت‌بندی و به تعمیرکاران ارجاع دهند و بر روند رسیدگی نظارت داشته باشند.
محدودهٔ دقیق فضاهای تحت پوشش سامانه، از جمله کلاس‌ها، آزمایشگاه‌ها، فضاهای عمومی، اداری و خوابگاه‌ها، در مراحل بعدی تحلیل مشخص خواهد شد.
## ۲. کاربران سامانه ## ۲. کاربران سامانه
- **دانشجو و استاد:** ثبت گزارش خرابی و مشاهدهٔ وضعیت درخواست. - **دانشجو:** ثبت گزارش خرابی و مشاهده و پیگیری گزارش‌های ثبت‌شده توسط خود.
- **مسئول تأسیسات:** بررسی گزارش‌ها، تعیین اولویت و ارجاع درخواست‌ها. - **استاد:** ثبت خرابی‌های مربوط به کلاس‌ها و آزمایشگاه‌ها و پیگیری وضعیت گزارش‌ها.
- **تعمیرکار:** مشاهدهٔ درخواست‌های ارجاع‌شده و ثبت نتیجهٔ تعمیر. - **کارمند تأسیسات:** بررسی گزارش‌ها، تعیین اولویت، ارجاع درخواست‌ها و نظارت بر فرایند تعمیر.
- **تعمیرکار:** مشاهدهٔ درخواست‌های تخصیص‌یافته، انجام تعمیرات و ثبت نتیجهٔ اقدامات.
- **مدیر:** نظارت بر عملکرد کلی سامانه و مشاهدهٔ اطلاعات و گزارش‌های مدیریتی.
- **کاربر سیستم:** عنوان عمومی برای اشاره به کاربران دارای حساب کاربری و دسترسی به سامانه.
## ۳. نیازمندی‌های کارکردی (Functional Requirements) ## ۳. نیازمندی‌های کارکردی (Functional Requirements)
- **FR-01 — ثبت گزارش خرابی:** سامانه باید امکان ثبت گزارش شامل عنوان، توضیحات، محل خرابی و نوع تجهیز را فراهم کند. ### ۳.۱. مدیریت کاربران و دسترسی
- **FR-02 — مشاهدهٔ گزارش:** کاربر باید بتواند اطلاعات گزارش ثبت‌شده و وضعیت فعلی آن را مشاهده کند.
- **FR-03 — بررسی درخواست:** مسئول تأسیسات باید بتواند گزارش‌های ثبت‌شده را بررسی کند. - **FR-01 — ورود به سامانه:** سامانه باید امکان ورود کاربران از طریق نام کاربری و رمز عبور را فراهم کند.
- **FR-04 — تعیین اولویت:** مسئول تأسیسات باید بتواند اولویت رسیدگی به هر گزارش را مشخص کند. - **FR-02 — کنترل دسترسی:** سامانه باید دسترسی کاربران به امکانات و اطلاعات را بر اساس نقش آن‌ها مدیریت کند.
- **FR-05 — ارجاع به تعمیرکار:** مسئول تأسیسات باید بتواند درخواست را به تعمیرکار مربوطه ارجاع دهد.
- **FR-06 — به‌روزرسانی وضعیت:** وضعیت درخواست باید در مراحل مختلف رسیدگی قابل به‌روزرسانی باشد. ### ۳.۲. ثبت و مدیریت گزارش خرابی
- **FR-07 — ثبت نتیجهٔ تعمیر:** تعمیرکار باید بتواند نتیجهٔ بررسی و اقدامات انجام‌شده را ثبت کند.
- **FR-08 — مشاهدهٔ سوابق:** کاربران مجاز باید بتوانند سوابق درخواست‌ها و تعمیرات را متناسب با سطح دسترسی خود مشاهده کنند. - **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) ## ۴. نیازمندی‌های غیرکارکردی (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) – آمادهٔ بازبینی