Elicitation Techniques for Processes, Rules, and Requirements

hammer and egg

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.

elicitation technique comparison table

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.

Post to Twitter Post to Facebook

This article was published on Thursday, September 13th, 2007 at 10:17 pm and is filed under Business Analysis, Business Process Modeling, Business Rules, Product Management, Requirements, Requirements gathering.
You can leave a comment on this post

One Comment

  1. Great Article.
    Separation between Process, Requirements & Rules and why they change is really good.

4 Trackbacks

  1. By links for 2007-09-15 « D e j a m e S e r on September 15, 2007 at 9:21 am

    [...] Elicitation Techniques for Processes, Rules, and Requirements | Tyner Blain (tags: requirements) [...]

  2. [...] Consider managing rules and requirements outside a BRMS using requirements management software or as discussed here. Also consider the functionality of requirements management software (e.g., Rational) or BRMS that is not provided by an unassisted word processor or spreadsheet (e.g., as Ruleburst still presents here). [1] i.e., any form of waterfall development (e.g., iterative or spiral) where implementation is required after rules or requirements are captured or modified [2] Achieving ROI with Rational Requirements Management Tools [3]Note that the limitations of BRMS discussed here are even worse for Complex Event Processing vendors since ease of authoring is much less advanced in the CEP market. [4] Classification and Representation of Business Rules [5] Methods for Managing Business Rules with Haley Authority [6] A roadmap for the elicitation of business rules in information systems projects [7] Elicitation Techniques for Processes, Rules, and Requirements [8] The Unified Process Inception Phase: Best Practices in Implementing the UP (page 99 and here) [9] Blinded by Requirements – Don’t Miss those Business Rules [10] 1 MORE thing CIOs should know about requirements [11] ISO 9126 re Functionality, Reliability, Usability, Efficiency, Maintainability, and Portability [12] ISO 9126 plus Flexibility, Clarity, Resilience, Generality, Reusability and Economy [13] Functional Requirements and Use Cases [14] Requirements vs Process and Rules [15] Requirements, business process and business rules [16]OMG’s Business Motivation Model (BMM). [17] as in the Web Ontology Language (OWL) [18]Note that OWL and SBVR address some of these issues but not vocabulary. Ruleburst does not address the issues discussed here. [19]OMG’s Semantics of Business Vocabulary and Rules (SBVR)> [...]

  3. By Élicitation? | Michel Boustani on October 7, 2013 at 8:49 pm

    [...] Crédits d’image : Tyner Blain [...]

  4. [...] on 01/06/2014) Elicitation Techniques for Processes, Rules, and Requirements – http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/  (Retrieved on 01/06/2014) Analytic Hierarchy Process [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>