Keep Both Oars in the Water - Tips for Modeling Requirements


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

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.