صفحه 45 منبع

4. تعیین نیازمندی‌ها به‌عنوان یک تکنیک مرکزی

تعیین نیازمندی‌ها (Requirements Definition) نیازمندی‌های کارکردی و غیرکارکردی سیستم اطلاعاتی آینده را مشخص می‌کند. اهداف اصلی عبارت‌اند از:

• تشخیص و شناسایی نیازمندی‌های کاربران و کل سازمان/شرکت از سیستم آینده؛
• بیان نیازمندی‌ها به‌صورت کمیت‌های قابل اندازه‌گیری؛
• اطمینان از تمرکز بر خواسته‌هایی که از سیستم آینده انتظار می‌رود.

حاصل این فرایند «فهرست نیازمندی‌ها» یا «کاتالوگ نیازمندی‌ها» (Requirements Catalogue) است که در جریان بررسی سیستم تهیه می‌شود، اما فعالیت‌های دیگر الگوی پایه توسعه سیستم نیز از آن استفاده می‌کنند (شکل 20).

فهرست نیازمندی‌ها یکی از مهم‌ترین اجزای مشخصات نیازمندی‌ها است؛ این فهرست توصیفی کامل و دقیق از خواسته‌های مطرح‌شده برای سیستم آینده ارائه می‌کند و در نتیجه مبنای مراحل طراحی نیز هست.

مشخصات نیازمندی‌ها یک محصول مرکب است که مهم‌ترین بخش‌های مربوط به نیازمندی‌های پردازش داده در «مدل مفهومی»، «طرح رابط سیستم»، «مدل گردش کار» و «طرح داخلی» را در خود جای می‌دهد.

پاورقی 13: [CCTA95]، [CCTA95A]، Reference Manual Part 3: The Business Context, Requirements Definition, 3-25—3-46؛ Users Guide Part 2: Investigation, Requirements Definition. همچنین [CCAT90].

شکل 20. جایگاه فهرست نیازمندی‌ها در الگوی پایه توسعه سیستم. اجزای شکل: ساختار تصمیم‌گیری؛ بررسی/ارزیابی وضعیت؛ سازمان کاربران؛ مفاهیم و رویه‌ها؛ مشخصات؛ مدل مفهومی؛ طرح داخلی؛ طرح رابط سیستم؛ ساخت سیستم؛ فهرست نیازمندی‌ها.

صفحه 46 منبع

اصل پایه: سیستم اطلاعاتی برای کمک و پشتیبانی از مشاغل کاربران ایجاد می‌شود. فعالیت‌های سازمان در قالب وظایف گروه‌بندی می‌شوند و نقش‌های کاربری آن‌ها را انجام می‌دهند؛ نقش‌ها نیز در سازمان به افراد تخصیص می‌یابند. در حالت معمول، نیازمندی‌های فناوری اطلاعات از شرح شغل‌ها استخراج می‌شوند، نه برعکس.

تعیین نیازمندی‌ها تکنیکی تکرارشونده (Iterative) است و هم‌زمان با پیشرفت پروژه جزئیات بیشتری را آشکار می‌کند. میزان جزئیات لازم در نقاط و مراحل مختلف پروژه موضوع قضاوت حرفه‌ای است و نمی‌توان آن را صرفاً از یک قاعده رسمی نتیجه گرفت.

هر نیازمندی باید دارای ویژگی‌های زیر باشد:

• قابل اندازه‌گیری باشد؛
• به‌اندازه کافی جزئی باشد تا ابهام نداشته و بتوان بر اساس آن تصمیم گرفت؛
• در محصولات مختلف مشخصات، افزونگی غیرضروری و تکرار دوباره شرح نیازمندی‌ها را کاهش دهد.

4.1 فهرست نیازمندی‌ها

فهرست نیازمندی‌ها مخزن مرکزی اطلاعات مربوط به نیازمندی‌ها و ابزاری برای ثبت انعطاف‌پذیر آن‌ها و پیگیری سرنوشت هر نیازمندی است. این فهرست در ابتدای مرحله تحلیل نیازمندی‌ها تهیه می‌شود یا ممکن است در جریان مطالعه امکان‌سنجی ایجاد شده باشد. در ابتدا نیازها به‌صورت کلی ثبت می‌شوند. با پیشرفت پروژه، محتوای فهرست و مدخل‌های آن گسترش می‌یابد و دقیق‌تر می‌شود. رشد زیاد ممکن است ایجاب کند که فهرست به واحدهای کوچک‌تر، مثلاً بر اساس حوزه‌های کاری بررسی‌شده یا زیرسیستم‌ها، تقسیم شود.

فهرست نیازمندی‌ها بر مدل فعالیت سازمانی (BAM) تکیه دارد و بنابراین باید بر آینده متمرکز باشد؛ هرچند بخشی از نیازمندی‌ها ممکن است از مشکلات سیستم فعلی استخراج شوند. سیستم‌های موجود، همراه با رویه‌های دستی، با استفاده از مدل جریان داده و مدل منطقی داده قابل مدل‌سازی‌اند.

4.1.1 فهرست نیازمندی‌ها و ابزارهای CASE

در حالت ایده‌آل، در یک ابزار پیشرفته پشتیبانی نرم‌افزاری، فهرست نیازمندی‌ها به‌صورت یکی از نماهای داده‌ها/اطلاعات ذخیره‌شده نمایش داده می‌شود. در این حالت، محتوای آن به‌صورت یکپارچه با سایر محصولات SSADM، مانند مدل منطقی داده، تعریف عملکردها و دیالوگ‌ها، مرتبط است و به‌طور خودکار با آن‌ها سازگاری دارد. بنابراین پاسخ به هر نیازمندی، به‌واسطه ارتباط خودکار میان محصولات، در محصولات مشخصات و طراحی قابل رهگیری خواهد بود.

صفحه 47 منبع

نیازمندی‌های کارکردی و غیرکارکردی هر دو در فهرست نیازمندی‌ها ثبت می‌شوند. برای هر نیازمندی اطلاعات زیر باید نگهداری شود:

• شناسه نیازمندی: شناسه یکتا و بدون ابهام.
• نام نیازمندی: نام توصیفی و گویا.
• فعالیت سازمانی/کسب‌وکار: نام فعالیتی که تحقق این نیازمندی از آن پشتیبانی می‌کند.
• منبع: منشأ نیازمندی؛ مانند شخص، سند، محصول SSADM و غیره.
• اهمیت (اولویت): اهمیت تعیین‌شده از سوی کاربر؛ مثلاً زیاد/کم یا اجباری/مطلوب/اختیاری.
• مسئول: نام کاربر یا واحد سازمانی مسئول هماهنگی‌ها و مذاکره‌های مرتبط با نیازمندی.
• نیازمندی کارکردی: شرح خدمت یا ویژگی موردنیاز سیستم.
• نیازمندی غیرکارکردی: شرح نیازمندی غیرکارکردی و، در صورت امکان، مقدار هدف، دامنه قابل قبول (حداقل و حداکثر) و یادداشت‌های تکمیلی برای مشخص‌کردن آن.
• منفعت/سود: توصیف منافع حاصل از برآورده‌شدن نیازمندی.
• یادداشت‌ها و راه‌حل‌های پیشنهادی: ثبت راه‌حل‌های قابل طرح برای پیاده‌سازی نیازمندی و یادداشت‌های عمومی، با امکان ارجاع متقابل به عوامل بحرانی موفقیت.

شکل 21. فهرست نیازمندی‌ها در ساختار محصولات. اجزای شکل، مسیر فهرست نیازمندی‌ها را در تحلیل نیازمندی‌ها، مشخصات نیازمندی‌ها، مشخصات منطقی سیستم، طرح منطقی و طرح فیزیکی نشان می‌دهد.

صفحه 48 منبع

ادامه اطلاعاتی که برای هر نیازمندی ثبت می‌شود:

• اسناد مرتبط: ارجاع به هر سند مرتبط، مانند اسناد کاربران، نمودار جریان داده و منشور پروژه.
• نیازمندی‌های مرتبط: اگر نیازمندی‌ها بر یکدیگر اثر می‌گذارند یا با هم تعارض دارند، باید ارجاع متقابل داشته باشند تا اثر هر تغییر در یک نیازمندی بر سایر نیازمندی‌ها قابل ارزیابی باشد.
• راه‌حل‌ها: ثبت راه‌حل‌های احتمالی، مثلاً ارجاع به تعریف عملکردهای متناظر. اگر تصمیم گرفته شود یک نیازمندی اجرا نشود، علت آن باید ثبت شود؛ مثلاً تصمیم حاصل از تحلیل گزینه‌های سیستم.

4.2 تکنیک تعیین نیازمندی‌ها

در این بخش مراحل اصلی تعیین نیازمندی‌ها تشریح می‌شود.

4.2.1 شناسایی نیازمندی‌های عمومی و شرایط مرزی

نیازمندی‌ها، مقررات و شرایط عمومی موجود در سازمان برای پروژه مشخص نیز ایجاد الزام می‌کنند. برخی نیازمندی‌ها می‌توانند تفسیر پروژه‌ایِ مقررات عمومی سازمان باشند؛ برای مثال سیاست‌های شرکت درباره روابط عمومی یا نحوه برخورد با مشتریان.

همچنین تطابق با توسعه‌های سیستم اطلاعاتی مقرر در برنامه راهبردی فناوری اطلاعات یا با اهداف عمومی حوزه کاریِ تحت بررسی می‌تواند نیازمندی‌های ویژه‌ای ایجاد کند.

شکل 22. مراحل تعیین نیازمندی‌ها: شناسایی نیازمندی‌های عمومی و شرایط مرزی؛ توسعه مدل فعالیت سازمانی (BAM)؛ بررسی نیازمندی‌های باقی‌مانده از مطالعات قبلی؛ شناسایی نقش‌های کاربری و تعیین میزان امکان تغییر آن‌ها؛ توسعه نیازمندی‌های کارکردی؛ بررسی امکان بهره‌برداری از سیستم‌های موجود؛ توسعه نیازمندی‌های غیرکارکردی؛ مستندسازی یافته‌ها در فهرست نیازمندی‌ها.

صفحه 49 منبع

4.2.2 توسعه مدل فعالیت سازمانی (BAM)

BAM مشخص می‌کند کدام فعالیت‌ها به پشتیبانی اطلاعاتی نیاز دارند. BAM توسعه‌یافته باید نیازمندی‌ها را در حوزه‌های زیر شناسایی کند:

• پشتیبانی اطلاعاتی از عملیات و فعالیت‌های جاری سازمان؛
• الزامات الزام‌آور مربوط به فعالیت‌های سازمان برای حفظ به‌روز بودن سیستم اطلاعاتی؛
• ارتباط و تبادل اطلاعات بین فعالیت‌ها؛
• ارتباط با محیط خارج؛
• امکان خودکارسازی برخی فعالیت‌ها؛
• گردآوری و ارائه داده‌های عملکرد؛
• آماده‌سازی اطلاعات لازم برای تصمیم‌های مربوط به فعالیت‌های کنترلی و مداخلات اصلاحی.

توجه: هر نیاز اطلاعاتی لزوماً به شکل یک نیازمندی فناوری اطلاعات ظاهر نمی‌شود؛ و برعکس، همه راه‌حل‌های فناوری اطلاعات نیز الزاماً با SSADM توسعه داده نمی‌شوند؛ نمونه‌هایی از این موارد پست الکترونیکی و صفحات گسترده مانند MS-Office Excel هستند.

4.2.3 نیازمندی‌های حاصل از مطالعات قبلی

ممکن است فهرست نیازمندی‌های نیمه‌تکمیل‌شده‌ای از کارهای پیشین وجود داشته باشد. نیازهای عمده‌ای که در برنامه‌ریزی راهبردی سازمانی و/یا فناوری اطلاعات شناسایی شده‌اند یا اسنادی که در جریان مطالعه امکان‌سنجی پروژه تهیه شده‌اند، می‌توانند به کار گرفته شوند.

4.2.4 شناسایی نقش‌های کاربری و تعیین میزان امکان تغییر آن‌ها

تعیین درجه تغییرپذیری نقش‌های کاربری عامل مهمی است و در تعیین نیازمندی‌ها، گزینه‌های سازمان‌دهی سیستم و مدل گردش کار نقش اساسی دارد. در برخی پروژه‌ها نقش‌های کاربری قابل تغییر نیستند و خدمات اطلاعاتی باید بر همان اساس ارائه شوند؛ مثلاً چون نقش موردنظر در سیستم‌های دیگری نیز مشارکت دارد و قبلاً تعریف شده است. در این حالت تنها تغییر مجاز، اصلاح جزئیات اجرای فعالیت و نحوه استفاده از خدمات فناوری اطلاعات است و بیان نیازمندی‌ها باید بر نیازهای پشتیبانی اطلاعاتی متمرکز باشد.

صفحه 50 منبع

در برخی پروژه‌ها مجوز بازتعریف نقش‌های کاربری برای بهبود گردش کار داده می‌شود؛ مثلاً برای حذف فعالیت‌های تکراری، کاهش تعداد افراد درگیر در یک فعالیت، ساده‌کردن ارتباطات یا بهره‌گیری حداکثری از فناوری اطلاعات. در چنین حالتی نیازمندی‌ها باید هم گردش کار و هم نیازهای فناوری اطلاعات را پوشش دهند.

4.2.5 توسعه نیازمندی‌های کارکردی

خدمات اطلاعاتی لازم برای برآورده‌کردن نیازمندی‌های کارکردی در مدل فعالیت سازمانی (BAM) شناسایی می‌شوند و در عمل در مدل مفهومی معماری سه‌شِمایی مشخص خواهند شد، از جمله:

• تولید داده/اطلاعات برای پشتیبانی فعالیت‌ها - یعنی پرس‌وجوها (Queries)؛
• حفظ به‌روز بودن داده‌ها - فراهم‌کردن ورودی‌های لازم برای حفظ وضعیت جاری و سپس ایجاد خروجی‌های موردنیاز از داده‌های جاری؛
• خودکارسازی احتمالی برخی فعالیت‌های سازمانی.

نحوه گروه‌بندی این خدمات و اینکه هر خدمت در اختیار چه کسی قرار می‌گیرد با مدل گردش کار رابطه نزدیکی دارد؛ مشخصات دقیق آن‌ها در طرح رابط سیستم ارائه می‌شود.

4.2.5.1 استخراج نیازمندی‌های کارکردی از مدل فعالیت سازمانی (BAM)

فعالیت‌های سازمان به اطلاعات نیاز دارند. این اطلاعات می‌تواند از سه منبع تأمین شود:

• سیستم اطلاعاتی که بخشی از سیستم رایانه‌ایِ در حال طراحی است، یعنی همان سیستمی که با SSADM توسعه می‌دهیم؛
• محیط خارجی؛
• سایر فعالیت‌ها.

فهرست نیازمندی‌ها باید نیازهای فناوری اطلاعات مربوط به دسترسی به سایر سیستم‌های خودکار را نیز دربر گیرد.

نیازهای اطلاعاتی لازم برای پشتیبانی عملیات سازمان، در قالب نیازمندی‌های کارکردی، حوزه‌هایی مانند موارد زیر را شامل می‌شود:

• اندازه‌گیری عملکرد فعالیت‌ها و مقایسه آن با مقادیر مورد انتظار؛ تعیین اینکه چه داده‌هایی باید جمع‌آوری شوند و آیا باید فوراً گزارش شوند یا در سیستم اطلاعاتی ذخیره شوند؛

صفحه 51 منبع

• پشتیبانی از فعالیت‌های کنترلی و حل تعارض. این فعالیت‌ها معمولاً به مداخله انسانی نیاز دارند و نمی‌توان آن‌ها را کاملاً خودکار کرد. معمولاً به پرس‌وجو، فهرست‌کردن و مرور داده، «داده‌کاوی»، پشتیبانی تصمیم، واردکردن داده‌ها - مثلاً از صفحات گسترده Excel - و مدل‌سازی برای پرسش‌های «اگر چنین شود چه؟» نیاز است.

4.2.5.2 نیازمندی‌های کارکردی و گردش کار

همان‌گونه که پیش‌تر بیان شد، نگاشت مدل فعالیت سازمانی بر ساختار سازمان، مدل گردش کار را به وجود می‌آورد. مسئولیت اجرای فعالیت‌ها به نقش‌های کاربری مناسب تخصیص می‌یابد. مدل گردش کار به دو شکل با نیازمندی‌های کارکردی مرتبط است:

1. گروه‌بندی کارکردیِ نیازهای پشتیبانی اطلاعاتی

مدل گردش کار فعالیت‌های سازمانی را در قالب وظایف گروه‌بندی می‌کند؛ هر وظیفه توسط یک کاربر/نقش واحد انجام می‌شود. نیازهای به‌روزرسانی و پرس‌وجویی که از فعالیت‌های داخل یک وظیفه پشتیبانی می‌کنند باید گردآوری شوند و در قالبی قابل استفاده بسته‌بندی و عرضه گردند. این گروه‌بندی موضوع «تعریف عملکرد» است.

در پروژه‌هایی که نقش‌های کاربری قابل تغییر نیستند، طرح رابط سیستم عمدتاً با وظایف کاربری‌ای تعیین می‌شود که باید در پروژه از نظر فناوری اطلاعات پشتیبانی شوند. حوزه‌های پوشش‌داده‌شده توسط این وظایف همان نیازمندی‌های کارکردی را تشکیل می‌دهند.

در پروژه‌هایی که بازطراحی نقش‌ها مجاز است، نیازمندی‌های کارکردی در تعامل پیچیده میان مدل گردش کار، تعریف عملکرد، ارزیابی نمونه اولیه و طراحی دیالوگ شکل می‌گیرند.

2. تعیین مرز بین فعالیت‌های دستی و خودکار

معمولاً برای خودکارسازی فعالیت‌ها چند گزینه وجود دارد؛ هرچند بعید است فعالیتی که از قبل در سیستم فناوری اطلاعات جاری خودکار بوده به فعالیت دستی تبدیل شود.

پس از تصمیم‌گیری درباره فعالیت‌های قابل خودکارسازی، آن فعالیت‌ها بخشی از مدل مفهومی می‌شوند، زیرا تغییر نقش‌های کاربری یا فناوری اطلاعات نباید ماهیت آن‌ها را تغییر دهد. طرح رابط سیستم، خدمات و رابط‌های مرتبط با این فعالیت‌ها و همچنین نیازهای پرس‌وجو و به‌روزرسانی بخش‌های دستی را مشخص می‌کند.

صفحه 52 منبع

4.2.6 بررسی امکان بهره‌برداری از سیستم‌های موجود

ممکن است فرصت‌ها یا نیازمندی‌هایی برای استفاده از بخش‌هایی از سیستم‌های فناوری اطلاعات موجود وجود داشته باشد، از جمله از طریق:

• اتصال سیستم‌ها به یکدیگر؛
• به‌ارث‌بردن یا مهاجرت داده‌های ذخیره‌شده، یعنی تبدیل و نصب آن‌ها در سیستم جدید؛
• جایگزینی سیستم‌های قدیمی ولی استفاده مجدد از برخی اجزا، مانند قالب صفحه‌ها و ماژول‌های برنامه.

نیاز به استفاده بالقوه از سیستم‌های موجود باید در بخش «یادداشت‌ها/راه‌حل‌های پیشنهادی» فهرست نیازمندی‌ها مستند شود.

بخشی از نیازمندی‌های غیرکارکردی ممکن است از مشکلات سیستم‌های موجود ناشی شوند. باید روشن شود ماهیت مشکل چیست: آیا آنچه سیستم انجام می‌دهد نادرست است یا شیوه انجام آن نامناسب است.

4.2.7 توسعه نیازمندی‌های غیرکارکردی

نیازمندی‌های غیرکارکردی بیان می‌کنند یک خدمت یا مجموعه‌ای از خدمات با چه کیفیت یا در چه سطحی باید ارائه شود. پرداختن به این نیازمندی‌ها برای موفقیت سیستم حیاتی است؛ برای نمونه توافق بر نیازمندی‌های سطح خدمت (Service Level) درباره عملکرد و دسترس‌پذیری سیستم.

یک نیازمندی غیرکارکردی ممکن است بر کل سیستم یا تنها بر بخشی از خدمات اعمال شود. دامنه آن با نیازمندی‌های کارکردیِ مرتبط تعیین می‌شود؛ مثلاً نیاز زمان پاسخ می‌تواند به یک پرس‌وجو خاص مربوط باشد.

دامنه اعتبار نیازمندی‌های غیرکارکردی باید در طول تحلیل پیوسته پایش و در صورت نیاز اصلاح شود؛ برای مثال ممکن است مشخص شود الزامی که ابتدا برای کل سیستم فرض شده، فقط برای بخشی مشخص لازم است.

4.2.8 مستندسازی یافته‌ها در فهرست نیازمندی‌ها

فهرست نیازمندی‌ها با وجود انعطاف‌پذیری برای مستندسازی و پیگیری، به تنهایی برای پایه طراحی فناوری اطلاعات دقت فنی کافی ندارد، زیرا توصیف‌ها معمولاً به زبان طبیعی نوشته می‌شوند. در مرحله «مشخصات نیازمندی‌ها» تکنیک‌های دقیق‌تر و صوری‌تری مانند تعریف عملکرد، مدل‌سازی منطقی داده و مدل‌سازی رفتار موجودیت به کار می‌روند تا سیستم را با تکیه بر مدخل‌های مرتبط فهرست نیازمندی‌ها، با جزئیات و دقت بیشتری مدل کنند.

صفحه 53 منبع

مدخل‌هایی که توسط هیچ‌یک از تکنیک‌های بالا بیشتر پردازش نمی‌شوند باید در فهرست نیازمندی‌ها تا مرحله مشخصات نیازمندی‌ها و سپس طراحی منطقی و گزینه‌های فنی سیستم همراه پروژه باقی بمانند. این موارد می‌توانند شامل محدودیت‌ها و شرایط کل سیستم و نیازمندی‌های مربوط به گفت‌وگوی انسان-ماشین و رابط کاربری باشند.

4.2.8.1 کمی‌سازی نیازمندی‌ها

در سراسر پروژه، تحلیلگر سیستم باید با قضاوت حرفه‌ای تشخیص دهد آیا نیازمندی‌ها با توجه به مرحله پروژه و سطح جزئیات تکنیک مورد استفاده، به اندازه کافی قابل اندازه‌گیری بیان شده‌اند یا خیر. برای مثال، تعیین سطح خدمت باید مقدار هدف و دامنه مقادیر قابل قبول را مشخص کند. این کار از سوءتفاهم جلوگیری کرده و امکان آزمون دستیابی سیستم پیاده‌شده به اهداف را فراهم می‌سازد.

کمی‌سازی نیازمندی‌ها دو هدف دارد: ایجاد توافق درباره انتظارات از سیستم و فراهم‌کردن امکان اثبات اینکه سیستم تحویل‌شده واقعاً مطابق خواسته‌ها ساخته شده است. مقادیر کمی‌شده می‌توانند در فرایند تحویل و پذیرش به‌عنوان معیار پذیرش و همچنین در تضمین کیفیت و بازبینی پس از خاتمه پروژه استفاده شوند.

حتی برای نیازمندی‌های نسبتاً ذهنی نیز می‌توان معیار مناسب تعریف کرد. اگر رضایت مشتریان یک شرکت باید سنجیده شود، تعداد شکایت‌ها و اعتراض‌های ثبت‌شده در هر ماه می‌تواند معیار باشد. سپس می‌توان اندازه‌گیری کرد که آیا پیاده‌سازی سیستم اطلاعاتی در این زمینه تغییری ایجاد کرده است یا نه.

4.3 تکنیک‌های کشف واقعیت

علاوه بر تکنیک‌های تشریح‌شده در SSADM، تحلیلگر باید در مجموعه‌ای از روش‌های کشف واقعیت مهارت داشته باشد:

• مصاحبه با کاربران؛
• تحلیل اسناد موجود؛
• تحلیل دفترهای ثبت کار و پرسش‌نامه‌ها؛
• مشاهده گردش کار، به‌صورت مخفیانه یا با مشارکت؛
• مشاهده آشکار؛
• طوفان فکری (Brainstorming) یا یکی از شکل‌های رسمی آن.

پاورقی 14: Service Level Agreement یا SLA در ادبیات انگلیسی.

پاورقی 15: همچنین نگاه کنید به Molnár Bálint: Bevezetés a rendszerelemzésbe، بخش 3.3 درباره تکنیک‌های پایه گردآوری داده و اطلاعات.

پاورقی 16: brainstorming.

صفحه 54 منبع

از جمله شکل رسمی‌تر طوفان فکری: توسعه مشترک کاربرد (Joint Application Development - JAD).

سایر تکنیک‌ها:

• ساخت نمونه اولیه (Prototyping)؛
• استفاده از شناخت محلی و قضاوت معقول درباره وضعیت.

تحلیلگر با این تکنیک‌ها باید پاسخ پرسش‌های زیر را کشف کند:

• چه چیزی لازم است و چه چیزی درخواست شده است، هم از نظر نیازمندی کارکردی و هم غیرکارکردی؟
• چرا به آن نیاز است؟
• هر نیازمندی چقدر اهمیت دارد؟
• با چه چیزی می‌توان آن را سنجید و چه معیاری می‌توان به آن نسبت داد؟

4.4 نیازمندی‌های غیرکارکردی

مهم‌ترین انواع نیازمندی‌های غیرکارکردی در اینجا فهرست شده‌اند، اما این فهرست جامع نیست:

• نیازمندی‌های سطح خدمت، مانند زمان پاسخ، توان عملیاتی، بهره‌برداری و غیره؛
• محدودیت حقوق دسترسی؛
• امنیت سیستم و داده؛
• حسابرسی و کنترل داخلی؛
• گذار از سیستم فعلی و انتقال داده؛
• ارتباط با سیستم‌های دیگر؛
• پشتیبان‌گیری و بایگانی داده؛
• قابلیت استفاده (Usability).

4.4.1 نیازمندی‌های سطح خدمت

چیزهایی که سیستم برای کمک به انجام کار فراهم می‌کند «خدمت» نامیده می‌شوند. نیازمندی سطح خدمت، معیاری برای کیفیت خدمت موردنیاز است و برای برنامه‌ریزی ظرفیت و طراحی فیزیکی اهمیت دارد.

تعیین نیازمندی‌ها می‌کوشد برای سطح خدمت مقادیر هدفِ واقع‌بینانه و قابل اندازه‌گیری تعیین کند و مقادیر حداکثر و حداقل و دامنه قابل قبول را مشخص سازد. در دور نخست، ممکن است کاربران مقادیر هدفی با دامنه بسیار گسترده تعیین کنند. بر پایه این نیازمندی‌ها می‌توان «توافق‌نامه سطح خدمت» (Service Level Agreement - SLA) را تدوین کرد.

پاورقی 17: [CCTA95]، Reference Manual Part 1: Managing SSADM Projects, 1-37—1-53.

صفحه 55 منبع

«توافق‌نامه سطح خدمت» قراردادی است که الزامات کیفی خدماتی را که باید به‌طور مستمر ارائه شوند توصیف می‌کند و توافق میان کاربر و ارائه‌دهنده خدمات فناوری اطلاعات را در این زمینه بازتاب می‌دهد.

نمونه‌هایی از نیازمندی‌های سطح خدمت که باید در چارچوب SSADM بررسی شوند:

• زمان خدمت: بازه زمانی‌ای که خدمت باید قابل دسترس باشد، با توجه ویژه به آخر هفته‌ها و تعطیلات؛
• دسترس‌پذیری خدمت: درصدی از زمان خدمت که کاربران واقعاً قادر به استفاده از سیستم‌اند؛
• پاسخ‌گویی (Responsiveness): زمان پاسخ در سیستم‌های تعاملی و میانگین زمان گردش برنامه‌ها در پردازش دسته‌ای؛
• میانگین تعداد درخواست خدمت: تعداد تراکنش‌ها در ساعت؛
• توان عملیاتی (Throughput): مقدار کار انجام‌شده در واحد زمان، مثلاً تعداد رکوردهای پایگاه داده که در یک ساعت خوانده یا تغییر می‌کنند؛
• زودترین زمان شروع و دیرترین زمان پایان برای برنامه‌های پردازش دسته‌ای؛
• قابلیت اطمینان:

- تعداد خرابی‌ها در یک بازه زمانی؛

- حداکثر زمان توقف مجاز در هر خرابی؛ خرابی‌های طولانی ولی نادر می‌توانند بیش از خرابی‌های کوتاه و پرتکرار مانع کار شوند؛

- میانگین زمان بین خرابی‌ها در یک بازه زمانی (Mean Time Between Failures - MTBF).

4.4.2 محدودیت حقوق دسترسی

• کدام داده‌ها به حفاظت نیاز دارند؟
• خواندن یا به‌روزرسانی کدام عناصر داده باید فقط برای نقش‌های کاربری خاص مجاز باشد؟
• چه سطحی از ابزارهای حفاظتی لازم است؛ مانند حفاظت فیزیکی، رمز عبور محرمانه و الگوریتم‌های رمزنگاری؟

4.4.3 امنیت سیستم و داده

• پشتیبان‌گیری از داده‌ها.

پاورقی 18: SLA به‌ویژه در برون‌سپاری اهمیت دارد، اما حتی وقتی ارائه‌دهنده خدمات فناوری اطلاعات یک واحد داخلی است نیز برای پیشگیری از اختلاف ارزشمند است.

پاورقی 19: در متن منبع «MBTF» آمده است؛ منظور Mean Time Between Failures است.

صفحه 56 منبع

ادامه امنیت سیستم و داده:

• پشتیبان‌گیری: با چه تناوبی پشتیبان‌گیری لازم است؟
• بازیابی:

- اولویت‌های بازیابی چیست و خدمات سیستم با چه ترتیبی باید بازگردانده شوند؟

- پس از خرابی سیستم، با چه سرعتی باید به شرایط عادی عملیاتی بازگشت؟

- داده‌های بازیابی‌شده باید تا چه حد به‌روز باشند؟

- آیا به یک سیستم موازیِ آماده‌به‌کار گرم (Warm Standby) نیاز است؟

• بهره‌برداری از سیستم جایگزین:

- تا پایان بازیابی سیستم و داده، چه خدمات و چه سطح خدمتی باید فراهم باشد؛ مانند سیستم دستی، خدمات کاهش‌یافته یا مراکز خدمات جایگزین؟

• برنامه‌های فاجعه:

- در صورت وقوع فاجعه، خدمات سیستم با چه ترتیبی باید بازیابی شوند؟

4.4.4 پایش

• داده‌های عملکرد سیستم تا چه اندازه باید پایش شوند؟
• چه گزارش‌هایی و با چه تناوبی لازم است؟
• آیا لازم است استفاده و میزان بهره‌برداری از سیستم پایش شود؟

4.4.5 حسابرسی و کنترل

• آیا حسابرسی مالی لازم است؟
• محدودکردن حقوق به‌روزرسانی؛
• تفکیک برخی عملکردها میان کاربران؛
• ایجاد ردپای حسابرسی (Audit Trail) برای رهگیری تراکنش‌ها؛
• آیا حسابرسی سیستم فناوری اطلاعات لازم است؟
• آیا تراکنش‌های کلیدی باید رهگیری شوند تا صحت و سازگاری داده‌های ذخیره‌شده در پایگاه داده تضمین و امکان کنترل آن فراهم شود؟
• چه نیازهایی برای حسابرسی عملکرد سیستم وجود دارد؟

پاورقی 20: audit trail.

صفحه 57 منبع

ادامه حسابرسی و کنترل:

• آیا برای نشان‌دادن اینکه سیستم منافع و مزایای مورد انتظار را ایجاد می‌کند به گزارش‌های آماری نیاز است؟
• چه خدماتی در پایگاه داده برای کشف ناسازگاری و اصلاح خطاها لازم است، مانند یافتن و تصحیح ارجاع به رکوردهای ناموجود؟
• آیا نیازهایی برای کنترل صحت مدیریت و پردازش داده وجود دارد؟

4.4.6 گذار از سیستم فعلی

شناسایی نیازمندی‌های ویژه گذار وظیفه تحلیلگر سیستم است. برای مثال، در دوره انتقال به سیستم جدید، افت شدید خدمات سیستم ممکن است مجاز نباشد. موارد قابل بررسی:

• کدام سیستم‌های قدیمی - دستی یا رایانه‌ای - باید تبدیل و در سیستم جدید ادغام شوند؟
• آیا لازم است سیستم قدیم و جدید مدتی به‌صورت موازی کار کنند؟
• آیا گذار باید یک‌باره انجام شود، یعنی سازمان بدون تأخیر از یک سیستم به دیگری منتقل شود؟
• آیا حجم زیادی داده باید بین دو سیستم منتقل شود؟
• اگر سیستم قدیمی رایانه‌ای بوده، آیا تبدیل خودکار داده ممکن است؟
• آیا تبدیل داده دشواری ویژه‌ای ایجاد می‌کند؟

4.4.7 ارتباط با سیستم‌های دیگر

اگر ایجاد ارتباط با سیستم‌های دیگر لازم باشد، نیازمندی‌های مربوط به این ارتباط باید شناسایی شوند:

• آیا داده‌ها باید از قالب‌های مختلف به یک قالب یکسان تبدیل شوند یا داده ورودی در یک قالب به چند قالب دیگر تبدیل شود؟
• آیا الزام خاصی برای انتقال فیزیکی داده وجود دارد، مانند خطوط و کانال‌های ارتباطی، نوار مغناطیسی یا دیسک انعطاف‌پذیر؟

4.4.8 پشتیبان‌گیری و بایگانی داده

• داده‌های منقضی‌شده تا چه مدت باید در سیستم تعاملی نگهداری شوند و چه زمانی بایگانی شوند؟
• کدام داده‌ها باید بایگانی و کدام داده‌ها طبق قواعد مدیریت اسناد و داده قابل حذف‌اند؟
• چه رویدادی بایگانی را آغاز می‌کند؟

صفحه 58 منبع

4.4.9 قابلیت استفاده

مفهوم قابلیت استفاده ریشه در گردش کار و اجرای عملی آن دارد؛ برای مثال پاسخ‌گویی سیستم، تنوع کار و سهولت همکاری با همکاران از عوامل مؤثرند. اگر مشاغل به‌خوبی طراحی شده باشند، قابلیت استفاده به موارد زیر مربوط می‌شود:

• دامنه خدمات پوشش‌داده‌شده توسط عملکردها؛
• ارگونومی؛
• اطلاعات و خدمات راهنما و آموزشی؛
• عملکرد سیستم.

4.4.9.1 دامنه خدمات پوشش‌داده‌شده توسط عملکردها

رویدادها و پرس‌وجوها باید به‌گونه‌ای در عملکردها گروه‌بندی شوند که عملکردها با وظایف قابل انجام منطبق باشند. اگر یک وظیفه به چند عملکرد نیاز دارد، باید استفاده ترکیبی از آن‌ها برای کاربر آسان باشد؛ مثلاً با امکانات ناوبری یا گروه‌بندی آن‌ها در «فوق‌عملکردها».

ساخت نمونه اولیه برای تعیین مرز خدمات عملکردها و کنترل درستی آن بسیار مفید است.

4.4.9.2 رابط گفت‌وگوی انسان-ماشین

رابط خارجی خدمات فناوری اطلاعات باید آسان‌استفاده باشد. این الزام لزوماً به این معنا نیست که کارکرد برنامه باید کاملاً بدیهی باشد؛ معمولاً باید میان تلاش موردنیاز برای آموزش کاربران و استفاده کارآمد از سیستم تعادل برقرار شود.

سبک رابط سیستم باید با توانایی کاربران سازگار باشد. کاربران را می‌توان به چهار گروه اصلی تقسیم کرد:

• اپراتور سیستم فناوری اطلاعات: کسی که شغل او استفاده از سیستم است، مانند اپراتور ورود داده. رابط باید از دید پردازش داده کارآمد باشد، حتی اگر استفاده از آن بدیهی نباشد. این کاربران به آموزش مناسب نیاز دارند.
• کاربران منظم: افرادی که سیستم را به‌عنوان بخشی از سایر وظایف خود به‌طور عملیاتی استفاده می‌کنند و معمولاً دقیقاً می‌دانند چه کاری باید انجام دهند. مقداری آموزش همچنان ممکن است لازم باشد. برای کاربران «آموزش‌دیده» و «متخصص» می‌توان حالت‌های متفاوت با سطوح مختلف راهنما و میان‌بر، مانند کلیدهای عملکرد، فراهم کرد.

صفحه 59 منبع

• کاربران گهگاهی: باید به آن‌ها یادآوری شود چه کاری انجام دهند. راهنما و آموزش باید در رابط کاربری تعبیه شود؛ رابط باید کاربرپسند، دارای گزینه‌های اندک و غیرگیج‌کننده و همراه با راهنمای فراوان باشد.
• کاربران غیرقابل‌کنترل از نظر آموزش: مانند عموم مردم که از دستگاه‌های خودپرداز بانک استفاده می‌کنند. رابط باید بسیار ساده، دارای گزینه‌های کم و توضیحات روشن باشد.

سایر ملاحظات:

• فراهم‌کردن امکان استفاده برای افراد دارای محدودیت جسمی یا توانایی‌های خاص؛
• حفاظت در برابر اثر محیط فیزیکی مانند گردوغبار و لرزش؛
• حفظ محرمانگی اطلاعات نمایش‌داده‌شده.

4.4.9.3 اطلاعات راهنما و آموزش

اطلاعات راهنما باید «کافی باشد، اما پرگویی نکند». معمولاً این امر به راهنمای وابسته به زمینه (Context-Sensitive Help) منجر می‌شود؛ یعنی هنگام درخواست کمک، اطلاعات مربوط به همان وظیفه جاری نمایش داده شود و کاربر مجبور به جست‌وجوی طولانی نباشد.

وقتی کاربر در استفاده از سیستم متخصص می‌شود، باید بتواند راهنمای دائماً نمایش‌داده‌شده را غیرفعال کند.

بخشی از آموزش را می‌توان، در صورت نیاز، در خود سیستم کاربردی تعبیه کرد و در این صورت کاربران نهایی آموزش اضافی دریافت نکنند. این رویکرد در دنیای رایانه‌های شخصی بسیار رایج است.