Some programmers consider documentation a waste of time (see “Agile programming”), even going so far as to claim it is detrimental to productivity. Instead of getting all the software specifications recorded on paper at the start, they prefer to begin hacking on the program code and keep modifying it until the end-user is satisfied.

Probably the most used facilitation technique in business analysis is brainstorming.  In summary, a group meets with a facilitator and attempts to gather as many ideas as possible to address a problem. The facilitator sets rules at the beginning of the session of which the most important is “no adverse judgment of ideas” during the session.

Many BAs (especially the most experienced ones) should be familiar with processes...  Let us try to reveal, how BA skills are applicable to BPM and which steps a BA should take to transfer their knowledge to a state sufficient to fully enter the BPM sphere.

Now we delve into data modeling, one of the core model types. We choose to start here because data requirements are an important foundation for most information technology projects. If you are a business analyst and not doing data modeling today, you should be able to at least read them to validate requirements against what a data modeler has created and our bias is that business analysts can and should be doing “functional” data modeling.

In the real world, good decision modeling is always a balance between science and art. The science is systematic decomposition of a structure (of data or logic) into a set of smaller structures based on the definitions of successive normal forms. The art, on the other hand, is a general decomposition into a set of smaller structures based on factors not related to detecting and correcting normalization errors.

How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer.

I’ve come to the conclusion that most projects produce better results when they have specialized people playing the various roles, rather than trying to be resourceful and wear multiple hats.

Visual models don’t have to be complicated. Unless your organization uses formal UML or BPMN standards, focus on learning to create simple visual models. In this article, we’ll explore 3 simple visual models that a new business analyst should be skilled in creating because they add a lot of value to projects and generally improve your requirements documentation. 

Driving Lessons. We all did it. We all know how that very first one went. It was described to us that the clutch should be engaged, place the car in first gear, release the handbrake, release the clutch and press down on the accelerator… Only for the car lurch forward then stutter and lurch forward again. This process continues several times before the car stalls and comes to a stop.

No matter how thorough a job you do on requirements elicitation, there is no way to be certain that you have found them all. No little green light comes on to announce “You’re done!” You should always plan on new requirements trickling in throughout the project. However, an excessive rate of change of requirements suggests that important requirements were overlooked during elicitation.

As a Business Analysts we work with goals and objectives of our clients or companies in order to deliver business value, but how often do we sit and work on professional goals and objectives? How often do we use the skills that we possess on ourselves and our own professional activities? This year I plan to do exactly that, I have put together four BA resolutions that I believe will make me a better BA.

So, what’s new now? A shift is occurring. Not only are decision models sanctioned as a new kind of deliverable, but thousands of them already operate in production systems serving major corporations. What’s new now is the emergence of an important question: what kinds of decisions belong in decision models and why?

The emergence of decision analysis techniques[1] is hugely important for both business rules in particular and business analysis in general. The same is true for decision tables, although current innovations[2] are more of a re-invigoration than fresh invention. [3]Every business analyst should be familiar with these decision analysis and decision table techniques.

Before we get carried away with decisions, however, we need to take a deep breath and do a reality check. This article discusses three major (and quite harmful) myths of the business decision space.

The close of one year tends to encourage us to reflect on what has occurred in business analysis and project management during the past year and think about future trends. As we reflect on the past, we thought it might be interesting to review some of the trends we’ve seen over the last five years and when we spotted them as trends

The purpose of this brief article is to provide a simple example on how to link and verify four models: use case, data flow diagrams, entity relationship diagrams, and state diagrams. Note the word verify, not validate. Verify in this context means that the technique is consistent and complete, not that it reflects correct requirements.