From User Guides to BRDs: Technical Writers as Business Analysts

By Dishaa Ganapathy

Section 1.0 Introduction

As a technical writer, do you at times feel discontented with your current involvement in projects? Typically, all the crucial work has been debated, designed, and developed? You are assigned to create a user guide and your SMEs are too busy to make time for face-to-face interviews? Do you wish to be at the forefront of design and product decisions and like to have a client-facing role? Do you feel that the current job market, growing scarier by the month, is friendlier toward people who can handle multiple roles? If you have nodded faintly or vigorously to these questions, thinking about working as Business Analyst may be an idea worth considering.

A Business Analyst (BA) gets involved in the requirements analysis phase of the SDLC and usually stays involved throughout a project’s lifecycle. BAs typically author Business Requirement Documents (BRDs), have client-facing roles, and work closely with the Project Manager during the course of the project. With enough experience, a BA can advance from a junior to a senior-level depending on the organization and even transition to the role of a project manager.

This short article aims to provide an overview of the similarities and differences between the two roles. Such a review may help technical writers realize skills that he/she already posses and help them focus on acquiring new ones. The article also cites some basic resources for a newbie business analyst.

Section 2.0 Commonalities

In the IT realm, professionals from either technical writing or business analysis share the following aspects:

• Working knowledge of products and services
• Gathering information
• Organizing information and presenting
• Analyzing information
• Understanding the end user
• Ability to work with standard publishing tools

Let us delve a little deeper and discuss the manner in which these aspects are similar for both the roles.

2.1 Domain Knowledge – Products and Services

Being the authors of requirement of the designed system, business analysts too have an excellent understanding of the product. To produce quality documentation, a technical writer must have a good understanding of the application/technology that must be authored. Though business analysts often provide initial inputs to technical writers, technical writers frequently offer system feedback from an end-user perspective to business analysts. Though the entry into the product or service cycle varies, both roles end up gaining a wide range of understanding of the engineered product or service. The key ingredient of success for both the roles is the desire to work with technology and understand how the features and functionality of a system meets end-user needs.

2.2 Gathering Information

Both roles require individuals to interact with cross-functional units to get the necessary information – many times with dogged persistence. A technical writer works with developers, testers, business analysts, and support teams to author end-user documentation. A business analyst must interact with the business stakeholders, end-users, developers, system architects, testers, and technical writers to facilitate, document, and coordinate the delivery of a business solution. The skill to not only ask the right questions but to ask them in the right manner is crucial to both roles. In addition to communication skills, both roles require listening and comprehension skills, a good understanding of technology, an interest to always keep the end-user in mind, and a keen sense of attention to detail.

2.3 Organizing Information and Presenting

In a sense, writing is the most absorbing and gratifying aspect of work for both the roles. Typically, a technical writer creates end-user documentation in a way that helps the audience perform tasks. The business analyst, on the other hand, writes requirements for a specific audience in a way that helps them understand and agree upon system and business requirements to arrive at a viable solution. Therefore, presenting information in a logical manner with clarity, accuracy, and precision are essential for both roles. To this end, a well thought of table of contents, figures, illustrations, and screen shots, in addition to text, go a long way in creating complete and solid documentation.

2.4 Analytical Skills

Analysis is the backbone of writing. Gathering information, interviewing stakeholders, reading project artifacts is ineffective without sound analytical skills to analyze gathered information and process it to meet a certain goal. For both technical writers and business analysts, analysis provides the opportunity to reach out and find information to fill gaps – many times potentially vital gaps in information. For instance, if a target system has decided to use a database that contains only domestic business entities, but the business requires an integration of its overall operations, then the business analyst must confirm if “overall operations” includes only domestic or international as well. If it includes the latter, then to size up the effort and resources required to update the database must be considered.  If a system generates reports, the technical writer may need to analyze different reports the system generates, the output format and so on. If the system generates only a PDF output, it maybe good to let the user know that his or her system must have a PDF viewer to view successfully view reports.

2.5 Understanding the End-user

Both roles require individuals to sit down with end-users and elicit requirements. This means understanding the end-user, finding out their concerns and issues, and delivering a product that addresses those concerns and issues. This may include addressing user interface design issues, prototyping, and getting involved in usability testing.

2.6 Standard Tools for the Job

Both technical writing and business analysis offer its professionals specialized tools that enable them to handle their tasks with efficiency. Microsoft Office, however, is still the most widely tool in many organizations. While Microsoft Word is used primarily for authoring, Microsoft Excel is typically used to track feature lists, requirements and so on.

Section 3.0 Points of Departure

Looking at the commonalities, some might not consider technical writing very different from business analysis. As real and valid the commonalities, there are indeed nuances in the above aspects that emerge as crucial differences between the two roles. To help the reader understand the difference, the analogy of a blind person versus a person with vision drawing an elephant may be useful.

Generally, a technical writer is brought into a project after the requirements are agreed upon. The system design and development are complete and the testing phase is in process. The system is in front of the person ready to be tried, tested, and documented.

A business analyst is presented with a radically different environment. When the business analyst starts a project, the target or intended system/solution is not present (especially if it is a new system). The only thing that exists is an idea or business need from which a suitable system or solution must be built that meets the business need. Much like the blind man drawing an elephant by touching and feeling the body of an elephant, a business analyst has to gather, elicit, and probe for information from different sources to produce a document that transforms business need to a well-defined requirement specification.

Highlighting commonalities and pointing out differences proves to be a good exercise in not only helping technical writers feel confident about making the shift, but also helps them navigate through the sift in role in an equally confident manner.

3.1 Domain Knowledge

Though domain knowledge is good-to-have for a technical writer, it is quintessential for a business analyst. Domain knowledge—or the lack of it—can be a critical factor in determining if requirements are complete and if the solution is delivered in the approved time frame. Let us consider an example where a bank is interested to implement KYC (Know Your Customer) policy when opening customer accounts online. As a business analyst it is hugely beneficial to understand the controls and guidelines stipulated under KYC to ensure such controls and business requirements are effectively detailed in the requirements document. To this end, a business analyst is vastly benefited by prior knowledge of systems and process. Having precedence or prior domain experience equips the business analyst to ask the right questions and cull out not-so apparent requirements.

On the other hand, once the target system is built, a technical writer may be able to easily document the review and approval process by familiarizing with the functionality and reading business and system requirement documents.

3.2 Gathering Information

The method of gathering information varies greatly as well. As a technical writer, boundaries for gathering information are defined, since the system/solution is already built. But as a business analyst, effectively moderating requirements elicitation sessions is paramount from the perspective of time management. Many times, business owners are not entirely sure what they need. For example, an open-ended question, such as “what information do you want to include under Personal Information section?” could result in hours of discussion. Thus it is imperative to ask the right questions and in the right manner. During tight deadlines, the KISS (Keep It Simple Stupid) guideline works well.

3.4 Writing Style

The method of writing varies as well. In technical writing, words such as “will” and “shall” are hardly ever used. Business analysts, who provide guidelines to testers and developers for building a solution, often use words such as “will”, “must”, and “shall.” For example, “the system must be able to send email notifications to registered users.”

3.5 Advanced Tools

While larger companies have technical writing teams use FrameMaker and RoboHelp, business analysts have at their disposal tools like Rational Requisite Pro and MS Visio to define, model, and track requirements.

Section 4.0 Getting into Business Analysis

A BA role can be a rewarding experience, however, if one has the right expectations about the role in a given organization. In some cases, the transition may not be easy and several criteria may need to be met. These include available opportunities, necessary skills, encouraging mentors, and above all the person’s passion and interest. Moreover, it may not be necessary to make a complete shift to business analysis. A person who has moved into business analysis can continue working on technical writing tasks, thus doing a bit of both.

Further Information

Websites:

1. IIBA: International Institute of Business Analysis (IIBA®) is an independent non-profit professional association serving the growing field of Business Analysis.

Website: http://www.theiiba.org/AM/Template.cfm?Sect=Home

IIBA has created the Certified Business Analysis Professional™ (CBAP®) for Business Analysts. Website: http://www.theiiba.org/AM/Templatecfm?Section=Certification.

2. Modern Analyst: A great community for business and systems analysts. Has a good collection of articles, news, and features to help practitioners participate in and contribute to the business analysis community. Website: http://www.modernanalyst.com/

Books:

1. More About Software Requirements: Thorny Issues and Practical Advice

Karl E. Wiegers

1. The Business Analyst’s Handbook

Howard Podeswa

1. Seven Steps to Mastering Business Analysis

Barbara A. Carkenord.

2. Writing Effective Use Cases (Agile Software Development Series)

Alistair Cockburn

3.Getting It Right: Business Requirement Analysis Tools and Techniques

Kathleen B. Hass, Don Wessels, and Kevin Brennan.

About the Article

A variation of this article first appeared in the STC NYC Metro Chapter Newsletter Volume 3, Issue 3, May/June 2009.

About the Author:

Dishaa Ganapathy has over ten years of experience in the IT realm. Her professional interests include, but are not limited to, technical communication, business analysis, product design, ethnography, and information architecture. In addition to loving time spent with family indoors watching old classic movies and cooking, Dishaa is an avid outdoor enthusiast interested in hiking, canoeing, rafting, and rock climbing.