Naturally this principle can be applied to business requirements as well. As an example take a look at your local bug tracking tool. I bet it's got the same features as my bug tracking tool, and that other reader's tool as well.
Features will include the ability to enter a bug name and description, add a screenshot or other image, generate reports on inflow and clsure rates, mean time to close etc, and the ability to move bugs through a couple of states from new to closed.
Did the product managers for these tools all hve to go to clients and learn about their needs, run focus groups and gather feedback customer by customer? Did they then have to go an write up (or otherwise explain) specific and detailed requirements for each requirement?
Well, yes and no. Yes they did have to all indepedently articulate requirements for the dev team, but no - not all the requirements needed to be elicited from scratch. For example, a BA or product manager may have been recuited from a competitir, or may have several years as a project manager or project tester under their belt and can thus go straight to the heart of the issue from direct experience.
In these cases personal patterns are leveraged.
Take a moment to think about your experience and the degree to which you elicit requirements versus make them up from your own experience. If you have any substantial experience you can't help apply your own judgement to how a reqirement should play. You may be wrong - and the verification process will tell you that, but the shortcust that experience provides are invaluable. (Thats why experience commands a $premium.)
Interesed in reading more? Check out Martin Fowler's website, or his books on analysis patterns.
- Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)