The Top 10 Trends in Business Analysis for 2016 examines the evolving ways in which BA practitioners can help organizations realize better business value and the shifts needed within the BA discipline to achieve it. The 2016 trends highlight BAs evolution from “order taker and liaison” between stakeholders to an increased focus on being an “agent of change”, and communicating and collaborating about much more than requirements.

Business Requirements are central to Software Development Offshoring relationship. Requirements are not hard objects that can be put across as formulas or equations. Irrespective of the artifacts used in requirements communication, requirements remain soft objects subject to various interpretations that may leave many voids for assumptions.

The purpose of this article is to investigate the challenges of requirements communication in Software Development projects.

It’s always the requirements fault! Whenever anything goes wrong with a software development project the requirements tend to be the scapegoat. It is a fact of life as a BA that at some point the requirements you write will be wrongly blamed for a mistake in the product. In reality, any oversight in the product is the responsibility of the entire development team. So what can the BA do to ensure they are not the convenient scapegoat for an issue with the product?

Customer journey mapping is a great way to understand your customer intimately to provide insights into providing targeted customer experience that empower the customer positively to drive better business outcomes.  This technique places the customer first with a deep emotional understanding, then looks backwards toward the experiences provided by the operating model, thus enabling good aspects to be reinforced and negative ones to be managed. It provides a complete 360 end to end experience of the customer to be realized driving customer insights, allowing more blue sky approaches to offsetting emotional deficits...

This article discusses a tool for documenting, categorizing, ranking and decomposing various types of requirements (business/user and solution).  The business analyst (BA) can use this tool to capture high-level business and user requirements and then decompose them into solution requirements. In fact, the tool can be used multiple times and results strung together to provide forward and backward traceability of requirements through specification and test cases. 

Despite of all the extensive literature available on Requirements Analysis, it is hard to find one which proposes an established framework on how to use this tool in general sense of application. However, let’s try to map a generic algorithm that can be leveraged for suitable circumstances since every problem or situation is different from the other. We need to calibrate our analytic skills such that a general algorithm can be applied suitably depending on the situation(s).

Developers complain that customers don’t know what they want. At the same time, customers complain about having to explain the obvious. Many projects can get stuck in this type of behavior.

Fortunately, there is a loophole. Many of the problems that business people find don’t actually require a fully working application. Often, a simple “picture” (aka mockup) is enough.

The scenario is simple: You’ve been tasked to determine the requirements for a new project. You’ve done your homework by reviewing existing documentation. And, now, you’ve arranged to have a meeting with a Subject Matter Expert (SME).

So, where does one begin on this path to enlightenment? When you talk to the SME for the first time, do you start by outlining everything that you think you’ve learned already?