Elicitation Techniques for Processes, Rules, and Requirements

Each elicitation technique we have in our toolbox is a tool. But not every elicitation job is the same. If we have a hammer, we might be working with nails, or screws, or even an egg. In our analysis, we have to develop a deep understanding of our customer’s business(es). And that means we need to understand not only the goals and ROI, but the processes, rules, and requirements. Which is the right tool for each job?

Elicitation Techniques

The BABoK (Business Analyst Body of Knowledge) identifies ten different methods of gathering information. That list is a good one for describing the complete tool set that business analysts should have for elicitation. The same techniques are valuable for product managers too.

We wrote about those techniques almost a year ago, from a requirements gathering perspective. Check out that article for more details, but here’s the short list:

1. Brainstorming
2. Document Analysis
3. Focus Group
4. Interface Analysis
5. Interview
6. Observation
7. Prototyping
8. Requirements Workshop
9. Reverse Engineering
10. Survey

Different Views of the Business

Processes, requirements, and rules all represent different elements of how the business works, or how software must work to support the business. The most obvious distinction is one of perspective.
To oversimplify a little, some rules define the regulations and policies that constrain how a business operates. Some rules represent calculations, inferences, or enable actions that provide some precision about the business operates at a greater level of precision.

Processes represent a business design decision by the company. Given a set of goals and constraints (both “rule constraints” and practical ones – resources, costs, market forces, etc), processes are designed to achieve business objectives. They generally manifest as procedural instructions for the business. Note that they should be modeled at a higher level of detail than “open this file, walk down to purchasing…”

Requirements are an articulation of what a tool (in our case, a software product) must do when it is used in one of the business processes. The design of those processes has an impact on the requirements of the software. The rules that constrain the business (and by extension, the processes) must be enforced within the software.

Ultimately, we have to understand all three to create successful software.

Different Drivers of Change

A more subtle difference is in recognizing that processes, rules, and requirements change differently. Each class of artifacts changes for different reasons, on a different time scale.

Policy rules generally change as top-down mandates, or external forces. State or federal regulation changes can affect how a company does business. The Sarbanes-Oxley act has driven massive changes in how companies operate. These are relatively infrequent, but sweeping changes. Their effects cascade through everything the business does (and therefore everything that is required of the tools used to operate the business).

Decision rules generally change as part of feedback loops in processes. Consider the set of rules that an insurance provider uses for determining what premium to charge for a given policy. These rules are so extensive that they are maintained in rate tables, or other complex rules-calculation systems. An insurance company will have a department who’s responsibility is to maximize the profits that come from setting premiums. That means that they will tweak the rules in their rate table on a regular basis – like an ongoing science experiment. Predict, modify, inspect, repeat.

Process changes can happen as a result of policy changes, but more likely, they happen because of business re-engineering. This is the same feedback loop that affects low level rules, but on a grander scale. The big business consulting companies make very good money providing business consulting services. Part of that is strategic guidance, and part of it is process re-engineering. They look for inefficiencies and missed opportunities in processes. The predict the ROI of changing the processes, propose changes (maybe even help manage those changes), and repeat. These larger changes take more time than changing low-level rules.

Requirements articulate how the software must support the given processes, while implementing or enforcing the company’s rules. Requirements can change because of process changes, and policy rules changes. As long as you separate rules from requirements, then changes to low-level rules will not force changes in requirements. And ideally, for volatile rules, will not require you to modify (and test and re-release) your software. Requirements also change because they represent our understanding of the business’ understanding of what they wanted when we gathered them. And the business can change it’s mind, as it gets new data. One of the arguments for iterative development is that people don’t know what they want until you’ve given them what they don’t want. There’s some truth in that.

Effectiveness of Different Techniques

We’ve mentioned before that the same elicitation activities, and people, generally gather process data, rules, and requirements. And that presents one of the challenges in managing them independently. Here’s a table that summarizes the effectiveness of different elicitation techniques for uncovering and defining a business’ processes, rules, and requirements.

Each technique has a row, and is graded Consumer Reports style. Each type of artifact has a column. A full green circle means that the technique is well suited to eliciting that information. A half-filled circle means that you can use that technique to gather the data, but it is not as effective as the full-green-circle techniques. An empty circle means it isn’t impossible, but you should avoid it if you can.

As an example, reverse engineering is ineffective at defining any of the above. Reverse engineering can tell you what you have, but in no way can you assume that what you have is what you need. In fact, if it were, then your customer wouldn’t need to do the new project at all. Reverse engineering is a last resort that we sometimes have to rely on, but you should always treat it as a “starting point” – a baseline to be corrected and validated. It is certainly going to paint an incomplete picture – and often an inaccurate one.

And You?

These effectiveness assessments are based on experiences with dozens of clients in the enterprise software space, over a decade of elicitation. That means they are anecdotal. Thousands of people will read this article [Really. How cool is that?!]. So if you can confirm the above, or even better – correct it and share your experiences, we’ll be able to paint a much better picture. So – join in the discussion and let us all know.