If I said Mentalist to you, I expect you would either think of a mind-reader of the David Copperfield ilk or the TV series of that name. In fact you would probably take it as an insult as neither of these images is particularly comfortable, but both would have a voyeuristic attraction.

The reason I bring this up is that there has always been a fascination with trying to guess what is going on the minds of the people in front of you. This is particularly apt when you are trying to understand what the in-duh-vidual in front of you really wants (aka requirements gathering).

So you want to be a better requirements analyst. Or maybe you’re completely new to business analysis and you just want to learn what requirements analysis involves, period.

One day I found that my husband posted an interesting status on Facebook and it made me think of how these two simple questions can produce different results based on the situations. My husband’s quote is as follows: "We can ask the question "Why?" or think of how to make it happen and say "Why not?"

Use Case Points are used as an analysis phase technique for estimating software development. Assuming the Business Analyst (BA) composes system use cases for describing functional requirements, the BA can use this technique for estimating the follow-on implementation effort. This article reviews the process of estimating the follow-on development effort for use cases.

It seems every now and then someone comes along with a new spin on how to estimate a project, either in its entirety or a portion of it. I have heard a lot of theories over the years, particularly in the Information Technology (I.T.) field where there is a tendency to pull numbers out of a hat, but I've long given up looking for panaceas.

Software development process is undergoing seismic shift from traditional waterfall software methodologies towards agile methodologies. Agile software development methodologies deliver high quality software products in rapid iterations with high flexibility and adaptability to changing conditions. This article discusses the dynamics of agile projects by comparing it with the SDLC project framework to help the IT leaders and organizations plan effectively for transitioning to Agile software development methodologies.

Congratulations! You've just won your first large client and you are being chosen to play the role of the Lead Implementation Consultant for the engagement. You are being chosen because you are, at your core, an excellent BA and have a very high level of expertise about the product or solution that has just been sold.

As agile methods become widespread in organizations, it’s not surprising to see the idea of the business analyst as a dispensable role taking root among IT project teams. After all, in agile approaches, tasks typically performed by a business analyst, such as requirements elicitation, analysis and documentation, are replaced by a conversation between customer and developers.

There are considerable benefits from extending business process management capabilities outside the boundaries of the company, and clearly measurable value is much easier to quantify when stakeholders are outside the traditional walls of the business.

Over the years I have noticed that we, as Americans, seem to possess a knack for attacking the wrong problems which I refer to as the “Rearranging the deck chairs on the Titanic” phenomenon. I see this not only in the corporate world, but in our private lives as well. Instead of addressing the correct problems, we tend to attack symptoms.

At UC Berkeley there has been an increasing awareness of the importance of business analysis (BA) and user experience (UX) in the software development lifecycle. In this article we will discuss the advantages of involving BA and UX practitioners in your development process, when and how to involve them, and the similarities and differences between the two professions.

Recently, I was watching an episode of "60 Minutes" which discussed the prosecution of a whistle blower at the NSA regarding the development of a major system to be used in the War on Terror, code named "Trailblazer." Although the intentions of the developers may have been good, the project started to spiral out of control almost from the beginning.

A swimlane diagram is a type of process flow diagram (also sometimes called a cross-functional diagram) that features divisions or "lanes." Each lane is assigned an actor (which may be an individual, department, division, group, machine, entity, and so on), or even a phase or stage in a process, that is responsible for the activity or work described in the lane.

I recently saw the "The King's Speech," a movie about the relationship between the stammering King George VI of England and his speech therapist... how is this commoner able to help the monarch and become his life-long friend? He is a master at influencing with absolutely no authority.  There are some lessons here for those of us business analysts and project managers whose jobs depend on our ability to influence without authority.

Structured business vocabulary is a missing ingredient in most current approaches to developing requirements. This omission should greatly concern every business analyst. Indeed, business vocabulary is key to a whole range of fundamental challenges, including but not limited to capturing business rules. One reason is that business vocabulary, like data and business rules, lives on beyond the point of system implementation and deployment.