I recently received an email from Anthony who asks:
How would you go about gathering and documenting requirements for modifications to an existing system?
Let me start of by saying that I LOVE getting questions – because it always gets me thinking of things that I sometimes take for granted. It makes me step back and really think about the details of things that I sometimes do on auto-pilot. And it gives me a chance to reach out to others to get their input to constantly refine and tune how I do what I do.
So…below are some of my thoughts on how I might tackle such a project. Add your comments below and help both Anthony and I think about what we might consider in this type of situation.
And yes, my advice starts with “it depends”. This is probably frustrating for new business analysts, but the truth of the matter is that there is no “right” or “wrong” way – but there are lots of things you can consider for crafting a plan that will work for you in your specific situation. With that in mind, I have three suggestions for things you might want to consider when starting on this type of project.
1. Define the Purpose of the Change
What is the purpose, pain, or need that is driving the change? Are they looking for minor changes that can improve inefficiencies? Are they looking to implement entirely new modules or functionality that is not already is use? Understanding this will help you to devise a plan to work with the right stakeholders to understand their need and also gives you a sense of the size and scope of the project.
2. Get Your Hands on the System
If you’re not already familiar with the system that will be modified, get your hands dirty! Get familiar with the existing functionality and its interdependencies. How are users using it today? What systems feed data to this system, and what systems rely on data from this system? No matter what the scope of the requested changes, you’re going to want to perform thorough impact analysis to fully understand how a change in one area could impact other areas.
3. Review Existing Documentation
If there is existing system/process documentation, study up! Hopefully there is at least some (although don’t be alarmed if it’s incomplete or non-existent because that happens sometimes too). But if you can get your hands on any system, process or technical documentation, it will help you to understand the intended purpose of the system and also may be helpful in identifying impacts. You hopefully will be able to see business rules and decisions that the system makes that might not be obvious from an end-user’s perspective.
What else would you recommend that someone consider when preparing to elicit requirements for modifications to an existing system? Help us out by posting your comments below!