صفحه 114 منبع

11. مروری بر تعریف عملکرد

11.1 هدف

تعریف عملکرد چندین هدف دارد:

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

11.2 محصولات تعریف عملکرد

محصول تعریف عملکرد، خود «تعریف عملکرد» است که از بخش‌های زیر تشکیل می‌شود:

• شرح عملکرد؛
• ساختار ورودی/خروجی (I/O Structure)؛
• شرح فرایندهای ابتداییِ مشترک یا عمومی.

صفحه 115 منبع

11. مروری بر تعریف عملکرد

11.3 چرا از تعریف عملکرد استفاده می‌کنیم؟

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

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

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

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

شکل 43 ـ نقش عملکردها در طراحی رابط سیستم

طرح شکل چنین رابطه‌ای را نشان می‌دهد:

«طراحی رابط سیستم» ↔ «عملکردها» ↔ «مدل مفهومی».

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

صفحه 116 منبع

11. مروری بر تعریف عملکرد

11.4 رابطه عملکردها با سازمان

هر عملکرد مشخص از یک فعالیت سازمانی/کسب‌وکاری معین پشتیبانی می‌کند؛ برای مثال: «این درخواست رزرو را ذخیره کن تا بعداً بتوان آن را بازیابی کرد».

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

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

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

صفحه 117 منبع

12. تعریف عملکرد

تکنیک تعریف عملکرد برای ایجاد شرح عملکردها و ساختارهای داده ورودی/خروجی مرتبط با آن‌ها به‌کار می‌رود. مخفف انگلیسی ساختار داده ورودی/خروجی، IOS (Input/Output Structure) است.

12.1 مفاهیم

12.1.1 عملکرد چیست؟

تعریف 12-1 ـ عملکرد

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

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

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

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

12.1.2 انواع عملکرد

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

• پرس‌وجویی یا به‌روزرسان؛ هرچند یک عملکرد به‌روزرسان می‌تواند مؤلفه پرس‌وجویی داشته باشد. منظور از به‌روزرسانی، تغییر وضعیت پایگاه داده است که برای یک موجودیت مشخص می‌تواند شامل ایجاد، تغییر ویژگی‌ها، تغییر وضعیت یا حذف باشد. اصطلاح «به‌روزرسانی» نیز با همین معنا به کار می‌رود؛
• تعاملی یا غیرتعاملی. یک عملکرد ممکن است عناصر تعاملی و غیرتعاملی داشته باشد، ولی نوع عملکرد باید از دید فرایند پردازشیِ به‌روزرسان یا پرس‌وجویی تعیین شود. اصطلاح‌های on-line/off-line یا دسترسی فوری/غیرفوری نیز به کار می‌روند؛
• برحسب نوع آغاز: آغازشده توسط کاربر یا آغازشده توسط سیستم.

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

صفحه 118 منبع

12. تعریف عملکرد

12.1.3 اجزای عملکرد

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

مدل عمومی عملکرد برای شرح هر نوع عملکرد قابل استفاده است، هرچند ممکن است تفاوت‌های کوچکی میان انواع مختلف وجود داشته باشد. شکل بعدی این مدل عمومی را نمایش می‌دهد. این مدل، نمایش مفهومی عملکرد است و نمودار تکنیک تعریف عملکرد محسوب نمی‌شود.

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

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

شکل 44 ـ مدل عمومی عملکرد

اجزای نمایش‌داده‌شده عبارت‌اند از:

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

صفحه 119 منبع

12. تعریف عملکرد

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

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

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

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

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

شکل 45 ـ مؤلفه‌های عملکرد که در مرحله 3 توصیف می‌شوند

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

صفحه 120 منبع

12. تعریف عملکرد

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

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

شکل 46 ـ نگاشت مدل عمومی عملکرد به معماری سه‌شمایی

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

صفحه 121 منبع

12. تعریف عملکرد

تکمیل شرح عملکرد

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

مرحله 3:

• مدل‌سازی منطقی داده:

- مسیرهای پرس‌وجو → آغاز پرس‌وجو؛

• مدل‌سازی موجودیت–رویداد:

- نمودارهای اثر رویداد → رویدادها؛

• تعریف عملکرد:

- ساختارهای داده ورودی/خروجی → ورودی‌ها و خروجی‌های معتبر.

مرحله 5:

• طراحی گفت‌وگو:

- ساختارهای گفت‌وگو → ورودی‌ها و خروجی‌های معتبر؛

• مدل‌سازی فرایند مفهومی:

- مدل‌های پردازشی → خروجی رویداد/پرس‌وجو و خطاهای یکپارچگی؛

- مدل‌های پردازش به‌روزرسان → پردازش‌های به‌روزرسان؛

- مدل‌های پردازش پرس‌وجو → پردازش‌های پرس‌وجویی.

مرحله 6:

• تعیین پردازش فیزیکی:

- طرح پیاده‌سازی مؤلفه‌های عملکرد؛

- خطاهای نحوی و کنترلی؛

- ورودی‌ها و خروجی‌های معتبر؛

- فرایندهای پردازش ورودی/خروجی و خروجی‌های خطا.

صفحه 122 منبع

12. تعریف عملکرد

12.2 شرح کوتاه تکنیک

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

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

فعالیت‌های آن عبارت‌اند از:

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

12.3 شکل‌دهی عملکردها

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

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

12.3.1 شناسایی عملکردها

عملکردها در گام 330، «ایجاد عملکردهای سیستم»، مستند می‌شوند، اما چند تکنیک مختلف بر شناسایی آن‌ها اثر می‌گذارند. شناسایی عملکرد یعنی تعیین کنیم کاربر می‌خواهد کدام رویدادها و/یا پرس‌وجوها هم‌زمان پردازش شوند.

منابع اصلی شناسایی عملکردها عبارت‌اند از:

• مدل جریان داده سیستم موردنیاز؛
• فهرست نیازمندی‌ها.

صفحه 123 منبع

12. تعریف عملکرد

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

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

12.3.1.1 شناسایی عملکردها از مدل جریان داده موردنیاز

مجموعه اولیه‌ای از عملکردها را می‌توان از مدل جریان داده سیستم موردنیاز ایجاد کرد.

عملکردهای آغازشده توسط کاربر:

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

در بسیاری از موارد دقیقاً یک فرایند ابتدایی یک عملکرد را تشکیل می‌دهد، اما این موضوع به تعداد جریان‌های داده بین‌فرایندی که تحلیلگر در نمودارها استفاده کرده است نیز بستگی دارد. هدف، شناسایی همه فرایندها، جریان‌های خروجی و تغییرات مخزن داده است که باید رخ دهند تا همه داده‌های جریان ورودی اولیه پردازش شوند. بسته به نحوه ترسیم DFD، ممکن است جریان‌هایی وجود داشته باشند که گروهی از رویدادهایی را که باید با هم پردازش شوند یکجا نشان دهند.

عملکردهای آغازشده توسط سیستم:

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

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

صفحه 124 منبع

12. تعریف عملکرد

اگر لازم باشد یک عملکرد هم به‌صورت تعاملی و هم غیرتعاملی پیاده شود، باید دو عملکرد جداگانه، یکی برای هر شیوه پیاده‌سازی، ایجاد کرد.

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

12.3.1.2 شناسایی عملکردها بر اساس فهرست نیازمندی‌ها

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

ممکن است در ماتریس دسترسی موجودیت نیز پرس‌وجوهایی که قبلاً در آن جدول ثبت شده‌اند قابل شناسایی باشند.

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

12.3.1.3 بحث درباره تقسیم‌بندی عملکرد با کاربر

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

یکی از دلایل مشارکت جدی کاربر در تعریف عملکرد این است که عملکردها باید فعالیت‌های سازمانی/کسب‌وکاری و وظایف واقعی شغلی کاربران را پشتیبانی کنند. هر عملکرد باید به فعالیت سازمانی متناظر در مدل فعالیت سازمانی متصل شود.

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

نمودارهای جریان داده سیستم موردنیاز، نیازمندی‌های پردازشی سیستم را ثبت می‌کنند، اما روابط زمانی و ترتیب میان آن‌ها را نمایش نمی‌دهند.

صفحه 125 منبع

12. تعریف عملکرد

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

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

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

«آیا کاربر نیاز دارد چند عملکرد را پشت‌سرهم آغاز کند؟» اگر پاسخ مثبت است، عملکردی ایجاد شود که این ترکیب را پوشش دهد.

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

12.3.1.4 تعیین پرس‌وجوهای موردنیاز عملکردهای به‌روزرسان

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

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

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

12.3.1.5 اصلاح عملکردها بر اثر نتایج مدل‌سازی موجودیت–رویداد

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

صفحه 126 منبع

12. تعریف عملکرد

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

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

در ارزیابی نمونه اولیه مشخصات، کاربران ممکن است ترکیب‌های جدیدی از رویدادها را شناسایی کنند که باید به‌صورت عملکرد ثبت شوند. همچنین ممکن است لازم شود شرح عملکردها اصلاح گردد.

12.3.2 کنترل گروه‌بندی رویدادها در عملکردها

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

چند معیار نسبتاً عینی برای بررسی اعتبار این گروه‌بندی وجود دارد. در این معیارها، داده‌های ورودی عملکرد بسته‌هایی از رویدادها در نظر گرفته می‌شوند. رویدادها را می‌توان در ورودی یک عملکرد با هم ترکیب کرد اگر:

I. از موجودیت‌های خارجی یکسان یا بسیار نزدیک به هم سرچشمه بگیرند؛

II. داده‌های خروجی را به موجودیت‌های خارجی یکسان یا بسیار نزدیک به هم ارسال کنند؛

III. در یک زمان یا با فاصله زمانی بسیار کم رخ دهند؛

IV. بر موجودیت‌های یکسان اثر بگذارند، یعنی:

A. نقطه ورود مشترکی به پایگاه داده داشته باشند؛

B. نقاط ورود آن‌ها ارتباط بسیار نزدیکی با هم داشته باشند؛

C. مسیر دسترسی آن‌ها یکسان باشد.

بدیهی است هرچه گروه‌بندی معیارهای بیشتری را برآورده کند، مناسب‌تر است.

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

12.3.3 عقلانی‌سازی فرایندهای پردازشی مشترک

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

صفحه 127 منبع

12. تعریف عملکرد

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

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

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

12.3.4 مستندسازی عملکردها

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

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

12.3.5 تهیه ساختارهای داده ورودی/خروجی برای هر عملکرد

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

در گام 330 و هم‌زمان با شروع تعریف عملکردها، فرایندهای پرس‌وجویی در فهرست نیازمندی‌ها به‌شکل شرح ساده مستند شده‌اند. پرس‌وجوهای مهم‌تر ممکن است همراه با شرح‌های ورودی/خروجی مرتبط روی نمودارهای جریان داده سیستم موردنیاز ظاهر شده باشند، ولی برای بیشتر پرس‌وجوها چنین شرحی وجود ندارد. بنابراین برای ایجاد ساختار IOS باید عناصر داده ورودی و خروجی پرس‌وجو شناسایی شوند. در عمل، این کار هم‌زمان با فعالیت بعدی که ساختار IOS پرس‌وجو را ایجاد می‌کند انجام می‌شود. لازم نیست این عناصر داده جداگانه مستند شوند؛ نمودار ساختار IOS و شرح ساختار IOS کافی است.

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

صفحه 128 منبع

12. تعریف عملکرد

12.3.5.1 نمادگذاری ساختار داده ورودی/خروجی

ساختارهای IOS برای نمایش ترتیب، انتخاب و تکرار از نمادگذاری نوع Jackson استفاده می‌کنند.

قطعه ساختار IOS در شکل یک توالی ساده را نشان می‌دهد که از چپ به راست خوانده می‌شود. هر عنصر ـ برگ سطح پایین ساختار ـ نماینده یک یا چند عنصر داده است که از مرز سیستم عبور می‌کند. عناصر داده متعلق به هر عنصر ساختار IOS باید در شرح ساختار IOS مستند شوند. هر عنصر باید به‌عنوان ورودی یا خروجی علامت‌گذاری شود.

• گروه‌های تکرارشونده عناصر داده با تکرار (Iteration) نمایش داده می‌شوند؛
• گروه‌های اختیاری عناصر داده با انتخابی نمایش داده می‌شوند که گزینه «تهی/Null» را نیز شامل می‌شود؛
• گروه‌های متقابلاً انحصاری به‌صورت گزینه‌های جداگانه یک ساختار انتخاب نمایش داده می‌شوند.

ساختارهای IOS و شرح‌هایشان پس از تکمیل، توصیف کاملی از عناصر داده ورودی و خروجی یک عملکرد ارائه می‌کنند.

در تهیه ساختار IOS، ورودی‌ها و خروجی‌های تعاملی باید متفاوت از ورودی‌ها و خروجی‌های غیرتعاملی مدیریت شوند.

12.3.5.2 عملکردها یا اجزای عملکرد تعاملی

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

شکل 47 ـ بخشی از ساختار ورودی/خروجی

نمونه شکل شامل «اطلاعات مالکیت»، «اطلاعات ملک ـ ورودی»، «اطلاعات مالک ـ ورودی»، «اطلاعات تصمیم ـ خروجی» و «اطلاعات رهن ـ خروجی» است.

صفحه 129 منبع

12. تعریف عملکرد

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

هنگام گروه‌بندی عناصر داده باید قواعد زیر رعایت شود:

• عناصر ورودی و خروجی نباید در یک گروه قرار گیرند؛
• در یک گروه تکرارشونده عناصر داده، عناصر خارج از آن گروه نباید قرار گیرند؛
• عناصر داده اجباری و اختیاری نباید در یک گروه قرار گیرند.

با استفاده از این قواعد باید شناسایی شوند:

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

ترتیب ورودی‌ها و خروجی‌های گروه‌بندی‌شده باید تعیین شود.

با استفاده از نمادگذاری Jackson باید ساختاری ترسیم شود که ترتیب ورودی و خروجی را نشان دهد؛ گروه‌های تکراری به‌صورت تکرار و گروه‌های اختیاری یا متقابلاً انحصاری به‌صورت انتخاب نمایش داده شوند.

12.3.5.3 عملکردها یا اجزای عملکرد غیرتعاملی

در عملکرد غیرتعاملی، جریان‌های داده ورودی و خروجی نباید مانند گفت‌وگوی تعاملی برای نمایش مکالمه کاربر و سیستم در یکدیگر تو در تو شوند. برای هر ورودی و هر خروجی یک عملکرد یا جزء غیرتعاملی باید ساختار IOS جداگانه‌ای تهیه شود.

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

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

صفحه 130 منبع

12. تعریف عملکرد

12.3.6 پرس‌وجوهای موردی (Ad-hoc)

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

• نوع؛
• پیچیدگی؛
• فراوانی.

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

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

12.4 ارتباط با تکنیک‌های دیگر

مدل‌سازی منطقی داده

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

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

صفحه 131 منبع

12. تعریف عملکرد

مدل‌سازی جریان داده

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

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

گزینه‌های سازمان‌دهی سیستم

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

تحلیل رابطه‌ای داده

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

مدل‌سازی رفتار موجودیت

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

در تعریف عملکردها باید به رویدادها ارجاع داده شود.

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

صفحه 132 منبع

12. تعریف عملکرد

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

شکل 48 ـ ارتباط تعریف عملکرد با سایر تکنیک‌های SSADM

شکل ارتباط میان تعریف عملکرد و این تکنیک‌ها/محصولات را نشان می‌دهد: مدل‌سازی جریان داده، گزینه‌های سازمان‌دهی سیستم، تعیین نیازمندی‌ها، گزینه‌های فنی سیستم، نمونه‌سازی مشخصات، طراحی گفت‌وگو، طراحی فیزیکی، طراحی پردازش منطقی داده، تحلیل تاریخچه موجودیت، مدل‌سازی منطقی داده، تحلیل رابطه‌ای داده و تحلیل اثر رویداد. ورودی‌ها و خروجی‌های متقابل شامل BSO انتخاب‌شده، نیازمندی‌های پرس‌وجویی، داده‌های کمی، تکمیل عملکردها، ساختارهای IOS، شرح عملکردها، رویدادها و عناصر داده آن‌ها، اثرها، موجودیت‌ها، رویدادهای اولیه، مدل‌های RDA، پرس‌وجوها، تکمیل DFD، نمودارهای جریان داده، گفت‌وگوهای بحرانی و ماتریس عملکرد/نقش کاربری هستند.

صفحه 133 منبع

12. تعریف عملکرد

نمونه‌سازی مشخصات

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

طراحی گفت‌وگو

هر عملکرد تعاملی باید از طریق یک یا چند گفت‌وگو پیاده شود. یکی از وظایف تعریف عملکرد شناسایی نقش‌های کاربری است که به عملکردها نیاز به دسترسی دارند؛ این نقش‌ها باید در شرح نقش‌های کاربری ثبت شوند. گفت‌وگوها با استفاده از ماتریس نقش کاربری–عملکرد شناسایی می‌شوند. ساختارهای IOS در طراحی گفت‌وگو به ساختارهای کامل گفت‌وگو توسعه می‌یابند و نام گفت‌وگوها باید در شرح عملکرد ثبت شود.

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

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

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

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

گزینه‌های فنی سیستم

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

مدل‌سازی فرایندهای مفهومی

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

صفحه 134 منبع

12. تعریف عملکرد

مدل‌سازی گردش کار

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

طراحی فیزیکی

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