Bridging The Gap: Best Practices In Translation For Business Analysts

Requirements analysts often play the role of translator. They listen to, understand, and document the needs of system users in the users’ natural language and they present the users’ needs to system designers and developers in a more formalized ‘language’ made up of models and other artifacts. It is critically important to project success for the analyst to communicate effectively with both audiences.

Most analysts do this without really thinking much about it or examining the process and the best analysts do it quite well. But translation is actually a complex undertaking and it’s worth spending some time on it to understand what is really going on and exploring for ways to improve the process and the results.

Know The Requirements Process

The simple description of the translation process involves just two steps: Decoding the source content and re-encoding the meaning of the content in the target language. A more in-depth look at these two steps reveals some significant complexity. Translating from one ‘natural’ or spoken language to another requires that the translator understand the syntax, grammar, and nuances of both the source and target language. This is a much more involved process than simply taking one word at a time from the source and finding the equivalent word in the target.

For requirements analysts the task has a further challenge in that the target must be precise and rigorous while the source will usually contain vague and indistinct literary constructs that are normal in the everyday use of a spoken or written natural language.

Know The Language Of Your Target Audience

I could not find any research on translation specific to the work of requirements analysts, but there is a fair amount of evidence that deep knowledge of the target language is more important for a translator’s success than expert level fluency in the source language. The research suggests that while perhaps coding experience is not necessary, it is important for RAs to have extensive knowledge of the models used in requirements specification and this knowledge should be from the perspective of the consumers of the specification, designers, developers, testers, etc.

Research and best practices from the translation business also suggest that the draft translation should be reviewed by a second translator with deep knowledge of the source language.

Many software requirements analysts do have a background in software design and development but many come from other disciplines as well.

The ideal situation may be for the requirements specification to be first drafted by an analyst with deep knowledge and background in software design and development and then reviewed by an analyst with deep knowledge and background in the business. Not every project team will have access to the ideal mix of analysts but if your project does it may be worth a try.