My understanding is that, in practice, successful agilists tend to bring together a number of activities, tasks, and deliverables that are from beyond the boundaries of what may be called “pure agile.” This mixing and matching of software process elements from agile and non-agile (more formal) approaches is a much more practical way of using these methods.

This article is all about putting your systems analysis into context; literally and metaphorically. It’s all about drawing and interpreting the not-quite-UML Context Diagram that is sometimes referred to as the System Context Diagram.

Why does it take an 'act of congress' for some organizations to realize that what they are doing is not working? I have been in many industries(media, manufacturing, financial and the judicial system) and no matter what industry I've been in I’ve seen some of the same themes.

Facilitation is one of the most critical soft skills of the business analyst, as well as one of the most difficult to master. Working with various stakeholders requires tremendous preparation, insight and finesse in addition to an understanding of key principles of the facilitation process.

Like most business analysts, Charles captured business rules as part of requirements gathering. Also like most business analysts, he followed traditional business rules approaches. These included writing individual business rule expressions, storing them outside the confines of process models and use cases, and providing pointers to them. However, he changed his approach after experimenting with The Decision Model.

Transaction Business Logic is the processing required in processing database transactions to enforce business policies. It is sometimes characterized as Enforcement logic, since the transaction should be rejected if the rules are not passed. Consider the insertion of a new Purchase Order...

When used properly, a performance measurement program can help BAs and their managers identify specific improvement priorities, clarify responsibilities, and drive the desired behaviors required to achieve business goals. However, in practice it's rare to see managers taking advantage of the benefits a good performance measurement system can offer...

Worldwide, there are between five hundred thousand and one million people working as Business Analysts...  So why are all types of businesses, from charities to investment banks, hiring so many of them?...  What do they actually do?...

I often get asked, “How can I get stakeholders to attend my meetings?” or “How can I get stakeholders’ buy-in on the project?” These are complex questions and the easy answer is that you can’t. As BAs and PMs we can’t get anyone to do anything, but we can certainly influence them so that they want to.

The Decision Model in practice has delivered many unanticipated, but positive surprises. The most obvious and powerful surprise is how it drastically simplifies process models. In fact, we regularly receive unsolicited messages from people who experience this effect. For example, one practitioner condensed a 45-page process model to one with eight task boxes.
 

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.