CM: The Next Generation of SCM Standards

Requirements, Software Requirements, High Level Requirements, Subsystem Requirements, etc.  What's important here is whether these terms represent "product" or "design" requirements, and what camp you're in, because that dictates what you mean by Requirement.  

My Vote:  Requirement, with a prefix when it is not a Product Requirement.

Artifact
Item, Artifact, Object, File, Document, Datum (Data), Record:  So what are the things we're managing in our CMDB?  Files?  Well if we're only managing Files, we're a first generation CM process.  We have to manage all sorts of data, in different sizes, shapes and forms.  Some need revision control, while this is an overkill (read overly complex) for things like Requests.  Some need Change Control - well, maybe all do to some extent - and some are just stored (e.g. attachments to a Problem).  

It doesn't really matter what we call these things.  And we're not going to get consistency here at any time in the near future because different things have different properties - like outputs of a process being referred to as Artifacts.  Good name, but so is Item, such as a list of Items making up the database subsystem.  Object is not a good choice in a software environment because of the obvious other connotation.  Document is all right as long as its used in the traditional sense only, otherwise it is simply too confusing to the average reader.  Similarly Data is fine if used in the small piece of data sense and not the large object sense which rarely comes to mind when the word is used.  Perhaps Record is a bit more inclusive in this case, but from a relational perspective, large objects are not really historically part of a record.  

The thing to avoid is that of taking an existing term with historical meaning and trying to stretch it into a wider (or narrower) meaning.  This causes confusion.

My Vote:  Item, Artifact , Record (in that order), but any of the others only in their traditional contexts.

Iteration
Iteration, Cycle, Internal Release, LifeCycle:  The development cycle.  What do we call it.  LifeCycle used to fit perfectly, with a new LifeCycle for each release. Then came Agile.  Now LifeCycle clearly has the meaning of Traditional LifeCycle.  Cycle is a bit too generic.  Iteration is good but does currently tend to imply Agile methods.  Still, there's no reason why, in a traditional shop, each release cycle couldn't be considered an Iteration.  Internal Release is OK except that it tends to imply "but not real releases".  But a Release is really an Internal Release that is followed by full verification, audit, product documentation and other packaging.  So we'll stick to dealing with the development cycle in this definition.

My Vote: Iteration, Internal Release (in that order)

Development Stream
Stream, Development Stream, Release Stream, Release Branch, MainLine, Product Branch:  So what do we call the sequence of development work done leading up to a release.  This may involve one or multiple Iterations.  It's really a stream of work activities including design, implementation, testing, documentation, etc.  So I like the term Development Stream, but that's a mouthful. I also like Release Stream, also a bit long, so I like the shorter term Stream.  Some like to use the terms Release Branch, generically encapsulating all of the work done along a development branch, and others MainLine, particularly if the Release Branch is the Main Trunk for the source code.  

The problem with both of these terms is that there is far more than source code in a development stream, and Release Branch and MainLine simply don't seem to