Death of a requirment
Death of a requirement
Shocked? How can our dear requirements die?
Requirements are very dear to business analysts. They provide us 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 project is completed. Many confuse between requirements life cycle, business analysis life cycle, project life cycle and solution life cycle.
It is imperative for us to distinguish between all these life cycle. Each life cycle has distinct focus and utility. Often they overlap with each other, but they are separate distinct entities.
Let me describe these 4 life cycles
|Requirements life cycle||To track requirements from origination till retirement||Once identified by a stakeholder or a system or a document||When the requirement loses relevance due to changing business needs such as regulatory changes or business changes|
|Business analysis life cycle||To develop requirements for an initiative||A need identified||Once requirements are fully developed|
|Project life cycle||To track a project||Once approved by sponsor||Deliverables successfully deployed|
|Solution life cycle||Track development / procurement of a solution till its retirement||Solution approach and solution finalized||Retired from live systems|
Now let’s understand the concepts using my organization’s journey so far.
We started Adaptive Processes 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 Processes had accounting requirement at the very same time it had its first financial transaction. This is where requirements life cycle began.
Our solution of managing accounting using an excel workbook took birth when we invoiced our first customer.
Now Adaptive Processes grew bigger and in 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 certain revenue number.
We started a simple business analysis exercise to identify the solution to our problem. We had 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 right accounting partner to outsource our accounting activities. That was 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 dis-continued. That’s end of life for our home grown accounting system.
But the business need for accounting continues. That does not die. The need for accounting for Adaptive Processes will exist as long as Adaptive exists as an 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, 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 various lifecycles.
24+ years of professional experience inbusiness analysis, software product development, business analysis, ERP implementations, software processes , strategic Change Management Consultancy.
Author of 12 books on Business Analysis and Requirements Engineering