March 5, 2012

3 Ways to Work With Requirements in TestTrack

Helix ALM
How you work with requirements in TestTrack depends on your role and where your team is in the development lifecycle (SDLC). I've outlined three ways of looking at the same data, giving everyone on the team flexibility in how they develop, review, approve, and track requirements throughout the lifecycle.

Specification Window

This view lets you write, review, and comment on requirements in a manner very similar to working in Microsoft Word. The Requirement Document container in TestTrack lets you group requirements in any manner you want, with support for grouping the same requirement in more than one "document" and having changes to a requirement propagate across all of those documents. The specification window is your view of the document container, giving you the ability to define requirements hierarchy, edit individual requirements, and review or approve requirements among other things. [caption id="attachment_11063" align="aligncenter" width="575" caption="Specification window showing requirement document"][/caption] The specification window is where business analysts and project stakeholders will spend more of their time early in the development lifecycle, iterating on project requirements and sending them out for stakeholder review.

List View

Viewing and working with individual requirements is sometimes easier from the requirement list window. During project implementation and verification, it's common to see Dev and QA folks working from this view as they code, test, and verify individual pieces of a project. There are a couple ways to optimize your use of list windows. First, use static and dynamic filters to limit the amount of information shown in a list window. Second, use tabbed views to quickly get the information you need without having to constantly re-work columns based on the information you're looking for. [caption id="attachment_11071" align="aligncenter" width="575" caption="Filtered requirement view"][/caption]


Folders are a great way to manage the entire project, which includes requirements as well as tests and defects. Like the requirement document container, folders allow for flexible grouping of project artifacts depending on how your team works. If you're using Agile concepts, you can set up folders to manage iterations with stories and built-in burn down charts. If you're doing more of the classic waterfall or iterative waterfall, you can manage the project that way as well with built-in design, development and verification status charts. [caption id="attachment_11074" align="aligncenter" width="575" caption="Folder view of project artifacts"][/caption]