Requirements for the Easter Bunny

When I was a teenager, I cut grass for the Tooth Fairy. Quite frankly, she was unpleasant to work for, and she was very slow to pay. I resolved to never work for anthropomorphic representations of mythological creatures again.

To my dismay, I found myself rolling off a project a few months ago, and I got my next assignment.

Helping to document IT requirements for the Easter Bunny.

This was something of a surprise to me. I generally don't associate "Easter Bunny" with IT. I normally think about colored eggs and woven baskets.

In reality, the Easter Bunny (EB) runs a complex operation with some fascinating and competing business needs that translate to IT requirements. EB needs to interface with major egg distribution networks, and to be able to coordinate deliver to his Indonesian egg painting factories. His accounting system is messy, since he's apparently paid using covert funds from the CIA. He operates in nearly every time zone, and has a major peak in IT requirements every Spring.

I was brought in to do requirements associated with the next release of the Egg Paint Inventory Control System (EPICS). The problem with EPICS was that EPICS had evolved slowly over a period of years. As an IT system, it was basically a collection of components that had been taped together and had many bandages applied. Generally, when I write requirements associated with a new release of a system, I write it as a delta from the existing system. In fact, this was the model that the EB's IT team had used in the past. The problem was that the original system was never documented, because at the time it was considered to be a relatively simple application that would be going away soon. Unfortunately, the business added a bunch of functionality in the early versions, and EPICS became inextricably linked to the other IT systems. Historically, updates to EPICS didn't go well. Users often reported that updates would add new features, but break old ones. This was clearly a case where writing the requirements as a delta to the existing system was going to be very risky. We needed to document the full system, and then write the changes as a delta.

This was an interesting exercise for me, since I generally write requirements documents in the form of an SRS or BRD. Should I write the documentation for the existing system like a requirements document?

I had to step back and think about the requirements for my document.
1. The current users of the EPICS system needed to be able to review the document for accuracy.
2. There would be elements of design in this document, since it was describing what had actually been done.
3. There needs to be a way to reference sections of the document at a high level of granularity, so that the "delta" documents are able to reference which sections are changing.

The document that I ultimately produced was centered around Use Cases, but with more details of the system interaction than I might normally use when producing a requirements document. Steps taken by the System tended to be more explicit. For example, rather than "System checks red paint levels", we'd write "System sends a signal to the troll guarding the paint. The troll measures the level of red paint remaining, and signals the elves manning the EPICS system." Lots of design built into that statement, but it helps us to understand what it is that the system is currently doing. Each of the use cases was numbered so that it would be easy to reference them in delta documents. For portions of the document that weren't use cases, we carefully numbered each paragraph.

Once the system was documented, the delta was actually fairly easy to write.

This project reminded me why I like working as a requirements analyst so much. I get exposure to business processes that I've never thought about before. Six months ago, I would never have connected the Easter Bunny to the Egg Cartels or to Indonesian sweat shops. Now I'm bugging our sales guys to get me a gig at the north pole...