A data flow diagram (commonly abbreviated to DFD) shows what information is needed within a process, where it is stored, and how it moves through a system to accomplish an objective. As its name implies, a data flow diagram depicts the flow of data within a system.

Welcome to the new series of articles on the BA as the 21st Century Creative Leader. It was a perfect storm. As we entered the second decade of the 21st century, we found ourselves struggling to adapt. ... It is no coincidence that the business analysis profession is taking hold to address many of the 21st century business challenges.
 

This article proposes a use case best practice technique: Always document decisions separately and explicitly in use case scenarios. This practice assists the business analyst in identifying where alternate and exception paths may be needed.This is similar to how decisions and resulting gateways are documented in Business Process Model and Notation (BPMN).

A business model should include behavioral rules, decision rules, operational business decisions, and operational business events — all as first-class citizens. Understanding their intertwined roles is key to creating top-notch business solutions and business operation systems unmatched in their support for business agility and knowledge retention. This article explains how such true-to-life business models can be created.

I’m pleased to continue to uphold: the unveiling of this year’s top 10 business analysis trends. This year business analysts (BAs) will need not only the balanced portfolio of technical and business skills they have been perfecting, but also a more comprehensive perspective in order to meet the challenging business environment of 2012.

Creating a BA Center of Excellence (BA COE) is a proven method for effectively reaching these goals with a BA team. In addition to improving BA performance in the traditional fields of elicitation and drafting, they aid in improving the other ‘soft’ skills that are becoming increasingly mandatory for a BA to possess.

At some stage in their working life, every business analyst will have some involvement with data modelling. They may need to model how data is (or will be) used or - if they only deal with requirements investigation - then someone else in the team will need to verify that the data to support new functions will be available.

There are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article, expect to spend more time than average developing detailed requirements specifications.

Lean techniques use a process-oriented approach. In non-industrial organizations however, the process is invisible. In order to apply Lean techniques successfully in this environment, the visibility of processes has to be significantly increased. Employees have to learn to look at their organization from a process viewpoint. Furthermore, it is important that the method is applied to all layers of the organization.

Instead of taking for granted that either you find a flavor of agile that will fit the needs of your organization, or you must completely dismiss the use of agile methods, a much more valuable approach is to determine, for each individual project, which agile concepts should be embraced or not.

To remain competitive, it is more important than ever for an organization’s leadership team to use business analysis (BA) practices to execute strategies through innovative solutions. Over the years, business analysis has been rapidly developing as a profession and as a core business practice in many organizations; however, all too often business analysis is still in its foundational stages.

Several conditions make it appropriate to leave the requirements descriptions at a higher level of abstraction. Recognize that these are broad guidelines. The BA should perform a risk-benefit analysis to balance the potential downside of omitting important information against the effort required to include it.

For several decades, software reuse has been a recognized solution to improving efficiency of software development. However, implementing reuse in practice remains challenging and the IT community has little visibility into the state of the practice specifically as it pertains to reusing software requirements. This paper presents the results of a survey conducted in the global IT industry in 2010 and discusses the state of the practice for software requirements reuse.

We have always been fascinated by the exceptional business analysts who can create order out of total chaos. The ones who can ask those great questions, who can figure out what’s important and what’s less so, who can synthesize lots of information, put it all into their magic hat and come out with requirements that make sense to all the stakeholders.

Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed to make the requirements?”