Login

Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  General  Engaging business users in functional analysis tools
Previous Previous
 
Next Next
New Post 12/22/2008 4:30 AM
User is offline hilliert
1 posts
No Ranking


Re: Engaging business users in functional analysis tools 
Modified By hilliert on 12/22/2008 8:44:43 AM)

 

Roy,

I noticed a number of posts were advocating UML tools to some extent and thought you'd appreciate my initial, short-lived experiences.  I've much prefered DFD's and ER models, but only ER's where there are a few entities.  ER models that get too big become too difficult for many business users to follow (and me for that matter!)  Even with DFD's, a simple flowchart using simple flowchart syntax can be easier - most if not all business users can follow a flowchart without the need to explain the notation etc, so you've half won the battle already there.

In my limited experience of UML coupled with a RUP environment, whilst on paper the techniques sound fantastic and make you question why you haven’t adopted the tools before, but in practise I have found the techniques to be very IT centric and favours the needs of IT more so than the business. UML requires mass educating of the techniques to most persons contributing to the project and is very resource hungry in terms of business engagement, particularly in the earlier stages.

My view is that it’s largely a trust methodology in that it’s absolutely paramount to gain your customer's trust and confidence from the start. The business will generally feel very uncomfortable by the whole approach if this is new to them and you are liable to pockets of resistance, particularly where a BA’s unease with UML is apparent by the power house communities. From an IT perspective, it’s a valuable tool as it arguably allows them to railroad development by way of disengaging the business (and blinding them with science!), all the while the business genuinely feels as though they are shaping requirements when in fact they're not!

 I’ve seen 3 business reactions to UML tools: 

  1. The business will half understand what’s being conveyed but trusts and has confidence in the BA that they know what the they want.
  1. The business gets tired of not understanding what’s being presented and will just ‘sign-off’ on anything (I use this phrase lightly as my experience very little appears to be signed-off given that shortcomings may be addressed in future iterations).  It's also a way of deflecting feeling stupid.
  1. The business is tired of not understanding, cannot see the benefit of this new approach and mount a full scale resistance.
Standards and general project configuration must be robust before marching on gathering requirements. Whilst this is true of any project methodology, it’s arguably more important in a RUP environment (or similar). Diagram notation styles will vary from person to person, resulting in a number of different ways to document the same things (e.g. use of decision gate vs no use of gates and having associations direct from an activity) – this will also lead to difficulties in identifying commonality and hocks into related use cases.  
  • Business Use Case diagrams have often gone down well, with the exception of ‘extends’ and ‘includes’, but these diagrams are not very useful in isolation - provide a good context and that's about it.
  • Activity diagrams have also been generally well received, although purist notation often needlessly confuses matters – i.e. a merge node following a decision often adds very little value to a diagram, but merely pollutes the diagram.
  • Object model – forget about it! Most business users will not like these whatsoever!  It’s also difficult to distance yourself from database table designs and business users will often be confused by cardinality, but this point is probably the same with traditional ER models.
  • Sequence diagrams – the business will not like these and are likely to insist that it’s too techie.
Experience of PRINCE2 based methodologies has usually entailed a BA to document requirements and then a System’s Analyst (or similar) to document understanding of the requirements by way of proposed solutions. I feel UML looks to merge these two functions into one (i.e Moi!), whereas for me there are greater benefits in keeping the roles distinct.
 
I appreciate this is a biased account and may be arguably unjust on some points, although this is a reflection of my horrendous experiences. Interestingly, I’ve heard similar accounts from others too. In fact I’ve yet to realise any benefits for business users from using UML over traditional methods – just confusion and delay. In the time faffing around with UML, I could have expressed and gained business understanding to requirements is much less the time. UML for me is a fashionable term and allows consultants to command huge rates for what is little more a rehash of the same stuff, rebadged!
 
“Keep it simple dummy!”
 
New Post 12/22/2008 6:02 AM
User is offline Roy
6 posts
10th Level Poster


Re: Engaging business users in functional analysis tools 

Terry

Thanks for your views. You have some valid arguments for steering clear of UML.

On the positive side, you mention use of DFDs ... I too have been a fan of these and in the past have used fairly complex multi-level diagrams quite successfully with business users. This does raise some questions though i.e.

Should DFDs be used to replace or supplement text-based Busines Requirement Lists?

A complete DFD 'set' should be supported by process narrative and data flows defined down to data elements... is this effort justified?

How do IT (i.e. Systems Analysts) react to DFDs these days? It may be viewed as an out-dated technique or 'stepping on IT's toes'.

Do DFDs fully convey the information that IT require?

Roy
 
New Post 12/22/2008 6:32 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Engaging business users in functional analysis tools 

Roy:

DFD's can creatively be used with text.    Or the final output can be just text.   DFD's are the discovery tool that text is not.  Once you have discovered the requirements, you can use whatever means you feel is best to document them.  Even use cases!  (Just remember, DFD's are a discovery the Use Cases only poorly imitate.)

Narratives and a logical data dictionary are often not necessary.   It depends on how much detail is necessary.   With medium rigor DFD's you are way ahead of anything the UML can offer.  Yourdon's latest book "Just Enough Analysis" is about 645 pages long.  Nobody is ever going to use DFD's with all of that.

DFD's are largely considered old fashioned.   But the question should be what works.    I have never seen anyone have success usines use cases or activity diagrams for other than relatively smallish solutions.      

Do DFDs convey the info that IT require?   With good DFD's developing integrated design diagrams is fairly straight forward.  The problem that I have seen over and over is IT people trying to create design diagrams without a logical functional model.

Tony

 

 
 
New Post 12/26/2008 8:34 PM
User is offline Kimbo
456 posts
5th Level Poster


Re: Engaging business users in functional analysis tools 
Modified By Kimbo on 12/26/2008 11:37:20 PM)

Hi Hilliert (is it Terry?),

What a hearfelt rant ;-)

The DFD v UML debate reminds me of the object oriented v client server / green screens war of the 90's. Object oriented was the new kid off the block with all the old coders (like me) ranting against the inevitable. Eventually I had to accept it or get out of coding. (I stayed in for a while to understand it, then converted to being a BA). DFD's are the Cobol of the BA world. UML is the industry standard whether you like it or not. I'm sure there'll be people who disagree but just look at the job adverts.

UML uses a behavioural approach, DFD uses a data driven approach. UML done badly is useless. DFD done badly is useless. Its just a different way of looking at the same thing.

In the UML I use the parts of it that I need to support my argument. For the past 18 months I've completed 7 consulting projects producing a mixture of "As-is" and "To-be" Business process models. Each node on the business process diagram is either a use case or another diagram. The use case is "manual" or "system". In this way the whole of the client's business process is mapped. The manual processes in the "To-be" model are opportunites in the future for more development work. The tool that I use can produce a website. Often the client will load this onto their own intranet as documentation and training of their internal processes.

The parts of UML I use are:

1. Activity diagrams - business process

2. Use cases - functional behaviour definition

3. Statechart - entity lifecycle (states and transitions), site maps

4. Class diagrams - business domain

Object diagrams and sequence diagrams and the like are far too techie for me. That is the realm of the solution architect and to be frank, I don't really care about them. I've been a full time BA since 2001 and have never written any of these. In fact I would refuse if asked because this is not what a BA does. I'd never show them to a business user.

Following this stage, if required I also do UI / report specs that realises the functional model i.e. the business process / functional model, plus a detailed business domain model and data dictionary. I don't use UML for this stage - apart from the class diagram. I have found prototyping to be most effective for screens / report modelling. I create a detailed spec for each screen / report in word. This engages the developers - they do the prototype - as well as the business. Prototypes should always be reusable during construction.

The idea of directly linking the activities on the activity diagram to a use case was somewhat of an epiphany for me. Its obvious when you think about it. I'm very happy with this approach and have proved it successfully (to myself) on those projects in the last 18 months.

So Hilliert mate, you don't want to be a dinosaur. Persist with the UML. How many jobs do you see for Cobol programmers around nowadays?

Kimbo

P.S. I just started a new contract last week. They use BPMN. Personally I hate it. Seems far too technical and needlessly hard to understand. But I'm determined to get on top of it. I'm sure its just because its new that I dislike it so much ;-)
 
New Post 12/28/2008 1:30 AM
User is offline Adrian M.
765 posts
3rd Level Poster




Re: Engaging business users in functional analysis tools 
Modified By Adrian M. on 12/28/2008 4:38:13 AM)

Hi Kimbo,

I've been using BPMN for a long time and it's a great tool!  For modeling business processes it is a much better way to go than a UML activity diagram.

Stick with it - you'll be glad you did!  At least it's one more tool in your toolbox.

BPMN might seem technical because of its integration with BPEL and because it's detailed specification but it is not - or at least it doesn't have to be.  You can use it as is without any integration to a specific process modeling tool.  The Visio template works just fine.

- Adrian

Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
 Page 4 of 5Previous12345Next 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  General  Engaging business users in functional analysis tools

Community Blog - Latest Posts

Agora Insights International
Agora Insights International

The CEO/CIO's Guide to Architecting AI: Vision to Value in Minutes

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

Mastering Effective Business Analysis Techniques: Strategies for Enhanced Decision-Making and Growth

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...
Charles Friedo
Charles Friedo

Sankey Diagrams vs Parallel Sets

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

 



Upcoming Live Webinars




 

brought to you by Modern Analyst Media LLC enabling practitioners & organizations to achieve their goals using:

Copyright 2006-2024 by Modern Analyst Media LLC