Forum Discussion

MartinH_1's avatar
MartinH_1
Occasional Contributor
15 years ago

Change Requests - Not Defects

Hi,

We have been using SoftwarePlanner for over a year and are interested in what is considered the best practise for managing Change Requests within SoftwarePlanner.  



Currently, they enter our system as Defects and get maintained as such but the reality is that up to half of all incoming defects are actually Change Requests and as much as 60% of those CRs are actually requests for amendments to requirements in various stages of implementation.



regards,

Martin
  • Hi Martin,

    There are probably a lot of different ways you could do this, but here are a couple of thoughts -



    If you attach a formal requirement document to your Requirements, you can track the changes to the document as you upload updates. There is a checkbox on the upload screen to "Replace existing files, save original as a prior version" and the results look something like this:

    http://screencast.com/t/ra5kXegBR



    If you need to change the Requirement itself, not the attachment, you can always view the History of changes on the History tab.



    If you like using Defects for gathering the information, you could add a Status for "Change Request" or a Custom Field for Defect Type = Change Request, Defect, etc., then use Traceability to link the Change Request type Defects to the original Requirement.








  • MartinH_1's avatar
    MartinH_1
    Occasional Contributor
    Thanks for the response!



    It partially answers the question really because what we would really like to see in SoftwarePlanner is the Defects section be renamed to something like "Issues" since in most software development a large proportion of items raised as defects actually aren't. 



    The above suggestions are great but they don't really help with managing
    whether to make the change to the requirement or not in the first
    instance.  We'd like to see a Change control section implemented or failing that, be able to classify "Issues" as either a "Defect" or a "CR". (It would be a bit onscure to manage a CR as a checkbox inside a defect that appears on all reports as a defect.  If there were an Issue type of "CR" then you could resolve and close the initial Issue report (currently a defect) by noting the number of the CR that was raised and then manage the CR in the change control system.



    cheers,

    Martin
  • Hi Martin,

    I got some more input here from the team, and found out that the way many users handle Change Request is through Requirements: make a Folder in Requirements for the Change Requests and create a Requirement for each one. You'd be handling the Change Request as a Requirement rather than a Defect.

    Then when the Change Request goes into a Release, you can just move the Requirement to the Release Folder.

    Let me know what you think!
  • MartinH_1's avatar
    MartinH_1
    Occasional Contributor
    Hi Barbara,

    We did think of that but the problem is that we have quite rigid policies in place for evolution of requirements and so there are numerous fields that must be populated for a requirement to get to certain states.  To enact the idea of using the Requirements sectino to maintain the Change Requests, we would need to create an "extra" set of states that don't have such restrictions, but these would be visible for Requirements.



    I'll have a think about it and discuss with the team.



    cheers,

    Martin
  • Hi.

    I've quite the same need:


    1. a user (or even a guy of working team) inserts a new item in "defect", supposing it's a real defect

    2. an analyst lokks at the new item and decides to "route" it to a "Request for change" (or "implementation") issue

    3. In the real world the "Implementation" workflow is not equal to "Defect workflow", and could have different user-fields and even statuses

    4. currently, in cases like this, it seems I have to "move" this new "defect" item into "Requirement" issues, but I could loose fields, values, status, and even links. Anyway an "Implementation request" is not logically equal to a "internal requirement" (ie: it has to be approved to become an internal requirement),... and the problem reappears again....


    I think a new "label"/Category should be inserted, soon or later, in ALMComplete: something like "Implementation request" or "RFC" (better a shorter name...), with a strong relationship with "defects" issues (easy copy/move between them, same user-fields to avoid looses in migrating, different workflows,...).



    Best regards!
  • Hi Sergio -

    It sounds like you've been looking at our Workflow function, that's great!  But I understand what you are saying. We don't have any additional "tabs" on the road map just now.

    We have the ability to automatically create a Defect from a Test Case; a Test Case from a Defect, and a Test Case from a Requirement. Everytyhing is automatically linked together.

    Personally, I like the idea of creating anything from anything and I'm pushing for that as an enhancement - I'd love to create a Requirement from a Defect. So I'll add your request to mine so we know there's interest.

    Thanks!