استراتژی ها و تکنیک های جمع آوری نیازمندیهای سیستم

استراتژی های تجزیه و تحلیل نیازمندیها(REQUIREMENTS ANALYSIS STRATEGIES)

قبل از اینکه تیم پروژه بتواند تعیین کند چه الزاماتی برای یک سیستم معین مناسب است، باید دید روشنی از نوع سیستمی که ایجاد می شود و سطح تغییری که برای سازمان ایجاد می کند وجود داشته باشد. فرآیند اصلی تجزیه و تحلیل به سه مرحله تقسیم می شود: درک سیستم همانطور که هست(as-is system)، شناسایی پیشرفت ها(identifying improvements)، و توسعه الزامات برای سیستم آینده(to-be system).
گاهی اوقات مرحله اول (یعنی درک سیستم همانطور که هست) نادیده گرفته می شود یا به صورت گذرا انجام می شود. این موضوع زمانی اتفاق می‌افتد که هیچ سیستم فعلی وجود نداشته باشد، یا اگر سیستم و فرآیندهای موجود به سیستم آینده بی‌ربط باشند، و یا اینکه تیم پروژه از یک روش RAD یا توسعه چابک استفاده می‌کند که در آن سیستم همانطور که هست تاکید نشده است. تحلیلگران از استراتژی های تحلیل نیازمندی ها و تکنیک های جمع آوری نیازمندی ها برای جمع آوری دقیق اطلاعات و الزامات سیستم استفاده می کنند. استراتژی‌های تحلیل نیازمندی‌ها، نوع اطلاعاتی را که جمع‌آوری می‌شود و در نهایت چگونه تجزیه و تحلیل می‌شوند را هدایت می‌کند. استراتژی های تحلیل نیازمندی ها و جمع آوری نیازمندی ها همزمان اتفاق می افتند و فعالیت های مکمل یکدیگر هستند.
برای انتقال کاربران از سیستم کنونی به سیستم آینده، یک تحلیلگر به مهارت های تفکر انتقادی قوی نیاز دارد. تفکر انتقادی توانایی تشخیص نقاط قوت و ضعف و بازنویسی یک ایده به شکل بهبود یافته است و برای درک واقعی مسائل و توسعه فرآیندهای تجاری جدید به مهارت های تفکر انتقادی نیاز است. این مهارت‌ها همچنین برای بررسی کامل نتایج جمع‌آوری نیازمندی‌ها، شناسایی نیازمندی‌های تجاری، و تبدیل آن الزامات به مفهومی برای سیستم جدید مورد نیاز است.

تجزیه و تحلیل مشکل Problem Analysis

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

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

بررسی دلیل ریشه ای Root Cause Analysis

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

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

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

■ ممکن است تامین کننده شرکت سفارشات را به موقع به شرکت تحویل ندهد.

■ ممکن است در کنترل موجودی شرکت مشکلی وجود داشته باشد.

■ سطح سفارش مجدد و مقادیر ممکن است اشتباه تنظیم شوند.

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

تجزیه و تحلیل زمان Duration Cause Analysis

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

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

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

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

هزینه یابی مبتنی بر فعالیت Activity-Based Costing

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

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

بنچمارک غیررسمی Informal Benchmarking

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

بنچمارک غیررسمی برای فرآیندهای تجاری customer-facing (یعنی فرآیندهایی که با مشتری در تعامل هستند) نسبتاً رایج است. با بنچمارک غیررسمی، مدیران و تحلیلگران به سازمان های دیگر فکر می کنند یا به عنوان مشتری از آنها بازدید می کنند تا نحوه انجام فرآیند کسب و کار را مشاهده کنند. در بسیاری از موارد، کسب و کار مورد مطالعه ممکن است یک رهبر شناخته شده در صنعت یا به سادگی یک شرکت مرتبط باشد.

تجزیه و تحلیل نتیجه Outcome Analysis

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

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

تجزیه و تحلیل فناوری (Technology Analysis)

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

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

تکنیک های جمع آوری نیازمندیها (REQUIREMENTS-GATHERING TECHNIQUES)

مصاحبه Interview

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

طراحی برنامه مشترک Joint Application Development(JAD)

یک فرایند ساختاری است که در آن ده تا بیست کاربر با راهنمایی یک مجری ماهر در فنون JAD با هم ملاقات می کنند. مجری برنامه جلسه را تنظیم می کند و بحث را هدایت می کند اما به عنوان یک شرکت کننده در بحث شرکت نمی کند. وی ایده ها یا نظراتی را درباره موضوعات مورد بحث ارائه نمی دهد تا در طول جلسه خنثی بماند. مجری باید هم در تکنیک های فرآیند گروهی و هم در تجزیه و تحلیل سیستم ها و تکنیک های طراحی متخصص باشد. یک یا دو منشی با ضبط یادداشت، تهیه نسخه و غیره به مجری کمک می کنند. اغلب منشی از رایانه و ابزار CASE برای ثبت اطلاعات در جلسه JAD استفاده می كنند.
گروه JAD چندین ساعت، چند روز یا چند هفته جلسه می گذارد تا اینکه در مورد همه مسائل بحث شده و اطلاعات لازم جمع آوری می شود. بیشتر جلسات JAD در یک اتاق جلسات که به طور ویژه آماده شده است، دور از دفاتر شرکت کنندگان برگزار می شود تا در آنها مزاحمت ایجاد نشود. اتاق جلسات معمولاً به شکل U تنظیم می شود تا همه شرکت کنندگان به راحتی یکدیگر را ببینند. در قسمت جلوی اتاق قسمت باز(U)، وایتبورد یا پروژکتور بالای سر برای استفاده توسط مجری که بحث را هدایت می کند، قرار دارد.

پرسشنامه Questionaries

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

تحلیل اسناد Document Analysis

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

مشاهده Observation

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

فاکتورهای استفاده از تکنیکها

نوع اطلاعات(Type of information)

اولین مشخصه نوع اطلاعات است. برخی از تکنیک ها بیشتر مناسب برای استفاده در مراحل مختلف فرایند تجزیه و تحلیل هستند، خواه درک سیستم موجود(as-is System)، بهبود سیستم(improvments) یا توسعه سیستم آینده(to-be System). مصاحبه و JAD معمولاً در هر سه مرحله مورد استفاده قرار می گیرند. در مقابل، تجزیه و تحلیل(Document Analysis) و مشاهده اسناد(Observation) معمولاً برای درک سیستم موجود بسیار مفید هستند، اگرچه گاهی اوقات اطلاعاتی در مورد مشکلات ارائه می دهند که باید بهبود یابند. از پرسشنامه ها اغلب برای جمع آوری اطلاعات در مورد سیستم موجود و همچنین اطلاعات کلی در مورد پیشرفتها استفاده می شود.

عمق اطلاعات(Depth of information)

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

وسعت اطلاعات(Breadth of information)

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

ادغام اطلاعات(Integration of information)

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

درگیری کاربر(User involvement)

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

هزینه(Cost)

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

منبع:

Systems Analysis and Design: An Object-Oriented Approach with UML, 5th Edition by Dennis, Wixom, and Tegarden