The Community Blog for Business Analysts

Seilevel
Seilevel

The Role of the Requirements Analyst in Driving Specialized Development Teams to Success

I am working on a project where Development teams are divided into specialized areas called Centers of Competence. For example, one team works on Customer data, another team on Product data and validation, another works with the Shopping Cart, another with Checkout and so on. Requirements are gathered within each of these Centers of Competence and handed off to Development for implementation.

The above approach works very well for modular functionality that is specific to a Center of Competence. For example, features specific to Customer Create are usually handled within the Customer Center of Competence and do not impact any of the other teams. But when Customer data flows from one team to another to be used further downstream for pricing, taxation, product segmentation and so on, the modular structure of requirements definition and development breaks down.

This is where the Requirements Analyst plays a crucial role in ensuring that proper functionality is developed. The key techniques we have used to ensure requirements flow across the modular functionality boundaries are as below.

1. Identify all development teams impacted by a requirement or feature request. For example, some specific Customer data may need to be captured to ensure proper pricing and taxation. These requirements will likely originate within those specific Centers of Competence, but will be developed by a different team. So, the analyst creating the requirements will clearly identify the impacted teams other than just his or her own Center of Competence.
2. Communicate clearly to impacted development teams the functionality they need to develop to support requirements in a specific Center of Competence.
3. Get estimates of time to develop, test and deploy from the other impacted teams. This is tracked as a separate task that must be completed prior to requirements being signed off for a release.
4. Conduct cross functional development and requirements meetings so that all impacted teams clearly understand the functionality that needs to be developed.
5. Define clearly the interfaces through which data and messages flow from one sub-system to another. Document any specific data requirements necessitated to support these interfaces.
6. Ensure that the test teams understand the implications for both unit testing and feature testing. There are typically two test teams to deal with. One test team works with a Center of Competence and the other is the global team that deals with the entire application.

All of the above tasks are managed, facilitated and executed by the Requirements Analyst. A good grasp of the overall application, a thorough understanding of data flow, an excellent working relationship with different teams and top notch facilitation skills are keys to success.
Good Requirements professionals managing both their individual areas and coordinating across boundaries are key to the success of the Center of Competence method of dividing and managing Development teams.

This entry was published on Feb 27, 2011 / Seilevel. Posted in Business Analysis Planning (BABOK KA), Business Analysis, Analytical and Problem Solving Skills, Career as a Business Systems Analyst. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  4 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC