Tuesday, 22 February 2011 08:49

The Eight Competencies of Highly Effective IT Business Analysts

Written by 
Rate this item
(4 votes)

According to IIBA's Business Analysis Body of Knowledge (BABOK), v2.0, "business analysis is the set of tasks and techniques used to work as a liaison among stakeholders ................... to recommend solutions that enable the organization to achieve its goals". A Business Analyst (BA) is any person who performs business analysis activities, no matter what their job title or organizational role may be.

When someone refers to a 'Business Analyst', he often 'means' an SME. However, over the years, the industry realized that simply having subject matter expertise is not enough for effective business analysis. The methods and practices used by the SME are equally important. This fact, along with the release of the BABOK v2.0, made organizations work towards enhancing their business analysis practices beyond simply recruiting subject matter experts.

This article aims at highlighting the important competency areas a BA should possess in order to do justice to his role, primarily on IT projects. The Figure shows the eight major competency areas of an IT BA. The intent of this article is not to present a new competency model but to expand on the existing competency models.

1. Business Analysis Practices

By business analysis practices, I mean primarily the 32 tasks (same as processes) described in IIBA's BABOK v2.0. The BABOK focuses on the processes to effectively perform business analysis on any project. Hence, as one would expect, the BABOK is not specific to any business domain and can be applied equally well to any business domain.

It is imperative for any BA to internalize the BABOK tasks and techniques in order to produce consistent results on projects, as far as business analysis is concerned. For instance, many projects directly begin with a discussion of 'requirements', without first obtaining a consensus on the business problems being encountered by the key stakeholders. The BABOK includes a knowledge area called 'Enterprise Analysis' that requires the BA to perform problem analysis (or opportunity analysis) and arrive at a 'Business Needs Statement', before the solution requirements can be fleshed out.

This approach remains the same, irrespective of whether it's the Insurance, Healthcare or any other business domain. That is the value the BABOK provides to an SME - a set of global business analysis best practices.

Feb22_8Competencies_figure1_FINAL

2. Usability Engineering

Very often, project teams tend to develop solutions or products for the stakeholders who communicate requirements to them, without being cognizant of the fact that no matter who communicates the requirements, if the end-users cannot use the system effectively, the project fails!

The Standish Group, a popular research organization that publishes 'the top 10 success factors' on projects, every year, based on its analysis of a large number of projects in North America, has been including the success factor 'user involvement' in the top 5 factors every year. It's strange to see that, in spite of the recommendation for involvement, that a large number of systems continue to be rejected by end-users, either partly or wholly, once made available to them. This typically occurs during UAT or post-deployment. Usability engineering is the answer to this issue.

Most people who don't understand 'usability engineering' invariably think that it is nothing more than designing UI screens and their look-and-feel. However, to be precise, that is part of user-centered 'design', which is just one subset of usability engineering. Usability engineering includes the entire lifecycle, right from UCA (User-Centered Analysis), through UCD (User-Centered Design) and Usability Testing that ensures that the solution is developed in close collaboration with the appropriate end-user representatives. In fact, user-centered analysis is an integral part of business analysis that keeps the end-user at the center of all business analysis activities. It focuses on the end-user's 'mental model', which is their sub-conscious way of doing things.

It is absolutely essential for all BAs to have a strong understanding of the usability engineering lifecycle, particularly, user-centered analysis and usability testing. User-centered design does not fall within the scope of work of a BA, but is based on the previous analysis and testing results.

3. Object-Oriented Analysis

The BABOK v2.0 includes a set of 34 generic techniques that can be applied to multiple business analysis tasks. Many of these techniques are relevant to object-oriented analysis. Since most software systems today are based on object-oriented technologies, it is important for BAs to be well-versed with object-oriented techniques relevant to their scope of work.

UML (Unified Modeling Language) enables BAs to convert requirements into different types of 'models' or 'diagrams', each of which describes a particular aspect of the requirements. Additionally, 'use cases' are a very simple, easy-to-understand technique to document requirements, primarily, 'functional specifications' (though they can be used with other non-UML-techniques to document business requirements as well), such that it becomes easy and much less error-prone to convert it to technical design and subsequently, to code.

It is important to acknowledge that one of the biggest communication gaps on projects is between the BA and the project team that converts the requirements specified by the BA to working software. UML makes it easy to communicate requirements specifications in a form that is easy for the project team, especially System Developers, to interpret and convert to low-level design, using simple UML tools.

Most BAs I have seen stay a mile away from UML, thinking that it is 'technical' and hence meant for the System or Technical Analyst. UML includes a set of over 10 types of models or diagrams that are developed at various stages of the SDLC. What many BAs probably don't know, but need to understand is that the initial set of diagrams is the responsibility of the BA (though this sometimes overlaps with the responsibility of the System Architect). These diagrams developed by the BA get further converted by Technical Designers to lower-level diagrams that form part of the low-level technical design, during the Low-Level Design activity.

The BABOK includes 'Scenarios and Use Cases' as well as 5 other UML diagrams in its Business Analysis Techniques section. If the techniques are described in the BABOK, they come within the scope of the BA's work and hence the BA must certainly know them. Again, as I have proved to BAs in every Business Analysis class of mine, UML is not "rocket science" and there is nothing 'technical' about it. It can be easily mastered by the so-called "non-technical" BAs, if they do away with their mental block towards UML. The industry certainly prefers BAs with an understanding of UML.

4. Quality Control

Since it's a BA's responsibility to ensure that the solution delivered to stakeholders meets the business need(s) for which the project was undertaken, it's important for the BA to 'verify' and 'validate' the requirements (part of the requirements review activity) as well as 'validate' the solution (typically part of UAT) to confirm that it actually does meet the business need(s). These activities are a subset of Quality Control activities.

A BA must be skilled at planning and facilitating user acceptance testing. This includes ensuring that 'all' the right stakeholders are included in the test and the right aspects of the solution are validated as part of the test. I have seen many UATs that are no different than System Testing, except that they are performed by end-users, who unfortunately may not be the right participants It's not very surprising then that in spite of an apparently 'thorough' UAT, the solution exposes many problems in the production environment.

System Testing does not fall within the scope of a BA's work, as there is no corresponding task or process in the BABOK. However, a BA might often be required to support the System Testing activity, especially if they have been involved in specifying non-functional requirements. Whether a BA is involved in System Testing or not, it is certainly important for the BA to understand how functional and more importantly, non-functional testing (such as performance testing, security testing, usability testing etc) are performed. This is because it is the BA's primary responsibility to elicit and document 'testable' non-functional specifications, a requirements-related activity that I have seen many BAs with little if any familiarity. It would be difficult for a BA to write 'testable' non-functional specifications, if he does not understand what they are or how they will be tested.

5. Documentation

This is one competency area that I would say, is the single biggest contributor to effective and successful business analysis, though the others are certainly very important. It is a known fact that a large percentage of the defects discovered during the System Testing and UAT activities are associated with poor quality requirements documentation. One of the major reasons for this is that the BA invariably assumes that the consumer of the documentation, primarily, the System Development team that actually builds the solution, possesses the same level of understanding of the business domain, as him or her. This makes him subconsciously exclude a lot of important details that deserve to be specified.

This problem gets compounded by the fact that most project team members, including BAs, 'detest' documentation, if I may use that word. The interesting aspect of an ambiguously written requirement is that the individual reading and interpreting the requirement might believe that he has perfectly understood the requirement, when his interpretation might actually be quite different from what was meant by the BA who documented the requirement. Unfortunately, the only time both might get to realize the discrepancies is during the UAT, or worse, during the production run, that leads to an unacceptable amount of rework. That explains the need for 'unambiguous' documentation.

6. Business Domain

By business domain, I mean industry verticals like finance, insurance, banking etc. Though the BABOK explicitly mentions that the role of an SME is distinctly different from that of a BA, it also mentions that often both might be performed by the same person. That is very true, especially on many IT projects with limited resources. The BA would probably not be called a BA if he is not an SME in the relevant business domain. And to a great extent, a BA is likely to be more effective in his role if he possesses a fair amount of breadth and depth of knowledge and experience in the business domain relevant to the project.

7. Business Process Management (BPM)

As mentioned at the beginning of this article, a BA is primarily a problem-solver. One of the things that enable him to identify and analyze problems (or opportunities) and to recommend the best solution is his ability to understand and analyze business processes. Modeling and analyzing the 'as-is' business processes and business rules in scope and then the 'to-be' processes is one of the key business analysis activities. Hence, it is essential for a BA to have a good understanding of BPM concepts and techniques.

The ABPMP's (Association of BPM Professionals) BPM CBOK (Common Body of Knowledge) describes nine different knowledge areas of BPM that a BA must understand well. Though some aspects of BPM, like business process modeling and process analysis (to a smaller degree) have been addressed in the BABOK, there are other aspects of BPM like process design, transformation and performance management that are equally important and central to the role of a BA. They are essential in order to solve a business problem.

8. Technology Awareness

Though a solution need not necessarily have an IT component, in all probability, most of them will, because most businesses today are IT-enabled. Hence it is imperative for every BA to possess the ability to understand how IT systems and technology can help solve business problems. In addition, since an IT BA works within the context of a software or IT-enabled project, a good understanding of the SDLC is essential to perform business analysis activities effectively. In fact, the organization's approved SDLC methodology (waterfall, iterative, agile etc) that is applied to the project directly influences what business analysis activities will be performed by the BAs and what activities are the responsibility of other team members.

Don't forget to leave your comments below.


 By Prasad Kamath   Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

 

Read 36816 times Last modified on Tuesday, 27 March 2012 12:46

Comments  

+4 # Colin101 2011-02-22 08:15
There are several statements in the article that I disagree with: 1.“ a BA is primarily a problem solver” – while the ability to solve problems is obviously a great asset, it is not the prime aspect of the BA role. I would suggest that the prime characteristic is the ability to understand what the business wants to achieve and then elicit and document the requirements in way that is clear, concise and unambiguous. 2. “its a BA’s responsibility to ensure the solution delivered....me ets the business need(s)” – the BA has responsibilitie s for specific tasks and deliverables, but overall responsibility lies with the Project Manager. For example, the BA cannot be responsible for developers that do not have the skills to write the code required to deliver functionality to meet t he requirements. 3 .“aspects of BPM like.... performance management... are central to the role of BA” – while theses skills may be useful in some projects, there is no way that they could be considered central to the role of BA. Also, the article suggests that BAs ”detest” documentation. Personally I have never come across any, and given that documentation is the only BA deliverable, I would suggest that any BA that detests documentation is in the wrong job.
Reply | Reply with quote | Quote
+1 # Balasubba 2011-02-22 12:15
Good article Prasad Kamath. Comments by Colin101 is apt. BA defines & carries out the UAT before the solution is shared with ther end customer.
Reply | Reply with quote | Quote
+2 # Prasad Kamath 2011-02-22 18:27
Dear Colin and Balasubba, I’d like to thank you for sparing time to comment on my article. Every comment might bring up a different perspective of looking at things and hence is useful. Here are my responses to your comments. Please feel free to debate. 1. You mention that the ability to solve problems is not the prime aspect of the BA role. However, ‘Problem-solvin g’ (or leveraging opportunities) is the reason why a BA needs to understand what the business wants to achieve and then elicit and document the requirements in a way that is clear, concise and unambiguous. Solving the relevant business problems is the end, whereas understanding business needs and requirements elicitation and documentation are actually the means to that end and cannot be the objective of business analysis. 2. You mention that the BA has responsibilitie s for specific tasks and deliverables, but overall responsibility lies with the Project Manager. This has been an area of debate between BAs and PMs since, I guess, these 2 roles came into being. If you look at the PMI PMBOK, 4th Ed and the IIBA BABOK V2.0, it is very clear that the BA’s role begins before the project is chartered (i.e. before a PM comes on board) and continues even after the outcome of the project has been accepted by stakeholders and transitioned to Operations or other relevant groups (i.e. after the PM is probably released from that project). The BA ‘owns’ the Business Case, not the PM, though is very important for the PM to understand the Business Case well, which is why it is the input to the ‘Develop Project Charter’ process. Hence it is obvious that the primary responsibility for ensuring that the Business needs (included in the Business Case) are met is that of the BA and not of the PM, though it cannot be achieved without close collaboration between the BA and PM. The project is considered to be successful once the outcome of the project is delivered according to the predefined scope, within time and budget and within quality thresholds and it is accepted by the key stakeholders and transitioned to the team that will use the project outcome. That is what the ‘Close Project or Phase’ process in the PMBOK is all about. However, the BA’s role continues even after that because it takes some time to assess whether the business needs have actually been met. Hence the BABOK includes the task ‘Evaluate Solution Performance’ that includes this post-implementa tion assessment to be performed by a BA to ensure that the solution meets the business needs ‘on an ongoing basis’. I shall continue my response in my next comment because of the size limitation of a single comment.
Reply | Reply with quote | Quote
+2 # Prasad Kamath 2011-02-22 18:29
Continued from my previous comment: 3. You mention that “there is no way that aspects of BPM like process design, process transformation and process performance management etc could be considered central to the role of BA”. According the ABPMP BPM Body of Knowledge: 3a. Process Design: could be the redesign of an existing process or the design of a new process and includes developing process specifications within the context of business goals, like process activities, business rules, integration with other business processes, process performance objectives etc. A BA models the ‘as-is’ processes in scope. This is followed by process analysis that results in the design of the ‘to-be’ processes, whether improved or new. I’d like to understand how a BA would define the ‘to-be’ processes without process design and process analysis. 3b. Process Transformation: includes implementation of the processes designed and might include process improvement, redesign or reengineering, as found necessary. Process improvement, redesign or reengineering could be part of the solution recommended by a BA. Additionally, without process transformation i.e. without implementation of the ‘to-be’ processes (part of the solution), how do you think a BA will be able to assess whether the business needs for which the project was undertaken have been addressed? 3c. Process Performance Management: includes definition of the process performance metrics, identifying the current and desired values of these process metrics and monitoring the solution to ensure that the gap between the two is bridged once the solution is implemented. T he metrics are and must be defined in the Business Case, which the BA ‘owns’. Additionally, performance management is addressed by the BABOK task ‘Evaluate Solution Performance’ in which the solution is monitored to ensure that the desired values of metrics defined in the Business Case have actually been achieved. Now that I have explained what each of the BPM knowledge areas mean, I guess you would probably agree that all of them are closely intertwined with process modelling and cannot really be separated out. One without the other might not be of much use. 4. I agree with your last comment that my choice of words was probably not appropriate. I could have used another word instead of ‘detest’ documentation. But the point I was trying to make is that there is a big difference between simply producing a requirements document because that is required to be done as part of the BA role and producing a meaningful requirements document. From my experience and in my opinion, a ‘meaningful and useful’ requirements document can only be produced if the BA genuinely loves documentation as an activity, barring cases where enough time is not available for requirements documentation. If that is not the case, how is it that some BAs produce good quality requirements documents (i.e. unambiguous, complete, consistent etc), whereas others with similar competencies and experience produce hard-to-compreh end requirements documents? Hop e my comments were useful and did not offend any reader. Warm Regards
Reply | Reply with quote | Quote
+2 # Syed 2011-02-23 03:21
Great article Prasad! It is very informative and has touched a lot of important areas in the field of Business Analysis. Thank you for your time and would like to see more articles like these from you.
Reply | Reply with quote | Quote
+2 # Ernesto 2011-02-23 15:05
Great article, Prasad. I totally agree with you. A true Business Analyst must be responsible of making sure a solution addresses the problems stated in the business case he or she prepared. That means the involvement of the BA is end-to-end even before a software project is started. What I've seen in real life is that the typical BAs scope is very limited, depending on the project and the BA's skills. Normally an IT-BA does not get involved in all the tasks leading to the business case. He/she is normally responsible of elicitation and documentation of software requirements. More of a Systems Analyst role which is more in line with the comments from Colin and Balasubba. On the other hand, there are BAs that are not good at writing software requirements specifications. My opinion is that a Business Analyst worth his salt should be part of the whole end-to-end process from needs identification and business case to making sure the implemented solution, IT or not, is solving the problems it was intended to.
Reply | Reply with quote | Quote
0 # Prasad Kamath 2011-02-23 16:03
Dear Ernesto, Thank you for your comment. Warm Regards
Reply | Reply with quote | Quote
0 # Rakesh 2011-02-23 20:03
Good article and good feedback by Colin! Mr. Prasad, waiting for ur comments...
Reply | Reply with quote | Quote
0 # Dhananjay 2011-02-26 02:41
Thanks for sharing such nice article this definatly give guide lines to aspiring BA's like me to take precaution and develop the skills thanks once again.tc
Reply | Reply with quote | Quote
+1 # GWilson 2011-02-27 17:38
I also think it is a terrific article too - and may yet take it home to my wife & kids to try again to explain to them what I do. :) I thought I should add though that as I was trained and have found in my 10 or so years as a BA - that the most competent BAs are those that have these skills but also have exceptional people skills. To know how to approach different types of people and ask the right questions the right way is a critical competency of the role that is not mentioned here. This is also linked to an ability to successfully run meetings that include either upper level management or end users. A BA also needs to know how to make people feel at ease or even excited about change. I hope that helps. :)
Reply | Reply with quote | Quote
0 # Charu 2011-03-01 04:01
Great article Prasad. It has nailed almost all of the important characteristics . But as Wilson has pointed out, stakeholder management and workshop facilitation are 2 very important competencies that every BA needs to be skilled at.
Reply | Reply with quote | Quote
0 # Rodolfo Meda 2011-03-06 06:19
Prasad, Very good article. Key points where is easy to understand why being only an SME is just not enough if the final idea is to be a complete BA. I made a review and a few conclutions that I posted on my BA spanish-speakin g blog www.analysisarena.com Rodolfo Meda
Reply | Reply with quote | Quote
+1 # Dean 2011-03-22 10:09
Excellent summary, Prasad. I have been doing BA and PM work for years, but only recently received formal BA training. As for a general distaste for documentation, perhaps you've hinted at a future article - Tips & Tricks to Speed Documenting! I, for one, would welcome it. Thank you, too, for the meniton of the ABPMP. I didn't know it existed, so will check their CBOK to which you allude. Cheers!
Reply | Reply with quote | Quote
0 # Bennett 2011-03-22 13:23
Very good points above and elaborations. I notice that documentation was mentioned, but why not communication in general which would include listening, empathizing, verbal and non-verbal communication in addition to documentation. Understandabl y, there are some folks who can speak well but cannot express themselves on paper and perhaps vice-versa, but a 'highly effective BA' has to be able to do both if not more.
Reply | Reply with quote | Quote
+1 # Prasad Kamath 2011-03-22 17:37
Dear Dean, Bennett, Rodolfo, Charu, GWilson and Dhananjay, Tha nk you for reading my article. I am in the process of authoring a follow-up article called "Enhancing the 10 Competencies of IT Business Analysts", in which I talk about how IT BAs can develop or enhance the competencies. Also, based on the valuable feedback by readers, I have added 2 more competencies to the list, thus making it 10. Warm Regards
Reply | Reply with quote | Quote
+1 # Cathy Brunsting 2011-03-23 01:06
I have to agree with Prasad and Ernesto - it is definitely the responsiblity of the Business Analyst to ensure that solution is meeting the needs of the business. A highly effective BA who does not accept this responsibility is letting their team down. In my company we focus on predictably delivering custom software solutions *every* time. To do this, the entire team is focused on delivering a quality solution to meet the clients' business needs. However, there are 3 main responsibilitie s: The BA is responsible (and accountable) for ensuring that we deliver a solution that meets the clients business needs; The PM is responsible (and accountable) for ensuring that we meet our budget and schedule committments; The Architect is responsible (and accountable) for ensuring that the technical solution is correct and sustainable. Ultimately, if individuals on a team only focus on their specific tasks and deliverables, without keeping in mind the ultimate business goals of the project, thne the team is being set up for failure. Every member of the team should be able "stop the line" and call out issues when they see them. Only with this level of team committment can you ensure that the project will be successful. Ultimately, it really does not matter if you are individually successful with your tasks and deliverables, if the overall project is not successful.
Reply | Reply with quote | Quote
0 # David Wright 2011-03-23 08:28
1) What is your source of information on User-Centered Analysis? I cannot find anything about the topic. User-Centered Design is well represented in academic papers and general material, but UCA is not. 2) UML for Business Analysis? Easy on that one; UML is a software modeling language. Being mentioned in the BABOK means enough people are (trying) to use it for Business Analysis that it merits inclusion, but it does not mean it is a best practice.I know whole books have been published on the topic of UML for Business Analysis, by real publishing companies; complete rubbish they are. ... And let's be clear that Use Cases are not a UML diagram, they existed long before UML did, and were adopted by the 3 amigos when UML was found wanting in defining what a system should before defining how it will do it. The rest of the skills depend on the definition of a BA role in an organization; biggest example is Quality Control (testing). Some companies have BAs do it, and others have QA Analysts (testers) do it. Again, something is mentioned in the BABOK if it is something that a BA might be asked to do. Personally, I believe Quality Assurance is a completely different discipline than Business Analysis, and I assume QA people would say the same thing. In closing, the IIBA has just published its latest definition of Business Analysis Competencies, which is longer and somewhat different from your list above. I would be interested in reading your view on those Competencies.
Reply | Reply with quote | Quote
+1 # Prasad Kamath 2011-03-23 18:16
Dear David, Thank you for your valuable comments. Here are my responses: 1. You may refer to Human Factors International's (HFI) web site - www.humanfactors.com. HFI is the global leader in Usability Engineering and User Experience. They deliver a 3-day course on User-Centered Analysis (UCA), which is part of the CUA (Certified Usability Analyst) program. The techniques and concepts under UCA are well-known and you will find a lot of references on them on the Internet, though the references may or may not explicitly call them UCA techniques. Here are some of them: a. Mental Model b. User Profiles and Personas c. Task Flow Analysis d. Information Architecture 2 . About UML, you may call the books on UML or UML for business analysis as rubbish. That's entirely your opinion. It however does not change the facts. If you noticed the title of my article, you might realize that my article is specific to IT Business Analysis and I'd like to know how many IT organizations would not consider UML as an 'important' methodology for business analysis. 3. I don't think it's worthwhile to argue whether use cases were discovered before UML or after. It doesn't really matter. However, if you read my article carefully, I am not just talking about use cases, but about UML diagrams. Use cases are not diagrams, they are textual specifications. However, use case diagrams, activity diagrams and other similar diagrams useful to IT business analysis are all UML diagrams because they use specific UML notations. I am continuing my responses in another comment following this one, due to restrictions on the comment length.
Reply | Reply with quote | Quote
+1 # Prasad Kamath 2011-03-23 18:17
This comment is in continuation of my previous comment..... 4 . About your comment on Quality Control (Testing). I'm not sure you've read my article carefully and completely, because it appears to me that you've commented after simply scanning the section titles. If you read the section 4 - Quality Control, you will see that nowhere have I said that BAs should perform testing. Your understanding that Quality Control means testing probably needs correction because Quality Control also includes review, in addition to testing. That is why I have not called the section as Quality Control (Testing), as you have called it. If you notice, it is called simply Quality Control. I have talked about requirements review and "facilitating" UAT. In fact, if you read my article, in section 4, I have explicitly mentioned "System Testing does not fall within the scope of a BA's work". I have also mentioned that it's important for BAs to "understand" how System Testing is performed so that, with that understanding, they are likely to be better enabled to write unambiguous and testable non-functional requirements. I am surprised you missed this point. 5. I have studied all the 3 versions of the IIBA Business Analysis Competency Model. All 3 versions map directly to the 32 tasks, 34 generic techniques and 6 categories of Underlying Competencies and there's no difference in the 3rd version either. The 3rd version provides more details related to the different levels of BA roles, but it still revolves around the 32 tasks, 34 generic techniques and 6 categories of Underlying Competencies. In my article, I have made explicit references to BABOK tasks or techniques because as a CBAP and a Business Analysis and CBAP Certification instructor, I understand the BABOK very well. However, you again seem to have missed the statement at the beginning of my article that says "the intent of this article is not to present a new competency model but to expand on the existing competency models". I have studied multiple popular Business Analysis Competency models, including the IIBA BA Competency Model, the ESI BA Competency Model, the one by SFIA (the BA part of the model) and another proprietary BA Competency Model. My article draws from all these 4 models, hence it may talk about competencies that have not been explicitly described in the IIBA BABOK. I don't see that as an issue because nowhere in my article have I said that my article is based only on the IIBA BABOK. Hope I have clarified your doubts and have been able to add value. Warm Regards
Reply | Reply with quote | Quote
0 # David Wright 2011-03-25 15:17
Well, I am not a CBAP, I only contributed to the writing of the BABOK 2.0 section on Competencies. Kevin Brennan and the gang at IIBA have been cool to my suggestion that people such as I should be grandfathered into the CBAP(!), but I guess they have their rules... the best they would do is give each contributor a free paper copy when 2.0 was published. I agree that I sold your quality control section short, so "nevermind" on that... But UML... My work as a Requirements Consultant takes me to many companies from year to year, most in the Fortune 300, and I have not yet found even one that considers UML to be something to use for Business Analysis. Those are my facts. Hey, its a big world. If you can point to examples of major companies that use UML for Business Analysis, point away. As for the books, it just seems so obvious that the authors are trying as hard as they can to force fit a design model on to business domains. Seriously, you are going to use a Sequence Diagram to model a business process? Consider the major business process modeling tools, as major as the BPM Model used on top of IBM's Websphere. Does it use a UML Sequence Diagram? Don't worry, it's a rhetorical question. But I am always willing to change my mind, given good examples and verifiable success stories. I will check back in a week or so to see what you have...
Reply | Reply with quote | Quote
+1 # Jack Owens 2011-03-29 09:24
In # 3 you mentioned "UML includes a set of over 10 types of models or diagrams that are developed at various stages of the SDLC" Can you please provide some pointer to where I can get what those 10 types of models are?
Reply | Reply with quote | Quote
+1 # Mark Hunt, CSM 2011-03-30 03:26
Interesting article, and just as interesting comments. A few things I couldn't help adding... In agreement with David Wright, I have a few issues with UML. First, I think there is often confusion regarding what is meant by "UML"; if you include activity diagrams (such as are often used in Use Cases) I personally don't consider that a "UML Diagram"-- you don't need UML context or tool to create one, a pencil and napkin works just fine. Secondly, like David I find few if any companies that I have consulted at or worked with really use it. They do often create system interaction diagrams, context diagrams, business process flows and so on-- but again these aren't necessarily UML (BPMN for example is a toolset you can use to create diagrams, and it's not UML). I would also argue that if you want to truely create a 'pure' UML diagram using a toolset (such as Visio), you do need a minimum amount of training to understand data relationships, data attributes and so on-- most tools won't let you save a box on the diagram until you fill all those things out. This isn't to say a person can't or shouldn't utilize UML, I only question if it's at the top of the list of BA skills-- or if we could perhaps more simply say that a BA should be able to flow and diagram business processes. That we should all agree on. Another point is in regard to the BA being involved in the entire process, from inception to completion. I know it's stated as such in the BABOK, but again this is something that isn't a reality at many companies. None of the companies I have worked for or consulted at included the Business Analyst in the project scoping, initiation or proposal phases. Instead, the BA is brought in once the project is funded and given the green light. Personally I do agree with the position taken by the writers of the BABOK and believe that the business analyst can provide a great deal of value here-- but the reality is that many companies just don't follow that. Therefore I see this as a 'should have' or 'nice to have' goal, but only within the confines of company policy. One other, minor point (which I know might raise some eyebrows, but oh well): as a Scrum practitioner, I beg to take issue with calling agile an SDLC. Some people may consider it that, but many of us don't-- we consider it more of an approach or philosophy (which may take on aspects of an SDLC if you get specific to Scrum, XP, etc.). I do get the meaning on how it was used here however, I just couldn't resist making a plug :-)
Reply | Reply with quote | Quote
0 # David Wright 2011-04-03 10:50
Still waiting for examples of companies using UML for business analysis...
Reply | Reply with quote | Quote
+1 # Prasad Kamath 2011-04-03 17:00
Dear David, I have worked with and have been delivering corporate training and consulting services to Indian MNCs as well as global MNCs in India. All the IT companies listed below use UML to a great extent, right from Business Analysis activities (starting from UML diagrams) to development work on software projects and this is just a small list. IBM, Wipro, Mahindra Satyam, Infosys, Unisys, TCS, Cognizant, Oracle, Mphasis (An HP Company), Syntel Ltd....... I can go on and on. All the above are MNCs with 15000 or more employees.There are many more medium size and smaller companies who are using UML too. If you want more data, you should check with IBM on their sales of Rational Rose Enterprise Edition. Also, you may check the client list of the Enterprise Architect, which is another popular UML tool. As I mentioned earlier, if the solution includes a software system, UML is one of the best ways to convert functional specifications (Use Cases) to design (Class Diagrams etc) with least human error. That is the driving force behind the usage of UML. Otherwise the process of converting functional specifications to design and code can be very risky and error-prone. W arm Regards
Reply | Reply with quote | Quote
0 # Prasad Kamath 2011-04-03 17:05
Dear Jack, Sorry for this delayed response. You could check this URL for information on the different UML diagrams. There are multiple UML resources at this URL. www.omg.org Warm Regards
Reply | Reply with quote | Quote
0 # David Wright 2011-04-05 09:01
" UML is one of the best ways to convert functional specifications (Use Cases) to design (Class Diagrams etc) with least human error." Well, it appears we are in violent agreement about the best use of UML because what you have described is not Business Analysis, it is solution/softwa re design. I have used Enterprise Architect for Business Analysis, Use Cases only, no UML Diagrams. I am also currently using IBM's Rational Requirements Composer on a project, for use cases and business rules, no UML diagrams supported in that tool. I used Rational Rose years ago, when I was first worked at a company using UML. My boss was big on UML for business modeling, so I did a conceptual level Class Diagram and a Sequence diagram to show how the classes would be created and used.We then showed it to our lead dev architect, who threw it back at us and said to stop doing his work, and get back to use cases. That was at DHL, considered the world's most international company; the use cases i subsequently created were used as input by developers in Kuala Lumpur, San Francisco, London and Brussels. So, if you still want to call creating UML diagrams "business analysis", that's your choice; just don't expect anybody to agree with you. similar regards, David Wright
Reply | Reply with quote | Quote
0 # uma lad 2011-04-06 04:50
Here are my comments on the article and the discussions - Here is what I think about UML - it is great tool but expensive for many organizations to purchase due to the fees being charged, hence many companies use Visio which is very inexpensive, practical and can do the job if the Business Analyst understands the requirements well and is able to translate into detailed process flows and swim lanes to show the interactions between systems. It is also helpful that BA to has some knowledge of the back end, and is involved in UAT testing. Regards, Uma
Reply | Reply with quote | Quote
0 # Nico 2011-04-08 20:08
Absolutely spot on article, well written. There is a fair bit of nit-picking in some reader's commentary, and also some utter nonsense. From my perspective, I've been a BA for over 13 years, working for top Blue Chip companies around the world - Oil & Gas, Telco, and now Banking. I manage a team of over 20 BA's, and would say that the qualities you describe, are pretty much what I'm testing, when I interview new candidates for employment. So you have my vote!
Reply | Reply with quote | Quote
0 # Z 2011-04-08 20:38
Relating to UML...I've used these techniques in several companies, and have also reviewed plenty of documentation that has incorporated these models and techniques. If you work as a BA, and haven't come across use of Use Cases, Entity Relationships Diagrams, Context Diagrams, Data Flow Diagrams, etc. - especially if you work is software related - I'm pretty surprised! This is an effective way to help illustrate requirements, demonstrate required functionality, and to convey needs to developers. From my experience, it's pretty usual for a BA to start considering the solution to some extent during requirements gathering (no, I'm not saying the solution belongings in the requirements doc). The reality is, as BA you are likely to be having chats with the technical folk during requirements gathering, to assess the feasibility of requirements that are being developed. There will be discussion with system SME's and architects, where it may be helpful to use UML techniques to illustrate functional requirements. I've done this in practice and in companies where it is mandatory procedure, and can attest to UML being an effective tool for the BA. In the BA capacity as a reviewer, it can also be essential to understand UML, as you could be reviewing docs from architects, or developers, where you need to validate that the requirements you have defined are being met by the solution. If you can't understand these technical docs, what value are you adding? Do we have to wait til testing to pic up 'misunderstood' requirements? U ML is 'free', once you've learned it, assuming you've got the usual MS Office Suite + Visio to be able to chuck together tables and diagrams. A whiteboard would also do though!
Reply | Reply with quote | Quote
0 # Prasad Kamath 2011-04-08 22:02
Dear Nico and Z, Thanks a lot for your comments and for sharing your experiences. W arm Regards
Reply | Reply with quote | Quote
0 # Syed Jalal 2011-04-14 21:55
Dear Prasad, With regards to second competency, you have mentioned towards the end as "User-centered design does not fall within the scope of work of a BA, but is based on the previous analysis and testing results". With the emerging tools in the market like Irise, Axure, Blueprint Sys BAs are moving towards enterperise visualization. Can you please explain more in detail why you consider User centered design does not fall within BA scope of work". I am particularly interested from Requirements Visualization point of view.
Reply | Reply with quote | Quote
+1 # Prasad Kamath 2011-04-15 03:12
Dear Syed, Thank you for your query. Tools like iRise certainly support requirements visualization, thereby supporting User-Centered Design (UCD). UCD typically includes the actual design of the high fidelity UI wireframes, based on the task flows and the information architecture developed during user-centered analysis. If a tool such as iRise supports analysis as well as UCD, it just means that the same tool now has multiple capabilities, however, it does not necessarily mean that the two activities are performed by the same role. It just means that the same tool will now probably be used by the BA as well as the UI Designer to perform their part of the work, though it is likely and probably even a good idea for both of them to work collaboratively . UCD typically requires a very strong understanding of the usability design best practices, with special emphasis on the 4 focal points of design - Navigation, Content, Presentation and Interaction (together called NCPA). This includes for instance, the layout of screen elements, the look-and-feel of the screens etc. Using a tool like iRise, a BA might certainly be able to put together a high fidelity prototype, but without a sound understanding of NCPA, I don't think the UI design or prototype will be effective in meeting the usability objectives of the product. For instance, can you expect a BA to know whether field labels should be left-aligned or right-aligned, or should a particular screen have only 2 colours or 5 colours, from a usability perspective? I certainly don't think so. These are some of the things addressed by the UI designer as part of UCD. BAs are not expected to have experience and understanding of the above mentioned aspects of UI design. Though some BAs might actually possess experience in these areas, the competency is certainly not core to the role of a BA. These activities are supposed to be handled by UI designers. The Usability Engineering Lifecycle includes UCA and UCD as 2 separate activities or phases, and these typically coincide with the requirements analysis and technical design activity respectively. As I have referenced earlier, you can get good information about the difference between UCA and UCD at www.humanfactors.com. In fact, Human Factors runs 2 separate courses for each of them, under it's CUA (Certified Usability Analyst) program. I hope I have been able to answer your question to your satisfaction. Warm Regards
Reply | Reply with quote | Quote
0 # Katie Metcalfe 2011-04-18 10:52
Great article! I agree that understanding the business needs and elicitation and documentation are the means to the end...or the problem solving or opportunity creation that is at the core of all good BA's work.
Reply | Reply with quote | Quote
0 # Putcha V. Narasimham 2011-07-03 05:46
Dear Prasad, Ernesto, David, and Nico I have quickly scanned Prasad's article but read the comments of Colin, Ernesto, David, Nico and Prasad's responses a bit more closely. Earlier I felt that IIBA up to V 2.0 has expanded the scope of BA's responsibilitie s to include many aspects of Solution, Software HLD, QA and Delivery directly or indirectly. I felt that the scope of BA's responsibilitie s should be defined more clearly to avoid the kind of discussion we have seen here (not to avoid debate but the basics should not be disputed). Accordingly, I appreciated the points made by Colin and David. Then I found Prasad quoting standards and statistics on the use of UML (I wonder how he has access to them from so many companies) to support his statements pretty well. The central point of how much of UML is used for BA is not clarified (it is besides the point that IIBA syllabus includes Class Diagrams, Sequence Diagrams and State-machines without explaining why. Personally I think a BA need not know them). I have been using / teaching UML since late 90s till now in multinational companies based in India and interacted with over 75 IT professionals / professors in India and USA and learnt that UML was not used. On probing I learnt that on rare occasions when it was claimed to be used, it was used wrongly (UML standard itself is not very clear many times) and it did not matter because it was never used beyond initial documentation. My sample may not be large and valid for professional debate but I would be interested in actually seeing how UML is being used. I REQUEST YOU ALL kindly to send me () sample documentation using UML. I wish to send my word documents to you for review. Please let me have your email IDs. I have been trying to approach the BA Scope definition from another side. Please let me know WHAT NEED NOT BE LEARNT by a beginner / Intermediate BA out of IIBA Syllabus. I would like to know from actual project managers what they want a beginner / Intermediate BA to do in the first 6 to 9 months of his or her job. Prasad, you have covered many other important points of BA and clarified them very well. Let’s keep in touch.
Reply | Reply with quote | Quote
0 # Putcha V. Narasimham 2011-09-04 16:29
Dear Prasad Kamath, Ernesto, David, Nico I revisited this site after two months. I would like to know the details of first publication of Use Case Concept by that or any other name. Any specific suggestions on WHAT NOT TO LEARN for a beginner / intermediate Business Analyst are WELCOME. Pleas e let me know good sources to learn and apply Enterprise Architecture Representation in Business Analysis.
Reply | Reply with quote | Quote
+2 # Landon Miller 2013-10-13 18:03
I judge the value of an article on how much discussion it generates; by that measurement Prasad's article is one of the best I have read in the past few years.

Thank you for braving the audience and publishing this article. While I may not agree with all of it, the resulting debate is most helpful!
Reply | Reply with quote | Quote

Add comment


Security code
Refresh