Have you ever hired a Business Analyst and expected them to write good quality solution requirements? Or perhaps hired a Functional Analyst and expected them to write good quality business and/or stakeholder requirements?
Perhaps, generally speaking, ever wondered what is the difference between many analyst roles that you have probably heard about but don't know what they do? How they differ? What value they bring to an organisation or to your project? What are the overlapping responsibilities and what are the differentiating factors that make these roles - unique?
Worry not. We have attempted to answer above questions in a simplified view.
There are many analyst roles across industries and identifying (or even hiring) the correct person for the job can be difficult.
Just within the context of software development, there is long list of analyst roles and understanding the difference between roles is crucial.
Each role brings a unique skill-set with them and provide value to the organisation. I have attempted to provide a simple distinction between some of the most common roles in software development that can be confused with the 'Business Analyst' role solely:
Business Analyst
Functional Analyst
Systems Analyst
Technical Writer
Please note:
Roles and responsibilities listed below is not an exhaustive view.
One or more responsibilities listed can overlap with one or more roles depending on the context.
Understanding the context is very important to identify under what conditions will these roles and responsibilities be performed.
A responsibility under a specific role can mean different for another role depending on the context. Without deep understanding of the context roles may/may not perform as per quality standards. E.g. 'requirement elicitation' is a trait of many of these roles. However, a Business Analyst may conduct workshops to elicit 'business and/or stakeholder requirements' whereas a Functional Analyst may conduct workshops to elicit more detailed functional requirements that map to stakeholder requirements. and achieves objectives from a product development perspective.
There are some commonalities and unique aspects that only a specific role brings. For example, a business analyst has a business focus whereas a functional analyst has a focus on system. However, both business and functional analyst may facilitate requirement workshops.
depending on size of the project and skill-set needed, all roles may/may not be hired as one person performing a role may be expected to wear multiple hats. For example, a business analyst who has working-knowledge of a functional analyst may be expected to fulfill two roles and vice-versa.
lastly, this is a high-level general view that provides distinction between these roles.
Frequently asked questions
Q: So how do people gain experience in more than one of these roles?
A: Good experience is gained by working on different projects e.g. by working on strictly business projects you may acquire solid understanding and knowledge about Business and Stakeholder requirements.
By working on pure software development projects you may experience writing good quality solution requirements that encapsulates defining Functional and Non-Functional requirements. Additionally, obtaining understanding about how good solution requirements are useful to the development team and how they trace back to stakeholder requirements will only add value to both the business and the product being developed.
Q: I work as one of the analyst roles mentioned in this post must I know more than one of the roles above?
A: There is no right and wrong answer to this. All analyst roles mentioned are in-demand, important, unique in nature, and knowing ins and outs of your role is crucial. Ultimately, it boils down to your personal choice and your comfort level. Every project is different and unique in nature. Therefore, projects will always require specific skill-sets.
Did the above clarify any of your doubts? Or do you have any questions related to the post?
Do you believe you can add value to this post?
Feel free to leave a comment and we will attempt to answer them.