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.
Read the rest of the article …
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.
These articles are written primarily for business analysts and product managers. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!
Latest Articles
Comments on all Articles