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

The CEO/CIO's Guide to Architecting AI: Vision to Value in Minutes Introduction to Architected AI Artificial intelligence (AI) is becoming part of our life at an unprecedented pace. As CEOs and CIOs grapple with how to leverage this powerful technology to drive strategy and enhance operations, the concept of Architected AI becomes importa...
In today's dynamic business environment, mastering effective business analysis techniques is crucial for organizations aiming to achieve sustainable growth and competitive advantage. Business analysis involves the systematic evaluation of business processes, requirements, and strategies to uncover insights that drive informed decision-making. T...
For many years now, a lot of people have found it difficult to identify the difference between Sankey diagrams and parallel sets. The two have made headlines, given that most people find it challenging to note what makes them different from each other. What remains to be undeniable is the fact that the Sankey diagram is among the top data visualiza...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC