Sure, you put a lot of time into creating a prototype, a mockup, screenshot, or wireframe (are there any other names for the user interface drawing I’ve missed?). You may have drawn it on a whiteboard, in VISIO, or even used a requirements tool to create it. At the end of the day, no matter how much time you spend on it, it’s nothing more than a picture. And those of you who have worked in IT know developers cannot code and create a solution solely from a picture. 

As Business Analysts, we are involved in requirements development and management day in and day out with most of the time spent on eliciting, analyzing and specifying business and software requirements for multiple projects. We follow or adopt multiple frameworks, approaches and tools that help us to successfully gather and analyze requirements. Having done all these things to ensure the success of the projects, we still end up in a few projects wherein we have “missed” few requirements.

An operational business decision has structure that you can’t capture using business process models, use cases, or similar techniques. If you fail to delineate that structure, you completely miss a core part of what makes business processes smart. The structure of a decision can be diagrammed in top-down, business-friendly fashion using a Question Chart (Q-Chart™ for short).

But what about user experience or interaction designers? Does every software project truly need a UX/UI specialist (or team of specialists)? Or could this aspect of the solution be taken care by the collaboration between the BA and the development team?

Unlike decision rules, behavioral rules do not pertain directly to determining the best or most appropriate answer (outcome) among alternatives... Three simple but typical examples in article illustrate. Avoid force-fitting a decision-oriented approach to every business rule problem. It simply doesn’t work!

As the Agile movement continues to gain momentum and managing projects using Agile methods becomes more and more prolific, project professionals must become more savvy in their use of Agile methods. While the techniques and processes associated with Agile are different than those associated with Waterfall, many innovative project teams are incorporating non-Agile techniques into the Agile environment, with great success.

Business analysts need to understand their role on a project. Please note I use the word 'role' and not 'job' or 'the work we do'. As business analysts, our role is to deliver business value. If you do not have a clear definition of what that business value is, how can you expect to deliver it? “Improve the customer experience.” Where is the business value in that? And how do you measure it? When faced with objectives that are poorly defined, the business analyst is allowed to become like that irritating toddler, constantly asking “why? why? why? why? why?”.

As a business analyst you are the all-important glue between the business and technology. Your skills range from various kinds of modeling to gathering of high-level as well as detailed robust requirements. Sometimes you operate in traditional systems development and sometimes within agile approaches. A business analyst’s responsibilities are wide and deep... What Are the New Opportunities for Business Analysts?

The CEO of a major corporation who was present when I described requirements traceability at a seminar asked, “Why wouldn’t you create a requirements traceability matrix for your strategic business systems?” That’s an excellent question. He clearly saw the value of having that kind of data available to the organization for each of its applications. If you agree with this executive's viewpoint, you might be wondering how to incorporate requirements traceability into your systems development activities in an effective and efficient way.

Recently I saw the movie “42,” based on the true story of Jackie Robinson,who in 1947 bravely fought custom, bigotry, and violent hostility to become the first African American to play major league baseball. His courage came from his inner strength which allowed him to withstand with dignity the cruel behavior from fans, other team managers and players, and at first some of his own teammates.

Many BAs are using the  BABOK which contains information about a Requirements Management process, from identifying organizational situations that give cause to a project, through to starting the requirements gathering process, to delivering a solution to the business or a client. TOGAF 9, from an Enterprise Architecture viewpoint, also provides some techniques to gather requirements to equally deliver business solutions. This paper illustrates the two processes, defines the mapping between the two approaches and identifies gaps in each.

If business analysts are to enable innovation, we must learn to decode the wishes of our customers into requirements that drive toward what the solution must achieve, without specifying how to achieve it. We can do this by formulating our requirements in abstract, technology-neutral descriptions, learning from patent claims how to achieve this difficult balancing act.

The web has opened a flood of learning resources for enterprises. It has reduced costs, extended learning channels and increased learning efficiencies. However, these benefits are only available to businesses that understand the new ways that we are absorbing and spreading information. By incorporating important elements of social curation and automation, Bloomfire remains a step ahead of the curve. It offers the advantages of reduced costs with increased employee engagement and productivity. The solution has created a tool for knowledge sharing and adoption and carved a new vertical of its own.

Business Analysis is the first link in the chain. Unfortunately many times it is also the weakest link. Probably because we have never considered the most important issue: Business Analysis is a people-oriented process. Why then do we behave like engineers with our UML diagrams and so forth? Furthermore, many people believe that Business Analysis is just a matter of describing the business as it is – which is completely wrong: Good Business Analysis is full of insight and is forward looking. The process itself can be meaningful, eye opening and creative.

In this rapidly changing situation, there are great opportunities for business analyst professionals who can propose resourceful modernization solutions at a fraction of the initial development cost.