If you hear that someone doesn't have "both oars in the water," you know he's out of control, he doesn't "get it," or he's going in circles. Why? To move forward in a rowboat, you need both oars in the water to steer and to gain speed. In this week's column, Mary Gorman explains how this concept applies to modeling requirements.
Imagine how the "both oars in the water" applies to modeling requirements. To gain velocity with requirements analysis--and control of your process--you need to row with two oars in the water. Documenting behavioral requirements (through use cases or stories) might get your boat under way, but you'll lose direction and speed without both "oars"--your data and your business rules.
Let's explore how business rules and data provide the oars for your requirements elicitation and analysis. We'll start with a user story: "As a customer, I want to pay for my purchase using a gift card."
Out to Launch
First, look at business rules. Requirements are full of nouns (the terms that represent a person, place, thing, or concept). By defining each term in our sample story--"customer," "purchase," and "gift card"--you are actually specifying business rules. Think about it. Each of your stakeholders probably defines "customer," "purchase," and "gift card" in her own way. By defining these terms from the organization's point of view, you help everyone understand what the terms mean and how to use them consistently throughout the life of the project and product.
Our story also implies some fact rules. We need to ask our business experts whether the following statements are true: A purchase is paid by a gift card and (the converse) a gift card pays for a purchase. These fact rules specify a relationship between two terms and may be visualized on a data model, a.k.a. a fact model or entity-relationship diagram.
While you're building a shared vocabulary of business terms, imagine grabbing one oar which we'll call the data oar. For each term, consider whether you need to capture business data. Facts about the gift card might include the date it was purchased and its face amount. These attributes can be added to the data model and captured in the project's data dictionary (more about that later).
There is a great resource on business rules, The Business Rules Manifesto, which reminds us that "Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts."
In the Deep Blue Sea
Let's pull harder on the other oar, our rules oar. Consider these types of rules: constraints and derivations. When a customer is paying for a purchase using a gift card, what if the total amount of the purchase is greater than the gift card's balance? Can the customer pay the balance in cash or with one or more credit cards? As you clarify these rules you'll uncover and analyze related data requirements.
We hear that a purchase sometimes is paid by one or more gift cards. The "sometimes" implies that there must be a story about paying for a purchase by means other than a gift card. And the fact that a gift card sometimes pays for one or more purchases leads us to ask what happens if a gift card is never used? Is there a story about that?
Rough Water
In another conversation with the business expert, we learn that a gift card must be activated before it can be used to pay for a purchase. Whoa, hang on! We're hearing a number of other views of the gift card. The water is getting choppy!
To analyze the states of the gift card, we can dip into our user requirements toolkit and fish out a state diagram. This diagram is a powerful tool used to understand the possible lifecycle states of the gift card (purchased, activated, expired, etc.) as well as the events and stories that move it through its states. Rest assured, building a state diagram will uncover more data requirements, such as the attributes "date activated" and "date expired." You'll also learn additional business rules appropriate for each state. For example, when a gift card expires, what rules must be applied to any remaining balance? Now you have both oars slicing through the water!
A quick note about the data dictionary: This repository of data attributes can include rules specific to each attribute. For example, the "gift card status" attribute has valid values of purchased, activated, and expired. The data dictionary may also reference business rule statements that constrain an attribute or business rules that state how to derive the value of an attribute.
Going Solo, or Working as a Team?
As you've seen, using both oars in combination provides significant value. That's true whether you're rowing solo or working as a team. On a small project, you can model data and rules with one analyst covering all models. On large projects, I've seen the team allocate rules and data among specific people, such as a data administrator, business analyst, rule analyst, process modeler, or business expert. Each offers specific skills to support their shared responsibility of delivering a complete set of requirements. That's fine, as long as the rowers keep the two oars--data and rules--moving in sync.
Better Together
Avoid unproductive requirements, which I call "circling." Elicit and analyze the behavior, business rules, and data in tandem, and you'll deliver comprehensive and integrated requirements faster.
Further Reading
- Business Rules Group and Business Rules Manifesto.
- The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements, by Ellen Gottesdiener. Reference for details on leveraging the User Requirements roadmap and associated models.
