Should we always require multiple Change Requests (CR) for more than one change?

LaShawn Dorsey's picture

I just joined an organization where they didn't use CRs to track changes to baselined requirements. One of the developers asked if they could use 1 CR for multiple changes.

Originally, I told him 1 CR could contain multiple changes as long as they relate to one configuration item. I'm starting to rethink and may have them create 1 CR for each change.

Is the first option OK or should I make them create multiple CRs per modification?

2 Answers

bglangston's picture
bglangston replied on October 31, 2011 - 5:27pm.

It depends...
How tightly (that is, to what level of detail) do you need/want to maintain the audit trail? Will you be using metrics? If so, to what level of detail?

For my money, it really boils down to one CR per concept. Again, it depends on the level of control/tracking desired. A lot also depends on the complexity of the product.

Here are some considerations or methods.

If the proposed change is simple and will probably result in a linear sequence of changes (req change, design change, product change, test change), then it maybe makes sense to include all those docs/files on a single change proposal.

In what I refer to as the chain method, each proposed change spawns a child change. That is, the requirement change proposal, spawns a design change proposal, which spawns a product change and a testing change, etc. A parent cannot be closed until its child is closed.

For my "key ring" method, the parent change proposal (against requirements) spawns a "bunch" of "child changes" to the other elements. Each child can be completed and closed, but the parent can only be closed after all the children are closed.

To keep you system "cleaner," you might want to consider NOT a specific configuration item but the nature or concept addressed by the change.

It also may depend on how much is known about implementing the change. To go back to the first method above, the linear sequence of changes, if it is known up front what all the changes will be (to the reqs, design, file, test), then it might not make more sense to use a single change document. So, knowledge about the downstream "impacts" is another consideration.

Passion4theWork's picture

Agree with langston. You may want to consider establishing some parameters for change requesters...even give them some training on what you expect.

Also, consider using a CR tool that has checkboxes for change types. You can make it generate a unique CR for each checkmarked category so the user doesn't have to repeat him/herself for each type. For simple examples:
* Component-related change: update Hardware X, associated software X, and associated Documentation X with a single CR.
* Help the requester think in a logical way about a change. A Class II change across multiple system CIs: "change the word 'functionality' in all documentation CIs for Products X and Z".

Personally, I like to make each change separate so I can run metrics on classes and types of change. However, should the user pay for my preferences?'s not necessary with a good automated CR tool.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.