The Community Blog for Business Analysts


Best Practices - Duplication

How often do you see the same piece of information documented in 2 places? I am used to seeing requirements information copied into design documents; whole sets of requirements being copied into a test repository and diagrams copied from one document to another. Unless you employ a strict change management control system that includes a traceability scheme, this sort of practice is going to prove expensive, for 2 main reasons:

  • The work of maintaining information is being done twice.
  • More expensively, if one artifact changes and the other doesn’t, how do we know which is correct? [1]

Employing an automatic update scheme, a traceability scheme which shows when something has changed or a strict configuration management scheme which prevents artifacts from being changed, will go some way to solving the duplication problems, but again they are expensive.

Rather than spending time and money in trying to control duplication; I recommend, ‘Don’t Do It’. Here are some schemes that can be used to prevent duplication:

  • Put the information in a central repository and reference it with hyperlinks.
  • If you must have the information displayed in two separate places, use Object Links and Embedding (OLE). Extract the information from both artifacts, place it in its own document and embed the document as an OLE.
  • Use document generation tools, such as SoDA, to insert duplicated information into your documents.
  • Ask yourself the question; ‘Do I need to put this information here?’ Or, ‘Can I reference the same information, located somewhere else?’

Do not copy, either use a link or make a reference if you absolutely must have it here.

[1] The worst example of this was on a contract where the test team did not like the way the developer’s document repository was organized, so they copied the developer’s documents into their own repository. The wrong tests were consistently being executed against the code.

Editor's Note: Check out the list of all related best practices.

This entry was published on Feb 12, 2010 / Leslie. Posted in Requirements Management and Communication (BABOK KA). Bookmark the Permalink or E-mail it to a friend.
Like this article:
  9 members liked this article

Related Articles


Leslie posted on Friday, March 19, 2010 2:11 AM
These blogs read a bit terse and out in left-field when read by themselves.
It might help to read preceding articles on best practices starting with:
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC