3

This question applies more in regulated environments.

We have our software requirements stored in Word documents an enterprise-wide CFR part 11-compliant document vault. These requirements are reviewed and approved by many organizations. Turns out that there are additional more detailed requirements which are needed to properly implement features and those are linked and managed within VS2010. We do traceability fairly manually (at this point) in an excel spreadsheet using the requirements from the Word documents with pointers to test cases which also live in the document vault. Again, there is quite a bit of review and approval on this part of the process. We haven't officially called these the "essential requirements" just yet, but it looks to me like they are. Software developers and testers are primarily involved in the writing, review and approval of the requirements and associated test cases which are being managed within VS2010. My question is: do others deal with layers of requirements and the associated traceability and how do you handle this?

Improve this question

1 Answer 1

Reset to default
1

In some shape or form, traceability can be found in (mostly) every organization. Each method has some manual aspects to it, though it really depends on

  • how much effort the team is willing to put into it,
  • how much of the end result will be used,
  • what development methodology/practices are being followed, and
  • how granular each linkage needs to be.

In most cases the general process is the same:

  1. Create requirements (specs, use cases, mockups, etc.), have them expanded, and approved.
  2. Create test plan and test cases.
  3. Test cases are then linked to the requirement(s) it tests / Requirements are linked to the test case(s) that tests it. (Depending on how the requirements/test cases are written, this can be a many-to-many relationship).

Excel is not a bad way of keeping this organized, but it can be fragile and error prone. If your organization is willing to invest in a traceability tool, it will make the process more streamlined. These tools do various things, from keeping track of requirements, subsequent test cases, and bugs found while executing the tests. They will also have reporting features which are helpful in getting the status out quickly to managers.

I have personally worked with the following tools and can vouch for their functionality:

Each tool can be used in totality, but they also boast the ability to sync with other tools, so if you already have Jira or Bugzilla for defect tracking, you are able to link the test cases/requirements to the bugs.

My wife has previously used the free combination of Bugzilla and Testopia and said that it good. (Note: Testopia is only for test case management, so it's slightly off topic, but thought to mention it, as well.)

Lastly, I would like to mention the idea of Behavior Driven Development, which creates the linkages directly inside the source code, as the requirements are written in a way (using the Gherkin language) that they are able to be turned into boiler-code/templates/tests. We had given this a try in a previous company and it required tremendous cooperation from the Business Analysts, but went pretty smooth.

Improve this answer
1
  • Thanks for the suggestion of Behavior Driven Development. This is a new term for me. In our environment this would be a high level requirement layer expressed in a way which would allow stakeholders to better express their view of what the system requirements are. This definitely fits in well with the validation phase of testing (was the right system built vs. was the system built right).
    – Jean Marchant
    Commented Apr 20, 2012 at 14:16

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.