In-Depth
The voice of the customer
- By Ellen Gottesdiener
- June 5, 2001
Patricia Cowall-Hanover has found that a focus on use cases and explicitly
stated business rules provides a tool that systems and business people can understand. As an associate regulatory
consultant for a new regulatory system at Indianapolis-based pharmaceutical giant Eli Lilly and Company, Cowall-Hanover
advocates the use of natural language. "We developed requirements in text format, rather than IT diagrams,
even though it took time to get the terminology simple enough, and to develop common definitions and terms."
The combination of use cases and business rules works to cut to the core of the requirements. "In other systems
efforts, business and IT would start by simply brainstorming requirements. This approach helped us think about
what we needed the system to do and the business process, [and then helped us] figure out what a requirement really
is," she said. Admittedly, this approach requires more up-front work. "It's tough. At the beginning we
have to spend a lot of time on this, but from experience, it saves time because the systems people will get us
closer to what we really want," noted Cowall-Hanover.
Using a facilitated workshop to elicit and verify use cases and business rules helped crystallize what was important.
"You need a good facilitator to help both business and IT focus on the right things," she said. The team
developed use cases, low-fidelity prototypes of the Web-based interface, text business rules, use case flow diagrams
and statechart diagrams. These were incorporated into the requirements document that, according to Cowall-Hanover,
is "like a bible for our project."
She recommends a staged approach: "The first
requirements need to be at a high level, such as the overall purpose of the application [for example, what basic
business processes and data needs to be managed]. Then determine some basic rules. Next, conduct additional [workshop]
sessions and get to the detailed processes and rules, like constraints. Do it in stages. You recognize the need
for detailed rules as you develop the use cases."
As to the value of capturing business rules, Cowall-Hanover indicated that changes to the system tend to result
from changes in the business rules. "We could be implementing a rule that is too restrictive or may need to
be more restrictive. As we develop system requirements, we try to determine all the scenarios. But we are developing
a global system and it's hard to identify and accommodate everyone's business practices," she said. "Once
we gain additional perspectives from our global users, we uncover the need for more or different business rules.
So the rules will evolve over time and, consequently, we need to change the system requirements."
Di Wang, a business integrator on the IT side of the Eli Lilly project, found that use cases and business rules
are the source for both the test design and detail test scripts. "We matched each business rule to a test.
Each use case had separate test cases that we tested to, both positive and negative. I would advocate doing this
test design and scripting as part of requirements," suggested Wang.
Extending the functional requirements with natural language business rules has aided developers. "Our requirements
document is 82 pages and our design document is 80 pages. The developers and testing people could more quickly
understand all of this because the business rules explained things," noted Wang. "They were able to read
them and say 'Oh, that's why you model that way.' It is a way for everyone to speak the same language."
In future projects, Wang plans to formalize the business rules to ensure they are atomic and can more easily map
to the other models used on the project. "Sometimes multiple rules were embedded in one business rule and
they might sometimes be open to interpretation," Wang said. Wang noted that since it takes some technical
writing skills to write business rules clearly and consistently, a more structured English format would be useful.
--Ellen Gottesdiener