چکیده:در سازمان‌ها و سامانه‌های بزرگ مقیاس و پیچیده، جهت تعیین نیازمندی‌های عملیاتی و غیر عملیاتی در گستره‌ای که ممکن است هزاران ذینفع را در بر گیرد، دانشی جهت استخراج نیازمندی‌ها احساس می‌گردد. با توجه به اینکه سازمان‌ها، داده‌ها و اطلاعات بسیاری در تصرف خود دارند و با فلج ساختن اطلاعات یک چالش کلیدی در تصمیم گیری تشکیلات سازمانی ایجاد می‌نمایند، فرایند کشف دانش از پایگاه داده سازمان مطرح گردیده که یک فرایند علمی برای شناسایی الگوهای معتبر، بالقوه مفید و قابل فهم از داده‌ها می‌باشد. در این تحقیق قصد داریم با بکار گیری داده کاوی به عنوان مرحله‌ای از فرایند کشف دانش به ارائه‌ی چارچوبی جهت استخراج و اولویت بندی نیازمندی‌ها در سازمان‌های بزرگ مقیاس پرداخته که در نتیجه کار خود، افزایش رضایتمندی را به همراه می‌آورد. بدین صورت که ابتدا با توجه به فرکانس تکرار و درجه اهمیت، نیازمندی‌ها را با استفاده از الگوریتم K-Means خوشه بندی کرده سپس با روشی به نام رتبه بندی و بهره گیری از ماتریس ارزش محور به اولویت بندی نیازمندی‌ها می‌پردازیم. مطالعه موردی چارچوب پیشنهادی، پایگاه داده سامانه مدیریت شهری 137 شهرداری تهران می‌باشد. بر اساس نتایج بدست آمده می‌توان خوشه‌های متفاوت از نیازها با اولویت اقدام متفاوت را معرفی نمود. کلمات کلیدی: مهندسی نیازمندی‌ها، استخراج نیازمندی‌ها، سازمان‌ها و یا سامانه‌های بزرگ مقیاس، داده کاوی، اولویت بندی نیازها، رضایتمندی فهرست مطالب فصل اول (مقدمه و کلیات تحقیق). 21-1 مقدمه. 21-2 مهندسی نیازمندی‌ها. 21-3 استخراج نیازمندی‌ها. 31-4 سازمان‌های بزرگ مقیاس. 41-5 ویژگی‌های سازمان‌ها و سامانه‌های بزرگ مقیاس. 51-6 چالش‌های سازمان‌های بزرگ مقیاس. 81-7 انگیزه. 81-8 تعریف مسئله. 91-9 فرضیه. 91-10 اهداف تحقیق. 10فصل دوم (ادبیات و پیشینه تحقیق). 122-1 مقدمه. 122-2 انگیزه‌های کاوش داده. 132-2-1 انگیزه‌های تجاری. 132-2-2 انگیزه‌های علمی. 152-3 چالش‌های داده کاوی. 162-3-1 چالش‌های اولیه. 172-3-2 چالش‌های ثانویه. 182-4 مروری بر کشف دانش و داده کاوی. 192-5 مراحل داده کاوی. 212-6 دلایل وجود و ضرورت داده کاوی. 292-7 داده کاوی سازمانی. 302-8 نقش داده کاوی سازمانی در معرفت سازمانی. 312-9 معیارهای تعریف نیازمندی‌های سیستم. 312-10 نتایج نیازمندی‌های نادرست. 322-11 پیشینه تحقیق. 322-11-1 روش‌های سنتی. 332-11-1-1 مقایسه روش‌های سنتی. 352-11-2 استفاده از ابزارها. 372-11-3 روش‌های نوین. 382-11-3-1 مقایسه روش‌های نوین. 462-12 تکنیک‌هایی در افزایش سطح بهبود رضایت ذینفعان در فاز استخراج نیازمندی‌ها 472-13 نتیجه گیری. 49فصل سوم (روش تحقیق). 533-1 مقدمه. 533-2 راهکار پیشنهادی. 533-2-1 آماده سازی و پیش پردازش داده. 543-2-1-1 جمع آوری و بارگذاری داده‌های استخراج شده. 543-2-1-2 پاک سازی داده. 543-2-1-3 انتخاب زیر مجموعه‌ای از ویژگی‌ها. 553-2-1-4 فیلترینگ نمونه‌ها. 553-2-1-5 تبدیل داده. 553-2-1-6 خلق ویژگی. 553-2-1-7 نمونه برداری. 563-2-2 یادگیری مدل. 563-2-2-1 خوشه بندی. 563-2-2-2 خوشه بندی K-Means. 563-2-2-3 خوشه بندی با استفاده از الگوریتم K-Means با توجه به فرکانس تکرار و درجه اهمیت درخواست‌ها و نیازمندی‌ها. 573-2-3 ارزیابی و تفسیر مدل. 583-2-4 دسته بندی جدید و اولویت بندی نیازمندی‌های استخراج شده با استفاده از تکنیک رتبه بندی. 583-2-4-1 روش رتبه بندی. 603-2-4-2 شاخص‌های رتبه بندی. 603-2-4-3 ضرایب یا وزن شاخص‌ها. 61فصل چهارم (محاسبات و یافته‌های تحقیق). 654-1 مطالعه موردی: سامانه مدیریت شهری 137 شهرداری تهران. 654-2 معرفی ابزار برتر داده کاوی RapidMiner664-3 پیاده سازی روش پیشنهادی. 684-4 ارزیابی و تفسیر خوشه‌ها. 69فصل پنجم (نتیجه گیری و پیشنهادات). 725-1 نتیجه گیری. 725-2 مشکلات و نقاط ضعف کارهای مرتبط. 725-3 مزایا و ویژگی‌های روش پیشنهادی. 735-4 کارهای آینده. 74پیوست – منابع و مآخذ. 75Abstract76 فهرست جداولجدول2-1: مقایسه روش‌های سنتی استخراج نیازمندی‌ها................. 36جدول2-2: مسائلی در ارتباط با نیازمندی‌های تطبیق شده............. 47جدول3-1: معیارهای SSEو ASC..................................... 57جدول3-2: بررسی برخی روش‌های اولویت بندی......................... 59جدول3-3: تعیین ضریب شاخص (درجه اهمیت).......................... 62جدول3-4: تعیین درجه اهمیت نیازمندی............................. 62جدول3-5: تعیین ضریب شاخص....................................... 63جدول4-1: جدول پیام............................................. 65جدول4-2: نتیجه خوشه بندی و اولویت بندی نیازمندی‌ها............. 69فهرست شکلهاشکل2-1: فرایند داده کاوی و کشف دانش............................ 20شکل2-2: استفاده از داده کاوی در استخراج نیازمندی‌ها............. 40شکل2-3: شبکه اجتماعی........................................... 43شکل2-4: روش مبتنی بر سناریو.................................... 44شکل2-5: مدل تکرار پذیر استخراج نیازمندی‌های جامع................ 46شکل3-1: مراحل اصلی راهکار پیشنهادی............................ 53شکل3-2: گام‌های مرحله آماده سازی و پیش پردازش داده.............. 54شکل3-3: تعیین اولویت........................................... 61شکل3-4: ترتیب اولویت........................................... 62شکل4-1: نمایی از یک پردازش در نرم‌افزار RapidMiner................. 67شکل4-2: نمایی از مصور سازی داده‌ها در نرم‌افزار RapidMiner.......... 67شکل4-3: استفاده از عملگرها در مراحل پیاده سازی................. 68 مقدمه و کلیات تحقیقمهندسی سیستم سعی می‌کند تا نیازمندی‌های سیستم را تشخیص دهد که این عمل با همکاری مشتریان، کاربران و تمامی ذینفعان انجام می‌شود [1]. مدیریت ارتباط با شهروند یکی از مباحث اصلی در مدیریت دولتی نوین محسوب شده و از اهمیت بسیاری برخوردار است. در مدیریت ارتباط با شهروند تمرکز اصلی بر شهروند محوری است و بهبود خدمت رسانی و پاسخ گویی به شهروندان بر اساس نیازهای ایشان، هدف اصلی محسوب می‌شود. در واقع درک درست از نیازها و خواسته‌های گروه‌های مختلف شهروندان و ارائه خدمات مناسب با این نیازها، موضوعی است که باید در مدیریت ارتباط با شهروند مورد توجه قرار گیرد [2].خروجی فرایند مهندسی سیستم تعریفی از یک سیستم کامپیوتری یا محصول است. در این مرحله نیز این مشکل وجود دارد که چگونه مطمئن شویم که تعریف ارائه شده از سیستم نیازهای مشتری را برطرف می‌کند و انتظارات او را رفع می‌سازد. برای این منظور نیازمند به طی فرایند مهندسی نیازمندی‌ها هستیم. این فرایند مکانیزم‌های مناسب را فراهم می‌آورد تا تشخیص دهیم مشتری چه می‌خواهد، نیازهای تحلیل چیست، یک راه معقول کدام است و ابهامات نیازمندی در کجا هستند.مهندسی نیازمندی‌ها دارای پنج فاز مهم زیر می‌باشد [1]:این پنج فاز مکانیزم مناسبی جهت درک خواسته‌های ذینفعان، تحلیل نیازها، تعیین امکان پذیر بودن پروژه، مذاکره در مورد راه حل قابل قبول، تعیین راه حل به صورت شفاف، اعتبار سنجی خصوصیات و مدیریت نیازمندی‌ها در زمان اعمال آنها به سیستم عملیاتی می‌باشد.هدف از فاز اول تعیین این موضوع است که چه مسائلی نیاز به حل شدن دارند. در فاز دوم درک ارتباط بین نیازمندی‌های گوناگون مشتری و شکل دادن به ارتباطات برای دستیابی به نتیجه موفق انجام می‌شود. در فاز سوم از روش‌هایی چون ایجاد یک مدل ملموس از سیستم می‌تواند به تعیین نیازمندی‌ها کمک کند. در فاز چهارم توسط بازبینی مدل به اعتبار و صحت سنجی نیازهای ثبت شده پرداخته و در فاز آخر به مدیریت این فرایند که شامل تعیین، کنترل و پیگیری نیازها و تغییرات آنها می‌باشند، می‌پردازیم.استخراج نیازمندی‌ها به عنوان اولین و مهم‌ترین فاز از پنج فاز مهندسی نیازمندی‌ها می‌باشد. هدف استخراج نیازمندی‌ها تعیین این مطلب است که چه مسائلی نیازمند حل شدن هستند. بیشتر سیستم‌هایی که در صنعت نرم افزار ساخته می‌شوند نمی‌توانند نیازهای کاربران را برآورده کنند. کیفیت نیازمندی‌ها برای موفقیت یک پروژه حیاتی است. استخراج نیازمندی‌ها فاز اول مهندسی نیازمندی‌ها است و نقش مهمی در طول چرخه‌ی عمر توسعه‌ی نرم افزار دارد. این فاز شامل مسائل اجتماعی، ارتباطی و تکنیکی و درگیر بیرون کشیدن نیازمندی‌های مشتری است و یکی از فعالیت‌های کلیدی و پیچیده محسوب می‌شود، زیرا در اکثر موارد کاربران از نیازهای خود آگاه نیستند و اختلاف در نقاط دید طرز تفکر و انتظارات بین کاربران و تحلیلگران این کار را مشکل و چالش برانگیز ساخته است. برای پشتیبانی و بهبود فرایند استخراج تکنیک‌های زیادی با نقاط ضعف و قدرت متفاوت وجود دارند اما مهندسان نیازمندی همواره برای انتخاب تکنیک مناسب از بین این تکنیک‌ها مشکلاتی دارند. مهم‌ترین دلیل آن این است که یک تکنیک برای همه‌ی موقعیت‌ها مناسب نیست و موقعیت در طول فرایند استخراج تغییر می‌کند. نقل قولی از فردریک بروکس جواب این سؤال را که "چرا نیازمندی‌ها اینقدر اهمیت دارند" می‌گوید: سخت‌ترین بخش ساخت یک سیستم نرم‌افزاری تصمیم گیری دقیق در مورداین است که چه چیزی باید ساخته شود. بخش‌های دیگر عمل درک نیازمندی‌ها بهسختی وضع کردن نیازمندی‌های فنی مجزا نیست که شامل همه رابطه‌های افراد،ماشین‌ها ، و سیستم‌های نرم افزاری دیگر است. بخش‌های دیگر سیستم حاصل رااینقدر عاجز نمی‌کنند اگر اشتباه انجام شود. هیچ بخش دیگری سخت‌تر از ایننیست که بعداً تصحیح شود. استنباط ، تحلیل ، و خوب نوشتن نیازمندی‌ها سخت‌ترین بخش‌های مهندسی نرم افزار هستند. به هر حال به نقل قول از کارل ویگرس "اگر شما نیازمندی‌ها را درست نگیرید هیچ اهمیتی نخواهد داشت که شماچیزهای دیگر را چقدر خوب انجام داده باشید".همان طور كه از نام سازمان‌هاي بزرگ مقياس برمي‌آيد، اين نوع از سازمان‌ها، سازمان‌هايي هستند كه از نظر مقياس و اندازه فراتر از سازمان‌هاي امروزي هستند. اين «بزرگ مقياس» بودن از هر نظر قابل بررسي است: از نظر افراد درگير در سازمان، داده‌هاي ذخيره شده، بازيابي شده، دستكاري شده و پالايش شده، ميزان اتصالات و وابستگي بين واحدي مؤلفه‌های نرم‌افزاري، عناصر سخت‌افزاري و ... .«مقياس» در سازمان‌هاي بزرگ مقياس باعث تغيير همه چيز مي‌شود. اين سازمان‌ها، لزوماً به شكل نامتمركز هستند؛ توسط تعداد زيادي از ذینفعان با نيازهاي متضاد، توسعه و به كار گرفته مي‌شوند؛ به طور مستمر تكامل پيدا مي‌كنند؛ از قطعات ناهمگن تشكيل مي‌شوند؛ افراد تنها كاربران سامانه نيستند، بلكه بخشي از سامانه محسوب مي‌شوند؛ خرابي‌هاي نرم‌افزاري و سخت‌افزاري يك امر كاملاً عادي محسوب مي‌شوند و نمي‌توان آنها را يك استثناء در نظر گرفت. همچنين، سامانه‌هاي بزرگ مقياس همزمان مورد استفاده قرار مي‌گيرند و نياز به روش‌هاي نوين براي كنترل دارند. اين ويژگي‌ها، لزوم بكارگيري روش‌هايي را براي استفاده، توليد، استقرار، مديريت، مستندسازي و تكامل سازمان‌هاي بزرگ مقياس اجتناب‌ناپذير مي‌سازد[3].از نمونه این سازمان‌ها می‌توان به شهرداری تهران اشاره نمود که دارای مجموعه وسیعی از نیروی انسانی در واحدهای مختلف بوده که هدف آنها جلب رضایت هرچه بیشتر شهروندان می‌باشد. ارضای نیازمندی‌های شهروندان در اولویت وظایف این سازمان قرار داشته و با بوجود آوردن زیرمجموعه‌هایی همچون سامانه مدیریت شهری 137، سامانه نظارت همگانی 1888 و ... با دخیل کردن شهروندان در ثبت نظرات، پیشنهادات، خواسته‌ها و نیازهایشان سعی به انجام بهتر این وظیفه بزرگ دارد.سازمان‌هاي بزرگ مقياس ويژگي‌هايي دارند كه باعث مي‌شوند رويكردهاي فعلي و مورد استفاده روش‌هاي مهندسي نرم‌افزار نتوانند پاسخگوي توسعه آنها باشند. اين ويژگي‌ها عمدتاً ناشي از «مقياس» اين گونه از سازمان‌ها است. ويژگي اصلي سازمان‌هاي بزرگ مقياس، اندازه بسيار بزرگ آنها در ابعاد مختلف است. البته ماهيت سامانه‌هاي بزرگ مقياس به مواردي فراتر از «اندازه» آنها برمي‌گردد. در واقع، اندازه باعث مي‌شود بسياري از مواردي كه در سازمان‌هاي معمولي غیر مهم يا كم اهميت بودند، تبديل به موارد بااهميت شوند. مشكلات ناشي از مقياس، نيازمند روش‌هاي جديد حل و تعريف مفاهيم نو براي طراحي، توسعه، كاركرد و تكامل سازمان‌ها است. مي‌توان هفت ويژگي را براي سازمان‌ها و یا سامانه‌های بزرگ مقياس در نظر گرفت. در ادامه، ضمن بيان اين ويژگي‌ها، مشخص مي‌كنيم چرا هر يك از آنها باعث مي‌شود كه رويكردهاي فعلي مهندسي نرم‌افزار در مقابله با آنها ناتوان باشد [3].مقياس سامانه‌هاي بزرگ مقیاس تنها به شكل بسيار محدودي اجازه كنترل مركزي و سلسله مراتبي داده، توسعه، تكامل، و كاركرد را مي‌دهد. حتي مقدار محدود كنترل سلسله مراتبي كه امروزه در سامانه‌هاي بسيار بزرگ امكان‌پذير است، در سامانه‌هاي بزرگ مقیاس مورد ترديد است، و در نتيجه مدل‌هاي متفاوتي را براي كنترل طلب مي‌كند.مقياس و پيچيدگي مسائلي كه سازمان‌هاي بزرگ مقياس بايد حل كنند، اغلب ما را به سمت وضعيتي سوق مي‌دهد كه در آن نيازمندي‌هاي يك سامانه تا زمان استفاده از آن سامانه ناشناخته‌اند. حتی، گاهي پس از آن كه سامانه مورد نظر عملياتي شد، درك ما از مسئله دچار تغيير مي‌شود. در واقع، هر تلاش براي حل مسئله، فهم ما را از آن مسئله بيشتر مي‌كند و باعث مي‌شود مسئله جديدي مطرح شده و به تلاشي ديگر براي حل آن نياز باشد. به اين شكل، بسياري از مسائلي كه سامانه‌هاي بزرگ مقياس بايد حل كنند، پايان‌پذير نيستند. از طرف ديگر، سامانه‌هاي بزرگ مقياس به دليل اندازه و ماهیتشان بايد طيف وسيعي از نيازمندي‌ها را ارضا كنند. هر چقدر دامنه اين نيازمندي‌ها وسيع‌تر باشد، تنوع و تضاد در بين آنها افزايش مي‌يابد. همچنين، يكپارچگي راه‌حل‌ها نياز به دانش در حوزه‌هاي مختلف و بين دامنه‌اي دارد، كه به دست آوردن آن چندان ساده نيست.يكي ديگر از پيامدهاي «اندازه» اين است كه سازمان‌هاي بزرگ مقياس براي مدت طولاني بايد به ارايه خدمات بپردازند. در واقع، اندازه اين نوع از سازمان‌ها جايگزيني يا از رده خارج شدن آنها را غيرممكن مي‌سازد. سازمان‌هاي بزرگ مقياس نيز همانند سامانه‌هاي بسيار بزرگ امروزي به طور مداوم تكامل پيدا مي‌كنند تا نيازمندي‌هاي جديد و تغييريافته را برآورده كنند. با اين حال، ما به تكاملي متفاوت از تكامل در سازمان‌هاي بسيار بزرگ امروزي نياز داريم. هنگامي كه از تكامل يك سامانه صحبت مي‌كنيم، منظورمان تغييرات هدايت‌شده‌اي است كه بر اساس قواعد و سياست‌ها، به شكل محلي انجام مي‌شود بدون آن كه يكپارچگي آن سامانه را از بين ببرد. اما، يكپارچگي در سامانه‌هاي بزرگ مقياس توسط گروه‌هاي مختلفي از ذینفعان انجام مي‌شود. هيچ تضميني وجود ندارد كه اين تغييرات كاملاً قاعده‌مند بوده و بر اساس قواعد از پیش تعریف شده انجام پذيرد.اندازه سامانه‌هاي بزرگ مقياس به این معني است كه عناصر آن (همچون سخت‌افزار، نرم‌افزار، روال‌ها، قواعد، افراد و ...) ناهمگن، ناسازگار و در حال تغيير هستند. عناصر نرم‌افزاري به دليل گوناگون بودن منابع آنها ناهمگن هستند (زبان‌هاي برنامه‌سازي متفاوت، سكوهاي مختلف، متدلوژی‌های متفاوت و ...). از آن جا كه ايجاد نرم‌افزارها نيز در شرايط متفاوتي (از منظر مكان‌ها، زمان‌بندي‌ها، فرآيندها، اهداف، ذینفعان و ...) انجام شده است، احتمالاً در طراحي، ساخت و بهره‌برداري با يكديگر ناسازگارند. بخش‌هاي مختلف يك سامانه همواره در حال تغيير هستند. محيط عملياتي تغيير مي‌كند؛ بخش‌هاي خراب سخت‌افزار بايد جايگزين شوند؛ نرم‌افزارها و سخت‌افزارها به روز مي‌شوند؛ و پيكربندي مؤلفه‌ها اصلاح مي‌شوند.