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