مدل ساختاری SSADM: گزینه‌های سازمان‌دهی و مشخصات نیازمندی‌ها | SSADM

مدل ساختاری SSADM: گزینه‌های سازمان‌دهی و مشخصات نیازمندی‌ها

توسط admin | گروه مهندسی نرم افزار | 1405/05/20

نظرات 0

مدل ساختاری SSADM: گزینه‌های سازمان‌دهی و مشخصات نیازمندی‌ها

بازه صفحات منبع: 172 تا 194
زبان منبع: مجاری
روش: SSADM
اعتبار ترجمه: ترجمه با کمک هوش مصنوعی

صفحه 172 منبع

17. مدل ساختاری

ادامه محصولات گام 130:

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

17.5.4 گام 140: بررسی داده‌های فعلی

هدف گام:

شناسایی و توصیف ساختار داده‌های سیستم، مستقل از روش فعلی ذخیره‌سازی و سازمان‌دهی داده‌ها.

شرح

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

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

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

مبانی شروع:

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

مواد مرجع:

  • مطالعه امکان‌سنجی؛
  • فرم‌ها و اسناد محیط فعلی؛
  • شرح داده‌های محیط فعلی.
تصویر مرجع صفحه 172 سند اصلیتصویر کامل صفحه 172 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 172 سند اصلی.

صفحه 173 منبع

17. مدل ساختاری

وظایف گام 140:

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

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

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

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

محصولات ایجاد/اصلاح‌شده:

  • مدل منطقی داده محیط فعلی؛
  • فهرست داده؛
  • فهرست نیازمندی‌ها.

17.5.5 گام 150: عقلانی‌سازی خدمات فعلی

هدف:

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

شرح

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

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

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

صفحه 174 منبع

17. مدل ساختاری

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

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

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

مبانی شروع:

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

وظایف گام 150:

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

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

40. شرح فرایندهای ابتدایی، شرح ورودی/خروجی و شرح موجودیت‌های خارجی متناسب با نمودارهای جدید تهیه شود.

50. کنترل شود مدل منطقی داده هنوز با شرح فرایندهای ابتدایی سازگار است.

50. هر محدودیت فیزیکی که همچنان معتبر است و هر نیاز جدیدی که در عقلانی‌سازی ظاهر شده در فهرست نیازمندی‌ها ثبت شود.

محصولات ایجاد/اصلاح‌شده:

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

صفحه 175 منبع

17. مدل ساختاری

17.6 مرحله 2: گزینه‌های سازمان‌دهی سیستم

هدف مرحله:

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

شرح

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

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

شرکت‌کنندگان: تحلیلگران نیازمندی دارای دانش SSADM و حوزه سازمانی/عملیاتی، تأمین‌کنندگان خدمات فناوری اطلاعات و اعضای گروه توسعه.

پیش‌شرط‌ها ـ محصولات/اسناد مدیریتی:

  • روش‌های کنترل مرحله 2؛
  • برنامه‌های مرحله 2؛
  • تصمیم درباره انتخاب گزینه سازمان‌دهی سیستم.

مواد شروع:

  • شرح خدمات فعلی؛
  • منشور پروژه؛
  • فهرست نیازمندی‌ها؛
  • فهرست کاربران.

مواد مرجع:

  • مطالعه امکان‌سنجی.
تصویر مرجع صفحه 175 سند اصلیتصویر کامل صفحه 175 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 175 سند اصلی.

صفحه 176 منبع

17. مدل ساختاری

محصولات:

  • گزینه‌های سازمان‌دهی سیستم؛
  • گزینه سازمان‌دهی سیستم منتخب.

تکنیک‌ها:

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

فعالیت‌ها:

  • گام 210: تعیین گزینه‌های سازمان‌دهی سیستم؛
  • گام 220: انتخاب گزینه سازمان‌دهی سیستم.

17.6.1 گام 210: تعیین گزینه‌های سازمان‌دهی سیستم

هدف:

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

شرح

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

در این گام باید چند راه‌حل ممکن تعیین و دو یا سه مورد از آن‌ها تا سطحی توسعه یابند که بتوان به مدیریت پروژه ارائه کرد.

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

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

شرکت‌کنندگان: اعضای گروه تحلیل، مدیر پروژه، تحلیلگر ارشد نیازمندی، تحلیلگران کمکی و نماینده کاربر.

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

صفحه 177 منبع

17. مدل ساختاری

مبانی شروع:

  • شرح خدمات فعلی؛
  • منشور پروژه و سایر مستندات پروژه؛
  • فهرست نیازمندی‌ها؛
  • فهرست کاربران.

مواد مرجع:

  • مطالعه امکان‌سنجی.

وظایف گام 210:

10. نیازمندی‌های کارکردی و غیرکارکردی که همه گزینه‌ها باید برآورده کنند گردآوری شوند.

20. دو یا سه گزینه تدوین شوند که در مجموع همه امکان‌های حل مسئله سیستم جدید را پوشش دهند.

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

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

50. برای هر گزینه سازمان‌دهی سیستم تحلیل هزینه–فایده ارائه شود که اثر آن گزینه بر سازمان را ترسیم کند.

محصولات ایجاد/اصلاح‌شده:

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

صفحه 178 منبع

17. مدل ساختاری

17.6.2 گام 220: انتخاب گزینه سازمان‌دهی سیستم

هدف:

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

شرح

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

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

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

وظایف:

10. گزینه‌های سازمان‌دهی سیستم به مدیریت پروژه و در صورت نیاز سایر مخاطبان ارائه شوند. در صورت نیاز با توضیح بیشتر و بحث درباره اثر گزینه‌ها، تصمیم‌گیری پشتیبانی شود. دلایل تصمیم‌ها ثبت گردد.

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

محصولات ایجاد/اصلاح‌شده:

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

صفحه 179 منبع

17. مدل ساختاری

17.7 ماژول مشخصات نیازمندی‌ها (RS)

این ماژول یک مرحله دارد: مرحله 3، تعیین نیازمندی‌ها.

17.8 مرحله 3: تعیین نیازمندی‌ها

هدف مرحله:

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

شرح

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

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

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

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

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

صفحه 180 منبع

17. مدل ساختاری

پیش‌شرط‌های مرحله:

محصولات/اسناد مدیریتی:

  • روش‌های کنترل مرحله 3؛
  • برنامه‌های مرحله 3.

مواد شروع:

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

محصولات:

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

تکنیک‌ها:

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

فعالیت‌ها:

  • گام 310: تعیین فرایندهای سیستم موردنیاز؛
  • گام 320: توسعه مدل داده سیستم موردنیاز؛
  • گام 330: تولید عملکردهای سیستم؛
  • گام 335: تهیه شرح شغل‌ها؛
  • گام 340: تأیید مدل داده موردنیاز؛
  • گام 350: توسعه نمونه‌های مشخصات؛
  • گام 360: تعیین فرایندهای پردازش؛
  • گام 370: نهایی‌سازی اهداف سیستم.
تصویر مرجع صفحه 180 سند اصلیتصویر کامل صفحه 180 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 180 سند اصلی.

صفحه 181 منبع

17. مدل ساختاری

17.8.1 گام 310: تعیین فرایندهای سیستم موردنیاز

اهداف:

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

شرح

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

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

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

شرکت‌کنندگان: اعضای گروه مشخصات نیازمندی و مدل‌سازان عملکرد.

مبانی شروع:

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

صفحه 182 منبع

17. مدل ساختاری

وظایف گام 310:

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

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

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

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

50. [در متن استخراج‌شده این وظیفه بدون شرح آمده است.]

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

محصولات ایجاد/اصلاح‌شده:

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

صفحه 183 منبع

17. مدل ساختاری

17.8.2 گام 320: توسعه مدل داده سیستم موردنیاز

اهداف:

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

شرح

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

شرکت‌کنندگان: اعضای گروه مشخصات نیازمندی، مدل‌سازان و تحلیلگران داده و متخصصانی مانند متخصص امنیت داده.

مبانی شروع:

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

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

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

صفحه 184 منبع

17. مدل ساختاری

وظایف ادامه گام 320:

20. تبدیل مدل منطقی داده به فرم نرمال سوم در گام 340 «تأیید مدل داده موردنیاز» انجام می‌شود؛ با این حال، استفاده غیررسمی از تحلیل رابطه‌ای داده در حین تهیه مدل سیستم موردنیاز اغلب مفید است.

30. نحوه پردازش نیازمندی‌های جدید در فهرست نیازمندی‌ها ثبت و به آن نیازمندی‌ها ارجاع مناسب داده شود.

40. کنترل شود مدل منطقی داده شرح فرایندهای ابتدایی را به‌درستی پشتیبانی می‌کند.

50. مدل منطقی داده با نیازمندی‌های غیرکارکردی ثبت‌شده در فهرست نیازمندی‌ها، مانند محدودیت‌های دسترسی، نیازهای امنیتی و نیازهای بایگانی، تکمیل شود.

محصولات ایجاد/اصلاح‌شده:

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

17.8.3 گام 330: تولید عملکردهای سیستم

اهداف:

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

شرح

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

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

صفحه 185 منبع

17. مدل ساختاری

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

عملکردها را می‌توان محل گردآوری اطلاعات حاصل از تکنیک‌های مرحله 3 «تعیین نیازمندی‌ها» دانست.

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

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

مبانی شروع:

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

مواد مرجع:

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

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

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

صفحه 186 منبع

17. مدل ساختاری

وظایف ادامه گام 330:

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

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

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

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

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

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

محصولات ایجاد/اصلاح‌شده:

  • شرح عملکردها؛
  • ساختارهای داده ورودی/خروجی؛
  • ماتریس نقش کاربری–عملکرد؛
  • شرح فرایندهای ابتدایی مشترک؛
  • ماتریس دسترسی موجودیت؛
  • فهرست رویداد و پرس‌وجو.
تصویر مرجع صفحه 186 سند اصلیتصویر کامل صفحه 186 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 186 سند اصلی.

صفحه 187 منبع

17. مدل ساختاری

17.8.4 گام 335: تهیه شرح شغل‌ها

هدف:

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

شرح

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

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

مبانی شروع:

  • نقش‌های کاربری؛
  • مدل گردش کار، نسخه اولیه.

مواد مرجع:

  • ساختار و سلسله‌مراتب سازمان.

وظایف:

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

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

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

صفحه 188 منبع

17. مدل ساختاری

وظایف ادامه گام 335:

30. وظایف به نقش‌های کاربری مناسب تخصیص داده شوند. وظایف پایه به یک یا چند نقش کاربری مرتبط می‌شوند. تهیه شرح شغل به تخصص ویژه نیاز دارد و SSADM روش واحدی را برای آن تحمیل نمی‌کند.

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

محصول ایجاد/اصلاح‌شده:

  • مدل گردش کار، شامل شرح شغل‌ها.

17.8.5 گام 340: تأیید مدل داده موردنیاز

هدف:

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

شرح

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

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

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

شرکت‌کنندگان: اعضای گروه مشخصات نیازمندی، مدل‌سازان و تحلیلگران داده و متخصصان دیگر مانند امنیت داده.

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

صفحه 189 منبع

17. مدل ساختاری

مبانی شروع:

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

مواد مرجع:

  • شرح عملکردها.

وظایف گام 340:

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

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

30. روابط نرمال‌شده همه عملکردهای منتخب به یک مدل منطقی داده یا مجموعه‌ای از مدل‌های جزئی منطقی تبدیل شوند.

40. مدل/مدل‌های جزئی با بخش متناظر مدل منطقی داده سیستم موردنیاز مقایسه شوند. اگر مدل جزئی ویژگی‌هایی داشته باشد که ساختار منطقی داده ندارد، تفاوت‌ها براساس نیازهای پردازشی و نیاز کاربران حل شوند و در صورت لزوم مدل منطقی داده با موجودیت‌ها و روابط جدید اصلاح گردد.

محصولات ایجاد/اصلاح‌شده:

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

17.8.6 گام 350: توسعه نمونه‌های مشخصات

هدف:

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

پاورقی 40: در اینجا می‌توان اصل پارتو را در نظر گرفت؛ حدود 20 درصد عملکردهای سیستم مسئول 80 درصد عملکرد/کارکرد سیستم‌اند، بنابراین سرمایه‌گذاری این تلاش اضافی معمولاً در اطراف عملکردهای بحرانی و مهم ارزشمند است.

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

صفحه 190 منبع

17. مدل ساختاری

شرح گام 350

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

دامنه نمونه‌سازی، اهداف تفصیلی و روش کنترل آن را مدیریت پروژه در سند «دامنه نمونه‌سازی» تعیین می‌کند. برای نقش‌های منتخب، منوها و ساختارهای فرمان تعریف می‌شوند؛ موارد باقی‌مانده در گام 510 «تعیین گفت‌وگوهای کاربری» مشخص خواهند شد.

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

شرکت‌کنندگان: اعضای گروه مشخصات نیازمندی، مدل‌سازان عملکرد و متخصصان دیگر مانند کارشناسان نمونه‌سازی.

مبانی شروع:

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

مواد مرجع:

  • شرح عملکردها؛
  • مدل جریان داده سیستم موردنیاز.
تصویر مرجع صفحه 190 سند اصلیتصویر کامل صفحه 190 برای حفظ شکل‌ها، جدول‌ها، شماره‌گذاری و چیدمان سند منبع.
تصویر مرجع صفحه 190 سند اصلی.

صفحه 191 منبع

17. مدل ساختاری

وظایف گام 350:

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

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

30. سند «اهداف ارائه نمونه» تهیه شود. نمونه‌ها به کاربران تعیین‌شده برای نقش مربوط ارائه و نتایج ارائه ثبت شوند.

40. در صورت نیاز، نمونه‌ها اصلاح و دوباره ارائه شوند.

50. گزارش نتایج ارائه نمونه‌ها تدوین شود.

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

محصولات ایجاد/اصلاح‌شده:

  • ساختارهای فرمان؛
  • ساختارهای منو؛
  • گزارش ارزیابی نمونه؛
  • فهرست نیازمندی‌ها.

17.8.7 گام 360: تعیین فرایندهای پردازش داده

مبانی شروع:

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

مواد مرجع:

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

صفحه 192 منبع

17. مدل ساختاری

وظایف گام 360:

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

وظایف 20 تا 40 به‌صورت موازی انجام می‌شوند.

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

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

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

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

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

صفحه 193 منبع

17. مدل ساختاری

17.8.8 گام 370: نهایی‌سازی اهداف سیستم

اهداف:

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

شرح

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

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

نیازمندی‌های غیرکارکردی در گام‌های 320 و 330 تعیین می‌شوند. این گام کنترل می‌کند آیا همه آن‌ها مشخص و با ارجاع مناسب ثبت شده‌اند.

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

مبانی شروع:

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

صفحه 194 منبع

17. مدل ساختاری

وظایف گام 370:

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

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

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

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

محصولات ایجاد/اصلاح‌شده:

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

17.9 ماژول مشخصات منطقی سیستم (LS)

اهداف ماژول:

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

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

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

امتیاز کاربران به این مقاله

☆☆☆☆☆

0 نفر امتیاز داده اند. میانگین: 0.0 از 5

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

نظرات محترم شما در خدمات رسانی بهتر ما را یاری می نمایند. لطفا اگر مایل بودید یک نظر ما را مهمان فرمائید. آدرس ایمیل و وب سایت شما نمایش داده نخواهد شد.

0 / 500

اطلاعات تماس

  • آدرس:اصفهان-خیابان ام کلثوم غربی - بعد خیابان تخم چی - بیست متر بعد از پیتزا ننه شب - کوچه تعمیر گاه سمار زغالی - پلاک 354 - درب مشکی - طبقه هفتم
  • آدرس ایمیل:najafzade@gmail.com
  • وب سایت:http://www.a00b.com/
  • تلفن ثابت:(+98)9131253620
  • تلفن همراه:09131253620