Death of Business Requirement- When can they die?

Shocked? How can our dear requirements die?

Requirements are very dear to business analysts. They provide us with our reason for existence. Should they die? When can they die?

These are many interesting questions for all business analysts. Sometimes I find very strange (and absolutely wrong answers from many learned trainers) who say requirements die when a project is completed. Many confuse between requirements life cycle, business analysis life cycle, project lifecycle, and solution lifecycle.

It is imperative for us to distinguish between all these life cycles. Each life cycle has a distinct focus and utility. Often they overlap with each other, but they are separate distinct entities.

Let me describe these 4 life cycles-

Now let’s understand the concepts using my organization’s journey so far.

We started Adaptive US as a 2 partners company. Initially, Adaptive had a couple of clients. We invoiced customers using an excel workbook and tracked payments in a simple workbook.

Adaptive US had accounting requirement at the very same time it had its first financial transaction. This is where the requirements lifecycle began.

Our solution to managing accounting using an excel workbook took birth when we invoiced our first customer.

Now Adaptive US grew bigger and in the next 10 years, and we were invoicing and collecting 500+ transactions a month. Transaction complexity increased as Adaptive also started exporting and importing.

We found it difficult to manage accounting in excel.  Legal requirements also increased as our books were to be audited as it crossed a certain revenue number.

We started a simple business analysis exercise to identify the solution to our problem. We had an option of hiring an accountant, purchase an accounting software and do accounting in-house. But this is quite expensive and at the same time, we weren’t sure of the capabilities to meet all regulatory aspects. This would have taken considerable management time as well.

So we looked for an accounting partner with a good solution for an accounting system.

We had a short project to choose the right accounting partner to outsource our accounting activities. That was the beginning of a short project. Once we found a suitable accounting partner, the project got over. Our business analysis exercise was also over with the project.

Once we outsourced accounting, the macro-enabled excel that we built was discontinued. That’s the end of life for our homegrown accounting system.

But the business need for accounting continues. That does not die. The need for accounting for Adaptive US will exist as long as Adaptive exists as a commercial organization.

Now this year, our government decided to unify 5 individual taxes into 1 tax. So the requirements for the 5 taxes die. At the same time, the requirement for the new tax takes birth. Our partner’s systems need to change as the new regulation sets in.

Hope with this example, we are able to distinguish between various life cycles.

Suggested readings-

 Why every BA must maintain a personal project retrospective?

 Should BAs encourage requirements churn?