Search This Blog


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?