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.

What if you want to use your business analysis skills, but don’t want to be in BA management or a team leader role? What if you want a different kind of role, but one that still uses your business analysis skills? Are there other roles out there for a skilled Business Analyst?

The answer is yes!

"What we have here, is failure to communicate". This is the catch phrase of a once very popular movie. And while the theme of this movie has nothing to do with the corporate business world, its meaning most certainly does.

How often do we hear “We don’t have time for analysis—let’s just get the project done!” Or “Modeling?! That’s so 1990s.” Or “Modeling is the developer’s job. Yours is to get the requirements.” Or “We’re doing Agile. Requirements evolve, so let’s not waste time with use cases or process models.” We have often heard every argument under the sun why spending time modeling requirements wastes time. However, we believe that modeling actually saves time.

Prior to the creation of something as potentially complex and ubiquitous of a website, an analyst must create a thorough, precise set of requirements in consultation with the right subject matter experts and business stakeholders. But unless one is armed with the proper planning procedures and techniques, the prospect of creating requirements for something as vast as an online business presence or functioning e-commerce system (or both) can be intimidating.

Do “Agile”projects need written requirements? Let us answer this question in this short article. As you may know, more and more software development teams have been adopting “Agile”processes over the past decade or so. As you may also know, Agile development processes such as Scrum and XP emphasize “working software” over requirements documentation.  Does this mean detailed, written requirements should be avoided in Agile projects?

Decision requirements models allow business analyst, architects and decision designers to describe the decision-making they need. When these models are combined with business-friendly decision tables, non-technical domain experts can represent critical “know-how” accurately and precisely resulting in faster time to value and fewer errors...

While a Business Analyst Manager has primary responsibilities of developing a team of Business Analysts and potentially best practices within the organization, the Lead Business Analyst’s key responsibilities also include ensuring the success of the execution of the Information Technology project, specifically the Business Analysis portion.

Today, it is very common for organizations to use The Decision Model for managing DQ logic. The results are impressive and also deliver unique advantages over other approaches. In some cases, organizations represent DQ logic in The Decision Model as part of requirements deliverables. In other cases, organizations create DQ logic in TDM-compliant software which validates the logic against TDM principles, generates and executes test cases, and sometimes deploys to target technology.

It's a new year, and time to go back to work. January is when we reset the statistics, brace for a new year, and try to prove ourselves once again.

Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are. Discussed, dissected, blogged about—why don’t they just go away?! 

The first core responsibility of the BA Manager is managing the team. BA Managers tend to be practice oriented. They strive to help grow and challenge their BA’s to be the best BA’s that they can. The BA Manager must know and understand the skills every BA needs and have the ability to help each BA perfect them. Understanding each BA’s strengths and weaknesses will help them create a development plan for their BA’s.

A few words to set up the story - my daughter is going to have a cyst removed from her left wrist. It's not a complicated procedure but she will be going in outpatient surgery on Dec 20 of this year. Now here's the business analysis part of the story.