مدتی است که می خواهم کتابی را ، از کتاب هایی که از آلمان و سوئد و کانادا تهیه کرده بودم ، برای ترجمه انتخاب کنم.

دو کتاب را برای ترجمه  انتخاب کرده بودم. کتاب Code Complete و کتاب Software Requirements. 

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

اما دلیل اصلی من برای ترجمه این کتاب،  تجربه کاری 20 ماهِ من برای SIEMENS آلمان بود. یکی از منابع اصلی کاری من این کتاب بود و به دلیل تخصص کاری من که در اکثر اوقات با این کتاب سر و کار داشته ام ، این کتاب را برای ترجمه مناسب تر دانستم.

کتاب Software Requirements ویرایش سوم، نوشته karlwiegers(+) و Joy Beatty(+)  است که در آن به بررسی نیازمندی های نرم افزار پرداخته می شود.

طبق گفته خود نویسندگان  از ده سال پیش که زمان انتشار ویرایش قبلی همین کتاب بوده تا زمان انتشار ویرایش سوم این کتاب (سال 2013) نیازمندی های نرم افزاری چندان تغییر نکرده است یا حداکثر تغییرات جزئی داشته است که موجب شده این کتاب به ویرایش سوم برسد. 

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

Despite decades of industry experience, many software organizations struggle to understand, document, and manage their product requirements. Inadequate user input, incomplete requirements, changing requirements, and misunderstood business objectives are major reasons why so many information technology projects are less than fully successful. Some software teams aren’t proficient at eliciting requirements from customers and other sources. Customers often don’t have the time or patience to participate in requirements activities. In many cases, project participants don’t even agree on what a “requirement” is. As one writer observed, “Engineers would rather decipher the words to the Kingsmen’s 1963 classic party song ‘Louie Louie’ than decipher customer requirements” (Peterson 2002).

The second edition of Software Requirements was published 10 years prior to this one. Ten years is a long time in the technology world. Many things have changed in that time, but others have not. Major requirements trends in the past decade include:

  • The recognition of business analysis as a professional discipline and the rise of professional certifications and organizations, such as the International Institute of Business Analysis and the International Requirements Engineering Board.
  • The maturing of tools both for managing requirements in a database and for assisting with requirements development activities such as prototyping, modeling, and simulation.
  • The increased use of agile development methods and the evolution of techniques for handling requirements on agile projects.

  • The increased use of visual models to represent requirements knowledge.

So, what hasn’t changed? Two factors contribute to keeping this topic important and relevant. First, many undergraduate curricula in software engineering and computer science continue to underemphasize the importance of requirements engineering (which encompasses both requirements development and requirements management). And second, those of us in the software domain tend to be enamored with technical and process solutions to our challenges. We sometimes fail to appreciate that requirements elicitation—and much of software and systems project work in general—is primarily a human interaction challenge. No magical new techniques have come along to automate that, although various tools are available to help geographically separated people collaborate effectively.

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

موضوعات کتاب فقط برای نرم افزار نیست بلکه تحلیل گران شغل یا Business Analystها می توانند به نحو احسنت از مطالب این کتاب بهره ببرند. هرچند توجهات کمی به این زمینه در Businessها می شود. 

اما همین توجه نکردن هاست که موجب مشکلات بزرگی در آینده Businessها می شود.

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

1) چون بعد از صرف مدت زمانی طولانی ( حدود 15 ماه) کسی را پیدا نکردم که در این زمینه دانش خوبی داشته باشد یا حداقل اکثر مطالب این کتاب را به کار گرفته باشد. 

2) در صورت امکان ترجمه گروهی ، زمان جمع بندی و ایراد گرفتن و یک دست کردن منبع را نخواهم داشت و قطعا این کار را انجام نخواهم داد. چون نمی خواهم یکپارچگی متن را از دست بدهم. 

بعد از کمی جستجو متوجه شدم که کتاب هم ترجمه شده است اما ناقص. نمی دانم چطوری کسی به خودش اجازه می دهد که  کتابی را که  640 صفحه و 32 فصل دارد را  به کتابی با  17 فصل و 424 صفحه تبدیل کند. برای مشاهده کتاب ترجمه شده می توانید این دو لینک  (1) و (2) را مشاهده کنید.

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

کتاب هایی که در ایران ترجمه می شود اکثراً همان نسخه های کتاب های دزدی به شکل PDF  هستند.

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

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