mirror of
https://github.com/AmirAref/paya-university-fault-system.git
synced 2026-11-03 06:39:38 +00:00
amir
407596264f
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
9.8 KiB
9.8 KiB
سند نیازمندی‌ها (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 — داشبورد مدیریتی: سامانه باید امکان مشاهدهٔ اطلاعات کلی مانند تعداد گزارش‌های ثبت‌شده، گزارش‌های باز و درخواست‌های فوری را برای مدیر و کارمندان تأسیسات فراهم کند.
۴. نیازمندی‌های غیرکارکردی (Non-functional Requirements)
۴.۱. امنیت و کنترل دسترسی
- NFR-01 — امنیت اطلاعات: سامانه باید از دسترسی غیرمجاز، افشای اطلاعات و تغییرات غیرمجاز در داده‌ها جلوگیری کند.
- NFR-02 — حفظ حریم خصوصی: اطلاعات کاربران و گزارش‌ها باید متناسب با سطح دسترسی هر نقش در اختیار افراد قرار گیرد.
۴.۲. سهولت استفاده
- NFR-03 — کاربردپذیری: رابط کاربری و فرم‌های ثبت و پیگیری گزارش باید ساده، قابل فهم و متناسب با نیاز کاربران طراحی شوند.
۴.۳. کارایی و عملکرد
- NFR-04 — زمان پاسخ‌گویی: عملیات معمول سامانه، مانند ثبت گزارش و مشاهدهٔ وضعیت، باید در زمان قابل قبول انجام شوند.
۴.۴. قابلیت اطمینان
- NFR-05 — صحت و نگهداری اطلاعات: سامانه باید اطلاعات ثبت‌شده را به‌درستی نگهداری کند و از حذف یا تغییر ناخواستهٔ آن‌ها جلوگیری کند.
۴.۵. قابلیت نگهداری و توسعه
- NFR-06 — قابلیت نگهداری: ساختار سامانه باید امکان اصلاح، نگهداری و افزودن قابلیت‌های جدید را در آینده فراهم کند.
۵. نکات و پرسش‌های باز
- این نیازمندی‌ها نسخهٔ اولیه هستند و ممکن است در مراحل بعدی تحلیل و بازبینی تغییر کنند یا نیازمندی‌های جدیدی به آن‌ها اضافه شود.
- محدودهٔ دقیق فضاهای تحت پوشش سامانه، از جمله خوابگاه‌ها و فضاهای اداری، هنوز مشخص نشده است.
- معیارهای دقیق اولویت‌بندی خرابی‌ها و نحوهٔ تشخیص درخواست‌های فوری باید تعیین شوند.
- روش اطلاع‌رسانی به کاربران، مانند اعلان داخل سامانه، پیامک یا ایمیل، هنوز مشخص نشده است.
- جزئیات سطح دسترسی هر نقش و شرایط بسته‌شدن نهایی درخواست‌ها باید در مراحل بعدی مشخص شوند.
- هر نیازمندی باید حداقل با یک داستان کاربر (User Story) تطبیق داده شود. ارجاع‌ها در فیلد «نیازمندی‌های مرتبط» همان سند user-story.md ثبت شده‌اند.
وضعیت سند: نسخهٔ اولیه (Draft) – آمادهٔ بازبینی