Reverse-Engineering Requirements?

Filed under Requirements | Posted by PMStudent

Fellow blogger Craig Brown over at Better Projects asked “Why reverse engineer requirements?” in a recent post.

Interesting question…? Craig asked what value there is in trying to derive requirements based on an existing system.? There are two points that came to mind on this.

  1. If formal requirements were not captured when the current system was designed, and you are about to do another project to build something similar, this might come in handy.? Personally, I would rather start with a functionality description, etc. as reference material and start the actual requirements gathering almost from scratch.
  2. When I gather requirements, I find it very useful to do a simplified set of use case scenario diagrams to capture high-level needs.? They can also be very useful for mapping out the processes that relate to and/or interface with a given system.? If I were building a new system similar to something that is already in use (and there were no documented requirements from the last build) I would construct use cases with the users to document how their needs are fulfilled today.? In fact, I have done this in the past more than a few times.? Note that the existing system may have functionality that is obsolete or unnecessary, and so I would not want to incorporate those features into the new product.? If you derive requirements from a design specification, you may spend time building stuff people won’t use anyway.? The root of all requirements must be the stakeholders who will “have a stake” in the product when you are finished.

Great post Craig, a very stimulating question!

project management basics

LIKE & SHARE THIS ARTICLE