A picture is worth a thousand words. Â A prototype is worth a thousand lines of code. Â Two key elements of product management – and of agile development are elicitation and feedback. Â Low fidelity artifacts can significantly improve both. Â Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.
Continue reading A Prototype is Worth a Thousand Lines of Code
A picture is worth a thousand words.Â Agile values working software over comprehensive documentation, and it values customer collaboration over contract negotiation.Â With that in mind, how much is a picture of a model worth?Â Check out a simple example, how it helped, and what we didn’t do.
Continue reading Simple Agile Model Example
Business rules are often hidden in processes as hidden decisions.Â Once you discover that hidden decision, how do you communicate the impact of exposing and managing the decision?
Continue reading The Impact of a Hidden Decision
A business process is not just a sequence of steps.Â A business process is a series of decisions and actions.Â Some decisions are obvious and can be actively managed.Â Some decisions are hidden, and until you discover them, you can’t manage or improve them.Â Here is a real-world example of the discovery of a hidden enterprise decision.
Continue reading Hidden Business Rule Example
We know to treat business rules and business requirements differently. One example – treat external government regulations as rules (because they are less subject to change than requirements). When you have multiple systems in an architecture, while “rules” makes sense for one system, “requirements” make sense for another. What do you do?
Continue reading Business Architecture, Rules, and Requirements
Some books on how to write and manage requirements mention using a glossary. Most books on requirements don’t go into enough detail about either the importance of a glossary of terms, or the precise use of the glossary of terms. Or if they do, they under-emphasize the benefits of a well-defined glossary of terms. Walking a day in the moccasins of a business rules analyst helps us all appreciate the importance of a well-managed glossary of terms.
Continue reading Glossary of Terms
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.
Continue reading Global Processes and Business Rules
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?
Continue reading Elicitation Techniques for Processes, Rules, and Requirements
Separation of business rules from requirements is a good thing. Not because of semantic distinctions, but because it allows you to write better software, write it faster, and change it more easily. This article is a response to an excellent comment on our recent article about hidden business rules. Thanks for challenging the idea – it either eliminates it from discourse or makes it stronger, and we all benefit. Here’s an attempt to make it stronger.
Continue reading Why Separate Rules from Requirements
The 10th International Business Rules Forum is coming up fast in October 2007. Scott Sehlhorst and James Taylor will be presenting Getting it Right. Rules and Requirements in Software on Thursday at the conference. The articles on rules and requirements that he and I have been publishing on our blogs for the last few months are leading to this presentation. The IBRF has graciously offered a 10% registration discount code to readers of Tyner Blain. Read on to get it.
Continue reading 10th International Business Rules Forum