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 responses to “Reverse Engineer to Business Requirements”

  1. Bill Gibbard Avatar
    Bill Gibbard

    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. […] your deliverable of requirements that will be provided to the ERP software vendors. There is an excellent article on how to do this mapping, by author Brett Beaubouef, that describes this […]

  3. […] approach to gathering requirements that (a) I would spend a lot of wasted effort gathering non-value add business requirements and (b) the fit/gap session would be much longer than planned, (c) and I was in a non-win situation […]

  4. […] The configuration-driven strategy is based upon the premise “The new system needs to do what the existing system does today”.  It may be a situation where a customer simply needs a replacement system because the existing system is nearing the end of its license and may become decommissioned software.  Starting with what the customer knows helps to expedite requirements gathering.  Business user time is minimized because IT can provide insight into the existing business system capabilities and configuration.    However, this approach will surface requirements based upon existing system limitations as well as legacy non-value-add business requirements.  […]

  5. […] processes, not individual business functions, generate business results.  Too often, we only focus on business activities and the specific software functionality that […]

  6. […] you need to understand the ERP functionality implemented but also how that functionality supports business results.   To achieve long-lasting value from ERP you need to have a long-term strategy to incrementally […]

  7. Igor Arkhipov Avatar
    Igor Arkhipov


    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).

  8. […] Bron : ERP the Right Way! Lees meer… […]

  9. […] gaining a better perspective of the requirement.  What is the desired result(s)?  How do the result(s) add value to the overall business process?   Odds are that you will have only a superficial understanding of the requirement if you do not […]

  10. […] lead your customer to challenge assumptions and perceptions in their current environment.  A perceived requirement may be a limitation of the current system or organizational structure.  Just remember that asking the right questions […]

  11. […] key objective is to assure customer success through early and continuous delivery of value-add business […]

  12. […] Business results are created through business processes, not individual functional activities or features. Given this reality, a vendor who can provide autonomy across a business process is considered a maturity improvement. (Level 2) […]

Leave a Reply

%d bloggers like this: