General Business Analysis

In an ideal world, all software projects would have an interaction designer or user experience (UX) specialist working with the team to ensure that the product is designed in a way that truly satisfies the needs of end-users. In a software project with separate business analyst and interaction designer roles, the work of these professional is complementary

On February 12, I wrote and passed the CBAP exam on the first try. I had completed my application way back in September but hadn’t been able to find an exam sitting date that I felt would give me enough time to study. I finally decided in December that I would never find the perfect time so I set the date for early February and told myself I’d find a way to make it happen.

I know many of you are still trying to get to grips with Service Oriented Architecture (SOA), so apologies in advance for the potential mental exertion and confusion of introducing Business Oriented Architecture (BOA).

The structure of business analysis documents isn't a commonly discussed topic. This article will show what documents are produced by a Business Analyst and the main sections they contain.

These are the main documents produced by a BA over the course of a project...
 

Business Process Modeling is becoming a higher priority for business managers and analysts as there is an increasing emphasis in organizations to document, understand and improve their business processes. Although Business process modeling provides many important benefits to companies and organizations, however, these five are the most critical and high impact.

Business requirements are usually captured in narratives and graphics that, regardless of how detailed, structured, cross-referenced and validated, are fundamentally imprecise. A data-driven approach to specifications has the potential to help avoid these problems and subsequently decrease the risk and increase the return on companies' IT investments.

As a result of budget constraints and limited resources, many companies, (mine included) look to automating tasks and processes to improve efficiency. And one of the easiest areas to demonstrate immediate improvement is by automating a manual process. While almost any manual process could show results by ‘simply’ being able to move documents and files electronically around the company, there is really a more important underlying requirement.

Abraham Maslow once said “If the only tool you have is a hammer, you tend to see every problem as a nail.” This article provides the project manager (PM) / business analyst (BA) a framework for categorizing business problems as a baseline for selecting a solution development life cycle (SDLC).

“The overall purpose of Business Analysis is to build a bridge between business and IT”. This is a good enough definition for a position as hard to define as Business Analysis.

A software tool for The Decision Model supports the entire life cycle of Decision Management. This includes the authoring, analysis, testing and deployment of entire decision models. Whether managed by the business – as some people consider ideal – or managed by IT or business analysts on behalf of the business – as others consider necessary – business decisions need not only a repository for storing decision models, but a range of functions to manage them effectively.

Taking a long lens approach to looking at 2011 is an apt metaphor that should serve as a reminder to BAs of the perspective they need to take to in terms of both their professional development and their role in the organization. There’s no better time to take stock and strategize on how to best prepare for the opportunities and the challenges you’ll experience ahead.

When you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking - I know this from experience. It's like driving a racing car - you have to push close to the limits but any error can throw you completely off the track.

How far can you take requirements elicitation in a project? Clearly, no one knows the ultimate answer. It would be very costly (if even possible) to capture all requirements, assumptions, rules, relationships, and hidden connections associated with a solution being built, so how do we know when we are done?

As I look back on the last nine years of my BA career, I realize just how well that initial reason for leaving the call center, that desire to make a difference for my customers, has served as a guiding light for me as a BA. Providing my customers with tools and processes that anticipate problems they may have has been a goal throughout my years as a BA.

Many IT professionals currently prefer the if-then form for expressing rules. Why? Put simply, it's closer to what they need for implementation, whether under a rule engine or a programming language. Consequently, they often resist expressions of rules from the business perspective as business people would naturally prefer them. But what effect does that have on the rules?