Reverse Engineer to Business Requirements

A critical activity for any ERP implementation is gathering business requirements.  The purpose of business requirements is to define the needs that will enable business activities to generate business results.   The traditional school of thought is that if we capture all the requirements then we assume that we will develop a solution that will produce the desirable results.  I believe that experience has taught us that the above assumption is not correct. 

Business modeling associating business activities with business results
Results-Oriented View of Business Activities

Let’s use the above illustration to elaborate on a few observations based upon my experience: 

  • Customer’s existing business models will have both value-add and non-value-add business activities.
  • Customer’s existing business models may produce undesirable business results.

 A concern with traditional requirements gathering techniques is that non-value-add requirements are carried throughout the requirements management process.   This results in wasted effort, loss of focus on the critical requirements, and informally creates the expectation that the new ERP system will replicate existing functionality.   A majority of non-value-add requirements are a result of current technology or organization limitation.  This is not a criticism but rather a reality we all (Customers, IT, Implementation Partner) must address as part of an ERP implementation.


Let’s consider something unconventional and trace desirable business results back to business activities and the individual needs (requirements) for each business activity.

Business requirements support business activities which support business results
Results-Oriented View of Business Requirements

Starting with the desired business results ensures that we drive to only those requirements that directly support true business value.  First, it is an exercise that really puts into perspective the purpose of a business model (results).  This exercise is not only useful to the project team but also the business stakeholders.  Second, it is an approach that can help you justify why certain existing business activities are not being carried forward in the new business solution.  Third, taking a business results oriented approach enables your project team to be more successful at focusing on the right business requirements and not wasting time on capturing requirements for non-value-add activities. 


Often we spend too much time and effort focusing on gathering requirements that do not support key business results and then gloss over the key business activities because of implementation time constraints.  Prioritizing business results is an activity that we need to initiate before gather requirements, not during fit/gap when expectations are harder to manage and negotiate.

Join the community! 10k followers across 100 countries!

12 thoughts on “Reverse Engineer to Business Requirements

  1. Bill Gibbard says:

    I find that “traditional requirement gathering” always shows up in a list of requirements in Excel. It’s a boring spreadsheet with hundreds of lines per business process with vague statements of requirement often very wordy but still ambiguous. Each Excel cell leaves the statement open to interpretation and can’t be fully defined in this impersonal format. Marching to this list is dangerous for the very reasons that you state. In between rare true requirements, we find many that will sink a project. After digging into many spreadsheet lines with customer interviews, we find the requirement is ultimately supported by “that’s the way we’ve always done it” or “our old system made us to it that way”.

    I strongly prefer your notion of “desired business results”. How do you get there? Define business metrics (along with as-is measurements)? Document business scenarios at a high level? Then marry the two? Any suggestions suggestions for implementation tasks and deliverables would be grealty appreciated.

  2. Igor Arkhipov says:


    let me debate on the topic a bit.
    To my mind, what you are describing here is just a good and proper way of requirements engineering, so why call it reverse?
    Really, when a stakeholder gives an analyst some requirement, there are two basic ways of handling it:
    1) Most popular (as easier to carry out) but lamentable – to write it down as-is and then send the specification to developers for implementation.
    2) Less popular (as it requires additional brain work 🙂 ) but desirable – to understand what was the reason for such requirement thus finding real lack of business value that stakeholder wants to eliminate (i call such reasons “real needs”). Satisfying such needs always results in what you call “desirable business results”.
    This is why there is a need in understanding what is there behind the requirement: stakeholder has some kind of ideal solution in his or her mind. This solution, when being formed as requirement, has to be transformed from the language of images in stakeholder’s head to some formal language (text or diagramms). Then vise versa this formal language has to be transformed to language of images in heads of project team. As stakeholder isn’t usually an expert in dealing with requirements, he or she cannot assure that the losses of information during this process are minimal.
    Another reason is that stakeholder, being expert in his or her area and having an understanding what the real problem is, can not always end up with most ideal solution to the problem within informational system. But people tend to come to the project team with solutions, not problems. Implementing such solutions without re-analysing them can result with total mess in a system from business result’s point of view.

    Returning back to reverse engineering of requirements, as I understand the term, it is a process of finding out, which requirements were standing behind some existing system without having any documentation about it. Such situation is common when dealing with legacy system (when we want to replace it with new one but remain same functinality) or as a result of non-structured or low-qualified development (when we finally want to create documentation about the system).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s