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
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 […]
Flashback: A Year Ago This Week on Tyner Blain [2006-10-20]
A look back at the best from a year ago.
Why Separate Rules from 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 […]
Business Rules Hidden in Use Cases
Business rules are not requirements. Yet they are often gathered at the same time as requirements, from the same sources, by the same business analysts. And unfortunately, often documented in the same artifacts. In this article we look at some of the ways that business rules are commonly hidden inside […]
Separating Business Rules From Requirements Increases Agility
We’ve written in the past about why it is important to gather and manage requirements. In short, you avoid some costly mistakes, and fix others before they become too expensive. We’ve also started exploring how business requirements and business rules live and play together. But why should we bother to […]
Business Rules And Requirements – Early Thoughts
We had a great interview with James Taylor a couple weeks ago, where we talked about his new book, Smart (Enough) Systems, co-authored with Neil Raden. James is an expert on decision management systems. I spent the late 1990s working on “rules-centric” software systems that allowed us to isolate rules […]
How To Use UML Statechart Substates
UML Statecharts can be very effective modeling tools for describing systems and software requirements. They provide a clear framework for identifying business rules. The same business rules often apply to multiple states – defining a commonality for those states. There is an element called a substate in UML statecharts that can be used to make it more obvious that a particular business rule applies to multiple states.
UML Statecharts and Documenting Business Rules
In yesterday’s article we compared use cases and UML statecharts as tools for discovering business rules. James Taylor asked a question about how we would document those rules, and then followed up my comment response with an article about business rules and RUP. In this article we move the conversation slightly forward – recognizing that we’re slowly entering the ocean of business process management.