Requirements Release Management

If I had a Fiver for every time I have heard this statement I would have retired a long time ago. I would now be on a beach in Portugal sunning myself and wondering why I ever bothered battering my head against brick walls in trying to explain the obvious to IT Managers as to why they should be concerned with continuous Process Improvement.

The excuse comes from the other end as well. Product development teams moan that the business users are always changing their minds, that the requirements are always changing, that there is always another enhancement, etc. Well, that is life.

That is why we are here. That is business and the very nature of the environment in which we work. So, we have to get on with it and learn to manage it. That is where Configuration, Change and Release Management comes in.

If it is a product within the Product Lifecycle, i.e. a product in the small rather the product in the large, then we can assign it attributes and associations and manage it. It is no different, really, from a piece of code.

Once we understand and accept that Change is the only constant then the logical follow-up is to understand that we must be able to manage it. We manage it by recognising that Release Management starts at the very beginning of the Product Lifecycle and is not something that magically materialises towards the end. So, back to the real world.

A requirement, of some sort, gets produced. I will not go into the how, or to what standard or to the techniques here but as a small aside I would suggest you look at the old SSADM versions for the format of a requirement, which is still as good as any, and UML, which is pretty good and becoming widely accepted, if not used.

Incidentally, if you ever went through any formal design training years ago you will pick up UML very quickly indeed. Maybe Pam will permit me to write an article on Requirements Definition and Proving?

Anyway, the requirement is produced. It is not complete but we need to start designing. So now we need to profile our requirements as to their business usage. We need to define which requirements are essential and core to the business?

Which ones will be used most often? These are the ones that we have to focus upon. (A Sigma-6 focus on testing and quality?). So, one of our first attribute of the requirement is Business-Importance closely followed by Frequency-of-Usage. We also need Date-Raised, Owner, Who-Raised, Title, Name, System Area, etc.

We start to place attributes against the requirement that will help us manage it as a product entity in its own right. Given that we have limited time we also have to put its first iteration Requirement-Phase-Release-Date.

This is the date that the requirement will be released into design. In order to Release this product we need a few more attributes; Phase-Release-Date, Percentage-Completed, Expected-Release-Version, Target-Release-Date, Change-History, Next-Expected-Phase-Release-Date, etc.

We can now package the requirements into a Release Version regardless of whether they are complete or not. At this stage the Release Package goes through a Quality Gate which performs the Quality Audit to ensure that all the respective products are present and accounted for.

The target is to have them all there but as we live in the real world we understand that they will not be. So an issue is raised against what is not there or what is there but not complete and a Risk is raised against the potential of these products not being completed.

One of the key product deliverables at this stage are the Test, or rather Proving and Validation Criteria for the requirements. If they are not there then the package move fails. In my book, absolutely no debate on this one. Again, maybe Pam will allow me to write further on how this is done.

The package now moves forward into design but now with the knowledge that there will be changes. The argument that this will affect the design method and techniques is invalid as change would happen anyway.

The key now is Change and Configuration Management. With change comes impact and so Impact Analysis has to play a key role. Impact Analysis, at this stage, works on the Configuration Identification logical model that was created during the initial Requirement phase and was included in the Quality Gate Audit.

Also used in Impact Analysis are the attributes stored in the Requirements Catalogue and the Validation and Proving conditions stored in the Proving Database.

It is obviously not possible to go into the finer details in an 800 word article and this is an introduction. However, I have always been a great believer in the K.I.S.S. principle.

The other sayings that are popular are, "It doesn't work like that" and "That is not the real world". Well, I have been in IT and System Development for over 26 years man, boy and, some would say, hoodlum. It can, it does and, the Real World, it is.

Ed McMahon, Director Itiss Ltd
ed.mcmahon@itiss.com