Forum Discussion

AlexKaras's avatar
Champion Level 3
14 years ago

Requirements-Tasks-Tests changes traceability


I would appreciate if you point me to the relevant help topic or any other resource that describes discussed functionality or consider its implementation.

The problem is that in the course of the project it is a common thing that requirements, development tasks and tests go out of sync.

For example, based on the talks with the customer, analyst can make changes in the requirement and this may appear to be not reflected in the relevant task. Alternatively, development can implement some functionality that may appear not to be reflected in the requirement. Finally, it is not the rare to appear in the situation when it is far not easy to say what tests are testing (requirements or actual implementation) and what results are expected to be correct ones (as described in the requirement or as it is implemented in the application).

Does ALMComplete (or any other application from the suite) contain functionality to easily visualize that something was changed in either requirement or in the task or in the test, make it possible to easily see what was actually changed and provide the means to signal other team members (maybe via the change of the status of the linked items or in some other way) that linked items must be reviewed?

Definitely, there should be an option to save the changes without any further actions. This is required when, for example, item is just reviewed by the editor and introduces only a syntax corrections, so there is no need to bother others and reduce their responsiveness to the change notifications by false alarms.

Please let me know if some points from above need further clarification.

2 Replies

  • AlexKaras's avatar
    Champion Level 3
    Hi Barbara,

    Unfortunately, notifications alone do not seem to be able to solve the problem I am trying to describe.

    I am talking about scenario like this:

    a) There is initial requirement with the development tasks and subtasks (just 'tasks' hereafter) created according to this requirement and linked to it and with tests created for every task and linked to the corresponding task. As a matter of fact, it is possible that there is no initial requirement but just tasks with linked tests (but this may be resolved by introducing a stub requirement);

    b) Now business analyst introduces some change to the initial requirement. If he considers that the change is significant but not just a cosmetic one, he should be able to execute some action (set a field, press a button, etc.) that change a status (or do a similar action) of the linked tasks to signal developers that these tasks need attention from their side. It is not analyst's responsibility to decide whether tasks must be corrected or not, but developers' one. If their decision is that the change does not influence on some given task, then they just put it back in the state the task was initially. If the developers decide that the requirement change require change in the task, then they should correct the task and execute the action similar to the one executed for the requirement to put linked tests in the state that signals testers that they (tests) should be reviewed. And the testers perform the process similar to the one done by developers for the tasks.

    To ease the process of change analysis and thus to decrease the chances that people will stop to analyze what was changed because it takes too much time to find out what was actually changed, the tool *must* provide an easy-to-access and clear view of what data were changed for the given item (requirement, task, subtask, test).

    I understand that design and implementation of such functionality is quite complex task, but I am sure that the tool that provides the project staff with the change management functionality for requirements, tasks, subtasks and tests will get a significant market benefit and a great customers' recognition.
  • Hi Alexei,

    ALMComplete and the related editions include email alerts and escalation rules. Email alerts allow you to set up an alert for yourself based on changes to Status or ANY change to Defects, Requirements, etc.

    Escalation rules can trigger and email to any selected team member based on a change to Status. Escalation rules are meant to be a reminder: if the status changes, you get an email. If the status doesn't change by tomorrow, you get another reminder.

    Here's a demo of escalation rules:

    And some info on email alerts:

    Let me know if this helps!