Identify Common Needs

Functionality that is common across applications (or products in your product line) are rarely presented as reusable software services or assets. Often you have to deduce or discern these reusable software capabilities from business requirements documents or user stories. Here are a few ideas to identify common capabilities that can become reusable software assets:

1. When your business stakeholder requests the same capability across multiple applications, your antennas should go up! Because this is definitely an opportunity to build out a product line. For example, may be there is a need to provide customer information for a call center representative and a sales representative. You definitely need to make getting customer information a reusable asset.

2. When you see a requirement – never examine it in isolation. Place the requirement within the broader domain that you need to support and identify closely related capabilities. In line with the earlier point, getting customer information could be placed within the context of the overall domain of managing customer information (don’t take this domain choice literally

   – your domain could be customer data management, direct marketing, or business intelligence you know your domain best!). Ergo you can see that in order to get customer you need to find a customer by a certain filter criteria, list all/sub-set of customers, validate contact information, pre-fill customer information etc.

3. Sometimes your business stakeholders write requirement specifying how something should be implemented. They might add specific system or database names, even module names, or other detailed development level details. This is when one should resist taking all this detail at face value! Instead, abstract away the specific systems and think domain capabilities. Repeatedly ask “why?” (yes, this is the popular technique) to arrive at the real business capability. Identifying the underlying requirement will lead to mapping the product line capabilities. Examining the get customer information requirement – for the sake of this example let us say it was presented as follows “Create a customer file from the ABC system. Update the ABC system’s CICS module to populate a table to store the file data. Then run a nightly job blah blah blah.” Asking the 5 whys for the stated requirement – create a file from ABC system could lead you to the need for developing components and services for grouping customer information by demographics or feeding an indexed search engine for customer data. Whatever. The point is never take the requirement at face value!

There are many additional perspectives and questions to consider but these should get you started.