Hey Business Analyst, where are the requirements

Ever since the role of Business Analyst came into being, they have been associated with one specific area more than anything else. That is requirements and over the last four decades or so, the words analysts and analysis  have become synonymous with requirements.  In a traditional project or product development context,one of the frequently asked questions for a Business Analyst undoubtedly  is “Where are the requirements?”. However, in the recent times of agile methodologies and lean processes, like all other roles in technology and business, BAs too have had a significant makeover. In this post, I will touch upon this transition and look at the all powerful tool kit of the new age business analysts.

Business Analyst as the owner of requirements 

BAs traditionally had been responsible primarily for requirements in a product development or project execution scenario. Even though the role of business analyst involves right from the pre-sales stage all the way through to the project delivery, their focus area had always been scoping and requirements areas. BAs traditionally had their mainstay contribution to the product/project starting with requirements gathering, and then specifying and documenting requirements and communicating them to the stakeholders ranging from the management to the team members and from customers to the end-users.

Not just requirements in terms of the functionality, the influence and focus areas of the analyst could well be extended to some of the adjacent areas. Besides requirements, the reach of the BA would still be restricted to the peripheral aspects such as vision, scope and roadmap for the product, system, process or business in question. BAs have been made the masters and owners of requirements. This has been the case with the various roles, forms and names of the business analyst – be it a business consultant, product specialist, functional consultant or a domain expert.

Traditional meaning and scope of requirements

 So, what exactly do I mean by requirements in the traditional sense of the business analyst’s focus? Let me clarify this very important point with some examples. Requirements traditionally meant the long list of documents that ran into hundreds and thousands of pages. Some were called as Business Requirements Documents (BRD) while some others were referred to in the eighties and nineties as System Requirements Specifications (SRS) during the time of SSAD (Structured Systems Analysis and Design) times. As we moved slowly into the software analysis and development, the focus of the BAs slowly shifted into writing Functional Requirements Specification (FRS) and Software Requirements Specification (SRS) documents. You can notice that its just a change of the name, however the perspective, work and the output of the analysts still remained the same.

New age BA goes beyond documentation

In the age and times that we now live in, virtually everyone and everything  is going digital, mobile, agile and social. Like all other professions and roles which have undergone a huge shift, BAs too have had a significant change, after a really long time. The actual transformation in the role, responsibilities and contribution of the analysts came with the introduction of agile development methodologies like SCRUM, BDD (Behaviour Driven Development) and User Stories.  As we started implementing more and more agile and lean methodologies in the businesses, products and projects, the role of the business analysts has a far reaching impact on how the end products or processes shape up.

Today’s analysts need to move beyond the realms of requirements area and become more versatile and tech-savvy. All the way from interactions with key stakeholders through to the time the product or process has been delivered, the new age BA has to actually work with the team members. Analysts have to actively engage with various people involved in the project, product, process or business context and work alongside them analyse, design, develop, deliver and continually enhance the solution. This means that the analysts have to now create various artefacts such as the product backlog, user stories, wireframes, domain models, solutions models, prototypes and test cases, to name a few. I will discuss the details  of how the new age business analyst creates and works with these more effectively, in a separate post.

Hope you found the post useful – like always, please feel free to drop in with your valuable feedback. Until next post, ciao!