Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Project Requirements for Multiple Applications
Previous Previous
 
Next Next
New Post 10/13/2009 3:46 PM
User is offline designdiva76
2 posts
No Ranking


Project Requirements for Multiple Applications 

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?

 
New Post 10/13/2009 5:16 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Project Requirements for Multiple Applications 

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

 
New Post 10/14/2009 9:34 AM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Project Requirements for Multiple Applications 

"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.


David Wright
 
New Post 10/14/2009 10:23 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Project Requirements for Multiple Applications 

Hi:

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.

Tony

 
New Post 11/5/2009 3:20 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Project Requirements for Multiple Applications 

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.

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Project Requirements for Multiple Applications

Community Blog - Latest Posts

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC