Business Process Model and Notation (BPMN) is already acknowledged as a de facto standard for business process modeling. However, it still takes a long journey to increase the maturity of business process modeling practice. In practice most business analysts do a lot of mistakes that make their BPMN models over complex, difficult to understand and maintain.

This means that The Decision Model is at the center of a serious shift in the way we perceive and manage the business rule and logic dimension. So, this month’s column highlights the shift, starting with 2009 and ending with 2012. At its core are the seven observations indicating that a shift is happening. More important, each observation contains corresponding article links to related Modern Analyst articles.

In my view, the most powerful quality practice available to the software industry today is inspection of requirements documentation. A peer review is an activity in which someone other than the author of a work product examines that product to find defects and improvement opportunities.

If I had to choose—not that I want to make such a choice—but if I had to choose, I’d take a scribe over a facilitator. I can almost hear a chorus of “You gotta be kidding!” No, I’m quite serious. How many meetings and workshops have we all attended where there was a weak facilitator or none at all?

There are capabilities necessary to implement Smart Systems, where business people manage business logic in a business-like and agile fashion, with highest integrity, and deployable to any and many targets. These are the requirements satisfied by a BDMS, not by a BRMS 

Whether linear or agile development approaches are being used, the Business Analyst needs to have a specific required point in time where the solution being implemented is checked against the original problem before it gets too far downstream.

Adaptability is a word that is not used enough in the context of business analysis and collecting requirements. Though it is used in the project world, “adaptability” is more synonymous with project methodology or project teams as a whole than it is with requirements elicitation or requirements management. Being adaptive to your surroundings is what can save you from the perils of uncertain environments, non-engaged subject matter experts or the dreaded “analysis paralysis” effect.

If a business analyst is to step up to the task of becoming a credible project team leader, she must have an understanding of how teams work and the dynamics of team development. Team leaders cultivate specialized skills that are used to build and maintain high-performing teams and spur creativity and innovation. Traditional managers and technical leads cannot necessarily become effective team leaders without the appropriate mindset, training, and coaching.

There is a direct link between business rules and business events – one not fully understood by many Business Analysts. What is that link and why is it so important? This discussion raises a very big question about how your current requirements approach addresses business rules. Can you answer that question confidently? Here is what every Business Analyst should know about business rules and business events.

A great approach under the right circumstances, agile is not a universal solution for successfully completing a software project. Some projects are simply not compatible with most agile practices. For such projects, NANW has been driving results in terms of project and rework costs, integration time, and improved quality as reported by customers.

The language of systems is no different; No, it is not C++, Java, COBOL, etc., but rather simple English (or whatever your native language happens to be). In the past I have gone into length about the differences between Systems and Software, the two are simply not synonymous. Whereas systems include business processes implemented by human beings, computers and other office equipment, software is simply instructions for the computer to follow. Systems are for people who must also take an active role in its execution. In fact, systems will fail more for the lack of people procedures than they will for well-written computer software.

As trusted advisors, business analysts must never forget the value of collaborating with stakeholders at all levels of an organization. The world of Agile has demonstrated this very point and is doing so with great positive impact and effect on the bottom line of many projects. When initiatives and projects are not collaborative, there is always a failing point within the stakeholder community.

Most of the projects inevitably struggle at some point or the other if the scope is not defined properly. The right note to start a project is to have a clear Project and Solution/Product scope at hand. It is very critical for a Business Analyst to clearly understand and define the Solution Scope in black and white before even going into the Requirement Elicitation phase. This article focuses primarily on key aspects of understanding and defining Solution Scope in traditional methodologies.  

In this article, I’ll show you how you can apply three specific business analysis elicitation or requirements gathering techniques as part of facilitating all or part of a meeting even if you aren’t in a business analysis role.

How do business rules relate to business processes? How do business rules support business agility and migration to new business platforms? What does re-use of business rules really mean? This column explains the deep insights offered by the Business Rules Manifesto on these questions. Already read it?