Reverse Engineering Business Requirements: Tips for Senior Business Analysts 🌟

What is Reverse Engineering (RE)? RE is the process of extracting information from an existing solution and presenting it in a needed format. In this context, a business analyst requires information that will serve as a foundation for formulating requirements.

This methodology is not explicitly covered in the IIBA’s knowledge base, BABOK, but it falls under the technique of Document Analysis.

The task of Reverse Engineering always arises within the context of another task. Businesses are not inherently interested in the RE process itself, as it can be an expensive operation that requires the involvement of various stakeholders and a high level of skill from the business analyst. Often, the focus is placed on the analyst's hard skills. Therefore, before embarking on RE, it's crucial to clearly define the scope of the task and its objective.

Scenarios for Reverse Engineering

• Clarifying requirements to support existing functionality.
• Joining a project that involves adding or significantly altering an existing solution.
• Planning a project to completely update an outdated system.
• The client has an old system, and you are introducing your ready-made product for a complete replacement.
• Developing requirements for data migration between two active systems.
• Formulating requirements for the integration of existing solutions.
• Conducting a detailed analysis of a competitor’s product to understand its useful features and how they work.

All of these tasks share one key characteristic: to execute them successfully, it’s essential to have up-to-date system requirements (ideally). Based on a reliable and profound understanding of the existing system (As-Is), the business analyst can formulate a new set of requirements.

Information Sources for Reverse Engineering:

• Interviews with technical experts: This may include developers, testers, and customer support staff.
• Hands-on experimentation: If you can interact with the system by pressing various buttons, this can be a great source for both description and hypothesis testing.
• Data analysis: Data-driven decision-making can significantly aid in the decision-making process.
• Detailed examination of data structures.
• Source code analysis (if available).
• Interviews with business stakeholders and end-users: Observing their interactions with the product may be the only available method in some cases.
• Understanding the domain specifics.
• Existing documentation: Unfortunately, this is often outdated or missing.
• Ticket analysis in Jira, Asana, Trello, or other systems.

Key Considerations for Reverse Engineering Business Requirements

• Avoid over-comprehensive documents: They are often unnecessary, especially if they exist in isolation. Our goal is to solve the task within the context of new requirements. Perfectionism is often misplaced here.
• All sources can be misleading: Even code and databases can be deceptive. It’s crucial to leverage all available means to verify information. Unfortunately, verification takes time, and deadlines for analysts are often tight, forcing them to choose where to invest their time and what to accept at face value.
• Be cautious with the level of detail: The reasons are the same as above.
• Distinguish how the system functions from how it should function: You can maintain a parallel list of changes to be added to the backlog, but restored requirements should be documented in the As-Is format.
• Clearly define and monitor the scope of your research: It’s easy to get caught up in trivial details or veer off course. What constitutes “trivial” depends on the criticality of the original task that prompted the requirements reconstruction.
• Plan for future work with the reconstructed requirements: If further work is anticipated, rather than just a one-time reconstruction, consider establishing a process for updating system documentation.

Understanding User Groups from BABOK and Their Communication Nuances

End Users: They work directly with the solution and can demonstrate its usefulness, but:

• They may not be interested in discussing the current state of the system as it’s their routine.
• They often jump to their ideal working scenarios.
• They poorly organize their knowledge and may forget both frequent and rare operations.
• They know only their part of the process, which can lead to mixing facts with assumptions.
• There might be just one person in the department responsible for a specific function, leading to information silos.

Operational Support: This group can provide useful information as they collect data from tickets, but:

• They often fail to notice their own mistakes, associating themselves with the system.
• Their process knowledge may be superficial.
• They are often passive and reluctant to engage in dialogue.
• As technical specialists, they may delve deeply into details.

Sponsor: The person responsible for the budget can clarify strange steps in the business process, but:

• They rarely delve into details and quickly forget about problems after they are resolved.
• They receive summarized information, which can lead to outdated perceptions.
• They are busy, making them hard to reach.

Customers: The clients of the business using the solution:

• They are rarely involved and available for interviews.
• They may misinterpret how the system works and show low interest.
• They face similar issues as end users.
• Regulators: Initially not very useful, but they can point out constraints that others may not be aware of.

Supplier/Vendor: They use pre-built components provided by third parties. They can be an additional source of information about implementation details, but:

• They rarely engage and may sabotage the project if their solution is disconnected.
• They may be absent due to their company exiting the market for other reasons.

Unfortunately, there is no magic button that resolves all the aforementioned issues. Overall, two recommendations can be made:
Cross-check information.
Verify against other sources.
Utilize techniques like "Observation" and "Document Analysis."

Gathering Information from Technical Specialists

Implementation Subject Matter Experts / Testers:
This group can be a valuable source of information about the implementation process, but they have their nuances. Technical specialists typically do not delve into business details. They understand how the system works but often struggle to explain why it’s necessary. This hinders their ability to assess the relevance of functionalities. In their environment, it is often claimed that a certain function is needed, supported by documentation, existing dependencies, and user bug reports related to both the function and adjacent aspects. Relying solely on the opinions of this group can easily reproduce the old behavior of the system with all its shortcomings, including misalignment with actual business needs.

Project Managers / Business Analysts:
Generally, this is a stable group of specialists positioned at the intersection of technical and business stakeholders, helping align needs with their implementation. Don’t expect them to provide in-depth technical descriptions, but they can narrate the project story, adding to the overall understanding of the context. They typically possess an up-to-date list of issues and a good grasp of the political landscape within the company. However, it’s essential to avoid excessive dependence on their support and involvement in corporate intrigues.