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 2: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 4: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 8: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 9: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 2: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

Salesforce has established itself as one of the most reputable CRM platforms, providing important customer data to assist businesses in effectively managing their operations. Salesforce is the world's best CRM platform that helps businesses to keep up the data in an arranged or structured manner. Salesforce is the world's most popular...
There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms: Data exploration means the deep-dive analysis of data in search of new insights. Data presentation means...
Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC