I am a business/systems analyst thinking that I have been applying the agile methodology for requirements management for quite some time already.

I would like to elaborate on this by giving an example from the last project I have worked on. Client was starting up a new business involving e-money. They had a great vision and their business model was very clear.

First, the solutions architect and I sat down with the client in a couple of workshops to understand their vision and started to build the business domain model in the workshops. Naturally, the client was dumping on us so much information in a totally unstructured way, e.g., talking about system integration then jumping into customer management then accounting practices and hardware requirements or fraud detection mechanisms. So, we managed to put the domain model together, object relationships and the functional architecture.

Then we asked the question: where do you want to start? What is the most crucial piece for you to get the business going? This meant starting to build the product road map and prioritisations. We focused on the core requirements first and identified a set of functionality to be built in the first iteration. I went on to detailed design of the requirements with use cases and user interface. After I got a sign off from the client, we made the delivery plan for the first iteration and the development started. The delivery cycles were around 1-1.5 month.

While the implementation of the first module was being built I went into the next set of requirements with the client and so on.

Each set of requirements were adding on to the final system. Then came a point the change requirements started to the existing modules along with new ones as well as the non-functional infrastructure requirements such as security and disaster recovery. I then put all these requirements into 3 different buckets, e.g., new build, product support and infrastructure. The project manager and I changed the project plan to reflect these 3 different buckets and changed the recourse allocations.

As the product map advanced the functional modules on the functional architectural diagram turned to green from grey.

To cut the story short, I think the important success points from my perspective as a BA/SA in this project were the following.
1. I knew the clients overall vision and was able to work with them to produce a good product road map
2. I always made sure that I was two modules ahead of the development team. Even if the business priority changed specifications shifted places in the delivery plan and the development team always had something to work against
3. I also made sure that I got a sign off from the client within two iterations of the specifications
4. I ensured that I had the technical team review on the specifications before the client sign off so that the team was happy with the upcoming requirements
5. I avoided taking in complex business rules and interdependencies between the modules at the beginning to simplify the solution. This of course meant some of the operational processes of the client were to be executed manually first. Client was happy with this.
6. As the modules completed I revisited (continuous process) the earlier requirements and extended the modules with more complex business rules and dependencies. I could do this because by this time I had built a very good relationship with the client.

Client was happy and is still happy with us. Even if they run out of money at some point in the future they still have a good asset: a working system, perhaps not complete as intended but a working solution.

Do you think this is agile enough?