12 August 2008

Why reverse engineer requirements?

A discussion at the Agile Modelling Group put this picture into my head.

The original question was about how to go an document requirements for an existing system. My initial response was why would you want to reverse engineer a system back to requirements?

It makes sense to me to get a full picture of what a system can do - and so document features, but I can't get why you would take things back to requirements.

After all, requirements are a statement around a particular problem or opportunity, not a design specification.

The diagram below came to me care of a comment made by Jon Kern.

Jon notes that not all formally accepted requirements make it in to the final release. Sometimes they are too hard, sometimes you run out of time and money before you get there.

Additionally extra non-formal requirements often make their way into the final release. Non-formal requirements arise from a number of places including uncontrolled requirements changes, requirements elaboration and developers realizing that a neat feature is just 30 minutes of code away.

So at the end of the day, a system doesn't match any particular set of requirements anyway.

Now, there is a case for re-using requirements. After all, if you have a set of standard requirements for say, logging into a system, why not re-use them. It saves time and builds consistency.  But requirements re-use isn't the same thing as reverse engineering a system to establish requirements.

I ask again; what value can there be in this? Any suggestions out there?


  1. Potentially this is a case of of semantics. Traditionally, a requirement is used in a future tense. What a system should be, what it is required to do. Requirements are directions to the implementers such as project managers for scope mgmt and cost est. developers for creating, and testers for verifying.

    However, in my experience, common usage of the term is a little different. Regardless of whether you document a system as a bulleted list of features, high level story cards or detailed specifications, you are still capturing the systems requirements. In common usage requirements are not necessarily what a system is required to deliver - as in a future tense, but can also be what it does deliver, as in the present tense, and can be provided in many levels of detail and still be regarded as requirements.

    My personal opinion is that requirements are only meant to be used in a future tense, but that puts me at odds with how the majority of people seem to use it.

    So documenting the existing system features may match documenting the business requirements that are realised by the current system. But using two different nomenclatures to describe the same thing.

    But needing to capture the functionality of an existing system does raise a long standing concern of mine.

    As we increasingly automate processes, burying knowledge in arcane business rule engines and complex workflow systems, dumbing down the operational workforce to produce more predictable outcomes and reduce operational costs, the business loses its knowledge of what drives the existing processes.

    Increasingly the power to analyse and change is moving into the hands of the technical, for better or worse. I have been on projects were the business analysts have been incapable of assessing the existing business rules, much less coming up with solutions, as you needed a high level of technical expertise to map the existing systems. So it ended up with the software developers, or at least a core number of them, driving the requirements, and providing assistance to the more technical of the BA's, the rest were left floundering.

    So do BA's need to be more technical? Is there still a role for non-technical BA's? Do software developers need to be more versatile and be able to elicit requirements, not just deliver them? Agile methodologies tend to encourage the software developers to extend their capabilities while reducing the role of the BA. So the question it raises in my mind is as we increasingly automate our processes, how will the role of the BA adapt? What new skill sets will be required for them to continue to be of value?


  2. Andrew

    You advocate of devilry! Great questions.

  3. Andrew asked if there was still a place for a "non-technical" BA. I would suggest that "non-technical" is in the eye of the beholder.

    My career has gone like this: programmer -> database administrator -> project manager -> software engineering manager -> business analyst. I suppose you would describe me as a "technical" BA. However, that doesn't always help in business process modeling. A lot of times you need someone familiar with the subject matter to get in and figure things out.

    This is where I have to ask what do you mean by "technical"? An accountant who becomes a BA is still and SME, but not a technology SME. If you see my point.

  4. Hi guys,

    I think the BA should be a business person first and technologist second.

    I also think that there are no more businesses not using technology of some sort. You have to know your tools, if you know what I mean.

    So any competent business person understands the technology of the business they work in.


  5. Okay, an excellent response by Adrian from Modern ANalyst can be found here.

    Adrian notes that you need to know thye original requirements so myou know the effect if you change a feature attribute.