CM: THE NEXT GENERATION of Quality Requirements

is made:  The
team commits to a set of requirements in a given timeframe.  After that, the allocation of requirements to tasks are usually organized to suit the development methodology, Agile, Waterfall or otherwise.  A series of work breakdown structures [WBS] (or perhaps one large one) is used to manage the tasks required to meet the commitment.  In my books,
it's preferable to have the "System/Design" level requirements tracked as the same object that project management is going to use in its WBS.  And there is a whole set of project management information tracked against these requirements that are not tracked against the Customer/Product requirements.

Either way works as long as the lines of authority and the required information are respected.

So, as a CM/ALM provider, we want to be able to manage changes to the requirements at all levels, and we also want to be able to track and support full traceability, not only to the test cases, but to the very test results themselves.

Managing Requirements

To manage requirements we need to look at the process in the small and in the large.

In the small, requirements will change.  We therefore would like to have revision control exercised over each requirement.  In that way we can see how each requirement has changed.  However, just like for software, a series of requirements will change together based on some input.  So we also want to be able to track changes to requirements in change packages/updates that package multiple requirement modifications into a
single Change.  We may want traceability on such a change back to the particular input which caused the change.

The CM/ALM provider must provide both of these functions, with as much ease-of-use as possible.

In the large, we have to understand that change will continually happen.  However, we don't want to be jerking the development team around every time a requirement changes.  So instead, we deal with releases of a requirements tree.  Perhaps this is done once per significant product release; or maybe it's done for every iteration or every other iteration of an Agile process.  A good rule of thumb is to look at product releases in general.  There are new features that you'll target for the next release, and there are some things that really have to be retrofitted into the current release.

A development team can deal with occasional changes to their current project schedule, but don't try to fit all of release 3 into release 2 - that's requirements creep in the extreme.  Create an initial requirements tree for release 2, and baseline it.  Review it with the development team so that they can size it and give you a realistic estimate on the effort required.  Go back and forth a couple of times until you reach a contract between Product Management and the Development Team.  Then baseline it again and deliver the Release 2 spec to development.  Everything else goes into release 3.  If it truly cannot wait, you then need to renegotiate the contract, understanding that either some functionality will be traded off, or deadlines modified.  Don't expect that more resources
can be thrown at the project - it won't work.  Your process should allow only one or two of the "must change" negotiations in a release, and they need to be kept small.  If not, you will need to completely renegotiate your release 2 content and contract, after agreeing to
first absorb costs to date.  Remember, if you reopen the can of worms, you may never get it closed again and the costs are already incurred and will continue to be incurred until such time as you reach a new agreement or call off the release.

Now if you happen to have an integrated tool suite that can tell you easily where you are in the project, what requirements have already been addressed or partially addressed,