The voice of the customer

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