Follow us...

Notes from a Requirementalist

Ray Engelberg, Business Analyst, UPS

New words are constantly making their way into the English language: Bling. BromanceD'oh

Here’s another one: Requirementalist.  

This is a word that was coined during a team-building exercise among my fellow BAs. It refers to a BA who, upon being confronted with multiple, ambiguous requirements, must analyze what is being articulated and determine what is actually meant. This effort calls for insight which goes beyond the intuitive and borders on the extra-sensory, even (dare I say it?) psychic.

This is where the mentalist part of requirementalist comes into play. Here are some examples.

Multiplying Emails

Our BA team was working on a project where the stakeholders expressed the need for a verification email stating an offer to be provided to the Customer. In further discussion we learned that Customers might or might not accept the offer immediately—potentially, they might get back to the business later.  

This begged the question: was there a requirement for a second email type, one that was forwarded upon acceptance? The stakeholders agreed that the answer was “yes.”

Which begged a further question: if the Customer accepted the offer, then decided to cancel, was there a need for a third email type? Once again, the answer was “yes.”

Lastly, the BAs needed to determine rules, not explicitly stated, for generating emails.  Here’s what we came up with: 1) the initial email summarizing the offer will have a unique identifying number, 2) a suffix will be added to this number once the offer is accepted and the revised number will appear on the acceptance and cancellation emails, and 3) if the Customer chooses to modify the terms of the offer, an additional acceptance email will be generated.

To summarize: the only requirement that the stakeholders actually verbalized was the initial email containing the offer. After further delving into the realm of the unsaid, we determined that this single requirement was really multiple requirements and rules. 

Minimized Costs versus Customer Experience

Everyone hates those telephone voice segments which seem to go on and on (“For option ABC, press 1…” ad nauseum). For this reason, it’s a standing policy in our business to keep these to a minimum.  

Until recently, our telephone applications stated an approximate cost for one of our services.  As the Customer provided additional information, that cost might be expected to change, up or down. In most cases, the actual cost did not vary significantly from the cost initially provided.
 
Over time, more and more functionality was added to the telephone application and the need to factor in additional costs was identified. There might now be a drastic difference between the stated cost and the actual cost billed to the Customer at a later date. Did this difference call for a requirement to add a voice segment stating the revised cost to the Customer?

The stakeholders’ initial response was “no.” Voice segments were provided by an outside vendor, which meant extra cost, man-hours, and test time in addition to keeping the Customer on the phone longer than necessary.

Although the stakeholders’ response was consistent with the policy of keeping voice segments to a minimum, the BA team noted a concern which conflicted with that policy. A Customer who originally heard a cost estimate of $X could later be billed for $X plus $Y, thus be taken by surprise (and not pleasantly) by the discrepancy. Did the business want to risk this potentially negative Customer experience?

The stakeholders conceded that a positive Customer experience superseded the need to minimize the phone time. They revisited their earlier response and opted to add a new voice segment and absorb the cost.

Credit Card Information

The business was adding a new service and the BA team was reviewing a draft of the data elements. For each data element, a description was provided along with appropriate attributes and whether it was Required, Optional, or Conditional.  

Three of the data elements were Credit Card Number, Card Type (i.e. Visa, MasterCard), and Expiration Date. Each of these was identified as Optional. The stakeholders’ rationale was that not all Customers would be paying for the service via Credit Card; therefore these fields should be Optional.

Our BA team evaluated the needs of the business and agreed that Credit Card Number was indeed Optional. We challenged the Optional attribute for Card Type and Expiration Date, however. If the Credit Card Number was populated, these data elements must be populated as well, rendering these data elements Conditional. If they were left Optional, the business ran the risk of having a Customer pay with an invalid or expired credit card.

The stakeholders confirmed the requirements to make the fields Conditional and the appropriate Business Rules were documented.

Conclusion

Stakeholders possess considerable knowledge of their domains which they are ready to share. They also, however, have knowledge they don’t know they have or knowledge that’s so second-nature that they don’t realize the need to share it with team members not familiar with their domains. It is from these hidden wellsprings of knowledge that additional requirements emerge. To ascertain these, a BA needs not only the business acumen of Peter Drucker, the statesmanship of Winston Churchill, and the deductive talents of Sherlock Holmes, but the clairvoyant capabilities of Carnac the Magnificent.