قرار هست چی رو بررسی کنیم؟
نیازمندیها را در چه سندی و با چه ساختاری ثبت کنیم که تیم بتواند با اطمینان از رویش کار کند؟
در طراحی سیستمها داشتنِ یک سند رسمی و دقیق برای ثبت نیازمندیها حیاتی است. این سند به همهی اعضای تیم میگوید سیستم دقیقاً قرار است چه کاری بکند، چه محدودیتی دارد و موفقیتش چطور سنجیده میشود.
SRS چیست؟
SRS (Software Requirements Specification) یک مدرک رسمی است که همهی نیازمندیهای عملکردی و غیرعملکردی یک سیستم نرمافزاری را مشخص میکند. پل ارتباطی ذینفعها، تحلیلگرها، طراحها، برنامهنویسها و تستکنندههاست، و اگر این پل خوب ساخته نشود پروژه به خطا میافتد.
ساختار پیشنهادی
۱. معرفی. هدف سند، دامنهی سیستم (Scope)، تعریف اصطلاحهای کلیدی و ارجاع به سندهای دیگر.
۲. نمای کلی سیستم. دیدگاه کلی، کاربران و کنشگرها، محدودیتهای کلی (بستر اجرا، زبان، قوانین)، و فرضها و وابستگیها.
۳. نیازمندیهای عملکردی. برای هر عملکرد: عنوان، توضیح، ورودی و خروجی، کنشگرهای دخیل و اولویت (کم، متوسط، بالا). بهتر است این بخش شمارهگذاریشده و دقیق باشد، مثل 3.1 ثبتنام کاربر، 3.2 ورود به سیستم، 3.3 ارسال پیام.
۴. نیازمندیهای غیرعملکردی. امنیت (رمزنگاری، احراز هویت)، عملکرد (زمان پاسخ، ظرفیت)، قابلیت استفاده، نگهداری و توسعهپذیری، و در دسترس بودن.
۵. رابطهای سیستم. رابط با سیستمهای دیگر، APIها و استانداردهای ارتباطی، پایگاه داده یا فایلها.
۶. معیار پذیرش و اعتبارسنجی. از کجا بفهمیم یک نیازمندی درست پیاده شده؟ چه تستهایی برایش طراحی میشود؟
نکتههای نگارش
- زبان ساده و دقیق و بیابهام
- هر نیازمندی باید قابل سنجش باشد، نه کلی یا ذهنی
- نیازها را طبقهبندی و اولویتبندی کنیم
- جدول، نمودار و Use Case برای روشنتر شدن کمک میکنند
- سند باید در طول پروژه قابل بهروزرسانی و بازبینی باشد
یک نمونهی ساده برای ثبت نیاز عملکردی:
| کد | عنوان نیاز | توضیح | کنشگر | ورودی | خروجی | اولویت |
|---|---|---|---|---|---|---|
| FR-01 | ورود به سیستم | کاربر با وارد کردن نامکاربری و رمز وارد سامانه میشود | کاربر | نامکاربری، رمز | داشبورد | بالا |
به نظرم SRS نقشهی راه پروژه است. اگر تحلیلگر آن را دقیق، قابل فهم و بهروز بنویسد، تیم طراحی و توسعه میتوانند با اطمینان جلو بروند.
مرتبط: 16 مقدمهای بر جمعآوری و تحلیل نیازمندیها (فصل بعد: خودِ نیازها را چطور جمع کنیم).