I have been working for an ecommerce client for the last 6 years as manual and automation QA engineering. New features gets applied to our site once in 2 weeks. Whenever a redesign project comes up, like say product page redesign - we keep forgetting to handle all the numerous features which were implemented in last few years. People who implemented it move out of the team often and its forgotten after sometimes. Its not the major features, but minor ones that are having this issue.

I was searching for ideas on how to keep track of all the features in the website. Ideally, when a new requirement comes we should be able to easily identify the impact of the new project on existing ones using this solution

  • +1 I'm still looking forward to someone sharing a success story of a project implementing bidirectional requirements traceability down to the code. Even better if it were using opensource (but I guess such a project wouldn't go unnoticed)
    – Alberto
    Commented Sep 26, 2012 at 21:40

4 Answers 4


What you need is to improve your Requirements Engineering processes. There are commercial tools that help in this area (I have worked with Doors some years ago), but I don't know of any open-source alternative I could recommend.

The problem is that these tools and processes are very "heavy weight", and in my opinion, achieving requirements traceability down to code and backwards is very expensive1 and probably not worthy for software not subjected to any kind of standards compliance (for instance, safety requirements like DO-178B).


1 Requirements traceability should though be feasible using some code generation tools, but I don't have experience in this area, and I'm afraid it's also out of the scope of your question.


"we keep forgetting to handle all the numerous features which were implemented in last few years"

If things are being forgotten on a regular basis, this isn't a tool problem - it's a process problem. Your process seemingly doesn't require that these things are tracked in an accessible place, and that the feature list be kept up-to-date.

We use SharePoint to hold our features/requirements. When it is maintained well, we can use it for impact analysis. When it isn't maintained, we cannot.

  • we dont forget it on a regular basis :). But its bound to happen once in a while. By maintaining it in sharepoint, are you able to the impact analysis as well?
    – A.J
    Commented Sep 26, 2012 at 22:16
  • 1
    Yes, we do impact analysis. But it doesn't matter where the knowledge is maintained, just that it is. Commented Sep 27, 2012 at 0:32
  • +1 for mention of impact analysis - although I've never heard of it is this it: mindtools.com/pages/article/newTED_96.htm Commented Sep 27, 2012 at 5:39

I approach that problem by maintaining written test cases in a wiki. Each test case is a declarative statement. (I have worked places where test cases were documented in step-by-step detail, but I found it was too hard to maintain the details when features changed, as they often did.) If you search SQA or Google, you will find other structures for written test cases. With some thought and experimentation, you can find one that works for your own organization.

I was the only tester in my little company for two or three years. When our second tester joined the team, the written test cases allowed her to learn the product more easily than she otherwise would.

I have had less success documenting test cases in such a way that it is easy to map a new requirement to the impacted test cases. You can get part of the way there by tagging a test case (or a page of test cases) with the relevant product components, but picking an appropriate granularity of tag -- neither too high-level or too low-level -- is easier said than done.

  • Thanks for the answer. Test cases are one solution. But don't you think even the dev and BA should have this ability? How will they design/code for the feature without doing an impact analysis? I was looking for some tool which the Business Analysts might be using, as they are the ones who should be knowing all the functionality of the site. Seems like there are none..
    – A.J
    Commented Sep 25, 2012 at 0:57
  • @A.J Are they using a tool? Do you have access to what they have? I typically use wiki's to maintain long term information for this sort of thing like user246 mentions, but if you don't keep it up then the information gets stale. As a wiki everyone has access and it can have multiple points of information flow.
    – MichaelF
    Commented Sep 26, 2012 at 12:10
  • @MichaelF I was hoping that they use a tool for this. But seems like they dont. I understand that its more of a process fix, but when you have a lot of features which change every 2 weeks and people doing keeps changing - its starting to become difficult
    – A.J
    Commented Sep 26, 2012 at 14:42
  • It may not be possible to maintain your team's current rate of change without sacrificing quality. Documenting and maintaining feature descriptions may help you determine the impacts of changes, but unless you have more resources to throw at the problem, it will also slow you down, at least at first. Sometimes slowing down is the right thing to do, although it may also force you to make some hard choices about how you spend your time.
    – user246
    Commented Sep 26, 2012 at 15:06

There are plenty of ways to keep track of the requirements.The very important thing to be considered is to keep track of requirements and changes from the Inception of thoughts/Requirement analysis, without which it might become a costly affair.

Requirement Analysis Aiding Tools-

  1. An Excel sheet could sometimes be the simplest way to keep track of requirements and impact analysis.
  2. I've used HP Quality center, Which was really a very good ALM tool for Requirement trace-ability and Impact Analysis.
  3. I've not used Doors but that could be another good option.


  1. Categorize the Requirements/Use Cases/Stories.
  2. For Each Category Draft the requirements relating the list of dependencies.
  3. Create a Matrix with the Requirements and Dependencies as Base.
  4. The Impact Analysis should consider all the dependencies.
  5. So whenever there is a change in the requirement around a particular categorized feature all the dependencies must be considered and all related requirements/Stories/use cases must be handled.

Since you've mentioned changes happen every 2 weeks, one more way of avoiding unexpected breaks and miss in any dependent features would be following a Continuous Integration Test Driven Development, where any breaks and dependent issues will be identified when you are committing the changes to the build.

Even after a perfect impact analysis, you could still see issues but keeping that under control should be the goal.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.