Archive of Business Process Modeling Articles

Traditional requirements happen after a multi-system architecture has been defined.

But what about the requirements that feed into that architecture? The requirements that drive the enterprise architecture decisions in the first place? We haven’t talked about those before.

We’ve written before about the importance of separating rules from requirements, particularly in use cases. We wrote that with the goal in mind of reducing the costs of system maintenance. Low-level rules like decision, calculation and inference rules tend to change frequently – and independently of other requirements. So a documentation approach that separates these rules from requirements can both reduce implementation costs (by encouraging separated implementation) and reduce the time required to manage and approve changes.

There are also benefits to abstracting high-level, or procedural rules, when dealing with global business requirements.

Each elicitation technique we have in our toolbox is a tool. But not every elicitation job is the same. If we have a hammer, we might be working with nails, or screws, or even an egg. In our analysis, we have to develop a deep understanding of our customer’s business(es). And that means we need to understand not only the goals and ROI, but the processes, rules, and requirements. Which is the right tool for each job?

We created a series of Visio 2003 stencils last September to support our series of articles on BPMN. Anthony Britton has created a Visio 2002 version of the stencils for people who do not have Visio 2003 (or Visio 2007).

Should you use use cases or process flow diagrams to document business requirements? At some level, they both document the same thing, they just document it differently. The best requirements will come from doing both – but what if you are forced to choose one? What are the tradeoffs between use cases and process flows? In this article we look at the documentation of failure handling.

Outsourcing is gaining momentum not only as a way to reduce costs, but as a way to create global teams. This trend is driving an increase in demand for business analysts. The change in perspective is driving companies to think about how they manage their business in new ways, and driving interest in new tools for business analysts to achieve these goals.

What is the difference between a business rule and a business requirement? Does the difference matter? A business requirement is something that is multi-customer, and a business rule represents a single customer’s approach to meeting that requirement. Product managers and analysts care about both, but product managers emphasize requirements, and analysts focus more on rules.

In support of our series of BPMN Tutorial posts, we’ve created a series of Visio 2003 stencils (*.vss) and a template (BPMN_Template.vst) of BPMN symbols. Download this free resource today courtesy of Tyner Blain!

All process improvements are not created equal. How should we select which processes (or process steps) to improve? How do we approach this for a really large migration project? Start with understanding the potential for improvement and then narrow it down from there.

Sandy, of Column 2 fame, is blogging the Process 2006 convention “live” as it goes. Subscribe to her blog to stay on top of things. For now, here are the articles she’s posted from day 1.