An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable.

The once lowly business analyst is suddenly in high demand. Here's how to work well with the ones you've got.   The hottest job in IT right now might be the least "T" of them all: business analyst.
 

There is an exciting paradigm shift happening within the information systems (IS) field. This means a new breed of information systems is emerging as are new approaches for developing them. The good news is that business analysts may be more critical to the new paradigm than to past ones. 

Now that you’re prepared to work with executives, I’m sorry to inform you that the tough stuff is about to begin. While preparation and understanding are crucial elements, and speaking executive language further deepens our conversations, the real meat on the dog bone is taking the next step and beginning to develop your relationship and establishing yourself as a trusted advisor.
 

CBM Analyst is a simple and inexpensive way to implement business modeling. Business analysts may also choose to upgrade their business modeling solution to No Magic’s Cameo Business Modeler Plugin. The No Magic professional services team is ready to assist you in building and deploying a consistent business modeling solution.

As businesses acknowledge the value of business analysis – the result of the absolute necessity to drive innovation through projects – they are struggling to figure out three things: (1) What are the characteristics of their current BA workforce, and how capable does their BA team need to be?  (2) What is needed to build a mature BA Practice?  (3) How are we going to get there?

Business value is a new indicator for project success. Huh? You may be wondering what ever happened to the good ole scope, schedule, and budget. They are still there and measured, but what the 2012 trends have been pointing to is that a project completed within scope, schedule, and budget and not be successful.

In writing a business requirements document (BRD), the business analyst needs to document who can access the solution (assuming software) and what data can be created, updated, read, and deleted (CRUD). In other words, a security model that a security analyst can build access profiles with the appropriate privileges.  This article provides the business analyst a method for documenting a security model in the BRD based on information extracted from Use Case and Class models

Business process models are intuitive. That’s why people like them. They provide management blueprints for coordinating repetitive work. But are they sufficient for creating an optimal business solution for a business challenge? No. This discussion brings into focus some of their blind spots and what you can do to address them successfully.
 

Working on a new application? You never really know how it will go over until it rolls out. No matter how detailed a wireframe may be, no one can completely picture it in action until they experience the real thing—hours of detailed coding and all. With Prototyper 4.6, your wireframe prototypes look, feel, and behave just like your final application, giving stakeholders and potential users the full experience of the application before any coding even begins.

In this four part series, I will give you the confidence and motivation you need to make a difference; a difference that will allow you to “Bark with the Big Dogs.” What I’m about to share is tried, tested and true. There are no gimmicks. Before you read on, ask yourself this: “Am I willing to try something different?”

I was recently working with a client who said that the life of a BA in his organization is complicated, primarily because very few people really understand what Business Analysts (BAs) do. I have felt for a very long time that perhaps our most compelling challenge is to change the organizational view of our role as primarily “requirements collectors” and to help stakeholders see the true value that business analysis brings to the enterprise.

While many organizations have already adopted The Decision Model, others are actively exploring how it may improve or totally replace their current business rules approaches. The latter are asking the critical question:  How is The Decision Model different from what we are doing and why are these differences important?
 

Many run into the problem of differentiating between a systems analyst and a business analyst. The differences in some organizations do not exist. In other companies, the comparison is almost an insult. Depending on the business or corporation, there are many differences. The job title is not the only thing with which to compare these two separate roles. The problem occurs when the title is not so conclusive. The business systems analyst or the systems business analyst can actually be one or the other or both. Job description is the only way to tell when this happens. There are differences, though.

Author: Tony de Bree

I learned this in a virtual meeting where about 10 stakeholders were invited to give input to a mock-up created by our project. They were all subject matter experts within the area, and had earlier provided some input on an individual basis. I walked through the whole thing, and what happened? There were no comments or suggestions. I couldn't believe it. I know that subject matter experts always have an opinion.