تحلیلگر نرم‌افزار کیست؟ وظایف، مهارت‌ها و مسیر شغلی Software Analyst

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

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

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

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

۱. تحلیلگر نرم‌افزار چیست؟

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

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

مسئله و نیاز → تحلیل → راهکار نرم‌افزاری

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

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

البته عنوان Software Analyst در همه شرکت‌ها یک تعریف کاملاً یکسان ندارد. در برخی سازمان‌ها وظایف این نقش به Systems Analyst، Business Systems Analyst، Applications Analyst یا عناوین مشابه نزدیک است و بخشی از مسئولیت‌های آن‌ها با یکدیگر هم‌پوشانی دارد. بنابراین برای شناخت دقیق نقش، علاوه بر عنوان شغلی باید شرح وظایف (Job Description) را نیز بررسی کرد.

هدف اصلی تحلیلگر نرم‌افزار چیست؟

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

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

در واقع می‌توان نقش او را در یک زنجیره ساده این‌گونه نشان داد:

Business Problem → Requirement → Analysis → Software Solution → Development → Testing

تحلیلگر نرم‌افزار در بخش قابل‌توجهی از این مسیر حضور دارد و بسته به ساختار سازمان ممکن است با Business Analyst، Product Owner، Developer، Software Architect و Software Tester همکاری کند.

۲. تحلیلگر نرم‌افزار چه کاری انجام می‌دهد؟

وظایف تحلیلگر نرم‌افزار به نوع پروژه، ساختار سازمان و میزان تفکیک نقش‌ها بستگی دارد. در یک شرکت ممکن است تحلیلگر بیشتر روی نیازمندی‌ها و تحلیل سیستم تمرکز کند و در شرکت دیگری بخشی از وظایف Business Analyst یا System Analyst را نیز بر عهده داشته باشد.

با این حال، فعالیت‌های اصلی این نقش معمولاً حول یک سؤال شکل می‌گیرند:

نرم‌افزار باید چه مسئله‌ای را حل کند و برای حل آن دقیقاً چگونه باید عمل کند؟

شناخت مسئله و نیاز

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

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

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

بررسی سیستم و فرایند موجود

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

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

شناخت As-Is به تحلیلگر کمک می‌کند قبل از پیشنهاد تغییر، بداند سیستم در حال حاضر چگونه کار می‌کند.

جمع‌آوری و تحلیل نیازمندی‌ها

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

نیازمندی‌ها ممکن است از منابع مختلفی به دست بیایند؛ برای مثال:

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

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

برای مثال، اگر یک نیازمندی بگوید:

«کاربر باید بتواند سفارش خود را لغو کند.»

تحلیلگر باید سؤالات بیشتری را مشخص کند:

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

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

تبدیل نیازمندی به مشخصات قابل استفاده برای تیم فنی

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

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

• Functional Requirements
• Non-functional Requirements
• User Story
• Use Case
• Acceptance Criteria
• Process Flow
• Data Flow
• Functional Specification

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

تحلیل فرایندها و جریان اطلاعات

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

برای مثال در یک سیستم فروش آنلاین، تحلیلگر ممکن است جریان زیر را بررسی کند:

ثبت سفارش → بررسی موجودی → پرداخت → تأیید سفارش → ارسال → به‌روزرسانی وضعیت

در هر مرحله باید مشخص شود چه داده‌ای وارد سیستم می‌شود، چه تصمیمی گرفته می‌شود، چه سیستمی درگیر است و چه خروجی‌ای ایجاد می‌شود.

شناسایی مشکلات و نقاط ضعف سیستم

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

در این شرایط ممکن است تحلیلگر مواردی مانند موارد زیر را شناسایی کند:

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

سپس می‌تواند برای بهبود آن‌ها راهکارهای مناسب را با همکاری ذی‌نفعان و تیم فنی بررسی کند.

همکاری با تیم توسعه

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

در طول توسعه ممکن است Developer درباره یک Requirement، Rule یا رفتار خاص سیستم سؤال داشته باشد. تحلیلگر باید بتواند ابهام را برطرف کند و در صورت نیاز، Requirement را با توجه به اطلاعات جدید اصلاح کند.

به همین دلیل، ارتباط مداوم میان تحلیلگر و تیم توسعه اهمیت زیادی دارد.

همکاری با تیم تست

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

برای مثال، اگر Requirement مشخص کند:

«پس از سه بار ورود رمز عبور اشتباه، حساب کاربر به مدت ۱۵ دقیقه مسدود شود.»

تستر می‌تواند بر اساس همین رفتار مورد انتظار، سناریوهای تست مناسب را طراحی کند.

تحلیلگر نیز می‌تواند در بررسی ابهام‌های Requirement، تعریف Acceptance Criteria و مشخص کردن رفتار مورد انتظار سیستم با Tester همکاری کند.

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

مستندسازی

مستندسازی بخش دیگری از فعالیت تحلیلگر است، اما هدف مستندسازی صرفاً تولید حجم زیادی از Document نیست.

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

نوع و میزان این مستندات به روش توسعه، سازمان و پروژه بستگی دارد. در یک پروژه ممکن است مستندات رسمی و مفصل مورد نیاز باشد و در یک تیم Agile، بخش زیادی از اطلاعات در قالب User Story، Acceptance Criteria، Diagram و ابزارهای مدیریت کار نگهداری شود.

مدیریت تغییرات و تحلیل اثر تغییر

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

در چنین شرایطی، تحلیلگر باید بررسی کند:

این تغییر چه بخش‌هایی از سیستم، فرایندها، داده‌ها، Requirements و قابلیت‌های موجود را تحت تأثیر قرار می‌دهد؟

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

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

۳. فرایند کار تحلیلگر نرم‌افزار چگونه است؟

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

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

یک تصویر ساده از این فرایند می‌تواند چنین باشد:

Problem → Requirement → Analysis → Solution → Specification → Development → Testing → Change

۱. شناخت مسئله

اولین قدم این است که مشخص شود چرا اصلاً به تغییر یا ایجاد یک سیستم نیاز داریم.

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

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

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

۲. شناخت کاربران و ذی‌نفعان

تحلیلگر باید مشخص کند چه افرادی با سیستم کار می‌کنند یا از نتایج آن تأثیر می‌پذیرند.

برای مثال در یک سیستم فروش ممکن است این افراد درگیر باشند:

• مشتری
• کارشناس فروش
• مدیر فروش
• مسئول انبار
• واحد مالی
• مدیر سیستم

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

۳. بررسی وضعیت موجود

در این مرحله تحلیلگر به سراغ سیستم و فرایند فعلی می‌رود.

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

این مرحله معمولاً با مفهوم As-Is مرتبط است؛ یعنی توصیف وضعیت موجود.

۴. شناسایی و تحلیل نیازمندی‌ها

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

در این مرحله تحلیلگر باید میان موارد مختلف تمایز ایجاد کند:

• نیاز واقعی
• راهکاری که کاربر پیشنهاد داده است
• محدودیت
• فرض
• Business Rule
• Functional Requirement
• Non-functional Requirement

این تفکیک مهم است، چون ممکن است کاربر راه‌حل مشخصی را درخواست کند، در حالی که مسئله اصلی می‌تواند با راهکار دیگری بهتر حل شود.

۵. بررسی امکان‌پذیری و محدودیت‌ها

هر نیازمندی لزوماً به این معنی نیست که می‌توان آن را بدون محدودیت پیاده‌سازی کرد.

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

• محدودیت سیستم فعلی
• فناوری مورد استفاده
• Integration
• داده‌های موجود
• امنیت
• Performance
• هزینه
• زمان

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

۶. تعریف راهکار و رفتار مورد انتظار سیستم

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

برای مثال، به جای اینکه فقط گفته شود:

«کاربر باید بتواند سفارش خود را لغو کند.»

ممکن است رفتار سیستم دقیق‌تر تعریف شود:

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

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

۷. مستندسازی و ایجاد مدل

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

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

• Requirement
• User Story
• Use Case
• Acceptance Criteria
• Process Flow
• UML Diagram
• Data Flow
• Functional Specification

هدف از این مستندات ایجاد یک درک مشترک از سیستم است.

۸. همکاری با تیم توسعه

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

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

۹. همکاری در تست و اعتبارسنجی

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

در این مرحله تحلیلگر می‌تواند با Tester همکاری کند، به سؤالات مربوط به رفتار مورد انتظار پاسخ دهد و در بررسی Acceptance Criteria یا نتایج تست مشارکت داشته باشد.

برای مثال اگر Requirement می‌گوید:

«سیستم نباید اجازه ثبت سفارش بدون آدرس معتبر را بدهد.»

تحلیلگر باید بتواند مشخص کند منظور از «آدرس معتبر» چیست و چه شرایطی باید توسط سیستم بررسی شود.

۱۰. بررسی تغییرات و بهبودهای بعدی

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

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

بنابراین فرایند تحلیل می‌تواند بارها تکرار شود:

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

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

۴. تحلیلگر نرم‌افزار چه خروجی‌ها و مستنداتی تولید می‌کند؟

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

در یک پروژه ممکن است تحلیلگر با مستنداتی مانند SRS و Functional Specification کار کند و در یک تیم Agile، بخش زیادی از اطلاعات در قالب User Story، Acceptance Criteria، Diagram و آیتم‌های موجود در ابزار مدیریت پروژه ثبت شود.

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

Requirement

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

برای مثال:

سیستم باید امکان جست‌وجوی سفارش‌ها بر اساس شماره سفارش، شماره مشتری و بازه زمانی را فراهم کند.

تحلیلگر باید کمک کند Requirementها تا حد امکان شفاف، دقیق، قابل فهم و قابل بررسی باشند.

Functional Requirement

Functional Requirement مشخص می‌کند سیستم چه کاری باید انجام دهد.

برای مثال:

سیستم باید پس از ثبت موفق پرداخت، وضعیت سفارش را به «پرداخت‌شده» تغییر دهد.

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

Non-functional Requirement

Non-functional Requirement به ویژگی‌ها و محدودیت‌های سیستم مربوط می‌شود؛ مانند Performance، Security، Availability یا Usability.

برای مثال:

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

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

User Story

در تیم‌های Agile ممکن است نیازمندی‌ها در قالب داستان کاربرUser Story بیان شوند.

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

در اینجا تحلیلگر ممکن است در تعریف Story، شفاف‌سازی جزئیات و تعیین شرایط پذیرش با Product Owner، تیم توسعه و سایر اعضای تیم همکاری کند.

Use Case

یوزکیس Use Case برای توصیف تعامل یک Actor با سیستم و بررسی سناریوهای مختلف استفاده می‌شود.

برای مثال در یک سیستم فروش:

Actor: مشتری
Use Case: ثبت سفارش

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

Acceptance Criteria

Acceptance Criteria مشخص می‌کند یک قابلیت تحت چه شرایطی قابل قبول است.

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

Acceptance Criteria نقش مهمی در ایجاد درک مشترک بین تحلیل، توسعه و تست دارد.

Process Flow

گاهی برای درک بهتر یک فرایند، تحلیلگر آن را به شکل یک جریان ترسیم می‌کند.

ثبت سفارش → بررسی موجودی → پرداخت → تأیید سفارش → ارسال

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

UML Diagram

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

• Use Case Diagram
• Activity Diagram
• Sequence Diagram
• Class Diagram

البته استفاده از UML برای همه پروژه‌ها و همه تحلیلگران یکسان نیست و به نیاز پروژه و استانداردهای سازمان بستگی دارد.

Functional Specification

در برخی سازمان‌ها لازم است رفتار مورد انتظار یک قابلیت یا سیستم با جزئیات بیشتری مستند شود. در این شرایط ممکن است از Functional Specification یا اسناد مشابه استفاده شود.

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

مستندات تغییرات

اگر قرار باشد قابلیت جدیدی به سیستم اضافه شود یا رفتار یک قابلیت موجود تغییر کند، تحلیلگر ممکن است اطلاعات مربوط به Change Request و اثر آن بر سیستم را مستند کند.

در اینجا تحلیل Impact Analysis اهمیت پیدا می‌کند؛ زیرا باید مشخص شود یک تغییر چه بخش‌هایی از سیستم، داده‌ها، فرایندها و قابلیت‌های موجود را تحت تأثیر قرار می‌دهد.

آیا تحلیلگر نرم‌افزار باید همه این مستندات را تولید کند؟

خیر. فهرست بالا مجموعه‌ای رایج از خروجی‌های مرتبط با تحلیل نرم‌افزار است، نه شرح وظایف ثابت و اجباری برای همه Software Analystها.

در یک سازمان ممکن است Business Analyst مسئول Requirement و User Story باشد و Software/System Analyst روی تحلیل سیستم و Functional Specification تمرکز کند. در سازمانی دیگر ممکن است بخش زیادی از این مسئولیت‌ها در یک نقش ترکیب شده باشد.

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

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

۵. تحلیلگر نرم‌افزار با چه کسانی همکاری می‌کند؟

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

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

تحلیلگر نرم‌افزار و Business Analyst

یکی از نزدیک‌ترین نقش‌ها به تحلیلگر نرم‌افزار، Business Analyst است.

در یک تقسیم‌بندی کلی، Business Analyst بیشتر روی مسئله، هدف و نیاز کسب‌وکار تمرکز می‌کند؛ در حالی که تحلیلگر نرم‌افزار بیشتر به این موضوع می‌پردازد که این نیازها چگونه در قالب یک سیستم یا راهکار نرم‌افزاری پیاده‌سازی شوند.

برای مثال، Business Analyst ممکن است مشخص کند:

«شرکت نیاز دارد فرایند ثبت سفارش را سریع‌تر و ساده‌تر کند.»

تحلیلگر نرم‌افزار می‌تواند این نیاز را بررسی کند و به سؤالاتی مانند این بپردازد:

• سیستم فعلی چگونه سفارش را ثبت می‌کند؟
• چه اجزایی باید تغییر کنند؟
• چه داده‌هایی مورد نیاز است؟
• سیستم چه رفتاری باید داشته باشد؟
• این تغییر چه اثری بر سایر بخش‌های سیستم دارد؟

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

تحلیلگر نرم‌افزار و Product Owner

در تیم‌های Agile، Product Owner مسئول بیشینه‌سازی ارزش محصول و مدیریت Product Backlog است.

تحلیلگر نرم‌افزار می‌تواند در تحلیل جزئیات نیازمندی‌ها، شفاف‌سازی User Storyها، بررسی وابستگی‌ها و آماده‌سازی اطلاعات مورد نیاز تیم توسعه با Product Owner همکاری کند.

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

تحلیلگر نرم‌افزار و Developer

یکی از ارتباط‌های اصلی تحلیلگر با تیم Software Development است.

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

این تعامل می‌تواند باعث شود Requirement یا راهکار اولیه اصلاح شود.

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

تحلیلگر نرم‌افزار و Software Architect

در پروژه‌های پیچیده‌تر، تحلیلگر ممکن است با Software Architect نیز همکاری کند.

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

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

این دو نقش مکمل یکدیگر هستند، هرچند مرز مسئولیت‌ها در سازمان‌های مختلف می‌تواند متفاوت باشد.

تحلیلگر نرم‌افزار و Software Tester

ارتباط تحلیلگر و تستر برای کیفیت محصول اهمیت زیادی دارد.

تستر برای طراحی Test Scenario و Test Case به اطلاعات دقیقی درباره رفتار مورد انتظار سیستم نیاز دارد. تحلیلگر نیز می‌تواند در تعریف Requirement، Acceptance Criteria و Business Rules با تستر همکاری کند.

برای مثال، اگر یک Requirement بیان کند:

«کاربر پس از سه بار وارد کردن رمز عبور اشتباه باید موقتاً مسدود شود.»

تستر باید بداند:

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

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

تحلیلگر نرم‌افزار و کاربران

کاربران نهایی یکی از منابع مهم اطلاعات برای تحلیلگر هستند.

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

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

برای مثال کاربر ممکن است بگوید:

«کار کردن با این صفحه خیلی سخت است.»

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

تحلیلگر نرم‌افزار و Project Manager

در برخی پروژه‌ها تحلیلگر با Project Manager نیز در ارتباط است.

تغییرات Requirement، ابهام‌های تحلیلی، وابستگی‌های بین قابلیت‌ها و پیچیدگی یک نیازمندی می‌توانند روی زمان‌بندی و برنامه پروژه اثر بگذارند.

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

جایگاه تحلیلگر نرم‌افزار در تیم

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

Business / Users
↓
نیاز و مسئله
↓
Software Analyst
↓
Requirements / Analysis / Specification
↓
Developer + Architect + Tester
↓
Software Solution

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

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

۶. تفاوت تحلیلگر نرم‌افزار و تحلیلگر کسب‌وکار چیست؟

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

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

به‌طور ساده:

Business Analyst بیشتر می‌پرسد: «چه مسئله‌ای در کسب‌وکار وجود دارد و چه نیازی باید برطرف شود؟»

در مقابل:

Software Analyst بیشتر می‌پرسد: «این نیاز در یک سیستم نرم‌افزاری چگونه باید تحلیل و پیاده‌سازی شود؟»

تمرکز تحلیلگر کسب‌وکار

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

• مشکل فعلی کسب‌وکار چیست؟
• هدف سازمان از اجرای پروژه چیست؟
• چه افرادی تحت تأثیر این تغییر قرار می‌گیرند؟
• فرایند فعلی چگونه انجام می‌شود؟
• چه نیازی باید برآورده شود؟
• چه Business Ruleهایی وجود دارد؟
• راهکار پیشنهادی چه ارزشی برای کسب‌وکار ایجاد می‌کند؟

بنابراین تمرکز اصلی Business Analyst معمولاً روی Business Need، Business Process، Stakeholder و Value است.

تمرکز تحلیلگر نرم‌افزار

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

• سیستم فعلی چگونه این فرایند را انجام می‌دهد؟
• چه قابلیت‌هایی باید تغییر کنند؟
• داده‌ها چگونه در سیستم جریان پیدا می‌کنند؟
• سیستم جدید چه رفتاری باید داشته باشد؟
• چه سیستم‌هایی باید با یکدیگر ارتباط داشته باشند؟
• چه محدودیت‌های فنی وجود دارد؟
• تغییر موردنظر چه اثری بر بخش‌های دیگر سیستم دارد؟

در نتیجه تمرکز تحلیلگر نرم‌افزار بیشتر به Software/System، Requirements، Functional Behavior و تعامل میان اجزای سیستم نزدیک می‌شود.

یک مثال ساده

فرض کنید یک شرکت می‌خواهد امکان لغو سفارش آنلاین را اضافه کند.

Business Analyst ممکن است ابتدا بررسی کند:

• چرا مشتریان به لغو سفارش نیاز دارند؟
• چه سیاستی برای لغو سفارش وجود دارد؟
• چه شرایطی باید برای بازگشت وجه در نظر گرفته شود؟
• کدام ذی‌نفعان تحت تأثیر این تغییر هستند؟

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

• سیستم در حال حاضر وضعیت سفارش را چگونه مدیریت می‌کند؟
• چه Statusهایی باید اضافه یا تغییر کنند؟
• چه APIهایی درگیر خواهند شد؟
• لغو سفارش چه اثری بر انبار و پرداخت دارد؟
• سیستم در هر وضعیت سفارش چه رفتاری باید داشته باشد؟

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

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

موضوع	تحلیلگر کسب‌وکار	تحلیلگر نرم‌افزار
تمرکز اصلی	نیاز و مسئله کسب‌وکار	سیستم و راهکار نرم‌افزاری
نقطه شروع	Business Problem	نیازمندی و مسئله سیستم
تمرکز بر فرایند کسب‌وکار	زیاد	بسته به پروژه
تمرکز بر سیستم	ممکن است	معمولاً بیشتر
تعامل با ذی‌نفعان	زیاد	زیاد
تعامل با تیم توسعه	بسته به سازمان	معمولاً زیاد
تحلیل Requirements	بله	بله
تحلیل رفتار سیستم	ممکن است	معمولاً پررنگ
دانش فنی	بسته به نقش	معمولاً اهمیت بیشتری دارد
تحلیل اثر تغییرات سیستم	ممکن است	معمولاً مهم
مستندسازی فنی	بسته به سازمان	معمولاً بیشتر

آیا تحلیلگر نرم‌افزار همان Business Analyst است؟

نه لزوماً.

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

در یک سازمان ممکن است Business Analyst و Software/System Analyst دو نقش کاملاً جدا باشند. در سازمان دیگری ممکن است یک نفر مسئولیت‌های هر دو را انجام دهد.

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

ارتباط این دو نقش در یک پروژه

در پروژه‌هایی که هر دو نقش حضور دارند، می‌توان رابطه آن‌ها را به‌صورت ساده چنین دید:

Business Problem
↓
Business Analysis
↓
Business Need / Requirement
↓
Software/System Analysis
↓
Software Solution
↓
Development & Testing

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

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

۷. تفاوت تحلیلگر نرم‌افزار و تحلیلگر سیستم چیست؟

یکی از ابهام‌های رایج در مسیر شغلی تحلیل، تفاوت بین تحلیلگر نرم‌افزار (Software Analyst) و تحلیلگر سیستم (Systems Analyst) است. این ابهام تا حدی طبیعی است؛ زیرا در بسیاری از سازمان‌ها این دو عنوان شغلی هم‌پوشانی زیادی دارند و حتی ممکن است وظایف یکسانی برای آن‌ها تعریف شود.

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

البته این مرزبندی یک قانون ثابت نیست و به ساختار سازمان و شرح شغل بستگی دارد.

تحلیلگر سیستم چه کاری انجام می‌دهد؟

Systems Analyst معمولاً مسئله را از زاویه یک «سیستم» بررسی می‌کند. منظور از سیستم نیز فقط یک نرم‌افزار نیست؛ بلکه مجموعه‌ای از نرم‌افزارها، کاربران، فرایندها، داده‌ها و ارتباطات میان آن‌ها می‌تواند بخشی از سیستم مورد تحلیل باشد.

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

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

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

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

تحلیلگر نرم‌افزار بیشتر روی چه چیزی تمرکز می‌کند؟

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

برای مثال، اگر قرار باشد قابلیت «لغو سفارش» به یک فروشگاه اینترنتی اضافه شود، تحلیلگر نرم‌افزار باید مشخص کند:

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

در اینجا تمرکز اصلی روی رفتار مورد انتظار نرم‌افزار و تعامل اجزای آن است.

تفاوت تحلیلگر نرم‌افزار و تحلیلگر سیستم در یک نگاه

موضوع	تحلیلگر سیستم	تحلیلگر نرم‌افزار
دامنه تحلیل	معمولاً گسترده‌تر و در سطح سیستم	معمولاً متمرکزتر بر نرم‌افزار
تمرکز اصلی	سیستم، فرایندها، داده‌ها و تعامل بین اجزا	رفتار و نیازمندی‌های نرم‌افزار
نگاه به سازمان	معمولاً پررنگ‌تر	بسته به نقش و پروژه
تحلیل تعامل بین سیستم‌ها	معمولاً بخش مهمی از کار	در صورت ارتباط با نرم‌افزار موردنظر
تحلیل نیازمندی‌ها	بله	بله
تحلیل فرایندها	معمولاً پررنگ	بسته به پروژه
درک معماری و یکپارچه‌سازی	ممکن است گسترده‌تر باشد	در محدوده نرم‌افزار موردنظر اهمیت زیادی دارد
همکاری با توسعه‌دهنده	بله	بله
همکاری با تستر	بله	بله
عنوان شغلی	Systems Analyst	Software Analyst
میزان هم‌پوشانی	زیاد	زیاد

آیا تحلیلگر نرم‌افزار همان تحلیلگر سیستم است؟

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

عنوان Systems Analyst در بسیاری از سازمان‌ها برای نقشی استفاده می‌شود که بین نیازهای کسب‌وکار و راهکارهای فناوری اطلاعات قرار دارد. در برخی شرکت‌ها نیز فردی که عنوان Software Analyst دارد، تقریباً همین مسئولیت‌ها را انجام می‌دهد.

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

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

یک مثال برای درک بهتر تفاوت

فرض کنید یک بانک قصد دارد سامانه پرداخت خود را توسعه دهد.

تحلیلگر سیستم ممکن است مسئله را در سطح گسترده‌تری بررسی کند:

کاربر → سامانه بانک → سامانه پرداخت → بانک مقصد → سرویس احراز هویت → سیستم ثبت تراکنش

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

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

کاربر در نرم‌افزار چه چیزی می‌بیند؟ → چه داده‌ای وارد می‌کند؟ → چه اعتبارسنجی‌هایی انجام می‌شود؟ → چه درخواست API ارسال می‌شود؟ → پاسخ چگونه پردازش می‌شود؟ → وضعیت تراکنش چگونه نمایش داده می‌شود؟

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

تفاوت اصلی در یک جمله

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

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

۸. تفاوت تحلیلگر نرم‌افزار با برنامه‌نویس چیست؟

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

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

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

تحلیلگر نرم‌افزار چه کاری انجام می‌دهد؟

تحلیلگر نرم‌افزار مسئله را بررسی می‌کند و تلاش می‌کند نیازها و رفتار مورد انتظار سیستم را به شکلی روشن و قابل استفاده برای تیم فنی مشخص کند.

برای مثال، فرض کنید قرار است قابلیت لغو سفارش به یک فروشگاه اینترنتی اضافه شود.

تحلیلگر نرم‌افزار باید درباره موضوعاتی مانند این تصمیم‌گیری یا آن‌ها را مشخص کند:

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

خروجی این تحلیل می‌تواند به شکل Requirement، User Story، Use Case، Acceptance Criteria، نمودار فرایند یا سایر مستندات مورد استفاده پروژه باشد.

برنامه‌نویس چه کاری انجام می‌دهد؟

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

در همان مثال لغو سفارش، برنامه‌نویس ممکن است:

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

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

یک مثال ساده

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

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

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

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

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

موضوع	تحلیلگر نرم‌افزار	برنامه‌نویس
تمرکز اصلی	تحلیل مسئله و نیازمندی‌ها	پیاده‌سازی راهکار
سؤال اصلی	سیستم چه کاری باید انجام دهد؟	چگونه این رفتار را پیاده‌سازی کنیم؟
نیاز به درک کسب‌وکار	معمولاً زیاد	بسته به پروژه
تحلیل نیازمندی	بخش اصلی نقش	برای پیاده‌سازی ضروری است
طراحی راهکار	در سطح تحلیل و رفتار سیستم	در سطح فنی و پیاده‌سازی
کدنویسی	الزاماً بخش اصلی کار نیست	بخش اصلی کار
کار با Requirement	ایجاد، تحلیل و شفاف‌سازی	استفاده برای پیاده‌سازی
کار با تست	همکاری برای قابل‌تست بودن نیازمندی‌ها	رفع خطا و پیاده‌سازی تست‌های فنی
خروجی اصلی	مشخصات و مدل‌های قابل استفاده برای تیم	کد و اجزای نرم‌افزاری پیاده‌سازی‌شده

آیا تحلیلگر نرم‌افزار باید برنامه‌نویسی بلد باشد؟

الزاماً نه.

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

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

• API و نحوه ارتباط سرویس‌ها
• Database و ساختار داده
• Client و Server
• معماری نرم‌افزار در حد موردنیاز نقش
• HTTP و مفاهیم پایه ارتباطات وب
• Authentication و Authorization
• Integration و ارتباط بین سیستم‌ها
• منطق برنامه و جریان داده
• مفاهیم پایه کدنویسی

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

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

آیا برنامه‌نویس می‌تواند تحلیلگر نرم‌افزار شود؟

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

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

• تحلیل مسئله
• نیازمندی‌نویسی
• ارتباط با ذی‌نفعان
• مدل‌سازی
• مستندسازی
• تحلیل فرایند
• پرسیدن سؤال‌های درست
• مدیریت ابهام
• تحلیل اثر تغییرات

بنابراین مسیر Developer → Software Analyst می‌تواند یکی از مسیرهای ورود به این نقش باشد، اما تنها مسیر ممکن نیست.

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

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

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

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

در نهایت، می‌توان تفاوت این دو نقش را در یک مسیر ساده دید:

مسئله و نیاز → تحلیل → مشخصات و رفتار مورد انتظار → طراحی فنی → کدنویسی → تست

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

۹. تفاوت تحلیلگر نرم‌افزار و تستر نرم‌افزار چیست؟

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

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

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

تحلیلگر نرم‌افزار چه نقشی دارد؟

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

برای مثال، فرض کنید در یک فروشگاه اینترنتی این نیاز مطرح شده است:

«کاربر باید بتواند سفارش خود را لغو کند.»

این جمله به‌تنهایی برای توسعه و تست کافی نیست.

تحلیلگر نرم‌افزار باید سؤال‌هایی مانند این مطرح کند:

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

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

تستر نرم‌افزار چه نقشی دارد؟

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

برای همان قابلیت لغو سفارش، تستر ممکن است سناریوهایی مانند موارد زیر را بررسی کند:

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

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

تفاوت تحلیلگر نرم‌افزار و تستر در یک نگاه

موضوع	تحلیلگر نرم‌افزار	تستر نرم‌افزار
تمرکز اصلی	تحلیل مسئله و تعریف رفتار مورد انتظار	ارزیابی محصول و شناسایی مشکلات و ریسک‌ها
سؤال اصلی	سیستم باید چه کاری انجام دهد؟	آیا سیستم مطابق انتظار عمل می‌کند؟
نیازمندی‌ها	تحلیل، شفاف‌سازی و مستندسازی	بررسی قابلیت تست و استفاده برای طراحی تست
Acceptance Criteria	کمک به تعریف و شفاف‌سازی	مبنایی برای ارزیابی پذیرش قابلیت
سناریوی تست	ممکن است در تعریف رفتار کمک کند	طراحی و اجرای سناریوهای تست
Bug	ممکن است در تحلیل علت ابهام یا نیازمندی نقش داشته باشد	شناسایی، ثبت و پیگیری نقص
همکاری با توسعه‌دهنده	برای انتقال و شفاف‌سازی نیازمندی	برای بررسی و رفع مشکلات
هدف نهایی	ایجاد درک مشترک از راهکار مورد انتظار	ارائه اطلاعات درباره کیفیت و ریسک محصول

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

یکی از نکات مهم این است که تست نباید الزاماً بعد از پایان توسعه شروع شود.

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

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

برای مثال، فرض کنید نیازمندی نوشته شده است:

«سیستم باید در مدت کوتاهی پاسخ مناسبی به درخواست کاربر بدهد.»

این جمله از دید تست قابل اندازه‌گیری نیست. «مدت کوتاه» دقیقاً چند ثانیه است؟

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

ممکن است در نهایت مشخص شود که:

«در شرایط عادی، پاسخ API باید حداکثر طی ۲ ثانیه به کاربر برگردد.»

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

آیا تحلیلگر نرم‌افزار تست انجام می‌دهد؟

ممکن است، اما این موضوع به ساختار تیم و شرح شغل بستگی دارد.

در بعضی تیم‌ها تحلیلگر نرم‌افزار در فعالیت‌هایی مانند بررسی Acceptance Criteria، مرور سناریوهای تست یا بررسی نتایج UAT مشارکت می‌کند.

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

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

آیا تستر باید تحلیل بلد باشد؟

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

تستر برای طراحی تست مناسب باید بداند:

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

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

یک نکته مهم درباره ترتیب کار

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

تحلیلگر → برنامه‌نویس → تستر

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

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

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

تفاوت اصلی در یک جمله

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

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

مهارت‌های مورد نیاز تحلیلگر نرم‌افزار

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

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

مهارت تحلیل و حل مسئله

مهم‌ترین مهارت تحلیلگر نرم‌افزار، توانایی تحلیل مسئله است.

ممکن است یک کاربر یا مدیر فقط بگوید:

«سیستم سفارش‌ها مشکل دارد و باید بهتر شود.»

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

تحلیلگر باید بتواند مسئله را به بخش‌های کوچک‌تر تقسیم کند و بفهمد:

• مشکل دقیقاً در کدام بخش رخ می‌دهد؟
• چه کسانی با این مشکل مواجه هستند؟
• وضعیت فعلی چگونه است؟
• علت یا عوامل مؤثر چیست؟
• چه محدودیت‌هایی وجود دارد؟
• نتیجه مورد انتظار چیست؟
• تغییر موردنظر چه اثری بر بخش‌های دیگر دارد؟

بنابراین تحلیلگر نباید صرفاً پاسخ اولیه را ثبت کند؛ بلکه باید بتواند پشت درخواست اولیه را ببیند و مسئله واقعی را کشف کند.

مهارت تحلیل نیازمندی‌ها

بخش مهمی از کار تحلیلگر نرم‌افزار با Requirementها سروکار دارد.

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

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

برای مثال، اگر گفته شود:

«کاربر باید بتواند سفارش خود را سریع لغو کند.»

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

مهارت پرسیدن سؤال‌های درست

یکی از مهارت‌هایی که ممکن است در فهرست مهارت‌های فنی کمتر دیده شود، توانایی سؤال پرسیدن است.

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

برای مثال، به‌جای اینکه فقط بپرسد:

«آیا کاربر می‌تواند سفارش را لغو کند؟»

ممکن است لازم باشد بپرسد:

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

پرسش‌های مناسب می‌توانند بخش بزرگی از ابهام موجود در یک پروژه را آشکار کنند.

مهارت مدل‌سازی

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

بسته به پروژه ممکن است از مدل‌ها و نمودارهایی مانند موارد زیر استفاده شود:

• Flowchart
• Process Flow
• Use Case Diagram
• Activity Diagram
• Sequence Diagram
• ER Diagram
• State Diagram

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

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

دانش فنی نرم‌افزار

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

• Client و Server
• API
• Database
• HTTP
• Authentication و Authorization
• Web Services
• Integration
• Data Flow
• Software Architecture
• Version Control
• مفاهیم پایه برنامه‌نویسی

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

مهارت ارتباط با ذی‌نفعان

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

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

• کاربر درباره مشکل روزمره صحبت می‌کند.
• مدیر درباره نتیجه و هزینه تغییر صحبت می‌کند.
• برنامه‌نویس درباره محدودیت فنی سؤال می‌کند.
• تستر درباره قابل‌تست بودن نیازمندی سؤال می‌کند.
• معمار درباره تأثیر تغییر بر ساختار سیستم بررسی انجام می‌دهد.

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

مهارت مستندسازی

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

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

• Requirement
• User Story
• Use Case
• Acceptance Criteria
• Functional Specification
• Process Flow
• UML Diagram
• Change Documentation

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

تفکر سیستمی

تغییر یک بخش از نرم‌افزار ممکن است روی بخش‌های دیگری نیز اثر بگذارد.

برای مثال، تغییر وضعیت سفارش ممکن است روی موارد زیر اثر داشته باشد:

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

تحلیلگر باید بتواند این ارتباط‌ها را ببیند و فقط روی همان صفحه یا قابلیت موردنظر تمرکز نکند. این توانایی به‌ویژه هنگام Impact Analysis اهمیت دارد.

درک فرایندهای کسب‌وکار

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

برای مثال، تحلیلگر یک نرم‌افزار مدیریت مرخصی باید بداند:

درخواست مرخصی → بررسی مدیر → تأیید یا رد → ثبت در سیستم منابع انسانی → محاسبه مانده مرخصی

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

آشنایی با تست نرم‌افزار

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

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

آشنایی با مفاهیمی مانند موارد زیر می‌تواند در همکاری میان تحلیلگر و تستر بسیار مفید باشد:

• Test Scenario
• Test Case
• Acceptance Criteria
• Verification
• Validation
• Functional Testing
• Non-functional Testing

مهارت اولویت‌بندی

در پروژه‌های واقعی معمولاً همه نیازها را نمی‌توان هم‌زمان پیاده‌سازی کرد.

تحلیلگر باید بتواند تفاوت میان موارد زیر را درک کند:

• نیاز ضروری
• نیاز مهم
• نیاز مطلوب
• نیاز کم‌اهمیت

همچنین باید درباره وابستگی‌ها و پیامدهای هر تغییر اطلاعات مناسبی در اختیار تیم قرار دهد.

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

مهارت تحلیل اثر تغییرات

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

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

«اگر این قسمت تغییر کند، چه چیزهایی ممکن است تحت تأثیر قرار بگیرند؟»

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

• قابلیت‌های مرتبط
• نیازمندی‌های وابسته
• APIها
• داده‌ها و جداول
• رابط کاربری
• گزارش‌ها
• سیستم‌های یکپارچه
• تست‌ها
• مستندات

ترکیب مهارت‌ها مهم‌تر از یک مهارت خاص است

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

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

حل مسئله + تحلیل نیازمندی + دانش فنی + ارتباط مؤثر + مدل‌سازی + مستندسازی + درک فرایند + توجه به کیفیت

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

آیا تحلیلگر نرم‌افزار باید برنامه‌نویسی بلد باشد؟

یکی از سؤال‌های رایج درباره شغل تحلیلگر نرم‌افزار این است که آیا برای ورود به این حوزه باید برنامه‌نویس بود یا حداقل یک زبان برنامه‌نویسی را به‌صورت حرفه‌ای یاد گرفت؟

پاسخ کوتاه این است: نه، تحلیلگر نرم‌افزار الزاماً برنامه‌نویس نیست.

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

بنابراین بهتر است بین این دو موضوع تفاوت بگذاریم:

برنامه‌نویسی حرفه‌ای ≠ دانش فنی موردنیاز تحلیلگر نرم‌افزار

تحلیلگر نرم‌افزار چقدر باید برنامه‌نویسی بداند؟

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

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

در مقابل، تحلیلگری که روی یک محصول فنی، APIهای متعدد، Microservices یا یک سیستم پیچیده کار می‌کند، احتمالاً به دانش فنی عمیق‌تری نیاز دارد.

بنابراین بهتر است دانش موردنیاز را در چند سطح ببینیم.

سطح اول: درک مفاهیم برنامه‌نویسی

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

برای مثال، بهتر است مفاهیمی مانند این موارد را بشناسد:

• Variable
• Condition
• Loop
• Function
• Object
• Data Structure
• Error Handling
• Input و Output
• الگوریتم و منطق اجرای برنامه

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

سطح دوم: شناخت فناوری‌های مورد استفاده در پروژه

تحلیلگر نرم‌افزار باید بداند نرم‌افزاری که درباره آن تحلیل انجام می‌دهد، در چه محیطی کار می‌کند.

برای مثال، بسته به نوع پروژه ممکن است نیاز باشد با مفاهیمی مانند این‌ها آشنا باشد:

• Web Application
• Mobile Application
• Backend
• Frontend
• Database
• API
• REST
• HTTP
• Authentication
• Authorization
• Message Queue
• Microservices
• Cloud

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

سطح سوم: توانایی خواندن کد

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

برای مثال، فرض کنید یک توسعه‌دهنده می‌گوید:

«این تغییر به دلیل نحوه پیاده‌سازی فعلی، روی سرویس پرداخت هم اثر می‌گذارد.»

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

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

آیا تحلیلگر باید یک زبان برنامه‌نویسی یاد بگیرد؟

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

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

• Java
• C#
• Python
• JavaScript
• TypeScript

اما انتخاب زبان باید بر اساس محیط کاری و نوع پروژه انجام شود. اگر قرار است تحلیلگر در تیمی کار کند که Backend آن با Java توسعه داده می‌شود، آشنایی با Java می‌تواند کاربردی‌تر باشد. در پروژه‌ای دیگر ممکن است Python، C# یا TypeScript انتخاب مناسب‌تری باشد.

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

آیا ندانستن برنامه‌نویسی مانع ورود به این شغل است؟

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

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

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

• تحلیل API
• بررسی Database
• Integration
• تحلیل معماری
• Microservices
• بررسی Logها
• تعامل نزدیک با Backend و Frontend

به همین دلیل هنگام بررسی آگهی‌های استخدامی، بهتر است فقط به عنوان Software Analyst توجه نکنید و بخش Requirements یا Responsibilities آگهی را نیز با دقت بخوانید.

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

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

آیا یادگیری برنامه‌نویسی برای یک تحلیلگر ارزش دارد؟

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

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

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

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

پس برای شروع چه چیزی یاد بگیریم؟

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

یک مسیر منطقی می‌تواند این باشد:

مفاهیم پایه برنامه‌نویسی → درک Client/Server → Database → API و HTTP → معماری نرم‌افزار در حد کاربردی → آشنایی با یک زبان برنامه‌نویسی → توانایی خواندن کد

در کنار این مسیر، یادگیری Requirement، مدل‌سازی، مستندسازی، فرایندهای نرم‌افزار و مفاهیم تست اهمیت زیادی دارد.

در نتیجه، پاسخ دقیق‌تر به سؤال «آیا تحلیلگر نرم‌افزار باید برنامه‌نویسی بلد باشد؟» این است:

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

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

ابزارهای مورد استفاده تحلیلگر نرم‌افزار

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

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

ابزارهای مدیریت نیازمندی و مستندات

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

ابزارهایی مانند Confluence می‌توانند برای مستندسازی نیازمندی‌ها، تصمیمات، فرایندها و دانش پروژه استفاده شوند.

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

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

• ثبت Requirement
• مستندسازی تصمیمات
• نگهداری مستندات تحلیل
• ایجاد ارتباط بین مستندات
• ثبت تغییرات
• ایجاد یک مرجع مشترک برای اعضای تیم

ابزارهای مدیریت پروژه و وظایف

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

برای مثال، Jira در بسیاری از تیم‌های نرم‌افزاری برای مدیریت Work Itemها، User Storyها، Taskها، Bugها و وضعیت انجام کار استفاده می‌شود.

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

• ایجاد یا اصلاح User Story
• ثبت Acceptance Criteria
• بررسی وضعیت فعالیت‌ها
• مشاهده Bugهای مرتبط
• پیگیری تغییرات
• ارتباط دادن نیازمندی با Taskهای توسعه و تست

ابزارهایی مانند Trello، Azure DevOps یا سایر سیستم‌های مدیریت کار نیز بسته به سازمان ممکن است مورد استفاده قرار گیرند.

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

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

از جمله:

• Microsoft Visio
• diagrams.net (Draw.io)
• Lucidchart
• Visual Paradigm
• Enterprise Architect

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

• Flowchart
• UML
• Activity Diagram
• Sequence Diagram
• Use Case Diagram
• ER Diagram
• Process Flow

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

ابزارهای طراحی رابط کاربری

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

ابزارهایی مانند Figma می‌توانند برای ایجاد Wireframe یا Prototype و مشخص‌کردن جریان تعامل کاربر با سیستم استفاده شوند.

برای مثال، اگر قرار است قابلیت لغو سفارش ایجاد شود، تحلیلگر می‌تواند همراه با طراح مشخص کند:

صفحه سفارش → گزینه لغو → نمایش تأیید → انتخاب دلیل → نتیجه عملیات

البته طراحی بصری حرفه‌ای رابط کاربری معمولاً مسئولیت اصلی UI/UX Designer است و میزان مشارکت تحلیلگر به ساختار تیم بستگی دارد.

ابزارهای کار با Database

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

ممکن است برای بررسی Database از ابزارهایی مانند موارد زیر استفاده شود:

• MySQL Workbench
• SQL Server Management Studio
• DBeaver
• pgAdmin

هدف تحلیلگر لزوماً مدیریت یا توسعه پایگاه داده نیست. ممکن است از این ابزارها برای مواردی مانند موارد زیر استفاده کند:

• بررسی ساختار جداول
• شناخت ارتباط بین داده‌ها
• بررسی جریان اطلاعات
• اجرای Queryهای ساده
• بررسی اثر یک تغییر روی داده‌ها

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

ابزارهای بررسی و تحلیل API

در پروژه‌های مدرن، APIها بخش مهمی از ارتباط میان نرم‌افزارها هستند.

ابزارهایی مانند Postman می‌توانند به تحلیلگر کمک کنند تا رفتار API را بهتر بررسی کند.

برای مثال، تحلیلگر می‌تواند بررسی کند:

• Endpoint چیست؟
• چه پارامترهایی دریافت می‌شود؟
• چه داده‌ای ارسال می‌شود؟
• Response چه ساختاری دارد؟
• کدهای خطا چه هستند؟
• چه شرایطی باعث خطا می‌شود؟
• ارتباط بین چند API چگونه انجام می‌شود؟

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

ابزارهای مدیریت نسخه و مشاهده تغییرات

در بعضی تیم‌ها تحلیلگر نیز ممکن است با ابزارهای Version Control مانند Git برخورد داشته باشد.

البته تحلیلگر معمولاً مانند برنامه‌نویس مسئول مدیریت کد نیست، اما آشنایی با مفاهیمی مانند موارد زیر می‌تواند در درک بهتر فرایند توسعه و پیگیری تغییرات مفید باشد:

• Repository
• Branch
• Commit
• Pull Request
• Version

ابزارهای همکاری و ارتباط تیمی

تحلیلگر نرم‌افزار دائماً با افراد مختلف در ارتباط است؛ بنابراین ابزارهای ارتباط و همکاری نیز بخشی از محیط کاری او هستند.

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

• Microsoft Teams
• Slack
• Zoom
• Google Meet

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

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

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

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

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

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

آیا تحلیلگر نرم‌افزار باید همه این ابزارها را بلد باشد؟

خیر.

فهرست ابزارهای موردنیاز به شرکت، محصول و نوع نقش بستگی دارد. برای مثال، ممکن است یک آگهی شغلی روی Jira و Confluence تأکید داشته باشد، در حالی که موقعیت دیگری به SQL، API و ابزارهای مدل‌سازی اهمیت بیشتری بدهد.

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

یک ترکیب کاربردی برای شروع می‌تواند شامل این موارد باشد:

حوزه	نمونه ابزار یا فناوری
مدیریت کار	Jira، Azure DevOps
مستندسازی	Confluence
مدل‌سازی	Draw.io، Visio، Lucidchart
طراحی و Prototype	Figma
Database	SQL، DBeaver، SSMS
API	Postman
Version Control	Git
ارتباط تیمی	Teams، Slack
هوش مصنوعی	ابزارهای AI متناسب با نیاز پروژه

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

تحلیلگر نرم‌افزار در Agile و Scrum

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

نکته مهم این است که Software Analyst یک نقش رسمی و ثابت در Scrum نیست. Scrum نقش‌های مشخصی مانند Product Owner، Scrum Master و Developers دارد و مسئولیت‌های تحلیل ممکن است بسته به ساختار سازمان بین این نقش‌ها و سایر افراد تیم تقسیم شود.

بنابراین ممکن است یک سازمان تحلیلگر نرم‌افزار داشته باشد، در حالی که سازمان دیگری همان فعالیت‌ها را توسط Business Analyst، Product Owner یا اعضای تیم توسعه انجام دهد.

تحلیلگر نرم‌افزار در Agile چه نقشی دارد؟

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

برای مثال، ممکن است جریان کار به شکل زیر باشد:

نیاز کسب‌وکار → تحلیل → Requirement → User Story → Acceptance Criteria → Development → Testing → Feedback

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

• با Product Owner درباره هدف قابلیت صحبت می‌کند.
• با کاربران و ذی‌نفعان نیازها را شفاف می‌کند.
• با تیم توسعه درباره امکان‌پذیری و رفتار سیستم صحبت می‌کند.
• با تستر درباره قابل‌تست بودن Acceptance Criteria همکاری می‌کند.
• تغییرات و وابستگی‌های سیستم را بررسی می‌کند.

آیا در Scrum تحلیلگر نرم‌افزار وجود دارد؟

الزاماً نه.

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

برای مثال، در یک تیم ممکن است:

Product Owner
نیاز و اولویت محصول را مشخص کند.

Business Analyst
مسئله کسب‌وکار و نیاز ذی‌نفعان را تحلیل کند.

Software Analyst یا System Analyst
نیاز را از منظر سیستم و نرم‌افزار تحلیل کند.

Developers
راهکار فنی را طراحی و پیاده‌سازی کنند.

Testers
قابلیت را از نظر کیفیت، نیازمندی‌ها و ریسک ارزیابی کنند.

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

تحلیلگر نرم‌افزار و Product Owner

Product Owner بیشتر مسئول به حداکثر رساندن ارزش محصول و مدیریت Product Backlog است.

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

برای مثال، Product Owner ممکن است بگوید:

«کاربر باید بتواند سفارش خود را لغو کند.»

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

• در چه وضعیت‌هایی؟
• با چه محدودیت‌هایی؟
• چه اثری روی پرداخت دارد؟
• چه اثری روی موجودی دارد؟
• چه پیامی به کاربر نمایش داده شود؟
• چه سیستم‌هایی تحت تأثیر قرار می‌گیرند؟

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

تحلیلگر نرم‌افزار و User Story

در بسیاری از تیم‌های Agile، نیازمندی‌ها ممکن است در قالب User Story بیان شوند.

برای مثال:

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

اما User Story به‌تنهایی همیشه تمام جزئیات رفتاری سیستم را مشخص نمی‌کند.

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

• شرایط پذیرش
• قوانین کسب‌وکار
• حالت‌های مختلف سیستم
• وابستگی‌ها
• خطاها
• محدودیت‌های فنی
• اثر تغییر

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

تحلیلگر نرم‌افزار و Acceptance Criteria

Acceptance Criteria در Agile اهمیت زیادی دارد، زیرا مشخص می‌کند یک قابلیت تحت چه شرایطی قابل پذیرش است.

برای مثال:

User Story:
کاربر می‌تواند سفارش خود را لغو کند.

Acceptance Criteria:

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

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

البته در هر تیم، مسئولیت نوشتن Acceptance Criteria ممکن است بر عهده Product Owner، Business Analyst، Software Analyst یا ترکیبی از این افراد باشد.

تحلیلگر نرم‌افزار در Refinement

یکی از نقاط مهم همکاری تحلیلگر با تیم Agile، جلسه یا فرایند Backlog Refinement است.

در این مرحله، آیتم‌های آینده Backlog بررسی می‌شوند تا قبل از ورود به Sprint، ابهام‌های مهم آن‌ها کاهش پیدا کند.

تحلیلگر می‌تواند در این مرحله کمک کند:

• نیازمندی‌ها روشن شوند.
• شرایط و استثناها مشخص شوند.
• وابستگی‌ها شناسایی شوند.
• اطلاعات موردنیاز تیم توسعه تکمیل شود.
• Acceptance Criteria بررسی شود.
• بخش‌های مبهم برای بررسی بیشتر مشخص شوند.

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

آیا تحلیلگر نرم‌افزار در Sprint هم فعالیت می‌کند؟

بله، بسته به ساختار تیم.

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

در این شرایط تحلیلگر می‌تواند این جریان را تسهیل کند:

سؤال تیم → بررسی نیاز → گفت‌وگو با ذی‌نفع → تصمیم → به‌روزرسانی اطلاعات → ادامه توسعه

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

تحلیلگر نرم‌افزار و تغییرات در Agile

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

ممکن است پس از دریافت بازخورد کاربران مشخص شود که یک قابلیت باید تغییر کند. تحلیلگر باید بتواند بررسی کند:

• نیاز جدید دقیقاً چیست؟
• چه چیزی نسبت به وضعیت قبلی تغییر کرده است؟
• کدام قابلیت‌ها تحت تأثیر قرار می‌گیرند؟
• آیا Requirementهای قبلی باید تغییر کنند؟
• آیا Acceptance Criteria باید اصلاح شود؟
• چه اثری بر توسعه و تست خواهد داشت؟

بنابراین مهارت Impact Analysis در محیط Agile نیز اهمیت زیادی دارد.

آیا تحلیلگر نرم‌افزار در Scrum همان Business Analyst است؟

نه لزوماً.

در بعضی تیم‌ها Business Analyst و Software Analyst دو نقش جدا هستند و هر کدام تمرکز متفاوتی دارند.

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

برای مثال:

Business Analyst:
مسئله کسب‌وکار چیست؟ چه نیازی وجود دارد؟ چه ارزشی ایجاد می‌شود؟

Software Analyst:
این نیاز در نرم‌افزار چگونه باید رفتار کند؟ چه داده‌ها و سیستم‌هایی درگیر هستند؟ چه محدودیت‌ها و وابستگی‌هایی وجود دارد؟

اما این تقسیم‌بندی استاندارد و اجباری Scrum نیست و هر سازمان می‌تواند ساختار متفاوتی داشته باشد.

جایگاه تحلیلگر نرم‌افزار در یک تیم Agile

می‌توان نقش تحلیلگر را به‌صورت ساده این‌گونه نمایش داد:

Business / Users
↓
Business Need
↓
Analysis
↓
Requirement / User Story / Acceptance Criteria
↓
Development + Testing
↓
Feedback
↓
Analysis و بهبود بعدی

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

نکته مهم برای کسانی که می‌خواهند وارد این شغل شوند

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

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

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

به همین دلیل، مهارت‌هایی مانند Requirement Analysis، User Story، Acceptance Criteria، مدل‌سازی، Impact Analysis و ارتباط با تیم فنی در کنار آشنایی با Agile و Scrum اهمیت دارند.

در نهایت، نقش تحلیلگر نرم‌افزار در Agile را می‌توان در یک جمله خلاصه کرد:

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

تحلیلگر نرم‌افزار در SDLC

SDLC یا Software Development Life Cycle به چرخه‌ای گفته می‌شود که طی آن یک نرم‌افزار از شکل‌گیری نیاز و ایده تا توسعه، تست، انتشار و نگهداری پیش می‌رود.

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

در یک نگاه ساده، می‌توان ارتباط تحلیلگر با SDLC را این‌گونه دید:

نیاز → تحلیل → طراحی → توسعه → تست → انتشار → نگهداری و بهبود

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

تحلیلگر نرم‌افزار در مرحله نیازمندی‌ها

در ابتدای پروژه، یکی از مهم‌ترین فعالیت‌ها فهمیدن مسئله و نیاز است.

تحلیلگر تلاش می‌کند مشخص کند:

• چه مسئله‌ای باید حل شود؟
• کاربران چه نیازهایی دارند؟
• سیستم فعلی چگونه کار می‌کند؟
• چه محدودیت‌هایی وجود دارد؟
• چه قابلیت‌هایی موردنیاز است؟
• معیار پذیرش راهکار چیست؟

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

این بخش می‌تواند شامل تحلیل Functional Requirement و Non-functional Requirement نیز باشد.

تحلیلگر نرم‌افزار در مرحله طراحی

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

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

برای مثال، ممکن است لازم باشد مشخص شود:

کاربر → رابط کاربری → API → سرویس سفارش → پایگاه داده → سرویس پرداخت

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

تحلیلگر نرم‌افزار در مرحله توسعه

در مرحله توسعه، تحلیلگر لزوماً کدنویسی نمی‌کند؛ اما ارتباط او با تیم Development می‌تواند ادامه داشته باشد.

توسعه‌دهندگان ممکن است هنگام پیاده‌سازی با سؤال‌هایی مواجه شوند:

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

تحلیلگر می‌تواند این ابهام‌ها را بررسی و در صورت نیاز با ذی‌نفعان یا سایر اعضای تیم شفاف کند.

تحلیلگر نرم‌افزار در مرحله تست

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

برای مثال، تحلیلگر می‌تواند به تیم تست کمک کند تا:

• نیازمندی‌ها را بهتر درک کند.
• Acceptance Criteria را بررسی کند.
• رفتار مورد انتظار سیستم را مشخص کند.
• شرایط خاص و استثناها را توضیح دهد.
• تغییرات Requirement را منتقل کند.

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

به این ترتیب، ارتباط تحلیل و تست می‌تواند دوطرفه باشد.

تحلیلگر نرم‌افزار در مرحله انتشار

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

برای مثال، قبل از انتشار یک قابلیت جدید ممکن است لازم باشد مشخص شود:

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

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

تحلیلگر نرم‌افزار در مرحله نگهداری

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

پس از انتشار، ممکن است:

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

در چنین شرایطی، تحلیلگر دوباره باید مسئله را بررسی کند و اثر تغییر را روی سیستم موجود مشخص کند.

برای مثال، اگر شرکت تصمیم بگیرد روش محاسبه تخفیف را تغییر دهد، تحلیلگر باید بررسی کند این تغییر روی چه بخش‌هایی اثر خواهد گذاشت:

قیمت سفارش → پرداخت → فاکتور → گزارش مالی → APIها → تست‌ها

نقش تحلیلگر در مدل‌های مختلف SDLC

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

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

در Agile، تحلیل معمولاً به شکل تکرارشونده انجام می‌شود و با دریافت بازخورد، نیازمندی‌ها و جزئیات آن‌ها می‌توانند تغییر کنند.

بنابراین نمی‌توان یک الگوی ثابت برای فعالیت تحلیلگر در تمام پروژه‌ها تعریف کرد.

یک مثال از حضور تحلیلگر در کل SDLC

فرض کنید یک شرکت تصمیم گرفته قابلیت لغو سفارش را به فروشگاه اینترنتی خود اضافه کند.

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

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

↓

تحلیل
بررسی وضعیت‌های سفارش، پرداخت، موجودی و سیستم‌های مرتبط.

↓

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

↓

توسعه
پاسخ به ابهام‌های تیم توسعه درباره رفتار قابلیت.

↓

تست
شفاف‌سازی شرایط پذیرش و رفتار مورد انتظار برای تیم تست.

↓

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

↓

نگهداری
بررسی درخواست‌های جدید، خطاها و تغییرات مرتبط با قابلیت.

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

تحلیلگر نرم‌افزار در SDLC چه ارزشی ایجاد می‌کند؟

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

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

به‌صورت خلاصه:

Business / User Need → Analysis → Software Requirements → Design & Development → Testing → Release → Feedback → Analysis

این چرخه نیز نشان می‌دهد که تحلیلگر نرم‌افزار فقط «مستندکننده نیازمندی» نیست؛ بلکه درک و انتقال درست مسئله و بررسی اثر تغییرات، بخش مهمی از نقش او در طول SDLC است.

آیا تحلیلگر نرم‌افزار تست هم انجام می‌دهد؟

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

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

تحلیلگر در کدام فعالیت‌های تست مشارکت می‌کند؟

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

• بررسی و شفاف‌سازی Requirementها
• تعریف یا بررسی Acceptance Criteria
• توضیح رفتار مورد انتظار سیستم برای تستر
• بررسی سناریوهای مهم و حالت‌های استثنا
• همکاری در تحلیل نتایج تست
• بررسی اینکه آیا یک رفتار گزارش‌شده واقعاً با نیازمندی مغایرت دارد یا خیر
• مشارکت در UAT
• بررسی اثر تغییرات بر نیازمندی‌ها و تست‌های مرتبط

برای مثال، اگر تستر گزارش کند:

«کاربر بعد از پرداخت نمی‌تواند سفارش خود را لغو کند.»

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

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

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

آیا تحلیلگر باید Test Case بنویسد؟

الزاماً نه.

در بعضی تیم‌ها تحلیلگر ممکن است در تهیه سناریوها یا حتی Test Caseها مشارکت کند، اما این وظیفه در بسیاری از تیم‌ها بر عهده تستر است.

نقش مهم‌تر تحلیلگر این است که اطلاعات لازم را در اختیار تیم تست قرار دهد؛ برای مثال:

• شرایط مجاز و غیرمجاز
• قوانین کسب‌وکار
• رفتار مورد انتظار
• حالت‌های مختلف سیستم
• Acceptance Criteria
• وابستگی‌ها و محدودیت‌ها

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

آیا تحلیلگر می‌تواند خودش نرم‌افزار را تست کند؟

بله، ممکن است در بعضی سازمان‌ها چنین مسئولیتی نیز داشته باشد؛ به‌خصوص در تیم‌های کوچک که مرز نقش‌ها کمتر است.

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

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

تحلیلگر و UAT

یکی از حوزه‌هایی که تحلیلگر می‌تواند در آن مشارکت بیشتری داشته باشد، User Acceptance Testing یا UAT است.

در UAT، بررسی می‌شود که راهکار ارائه‌شده تا چه اندازه نیاز واقعی کاربران یا کسب‌وکار را پوشش می‌دهد.

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

• شناسایی سناریوهای واقعی کسب‌وکار
• توضیح رفتار مورد انتظار
• هماهنگی با کاربران
• بررسی ابهام‌های مشاهده‌شده
• تحلیل بازخورد کاربران

البته مسئولیت و نحوه اجرای UAT نیز در سازمان‌های مختلف متفاوت است.

تفاوت «تست کردن» و «کمک به تست»

این دو مفهوم را نباید یکی دانست.

ممکن است تحلیلگر در یک پروژه یک قابلیت را بررسی کند، نتیجه یک سناریو را با نیازمندی مقایسه کند یا حتی یک Test Case ساده اجرا کند. این کار به‌تنهایی به معنای آن نیست که نقش او همان Software Tester است.

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

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

جمع‌بندی

بنابراین پاسخ دقیق به سؤال «آیا تحلیلگر نرم‌افزار تست هم انجام می‌دهد؟» این است:

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

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

مسیر تبدیل شدن به تحلیلگر نرم‌افزار

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

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

اگر بخواهیم این مسیر را به چند مرحله ساده تقسیم کنیم، می‌توان از الگوی زیر استفاده کرد:

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

مرحله اول: آشنایی با مبانی نرم‌افزار

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

برای مثال:

• نرم‌افزار چگونه ساخته می‌شود؟
• Frontend و Backend چه تفاوتی دارند؟
• Database چیست؟
• API چیست؟
• Client و Server چگونه با هم ارتباط دارند؟
• Software Development Life Cycle چیست؟
• توسعه‌دهنده، تستر، تحلیلگر و سایر اعضای تیم چه نقشی دارند؟

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

مرحله دوم: یادگیری تحلیل نیازمندی

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

موضوعاتی مانند موارد زیر در این مرحله اهمیت دارند:

• Requirement
• Functional Requirement
• Non-functional Requirement
• User Story
• Use Case
• Acceptance Criteria
• Business Rule
• Process Flow
• Impact Analysis

برای مثال، اگر کاربر بگوید:

«می‌خواهم بتوانم سفارش را لغو کنم.»

نباید همین جمله را به‌عنوان یک Requirement نهایی در نظر گرفت.

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

مرحله سوم: یادگیری مدل‌سازی

تحلیلگر باید بتواند مسئله و رفتار سیستم را فقط با متن توضیح ندهد.

یادگیری مدل‌هایی مانند موارد زیر می‌تواند به درک بهتر سیستم و انتقال اطلاعات به اعضای تیم کمک کند:

• Flowchart
• Use Case Diagram
• Activity Diagram
• Sequence Diagram
• State Diagram
• ER Diagram

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

مرحله چهارم: تقویت دانش فنی

در این مرحله باید دانش فنی خود را به سطحی برسانید که بتوانید با تیم توسعه ارتباط مؤثر داشته باشید.

موضوعاتی مانند موارد زیر می‌توانند نقطه شروع مناسبی باشند:

• SQL
• API
• HTTP
• Database
• Authentication و Authorization
• Software Architecture
• Integration
• Git
• مفاهیم پایه برنامه‌نویسی

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

مرحله پنجم: یادگیری مفاهیم تست نرم‌افزار

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

به همین دلیل آشنایی با مفاهیمی مانند موارد زیر می‌تواند بسیار مفید باشد:

• Test Scenario
• Test Case
• Verification
• Validation
• Functional Testing
• Non-functional Testing
• Regression Testing
• UAT

این دانش به شما کمک می‌کند نیازمندی‌ها و Acceptance Criteria را به شکلی بنویسید که رفتار مورد انتظار سیستم تا حد امکان قابل بررسی باشد.

مرحله ششم: یادگیری ابزارهای رایج

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

مدیریت کار: Jira، Azure DevOps

مستندسازی: Confluence

مدل‌سازی: Draw.io، Visio، Lucidchart

طراحی و Prototype: Figma

Database: SQL و ابزارهایی مانند DBeaver یا SSMS

API: Postman

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

مرحله هفتم: تمرین تحلیل یک پروژه واقعی

دانستن تعریف Requirement یا User Story به‌تنهایی شما را به تحلیلگر تبدیل نمی‌کند.

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

برای مثال، یک سیستم فروشگاه اینترنتی را در نظر بگیرید و از خودتان بپرسید:

• کاربران چه کسانی هستند؟
• چه مسئله‌ای قرار است حل شود؟
• فرایند خرید چگونه است؟
• چه Requirementهایی وجود دارد؟
• سفارش چه وضعیت‌هایی دارد؟
• چه سیستم‌هایی با فروشگاه ارتباط دارند؟
• چه APIهایی لازم است؟
• چه Acceptance Criteriaهایی وجود دارد؟
• چه سناریوهایی باید تست شوند؟
• اگر قابلیت پرداخت تغییر کند، چه بخش‌هایی تحت تأثیر قرار می‌گیرند؟

سپس تلاش کنید پاسخ‌ها را مستند و مدل‌سازی کنید.

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

مرحله هشتم: ساخت نمونه‌کار

برای ورود به این شغل، داشتن نمونه‌ای از توانایی تحلیل می‌تواند مفید باشد.

برای مثال، می‌توانید یک پروژه فرضی را تحلیل کنید و موارد زیر را ایجاد کنید:

• Problem Statement
• Stakeholders
• Requirements
• User Stories
• Acceptance Criteria
• Use Cases
• Process Flow
• UML Diagrams
• API Analysis
• Database Model
• Test Scenarios
• Impact Analysis

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

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

لازم نیست همه افراد مستقیماً از موقعیت Junior Software Analyst شروع کنند.

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

Tester → Software Analyst

تجربه تست می‌تواند درک خوبی از Requirement، رفتار سیستم، سناریوها و خطاهای نرم‌افزار ایجاد کند.

Developer → Software Analyst

تجربه توسعه می‌تواند دانش فنی، درک معماری، Database، API و محدودیت‌های پیاده‌سازی را تقویت کند.

Business Analyst → Software Analyst

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

Support / Technical Support → Software Analyst

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

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

مرحله دهم: یادگیری از پروژه واقعی

تفاوت زیادی بین تحلیل یک پروژه تمرینی و کار روی یک محصول واقعی وجود دارد.

در پروژه واقعی با موضوعاتی مانند موارد زیر مواجه می‌شوید:

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

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

آیا برای تحلیلگر نرم‌افزار شدن باید مدرک خاصی داشته باشیم؟

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

آنچه در عمل اهمیت دارد این است که بتوانید نشان دهید:

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

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

یک مسیر پیشنهادی برای شروع

اگر بخواهیم کل مسیر را به شکل خلاصه نمایش دهیم:

۱. مبانی نرم‌افزار
↓
۲. Requirement و تحلیل نیازمندی
↓
۳. مدل‌سازی و مستندسازی
↓
۴. SQL، API و مفاهیم فنی
↓
۵. مفاهیم تست نرم‌افزار
↓
۶. ابزارهایی مانند Jira، Confluence، Postman و Draw.io
↓
۷. تحلیل یک پروژه تمرینی
↓
۸. ساخت نمونه‌کار
↓
۹. تجربه پروژه واقعی
↓
۱۰. تخصص در یک حوزه یا صنعت

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

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

تحصیلات و مدارک مورد نیاز برای تحلیلگر نرم‌افزار

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

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

چه رشته‌هایی برای تحلیلگر نرم‌افزار مناسب هستند؟

رشته‌های مرتبط با کامپیوتر و فناوری اطلاعات معمولاً ارتباط بیشتری با این شغل دارند؛ برای مثال:

• مهندسی کامپیوتر
• علوم کامپیوتر
• فناوری اطلاعات (IT)
• مهندسی نرم‌افزار
• سیستم‌های اطلاعاتی (Information Systems)

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

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

آیا مدرک دانشگاهی برای استخدام ضروری است؟

این موضوع به سازمان و آگهی شغلی بستگی دارد.

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

بنابراین نباید این دو گزاره را یکی دانست:

«مدرک مرتبط مفید است»
و
«بدون مدرک مرتبط نمی‌توان تحلیلگر نرم‌افزار شد»

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

آیا گواهینامه‌های حرفه‌ای لازم هستند؟

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

برای یک تحلیلگر نرم‌افزار، بسته به مسیر شغلی، آشنایی با حوزه‌هایی مانند موارد زیر می‌تواند مفید باشد:

• Requirements Engineering
• Business Analysis
• Software Development
• Software Testing
• Agile و Scrum
• Modeling و UML

برای مثال، گواهینامه‌های مرتبط با Business Analysis یا Agile ممکن است برای فردی که در این حوزه‌ها فعالیت می‌کند ارزشمند باشند؛ اما داشتن گواهینامه به‌تنهایی نشان نمی‌دهد که فرد می‌تواند یک سیستم واقعی را به‌درستی تحلیل کند.

برای ورود به این شغل، مدرک مهم‌تر است یا مهارت؟

بهتر است این موضوع را به‌صورت مدرک در برابر مهارت نگاه نکنیم.

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

برای مثال، تحلیلگری که بتواند:

• Requirementهای مبهم را شناسایی کند؛
• سؤال‌های مناسب از Stakeholder بپرسد؛
• فرایندهای سیستم را مدل کند؛
• نیازمندی‌ها را مستند کند؛
• با Developer و Tester ارتباط برقرار کند؛
• API و Database را در سطح مورد نیاز تحلیل کند؛
• و اثر یک تغییر را در سیستم بررسی کند؛

در عمل توانایی‌هایی دارد که صرف داشتن یک مدرک دانشگاهی آن‌ها را تضمین نمی‌کند.

اگر رشته دانشگاهی مرتبط نداشته باشیم چه؟

اگر رشته تحصیلی شما کامپیوتر یا IT نیست، می‌توانید مسیر یادگیری را به‌صورت مرحله‌ای طی کنید.

یک مسیر منطقی می‌تواند شامل این موارد باشد:

مبانی کامپیوتر و نرم‌افزار
↓
تحلیل نیازمندی و مستندسازی
↓
مدل‌سازی و UML
↓
مفاهیم Database و SQL
↓
API و مفاهیم ارتباط بین سیستم‌ها
↓
آشنایی با توسعه و تست نرم‌افزار
↓
تمرین تحلیل پروژه
↓
ساخت نمونه‌کار و کسب تجربه

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

جمع‌بندی

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

آنچه در بلندمدت اهمیت دارد، توانایی ترکیب چند نوع دانش است:

دانش کسب‌وکار + تحلیل نیازمندی + دانش فنی + مدل‌سازی + ارتباط مؤثر + تجربه پروژه

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

بازار کار و مسیر پیشرفت شغلی تحلیلگر نرم‌افزار

عنوان «تحلیلگر نرم‌افزار» در همه شرکت‌ها با یک شرح شغل یکسان استفاده نمی‌شود. ممکن است سازمانی فردی با این عنوان را استخدام کند و سازمان دیگری برای نقش مشابه از عنوان‌هایی مانند Software Analyst، Systems Analyst، Business Systems Analyst یا Applications Analyst استفاده کند.

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

تحلیلگر نرم‌افزار در چه شرکت‌هایی کار می‌کند؟

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

برای مثال:

• شرکت‌های تولیدکننده نرم‌افزار
• شرکت‌های تجارت الکترونیک
• بانک‌ها و شرکت‌های پرداخت
• شرکت‌های بیمه
• شرکت‌های حمل‌ونقل
• شرکت‌های ارائه‌دهنده خدمات آنلاین
• سازمان‌های بزرگ دارای سیستم‌های داخلی
• شرکت‌های فناوری و SaaS
• شرکت‌های مشاوره و پیاده‌سازی سیستم‌های سازمانی

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

عنوان‌های شغلی نزدیک به تحلیلگر نرم‌افزار

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

برخی از این عنوان‌ها عبارت‌اند از:

• Software Analyst
• Systems Analyst
• System Analyst
• Business Systems Analyst
• Application Analyst
• IT Analyst
• Programmer Analyst
• Software Business Analyst

البته مشابه بودن عنوان به معنای یکسان بودن شغل نیست. ممکن است یک شرکت از عنوان System Analyst برای نقشی استفاده کند که بخش زیادی از وظایف آن تحلیل نرم‌افزار است و شرکت دیگری همین عنوان را برای نقشی با مسئولیت‌های گسترده‌تر به کار ببرد.

بنابراین هنگام جست‌وجوی فرصت شغلی، بررسی Job Description اهمیت زیادی دارد.

مسیر رشد شغلی تحلیلگر نرم‌افزار چگونه است؟

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

یک مسیر احتمالی می‌تواند چنین باشد:

Junior Analyst
↓
Software Analyst / System Analyst
↓
Senior Analyst
↓
Lead Analyst / Analysis Lead
↓
Solution Architect، Product Management یا نقش‌های تخصصی و مدیریتی مرتبط

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

برای مثال، یک تحلیلگر ممکن است به سمت Business Analysis حرکت کند، فرد دیگری به سمت Product Management برود و فرد دیگری با تقویت دانش فنی خود به سمت System Analysis یا Solution Architecture حرکت کند.

چه چیزهایی باعث پیشرفت یک تحلیلگر می‌شود؟

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

برای مثال، یک تحلیلگر باتجربه‌تر ممکن است بتواند:

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

بنابراین رشد شغلی فقط به معنای گرفتن عنوان Senior نیست؛ بلکه معمولاً با افزایش دامنه مسئولیت و پیچیدگی مسائل نیز همراه است.

آیا تحلیلگر نرم‌افزار می‌تواند به برنامه‌نویسی یا معماری برود؟

بله.

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

برای مثال:

تحلیلگر → توسعه‌دهنده

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

تحلیلگر → تحلیلگر سیستم

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

تحلیلگر → Business Analyst

اگر تمرکز فرد بیشتر روی فرایندهای کسب‌وکار، Stakeholderها و نیازهای سازمانی باشد، مسیر Business Analysis می‌تواند گزینه‌ای مرتبط باشد.

تحلیلگر → Product Management

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

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

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

خیر.

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

برای مثال، یک شرکت بزرگ ممکن است سیستم‌هایی برای:

• فروش
• منابع انسانی
• مالی
• انبار
• ارتباط با مشتری
• مدیریت سفارش
• گزارش‌گیری

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

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

در بررسی یک موقعیت شغلی به چه چیزهایی توجه کنیم؟

اگر با عنوانی مانند Software Analyst یا System Analyst مواجه شدید، بهتر است این موارد را بررسی کنید:

1. مسئولیت اصلی نقش چیست؟
2. تمرکز روی Business Analysis است یا Software/System Analysis؟
3. آیا Requirement Engineering بخشی از وظایف است؟
4. میزان دانش فنی مورد انتظار چقدر است؟
5. آیا SQL، API یا UML مورد نیاز است؟
6. ارتباط با Developer و Tester چگونه تعریف شده است؟
7. آیا نقش در Agile/Scrum فعالیت می‌کند؟
8. آیا تجربه یک صنعت خاص لازم است؟
9. آیا مسئولیت مستندسازی و تحلیل تغییرات نیز بر عهده این نقش است؟

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

جمع‌بندی

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

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

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

تحلیلگر نرم‌افزار برای چه کسانی مناسب است؟

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

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

اگر از حل مسئله لذت می‌برید

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

برای مثال، فرض کنید کاربران یک سیستم می‌گویند:

«لغو سفارش درست کار نمی‌کند.»

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

• مشکل دقیقاً در چه مرحله‌ای اتفاق می‌افتد؟
• چه نوع سفارش‌هایی تحت تأثیر هستند؟
• سفارش در چه وضعیتی قابل لغو است؟
• بعد از لغو چه اتفاقی برای پرداخت می‌افتد؟
• موجودی کالا چه تغییری می‌کند؟
• آیا سیستم‌های دیگری نیز باید به‌روزرسانی شوند؟
• چه پیامی باید به کاربر نمایش داده شود؟

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

اگر از پرسیدن سؤال‌های زیاد خسته نمی‌شوید

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

ممکن است یک Stakeholder بگوید:

«سیستم باید امکان گزارش‌گیری داشته باشد.»

اما همین جمله سؤال‌های زیادی ایجاد می‌کند:

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

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

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

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

برای مثال ممکن است درباره این موضوعات سؤال کند:

کاربر → رابط کاربری → API → سرویس → Database → سیستم دیگر

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

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

اگر از ارتباط میان افراد و فناوری لذت می‌برید

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

ممکن است در یک جلسه با کاربر یا نماینده کسب‌وکار درباره نیاز صحبت کند و در جلسه‌ای دیگر همان نیاز را با Developer یا Tester بررسی کند.

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

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

برای Developer:
«بعد از تغییر وضعیت سفارش به Cancelled، چه سرویس‌هایی باید فراخوانی شوند؟»

برای Tester:
«در صورت لغو سفارش بعد از پرداخت، انتظار داریم وضعیت پرداخت و موجودی چگونه تغییر کند؟»

مسئله یکی است، اما نحوه بیان آن برای هر مخاطب متفاوت است.

اگر با ابهام مشکل دارید اما از برطرف کردن آن لذت می‌برید

بخش زیادی از کار تحلیلگر تبدیل ابهام به وضوح است.

یک Requirement ممکن است در ابتدا چنین باشد:

«سیستم باید سریع باشد.»

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

یا ممکن است گفته شود:

«کاربر باید بتواند سفارش خود را لغو کند.»

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

تحلیلگر باید این ابهام‌ها را شناسایی کند تا Requirement به شکلی قابل فهم‌تر و قابل بررسی تبدیل شود.

اگر به مستندسازی علاقه دارید

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

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

این اطلاعات ممکن است در قالب‌هایی مانند:

• Requirement
• User Story
• Use Case
• Acceptance Criteria
• Process Flow
• UML Diagram
• Functional Specification
• مستندات تغییرات

ثبت شوند.

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

آیا افراد درون‌گرا هم می‌توانند تحلیلگر نرم‌افزار باشند؟

بله. تحلیلگر بودن الزاماً به معنای برون‌گرا بودن یا زیاد صحبت کردن نیست.

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

بنابراین فردی که آرام‌تر است اما می‌تواند مسئله را دقیق بررسی کند و ارتباط مؤثری با اعضای تیم داشته باشد، می‌تواند در این نقش فعالیت کند.

چه کسانی ممکن است از این شغل لذت نبرند؟

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

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

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

یک چک‌لیست ساده برای شناخت علاقه به این شغل

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

• آیا از پیدا کردن علت یک مشکل لذت می‌برید؟
• آیا معمولاً درباره «چرا» و «چطور» سؤال می‌پرسید؟
• آیا از تبدیل یک مسئله مبهم به مسئله‌ای مشخص لذت می‌برید؟
• آیا به نحوه کار سیستم‌ها علاقه دارید؟
• آیا می‌توانید موضوعی پیچیده را به زبان ساده توضیح دهید؟
• آیا از کار هم‌زمان با افراد فنی و غیرفنی استقبال می‌کنید؟
• آیا به جزئیات توجه دارید؟
• آیا مستندسازی و ساختار دادن به اطلاعات برایتان قابل تحمل یا حتی جذاب است؟
• آیا می‌توانید در مواجهه با Requirement ناقص، به‌جای حدس زدن سؤال مناسب بپرسید؟

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

جمع‌بندی

تحلیلگر نرم‌افزار (Software Analyst) یکی از نقش‌هایی است که در فاصله میان نیاز، مسئله و راهکار نرم‌افزاری قرار می‌گیرد. هدف اصلی این نقش فقط نوشتن مستندات یا انتقال درخواست‌های کاربران به تیم توسعه نیست؛ بلکه تحلیلگر باید تلاش کند مسئله را به‌درستی درک کند، نیازمندی‌ها را شفاف کند و رفتار مورد انتظار سیستم را به شکلی قابل استفاده برای تیم نرم‌افزار مشخص کند.

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

همچنین مشخص شد که مرز این نقش با نقش‌های دیگری مانند Business Analyst، System Analyst، Developer و Software Tester همیشه ثابت نیست. در بعضی سازمان‌ها این مسئولیت‌ها میان چند نقش تقسیم می‌شوند و در بعضی تیم‌ها ممکن است یک نفر بخشی از چند نقش را بر عهده داشته باشد. بنابراین هنگام بررسی یک موقعیت شغلی، شرح وظایف اهمیت بیشتری از عنوان شغلی دارد.

برای فعالیت به‌عنوان تحلیلگر نرم‌افزار نیز الزاماً به یک مدرک دانشگاهی مشخص یا توانایی برنامه‌نویسی در سطح یک Developer نیاز نیست. بااین‌حال، آشنایی با مفاهیم نرم‌افزار، Database، API، معماری سیستم، تست، Requirement Engineering و مدل‌سازی می‌تواند درک فرد از مسائل فنی را افزایش دهد.

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

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

بنابراین اگر بخواهیم در یک جمله بگوییم تحلیلگر نرم‌افزار چیست، می‌توان گفت:

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

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

تحصیلات و مدارک مورد نیاز برای تحلیلگر نرم‌افزار

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

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

چه رشته‌هایی برای تحلیلگر نرم‌افزار مناسب هستند؟

رشته‌های مرتبط با کامپیوتر و فناوری اطلاعات معمولاً ارتباط بیشتری با این شغل دارند؛ برای مثال:

• مهندسی کامپیوتر
• علوم کامپیوتر
• فناوری اطلاعات (IT)
• مهندسی نرم‌افزار
• سیستم‌های اطلاعاتی (Information Systems)

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

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

آیا مدرک دانشگاهی برای استخدام ضروری است؟

این موضوع به سازمان و آگهی شغلی بستگی دارد.

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

بنابراین نباید این دو گزاره را یکی دانست:

«مدرک مرتبط مفید است»
و
«بدون مدرک مرتبط نمی‌توان تحلیلگر نرم‌افزار شد»

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

آیا گواهینامه‌های حرفه‌ای لازم هستند؟

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

برای یک تحلیلگر نرم‌افزار، بسته به مسیر شغلی، آشنایی با حوزه‌هایی مانند موارد زیر می‌تواند مفید باشد:

• Requirements Engineering
• Business Analysis
• Software Development
• Software Testing
• Agile و Scrum
• Modeling و UML

برای مثال، گواهینامه‌های مرتبط با Business Analysis یا Agile ممکن است برای فردی که در این حوزه‌ها فعالیت می‌کند ارزشمند باشند؛ اما داشتن گواهینامه به‌تنهایی نشان نمی‌دهد که فرد می‌تواند یک سیستم واقعی را به‌درستی تحلیل کند.

برای ورود به این شغل، مدرک مهم‌تر است یا مهارت؟

بهتر است این موضوع را به‌صورت مدرک در برابر مهارت نگاه نکنیم.

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

برای مثال، تحلیلگری که بتواند:

• Requirementهای مبهم را شناسایی کند؛
• سؤال‌های مناسب از Stakeholder بپرسد؛
• فرایندهای سیستم را مدل کند؛
• نیازمندی‌ها را مستند کند؛
• با Developer و Tester ارتباط برقرار کند؛
• API و Database را در سطح مورد نیاز تحلیل کند؛
• و اثر یک تغییر را در سیستم بررسی کند؛

در عمل توانایی‌هایی دارد که صرف داشتن یک مدرک دانشگاهی آن‌ها را تضمین نمی‌کند.

اگر رشته دانشگاهی مرتبط نداشته باشیم چه؟

اگر رشته تحصیلی شما کامپیوتر یا IT نیست، می‌توانید مسیر یادگیری را به‌صورت مرحله‌ای طی کنید.

یک مسیر منطقی می‌تواند شامل این موارد باشد:

مبانی کامپیوتر و نرم‌افزار
↓
تحلیل نیازمندی و مستندسازی
↓
مدل‌سازی و UML
↓
مفاهیم Database و SQL
↓
API و مفاهیم ارتباط بین سیستم‌ها
↓
آشنایی با توسعه و تست نرم‌افزار
↓
تمرین تحلیل پروژه
↓
ساخت نمونه‌کار و کسب تجربه

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

جمع‌بندی

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

آنچه در بلندمدت اهمیت دارد، توانایی ترکیب چند نوع دانش است:

دانش کسب‌وکار + تحلیل نیازمندی + دانش فنی + مدل‌سازی + ارتباط مؤثر + تجربه پروژه

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

بازار کار و مسیر پیشرفت شغلی تحلیلگر نرم‌افزار

عنوان «تحلیلگر نرم‌افزار» در همه شرکت‌ها با یک شرح شغل یکسان استفاده نمی‌شود. ممکن است سازمانی فردی با این عنوان را استخدام کند و سازمان دیگری برای نقش مشابه از عنوان‌هایی مانند Software Analyst، Systems Analyst، Business Systems Analyst یا Applications Analyst استفاده کند.

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

تحلیلگر نرم‌افزار در چه شرکت‌هایی کار می‌کند؟

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

برای مثال:

• شرکت‌های تولیدکننده نرم‌افزار
• شرکت‌های تجارت الکترونیک
• بانک‌ها و شرکت‌های پرداخت
• شرکت‌های بیمه
• شرکت‌های حمل‌ونقل
• شرکت‌های ارائه‌دهنده خدمات آنلاین
• سازمان‌های بزرگ دارای سیستم‌های داخلی
• شرکت‌های فناوری و SaaS
• شرکت‌های مشاوره و پیاده‌سازی سیستم‌های سازمانی

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

عنوان‌های شغلی نزدیک به تحلیلگر نرم‌افزار

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

برخی از این عنوان‌ها عبارت‌اند از:

• Software Analyst
• Systems Analyst
• System Analyst
• Business Systems Analyst
• Application Analyst
• IT Analyst
• Programmer Analyst
• Software Business Analyst

البته مشابه بودن عنوان به معنای یکسان بودن شغل نیست. ممکن است یک شرکت از عنوان System Analyst برای نقشی استفاده کند که بخش زیادی از وظایف آن تحلیل نرم‌افزار است و شرکت دیگری همین عنوان را برای نقشی با مسئولیت‌های گسترده‌تر به کار ببرد.

بنابراین هنگام جست‌وجوی فرصت شغلی، بررسی Job Description اهمیت زیادی دارد.

مسیر رشد شغلی تحلیلگر نرم‌افزار چگونه است؟

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

یک مسیر احتمالی می‌تواند چنین باشد:

Junior Analyst
↓
Software Analyst / System Analyst
↓
Senior Analyst
↓
Lead Analyst / Analysis Lead
↓
Solution Architect، Product Management یا نقش‌های تخصصی و مدیریتی مرتبط

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

برای مثال، یک تحلیلگر ممکن است به سمت Business Analysis حرکت کند، فرد دیگری به سمت Product Management برود و فرد دیگری با تقویت دانش فنی خود به سمت System Analysis یا Solution Architecture حرکت کند.

چه چیزهایی باعث پیشرفت یک تحلیلگر می‌شود؟

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

برای مثال، یک تحلیلگر باتجربه‌تر ممکن است بتواند:

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

بنابراین رشد شغلی فقط به معنای گرفتن عنوان Senior نیست؛ بلکه معمولاً با افزایش دامنه مسئولیت و پیچیدگی مسائل نیز همراه است.

آیا تحلیلگر نرم‌افزار می‌تواند به برنامه‌نویسی یا معماری برود؟

بله.

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

برای مثال:

تحلیلگر → توسعه‌دهنده

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

تحلیلگر → تحلیلگر سیستم

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

تحلیلگر → Business Analyst

اگر تمرکز فرد بیشتر روی فرایندهای کسب‌وکار، Stakeholderها و نیازهای سازمانی باشد، مسیر Business Analysis می‌تواند گزینه‌ای مرتبط باشد.

تحلیلگر → Product Management

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

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

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

خیر.

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

برای مثال، یک شرکت بزرگ ممکن است سیستم‌هایی برای:

• فروش
• منابع انسانی
• مالی
• انبار
• ارتباط با مشتری
• مدیریت سفارش
• گزارش‌گیری

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

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

در بررسی یک موقعیت شغلی به چه چیزهایی توجه کنیم؟

اگر با عنوانی مانند Software Analyst یا System Analyst مواجه شدید، بهتر است این موارد را بررسی کنید:

1. مسئولیت اصلی نقش چیست؟
2. تمرکز روی Business Analysis است یا Software/System Analysis؟
3. آیا Requirement Engineering بخشی از وظایف است؟
4. میزان دانش فنی مورد انتظار چقدر است؟
5. آیا SQL، API یا UML مورد نیاز است؟
6. ارتباط با Developer و Tester چگونه تعریف شده است؟
7. آیا نقش در Agile/Scrum فعالیت می‌کند؟
8. آیا تجربه یک صنعت خاص لازم است؟
9. آیا مسئولیت مستندسازی و تحلیل تغییرات نیز بر عهده این نقش است؟

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

جمع‌بندی

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

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

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

تحلیلگر نرم‌افزار برای چه کسانی مناسب است؟

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

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

اگر از حل مسئله لذت می‌برید

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

برای مثال، فرض کنید کاربران یک سیستم می‌گویند:

«لغو سفارش درست کار نمی‌کند.»

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

• مشکل دقیقاً در چه مرحله‌ای اتفاق می‌افتد؟
• چه نوع سفارش‌هایی تحت تأثیر هستند؟
• سفارش در چه وضعیتی قابل لغو است؟
• بعد از لغو چه اتفاقی برای پرداخت می‌افتد؟
• موجودی کالا چه تغییری می‌کند؟
• آیا سیستم‌های دیگری نیز باید به‌روزرسانی شوند؟
• چه پیامی باید به کاربر نمایش داده شود؟

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

اگر از پرسیدن سؤال‌های زیاد خسته نمی‌شوید

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

ممکن است یک Stakeholder بگوید:

«سیستم باید امکان گزارش‌گیری داشته باشد.»

اما همین جمله سؤال‌های زیادی ایجاد می‌کند:

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

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

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

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

برای مثال ممکن است درباره این موضوعات سؤال کند:

کاربر → رابط کاربری → API → سرویس → Database → سیستم دیگر

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

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

اگر از ارتباط میان افراد و فناوری لذت می‌برید

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

ممکن است در یک جلسه با کاربر یا نماینده کسب‌وکار درباره نیاز صحبت کند و در جلسه‌ای دیگر همان نیاز را با Developer یا Tester بررسی کند.

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

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

برای Developer:
«بعد از تغییر وضعیت سفارش به Cancelled، چه سرویس‌هایی باید فراخوانی شوند؟»

برای Tester:
«در صورت لغو سفارش بعد از پرداخت، انتظار داریم وضعیت پرداخت و موجودی چگونه تغییر کند؟»

مسئله یکی است، اما نحوه بیان آن برای هر مخاطب متفاوت است.

اگر با ابهام مشکل دارید اما از برطرف کردن آن لذت می‌برید

بخش زیادی از کار تحلیلگر تبدیل ابهام به وضوح است.

یک Requirement ممکن است در ابتدا چنین باشد:

«سیستم باید سریع باشد.»

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

یا ممکن است گفته شود:

«کاربر باید بتواند سفارش خود را لغو کند.»

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

تحلیلگر باید این ابهام‌ها را شناسایی کند تا Requirement به شکلی قابل فهم‌تر و قابل بررسی تبدیل شود.

اگر به مستندسازی علاقه دارید

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

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

این اطلاعات ممکن است در قالب‌هایی مانند:

• Requirement
• User Story
• Use Case
• Acceptance Criteria
• Process Flow
• UML Diagram
• Functional Specification
• مستندات تغییرات

ثبت شوند.

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

آیا افراد درون‌گرا هم می‌توانند تحلیلگر نرم‌افزار باشند؟

بله. تحلیلگر بودن الزاماً به معنای برون‌گرا بودن یا زیاد صحبت کردن نیست.

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

بنابراین فردی که آرام‌تر است اما می‌تواند مسئله را دقیق بررسی کند و ارتباط مؤثری با اعضای تیم داشته باشد، می‌تواند در این نقش فعالیت کند.

چه کسانی ممکن است از این شغل لذت نبرند؟

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

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

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

یک چک‌لیست ساده برای شناخت علاقه به این شغل

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

• آیا از پیدا کردن علت یک مشکل لذت می‌برید؟
• آیا معمولاً درباره «چرا» و «چطور» سؤال می‌پرسید؟
• آیا از تبدیل یک مسئله مبهم به مسئله‌ای مشخص لذت می‌برید؟
• آیا به نحوه کار سیستم‌ها علاقه دارید؟
• آیا می‌توانید موضوعی پیچیده را به زبان ساده توضیح دهید؟
• آیا از کار هم‌زمان با افراد فنی و غیرفنی استقبال می‌کنید؟
• آیا به جزئیات توجه دارید؟
• آیا مستندسازی و ساختار دادن به اطلاعات برایتان قابل تحمل یا حتی جذاب است؟
• آیا می‌توانید در مواجهه با Requirement ناقص، به‌جای حدس زدن سؤال مناسب بپرسید؟

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

جمع‌بندی

تحلیلگر نرم‌افزار (Software Analyst) یکی از نقش‌هایی است که در فاصله میان نیاز، مسئله و راهکار نرم‌افزاری قرار می‌گیرد. هدف اصلی این نقش فقط نوشتن مستندات یا انتقال درخواست‌های کاربران به تیم توسعه نیست؛ بلکه تحلیلگر باید تلاش کند مسئله را به‌درستی درک کند، نیازمندی‌ها را شفاف کند و رفتار مورد انتظار سیستم را به شکلی قابل استفاده برای تیم نرم‌افزار مشخص کند.

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

همچنین مشخص شد که مرز این نقش با نقش‌های دیگری مانند Business Analyst، System Analyst، Developer و Software Tester همیشه ثابت نیست. در بعضی سازمان‌ها این مسئولیت‌ها میان چند نقش تقسیم می‌شوند و در بعضی تیم‌ها ممکن است یک نفر بخشی از چند نقش را بر عهده داشته باشد. بنابراین هنگام بررسی یک موقعیت شغلی، شرح وظایف اهمیت بیشتری از عنوان شغلی دارد.

برای فعالیت به‌عنوان تحلیلگر نرم‌افزار نیز الزاماً به یک مدرک دانشگاهی مشخص یا توانایی برنامه‌نویسی در سطح یک Developer نیاز نیست. بااین‌حال، آشنایی با مفاهیم نرم‌افزار، Database، API، معماری سیستم، تست، Requirement Engineering و مدل‌سازی می‌تواند درک فرد از مسائل فنی را افزایش دهد.

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

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

بنابراین اگر بخواهیم در یک جمله بگوییم تحلیلگر نرم‌افزار چیست، می‌توان گفت:

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

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

منابع

• IIBA – BABOK® Guide
• Object Management Group – Unified Modeling Language (UML)
• ISO/IEC/IEEE 29148 – Requirements Engineering
• ISTQB – Certified Tester Foundation Level
• The Scrum Guide
• IBM – Systems Analysis