Successful business analysts have a mixture of many talents -- some more tangible than others – making Business Analysis both an art and a science. This article explores each area (art and science) and the types of skills necessary to be successful.

Has “Agile” killed “Use Cases”? Let us answer this question in this short article. As you may know, “Use Cases” have been a great way to document the detailed “Functional Requirements” of a system.
 

This article describes the Entity Relationship Diagram that allows you to document the structure of a database in terms of persistent entities and the relationships between them.  The Entity-Relationship Diagram (ERD) provides a way of graphically representing the logical relationships between entities in order to create a database schema to persist those entities.

Three questions regarding breaches of business rules should be addressed by Business Analysts: enforcement level, guidance message, and breach response. The goal is context-dependent, pinpoint reaction to breaches in real-time. Addressing breaches intelligently is key to creating friendly, agile, secure business solutions, ones that can evolve rapidly in day-to-day operation.

This article reviews the complexity of the role of the business analyst (BA) facilitator in obtaining a stakeholder agreement (i.e., a consensus or a compromise) on solution features and/or user requirements. The BA facilitator achieves this agreement by maintaining a neutral posture in guiding the stakeholders though a dialogue in a series of meetings.

Before an organization releases a new piece of software or web feature to all of its customers or the general public, it will generally offer a limited audience a chance to test drive the feature and offer their feedback. This is generally known as a Beta launch...

Many BAs wait until their requirements specification is complete before they present it to some reviewers. Busy developers, testers, project managers, and users have difficulty finding the time to scrutinize a large document on short notice. It’s far more effective to review an evolving document incrementally. Give reviewers just a few pages at a time, preferably soon after an elicitation activity.

 It is wise to use whatever techniques we can to discover the 'real' requirements and business rules before embarking on development. We all seem to know that it is cheaper to fix problems earlier rather than later in an IT project. So why do so many of our projects exhibit the same mistakes?

The product owner is an ideal. I have experienced this myself as product owner and business analyst in a scrum team. How many organizations have a job title that can cover the role completely? If not, is your organization ready to change in order to fit the scrum method? The organization I work in is not but it is still possible for the scrum team to have an efficient product owner. In our team, it was decided to adapt the role to fit our organization by establishing a product owner team in which I as business analyst am a member.

 It takes courage to scribe well. In many organizations we encounter pushback related to scribing. We hear lots of reasons why not to scribe. Remarks like those below can discourage us unless we have the courage to educate project and resource managers on why scribes are needed and influence them to assign this important role.

What role should business rules play in procedural languages and enterprise architecture? How do they relate to platform independence and compliance? What about knowledge retention? This column, the last in a series of three, explains the deep insights offered by the Business Rules Manifesto on these questions. Already read it? You may be surprised by what you find here!

This year’s top 10 business analysis trends focus on leveraging the power of requirements at all levels through Agile and business architecture to deliver business value to the organization. We also expect to see business analysts being utilized in more robust ways, forcing them to take on new skills to meet a broader job scope.

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.