I would like to get some feedback from this forum regarding requirement writing for multiple applications.
Currently, our environment has a BA (or in some cases, multiple BAs) assigned to a core application focus. In the duration of a single project, we may have one BA writing web requirements, another BA writing product requirements, and yet another BA writing requirements for our legacy system or database changes. We are considering a change to this workflow. We want to assign one BA to a project, and ask them to write the requirements for all of the impacted systems and web sites.
Do you feel this is a good idea? Should the BA be focused on just one application, or should the BA be involved in requirement writing across multiple applications (i.e. web, legacy systems, database, case management tools, etc.)? Do you have any experience writing requirements across multiple applications? Any feedback or suggestions regarding this change in workflow/process?
Hi:
Typically, the interfaces between applications are especially thorny requirements spec problems. If you are strong in functional modeling, i would say go after them. If you are weak in that area, do what is typically done: find some way to pawn off the responsibility to someone further down the line, like QA or even Tech Writing.
Tony
"should the BA be involved in requirement writing across multiple applications?"
Yes. In fact, the BA should not even be that concerned about which application or platform will eventually support the requirements. They should get the requirements, and then decisions can be made as to which app will be enhanced to meet them.
Of course, with a set of apps in place, it can usually be seen up front which app is most likely to be support a particular requirement, but if you then organize your requirements work around each app, you can miss new requirements that need a new app, and requirements that fall between two apps could go unrecognized.The best requirements work is application-agnostic. Get the requirements, then think about how they will be implemented.
Too many BA's are heavily grounded in solution delivery mechanisms. The reason for such is largely a desire to seek safety: being grounded in the implementation details is alot safer that venturing out onto the slipperly slope of higher levels of abstraction.
So, yes, in the ideal, you should seek to be an integrator across applications. As others have pointed, out, that is what being a "real" BA is all about. But, be aware, if you do not have strong management support, if you do such, you may be putting your job at more risk than you want.
There is an alternate model to the traditional one that Tony and David recommend here, which is particularly pertinent when dealing with an existing suite of systems.
Create a layered approach to BAs on a team. The top layer is addressing the business problem, as described in the project charter/mission statement/initiation docs, and a second tier of system SMEs who understand the capabilities within these systems.
This model means that analysts are taking a decisive step in design - maybe augmented by an architect or other design expert. This is not the common wisdon in the BA community, which says be soluton agnostic, but it has strengths in that it recognises people have more knowledge in their heads that that defined by their job description, and deals with the issues of partitioning system of system capability early.
brought to you by enabling practitioners & organizations to achieve their goals using: