Implied Requirements

Posted by Rich Crowley in Design, Requirements, Risk

Assume you are working on a project for an organization that is launching a new product. The product is similar to an existing group of products the organization already sells. This could be a sporting goods manufacturer that is launching a new line of hockey sticks, a packaged goods company that is adding a new line of cleaning products to its existing stable of cleaning products or a bank offering a new savings account product to their line of existing savings accounts.

Assume also that the internal business stakeholders on this project include a number of departments that use different computer systems that already have the existing products configured for whatever needs these departments have. Examples would finance being able to receive transactions with the product codes of existing products, customer service staff in a call centre being able to log complaints from customers who call in by selecting product codes from drop down lists on a customer relationship management application or sales and marketing areas being able to see sales by product on existing reports.

For the project whose goal it is to coordinate all launch activities for the new product, how should the business requirements describe any expectations that these systems will handle the new product without any changes? In my mind, there are three ways this can be handled.

– First, the requirements could say nothing about what is assumed will “just work”

– Second, the requirements could provide a blanket statement about high level elements of functionality that are assumed will “just work” (ie. interface elements like picklists in dropdown boxes, reports that are table driven, etc.)

– Third, the requirements could go into detail about specific systems deliverables that are expected to work. This would include all interface elements (screens, forms, web pages), reports (canned reports, custom reports, ad-hoc queries, end-user queries, extracts), correspondence (letters, statements, subscription info, marketing material), etc.

The problem with the first two is that they are too vague to be of any value to downstream consumers of the business requirements spec. If you are an analyst or developer, do either of these imply you should do anything? Your options would run from a cursory look to full blown impact analysis. The problem with the third is that it can be very expensive to analyse all components that use the new product identifier and you may find nothing needs to be changed.

Another problem is that from a roles and accountabilities perspective, if there is no system change required, the functional software spec or system spec probably should make no reference to these implied requirements since there is no system change to be made. This means that testers working from the technical spec docs produced by designers/developers/architects won’t see the implied requirements. The solution here of course is that the testers need to build their test documentation starting with the business requirements but also including any other project lifecycle documentation that is prepared.

As more applications become configurable via table changes rather than coding changes, and as business partners demand faster project execution, perhaps using either approach the first or second approach above is more acceptable than it has ever been. By doing some risk analysis on the scale of the changes, one may find these approaches are optimal in many situations.