Requirements-Tasks-Tests changes traceability
Hi, 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 ...
Forum Discussion
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.
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.
