Reverse-Engineering Requirements?
By Josh Nankivel
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.
- 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.
- 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!
About the author


