If the formal requirements weren’t captured when the current system was built, and you are currently working on another project to build something similar to it, this might be a good idea. Personally, I prefer to start with a functional description. As a reference material, you can start gathering the actual requirements almost from scratch.
It is very helpful to create a simplified set use case scenario diagrams when gathering requirements. This allows me to capture high-level requirements. These can be used to map out the processes that are related to or interface with a system. If I was building a system similar to one that is already in use (and there weren’t documented requirements from the previous build), I would create use cases with users to document their current needs. This is something I have done many times in the past. You should also note that functionality in an existing system might be obsolete or not needed. I wouldn’t want to include those features in my new product. You might spend time creating things people won’t use if you draw requirements from a design description. All requirements must have a root: the stakeholders who “have a stake in the product after you are done.”
Great post Craig, a very stimulating question!
