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?
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.