Existing products or services offer a great chance for you to gather project requirements through reverse engineering. You need to look at a product that already exists and figure out the fundamentals of what it does and why.
When the project is replacing a something already within the company, like a software system, you can learn what does and doesn’t work. If the company is looking for something brand new to be created, it’s likely a version of the product already exists somewhere for you to figure out some fundamentals.
In this article, we’ll explore key information about using reverse engineering to gather your requirements, such as:
- When you should use the process
- How to reverse engineer
- The reasons why you should do it
- Pitfalls to watch out for
So that you can understand if this process is going to work for your project.
Is reverse engineering appropriate for my project?
Reverse engineering is a useful tool when gathering your project requirements. It shouldn’t be used as the main technique, but it will provide you some valuable insight at the start of your project.
Used in conjunction with other processes that you complete early on, such as document analysis, it will help you to ask better questions when you begin to talk with your stakeholders.
Times when you’ll find reverse engineering particularly valuable include:
- When there’s little or no documentation with the current product
- When the current product or system is a legacy item
- When key knowledge has left the company and records weren’t kept
- When the current system or product has developed organically with no solid plan
These points are relevant for when an existing item is being improved upon.
However, you can reverse engineer external products too. If the client is looking to replicate a competitor product you can refer to that directly to get a deeper understanding of what needs to be achieved.
What process do I need to follow?
Depending on what you’re working with, reverse engineering can take a matter of hours or weeks of your time. Whichever the case, the process that you follow will be similar.
Step One
You need to get to grips with the item you’re working with. If it’s software, use a test or offline system; if it’s a product, get hold of one that’s expendable.
This is your chance to play with and explore the product. Take notes so that you can record any questions for stakeholders later.
Step Two
Once you know what you’re working with, it’s time to analyse it. Notice pinch points in the processes and understand why it isn’t suitable for your clients as it is.
Step Three
After you really understand how the system or product works, look at the outcomes. Do you get what you expected? Can it be improved upon? How easy was it to get there? These questions will inform what you go on to discuss with your stakeholders.
What are the positives and negatives of reverse engineering?
There are some great advantages to reverse engineering to establish your project requirements. Some of these include:
- You will clearly understand what the current product or system does
- There’s no user or stakeholder input required
- You’ll establish functional requirements
- Unknown requirements might come to light, such as market innovations
However, there are some points to be cautious about, as with every process. Some things to note are:
- You don’t learn anything about legal and security requirements or licensing
- There will likely be obsolete or unnecessary elements in current systems that you have to contend with
- The end product you work with won’t always have the initial requirements included
Summary
Reverse engineering as a way to gather your project requirements helps you to understand the good and bad points of what’s already out there. Rarely will you be asked to reinvent the wheel.
Take advantage of what people have done before you, both inside and outside of the company, to learn from their wins and mistakes.
