A Prototype is Worth a Thousand Lines of Code

Posted on:

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 […]

Simple Agile Model Example

Posted on:

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.

The Impact of a Hidden Decision

Posted on:

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?

Hidden Business Rule Example

Posted on:

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 […]

Business Architecture, Rules, and Requirements

Posted on:

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 […]

Glossary of Terms

Posted on:

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 […]

Global Processes and Business Rules

Posted on:

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 […]

Why Separate Rules from Requirements

Posted on:

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 […]