Reverse engineering requirements: how to explore the system

When you are conducting a current capabilities assessment, it’s critical that you take time early on to explore the system as fully as possible.  As important as input from stakeholders will be, you’ll establish much more credibility with these individuals if you’ve done your due diligence.  After exploring the system, you’ll have a surface level understanding that’s documented with a visual map or list of some sort. You will also create a list of targeted questions for your stakeholder interviews.

Note: This is a follow-on post from “Selecting a Business Owner and Defining Scope” and post #3 of the Current Capabilities Assessment series.

How to start?

When exploring the system, using a test or development environment is a best practice.  Ensure you can manipulate the data and follow your data through the system as this will give you many insights.  If a test environment is not available, you can explore in production, but your freedom will be limited as you wouldn’t want to mess with any public-facing data.  If you are dealing with a consumer-facing application, such as a website, you’ll want to start as any consumer would.  Think of a goal the website should help you fulfill and start navigating to achieve it.  If you are dealing with an internal tool, check around for training materials or business process documentation to gauge how a business user might use the tool. If nothing exists, which is likely given the project you are tackling, and you are new to the business, you might want to engage one stakeholder in a brief demo or invite yourself to some training of new hires.  Taking an hour of someone’s time in this situation will get you leaps and bounds ahead and make your exploration of the system much more fruitful.

Now what?

What’s the most important thing to do?  Just start clicking! Click, review, think, click again. Jump around the application until you have a general idea what’s there.  It can be really helpful to build a site map as you do this, with notes to yourself about things you want to check out.  Or instead of a site map, consider a features list or use case list, whatever seems most natural to you and the situation. Once you build this map or list, go back through each function and work through the data flow.  Add a new record, subscribe, do whatever you can to get data into the system.  Then look for this data in other places, checking what you can do with it, or what a user with a different role can do with it.  Watch out for any changes that aren’t triggered by your direct actions as these can indicate automation rules happening behind the scenes.

When do I stop?

Exploring the system involves a balancing act between doing your due diligence and getting lost in trying to figure something out that could be explained to you in a few minutes. Stop exploring the application when you’ve gone through every link you can find. Stop exploring a specific feature when you find yourself spending more than 10 minutes trying to figure something out with no luck. Clarify what you are hunting for an add a question to your list.  If you find this kind of thing exciting, you might want to time-box these activities within about a days worth of work.  If you think this will bore the heck out of you, consider forcing yourself to sit down and do it for at least a few hours.  Each system and project is different, the important thing is to inform yourself without letting this activity become a time sink.  At the outcome of this process, you should have a reasonable list of features with lists of questions tied to each one.

You can always come back to this step, and you likely will.  Your questions and stakeholder interviews should uncover areas of the system that aren’t readily apparent in your first round of exploration.

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

1. Reverse engineering requirements: Create a Work Plan
2. Reverse Engineering Testable Requirements: Interviewing Business Subject Matter Experts
3. Reverse Engineering Requirements: Select a Business Owner and Identify Scope