How to Explore the System to Discover Requirements

When you are discovering the current capabilities of a software system, it’s critical that you take time early on to explore the system as fully as possible.  Of course, you’ll also need input from stakeholders, but you’ll be able to 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, use as a list of use cases.  You will also create a list of targeted questions for your stakeholder interviews.

How to Get Started Exploring the System

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 no documentation can be found and you are exploring a new business domain, 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.

How to Discover What the System Does

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.

How to Stop Your Exploration Before it Becomes a Time Sink

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 during your analysis process, 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.

>> Get Better at Asking the Right Questions

Interested in receiving a comprehensive set of questions you can ask in almost any project context that will help you explore a system with more intelligence and purpose? Want to feel more confident asking questions in a new domain? If you are on our list, you’ll receive a special early pricing on our Requirements Discovery Checklist Pack in late September. (You’ll also get a free career planning course right away and a free checklist before we make the entire Pack available.)

Click here to learn more about the benefits of being a Bridging the Gap subscriber

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. Laura, This post gives great ‘how to’ tips on how to manage getting my head around a new system. Thank you!

  2. Excellent article. Reverse Engineering is very important to understand the As-Is system and to extract important functionalities.

Comment

*