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!
