Use A List Of Major Impact Areas To Think Through New Features

I often use a list of product “Impact Areas” to assess the impact of a new feature on the rest of the product.

As I’m developing a requirement, I go through the list of impact areas and note down whether this feature requires a change in that area. If not, I mark it as “N/A.” If there is an impact, I note it down. When I was managing Accept360, some of the impact areas were:

  • Table views and filters. (We had user-definable filters for finding entities, so if there was a new property, you’d have to make sure the filters supported it and the result list could display it in a useful way)
  • The release or sprint backlog. The feature might need a new column, or a new business rule for calculating a column value
  • History log entries
  • Default values or settings
  • Notifications required for this feature
  • The terminology and lexicon for the feature
  • Are there best practices for using the new feature? What are they?
  • Import or export 
  • Does this feature make other features obsolete?

In Accept360, I created a page in the requirement template with the Impact Area list. It was easy to go through the list and enter the notes. Today, using Confluence, I typically use a child page to capture the impact areas.

It’s sometimes difficult to make yourself go through this list, but particularly for bigger features, it’s a valuable exercise.

  • […] of my favorite techniques for quality requirements is the “Impact Areas” concept, which should be part of the table of contents of your […]

  • >
    %d bloggers like this: