این مطلب رو میشه به عنوان یک مقدمه ای بر نیاز سنجی نرم افزار یا Software Requirements در نظر گرفت.
در مطلبی تحت عنوان مهندسی نیاز ها(+) ، یک کتاب رو برای این کار معرفی کردم. اکثر گرفتاری ها و مشکلات نرم افزاری از Requirementها منشاء میگیره.
توی این مقاله(+) هم به طور کلی شرح دادم که چه مشکلاتی کجا و چطور ، توسط نادیده گرفتن نیازسنجی ها بروز می کنند.
مطالب این قسمت خیلی خیلی زیاده و مشکلات اون هم به دسته ها و گروه های مختلفی ربط و وابستگی داره. به همین خاطر هم توی نقشه راه وبلاگ برای این قسمت یک فصل جداگانه قرار داده ام.
خب بریم سر اصل مطلب .
مهندس نرم افزار در همون اول کار باید نیازسنجی بلد باشه. البته این نظر شخصی منه و خیلی از افراد موفق توی بازار کار نرم افزار ایران دارن کار میکنند و نیاز سنجی بلد نیستند. اما در جاهایی باید تاوان این ندانم کاری رو پس بدن. که خیلی خیلی سنگینه و بعضی اوقات کمر شکن.
خب برای شروع از این کتاب شروع می کنم. کتاب (+)software Requirements ویرایش سوم ، انتشارات مایکروسافت. نوشته کارل ویگرز و جوی بیتی.
When a group of people begin discussing requirements, they often start with a terminology problem. Different observers might describe a single statement as being a user requirement, software requirement, business requirement, functional requirement, system requirement, product requirement, project requirement, user story, feature, or constraint. The names they use for various requirements deliverables also vary. A customer’s definition of requirements might sound like a high-level product concept to the developer. The developer’s notion of requirements might sound like a detailed user interface design to the user. This diversity of understanding leads to confusion and frustration.
یکی از مشکلات نیاز سنجی اینه که هر کسی یه قسمتی از سیستم رو بلده و همون کار خودش رو از همه مهمتر میدونه.
بدبخت مهندس نرم افزاره وقتی که می خواد با این افراد سر و کله بزنه. نگران نباشید. نحوه برخورد با این افراد و حل مشکل اونها توی فصل مربوطه به طور کامل شرح و بسط داده میشه.
خب با این همه تفاسیر و مشکلات پس نیاز سنجی نرم افزار چی میشه.
بهترین تعریفی که من می تونم برای این کار در نظر بگیرم ، این که اون فردی که مسئول نیاز سنجی نرم افزاره ، باید مثل یک متخصص سیستم باشه. البته سیستمی که برای اون قراره یک نرم افزار طراحی بشه و کارهاش روال سیستمی بگیره و کامپیوتری بشه و از سیستم منوال یا دستی و کاغد بازی خارج بشه.
البته این حالت ، حالته ایده آل است. یعنی اگر کسی بتونه روال های یک اداره یا سازمان یا شرکت رو به طور کل سیستمی کنه ، کارش رو درست و حسابی و تمام کمال انجام داده.
اما از اونجایی که سیستم ها بزرگ و بی نهایت پیچیده هستند ، این کار در مواقع نادری به وقوع می پیوندد .
برای رفع این مشکل سیستم ها خرد میشوند. مثل بخش مدیریت که یکی از سخت ترین بخش های هر سازمانی است. (برای طراحی نرم افزار و نیازسنجی
برای شروع نیاز سنجی ها باید با نحوه کار سازمان آشنا بشید.
برای مثال در همون ابتدا نیاز سنجی ، خودتون رو یک مشتری در نظر بگیرد و به کارمند رجوع کنید و اون کاری رو که ازش می خواید انجام بده رو تحلیل کنید.
فرضاً من به یک اداره و به یک کارمند خاص ، برای انجام کاری رجوع میکنم. در این مرحله باید در نظر داشته باشم که مدارک لازم برای انجام کار من چیه ؟
و از طرف دیگه باید خودم رو به جای کارمند در نظر بگیرم که اگر ارباب رجوعی به من مراجعه کرد ، اونهم برای اولین بار، باید چه چیزهایی رو به او متذکر بشم؟
باید چه مدارکی رو همراه خودش داشته باشه ؟
اگر مدارکش کامل بود ، اون وقت کار من چیه ؟
اگر کارش کامل شد و احتیاج رجوع به بخش دیگر یا کارمند دیگری رو داشت ، باید به کدوم بخش رجوع بدم ؟
اصلا طبق چه معیار هایی من باید به یک بخش یا کارمند خاص، ارباب رجوع رو معرفی کنم ؟
در این معرفی آیا احتیاج به منابع یا مدارک دیگری هست ؟ اگر هست این مدارک و منابع چیست ؟
در پایان اگر کار این ارباب رجوع تمام شد ، کار من چیست ؟
آیا باید روی مسئله ارباب رجوع کار کنم یا ارباب رجوع دیگری را بررسی کنم ؟
به این دسته مسائل نیاز سنجی نرم افزار گفته میشه. طبق تعریفی که از کتاب آوردم ، نیاز سنجی ها دیدگاه ها و پرسپکتیوها و دسته هایِ خاص خودش رو داره که در فصل مربوط به خودش شرح داده میشه .
ادامه دارد ...
