You will rarely get a requirement that covers a wide gamut of your particular problem domain. Instead, you will get requirements for reusable assets in bits and pieces. It is in your team’s best interest to look not just at the immediate need. Look for domain relevant reusable assets that are related to your immediate requirement. Notice that I am not advocating building things that are nice to have! When you take time to understand domain relevant assets you will be surprised how effective you will get with incremental development. You will do work that is aligned with your business vision and throw away less code.
Take an example where the requirement is to provide a credit card authorization service for a customer. You can just build that one service of course and that would be fine for your project. But if you step back and consider the domain, maybe you identify that the credit card authorization is just one kind of funding. There could be debit card, traveler’s checks, or even electronic fund transfer capabilities that are required for the future.
Now, should you be building a credit card authorization service or an authorization service with credit card being one of the mechanisms?
You can enhance the authorization service by adding new capabilities over time. By creating modular interfaces new authorization types can be gracefully added. The service could interact with different authorization providers based on customer characteristics or traffic on the service or meeting specific service levels. Or it could use a set of business rules based on type of product being purchased or place of transaction etc. The bottom line – the capability will be able to encapsulate a myriad other domain-relevant functions offering opportunities for reuse in many places.