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-
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 the sponsor
Deliverables successfully deployed
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 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.
Ann heads the global sales and marketing role at Adaptive US Inc. She is also a coach and mentor to thousands of BAs in their pursuit of achieving IIBA certifications. Her mission is to help business analysts to start and build a successful professional career. She is a regular author, blogger on various Business analysis, management, and technology-related topics in leading tech sites and journals.