What constitutes Major and Minor changes in Software

As a Knowledge Manager, I'm new to the business analysis field. I was asked to put together a list and detail what constitutes a major and minor change request for software. The software in question is Adobe Experience Manager.
This paper will be used by the customer (authors/content managers) to establish workflows for certain internal processes. Can someone tell me what examples make up a major versus minor change. Please list examples. Are there any other "changes" that don't fall within major and minor. Also, please list examples.
I feel like I'm in bureaucratic limbo. Of course this is a govt agency.
Thank you all very much for assisting me.

I would like to give some clarification - these are changes the client may ask the developer to do. Example: Create a page, change a workflow, changes to arthur or publisher groups, etc...

I would think those would be defined by comparing the current contract requirements to any change request.

However, I am not a software expert. I would *think* this would be a gray area because the definition of major vs. the definition of minor would be not only company/project specific, but also customer specific. Customer expects X, gets X-1 and is dissatisfied while the supplier is seeing "we did everything the contract calls for". Supplier believes the change(s) is/are major by their company "standards" yet the client (purchaser) sees it as a minor change by their company definition.

I will say that any time I see a customer request for change, I stress how important Contract Review is prior to accepting a change (and typically these are "running changes"). I see a lot of these fail because the customer wants to tighten up a tolerance and the supplier doesn't have a qualified GD&T expert to review the print(s) and the next thing you know the company has committed to a change they can not produce to.

Unfortunately software is nothing like manufacturing. The is a lot of "slack" (for lack of a better word right now) when determining whether a software project meets it's intended purpose even when project management tools are used.

Consider: What Software Specification Tools Do You Use?

Also see these CMMI discussions here: CMMI - Note that the significant "companies" requiring CMMI are military related.

Work flow changes are another matter, but the same principles apply in that what you consider a minor work flow change your customer might see as a major change. Communication is important!

Oh - And as more "food for thought": US Requirement For Software Dev Certification Raises Questions

I apologise for being a bit off topic.

from a practical standpoint there are 3 perspectives on what constitutes a major or minor change depending on the purpose of the classification.

• The amount of work required to make the change
• The magnitude of the effect of the deficiency requiring a change in terms of the user's needs (intended consequence of the change)
• The effect of the change on function of the change on the software itself. (unintended consequences of the change)

Marc said:

I would *think* this would be a gray area because the definition of major vs. the definition of minor would be not only company/project specific, but also customer specific.

Click to expand...

Marc is spot on but may actually be understating! Indeed, there are a number of factors influencing the decision. A "technically minor" may require extensive coding. Whereas a "one line change" may have serious adverse effects.

Each change would need to be assessed, at a minimum, for cost and risk.

Recognize that cost has contributors well beyond just coding. You may need to update design documents, there will be test efforts, there may be impact on user's manuals (updates, printing, distributing, ...), there may be end user training required, etc. So when assessing costs, be sure to involve ALL stakeholders.

Risk is hard to categorize. Any change to the architecture is clearly a high risk. Adding an element to a database table may seem innocuous but may have dire ripple effects. Changing the user experience may not be well received by the users or may cause confusion. Again, you'll want to get a diversity of opinion when assessing risk. Experienced software / systems engineers will be your best friend.

ShadinDC said:

Can someone tell me what examples make up a major versus minor change. Please list examples. Are there any other "changes" that don't fall within major and minor. Also, please list examples.
I feel like I'm in bureaucratic limbo. Of course this is a govt agency.
Thank you all very much for assisting me.

Click to expand...

I am not sure which government agency you are working with. If you are working with FAA, you may need this document as a guide to classify your problem reports.

ShadinDC said:

As a Knowledge Manager, I'm new to the business analysis field. I was asked to put together a list and detail what constitutes a major and minor change request for software. The software in question is Adobe Experience Manager.
This paper will be used by the customer (authors/content managers) to establish workflows for certain internal processes. Can someone tell me what examples make up a major versus minor change. Please list examples. Are there any other "changes" that don't fall within major and minor. Also, please list examples.
I feel like I'm in bureaucratic limbo. Of course this is a govt agency.
Thank you all very much for assisting me.

Click to expand...

Below is a table we use for resolving software bugs and when making any changes to the software which includes some examples of changes; for some reason I can't attach files to my posts or I'd have attached the actual table I use. Once a change is requested, it's analyzed for impact and determination of what testing needs to be done to ensure the change worked and didn't adversely affect anything else.

Most Severe:
MUST be fixed. Problems that dramatically interfere with the reasonable use of the product.
- System crashes or hangs
- Missing critical functionality
- Inability to install
- Jeopardizes:
? data integrity,
? product integrity,
? critical functions

Fairly Severe:
Must be fixed. Problems that seriously interfere with reasonable use of the product; problem work around does exist, but is awkward, difficult to perform, or impacts performance.
- Failure to recognize and report significant error conditions.
- Overall performance deviates from goal greater than 10%.
- Increases chance of product failure.

Minor Problems:
Easy work-around, problems and anomalies generally not apparent with normal product use
- Help text inaccuracies.
- GUI inconsistencies.

Very minor problems: Cosmetic in nature which do not effect product use
- Incorrect text on button.
- Wrong color on an object.

No problem: Enhancement or request for change
- Change suggestion for next update of software.