Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Usability and U...  When to use what technique?
Previous Previous
 
Next Next
New Post 11/9/2011 11:49 AM
User is offline Tim G.
4 posts
No Ranking


When to use what technique?  

 As a business analyst there are plenty of techniques to use for post-requirement-elicitation clarification: use cases, prototyping (software applications such as iRise, UPerform, etc - or excel/visio), swim-lane as-is/to-be process flow diagrams, wireframes, etc. How do you know when it is appropriate to use which technique? Is it based on the type of project? Is it based on cost and/or schedule limitations of that project? If the business wants the best result, the more techniques and straight forward documentation used the better, although that is never the case based on lack of budget. What is your go to technique, and what are the pros and cons of each?

 
New Post 11/10/2011 9:19 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: When to use what technique?  

Hi:

Excellent question!   I mean a REAL excellent question!!     No - contrary to popular belief, the answer is not "what feels right".

To answer the question, you need to first look up the word "analysis" in a dictionary.  When you do, chances are that the first listed definition will be like "Analysis is breaking (partitioning, decomposing) an entity into its component parts and then evaluating how the parts interrelate. So, your  top priority as a BA, especially in larger scale projects, is to choose a technique that guides you through partitioning/decomposing.  Only data flow diagrams offer such.  You can use process flow diagrams at the lowest levels, but the higher levels need DFDs for a proper partitioning.

Also, systems at higher levels of abstraction have no definable sequence.  So you can not use sequence based techniques to model the bigger picture for larger systems.  You can not use, for example, process  flow diagrams, as they are sequence  based.

Also, if you need rigor, you need a technique that has a built in litmus test of completedness.  Something that makes logical holes in your analysis glaringly evident.  Only Data Flow Diagrams have such.

Regarding which software to use:  Software is how you do modeling.  Be sure to first figure out what technique you are going to use BEFORE you determine how you will proceed.

Tony

 

 

 
New Post 11/11/2011 12:46 PM
User is offline Chris Adams
323 posts
5th Level Poster






Re: When to use what technique?  

While I agree with Tony that Data Flow Diagrams are a powerful discovery tool, I think that many other tools are just as helpful.

First, I would say that "whatever feels right" to use isn't all bad.  An experienced analyst should be able to assess the project circumstances and determine which deliverables will be needed to ensure the projects success.  No one process and set of artifacts fits all circumstances.  Sure, you can use them all everytime, but that would be a substantial waste of resources in some circumstances.

In the end, regardless of the project type, size, scope, etc...you need to be able to answer all of the same questions.

1) Do you understand the Customers Need and how this system should support those needs?  This goes beyond requirements.  Do you understand the rationale for each requirment?

2) Do you understand each business groups requirements? Sometimes different groups have competing requirements.  When a decision is made can you document why the decision was made so that looking back people understand why each requirement was satisifed the way that it was.

3) Are discussion happening using the same terminology?

4) Do you understand the data that is being used by the process that the user is trying to complete.

ETC...

Regarding artifacts and deliverable, almosts all projects require some form of:

  • Requirements list with traceablity to the customer needs and down to the other solution documents.
  • Business Entity Model or Fact Model
  • Process Flow (UML or BPMN) to document AS-IS and TO-BE states.
  • Functional descriptions of how the systems UIs should behave.





Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
New Post 11/14/2011 9:52 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: When to use what technique?  

Chris:

Hate to say it, but "by experince", "other techniques are just as usfull",  "no one set of artifacts fits all circumstances", "you need to answer the same questions",  and "all most all projects require some form of..." are the same as "by feelings":  none provide a concrete answer to the when to use what technique.  

The original question is a GREAT question!  It is also a very obvious question to ask.    Unfortunately, it impossible for most BA's to answer.  Heck the BABOK 2.0 does not address this basic question.  But, there is an answer.

Tony

 

 
New Post 11/15/2011 1:57 PM
User is offline Chris Adams
323 posts
5th Level Poster






Re: When to use what technique?  

Tony,

Don't get me wrong, I'm all for following a prescribed plan, hence the use of tested methodolgies.  My only point is that you can't simply follow a checklist of deliverables to create and hope that all will end well. 

It's imperative that the analyst understands that benefits of each technique/deliverable and assesses whether the cost of creating such a deliverable for the specific project outways the risk of not having it.

In short, analyst actually have to do analysis.  They have to take their brains out of neutral and put them in gear.


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Usability and U...  When to use what technique?

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC