I'm an experienced BA and having a bit of a disagreement with our CMMI guy. Would love some outside perspective. We are a federal contractor working on a contract to do maintenance development on a system that was originally built by another contracting house years ago. We do not have the original requirements in documentation form.

Because we're just doing maintenence, our process is to get change requests, I dig out the detailed requirements and document them. We're supposed to also start and maintain a RTM, but we haven't yet. I started a draft of one that I like in Excel. It has columns for these data elements:

• business request number (from my BR document, for example BR1 or BR2)

• change request number (from our issue tracking system)

• BR reference number (the high level number from my BR document, for example 6.1.5.3)

• brief description of the change type (for example "change to dropdown list", "change to work flow", "new button", etc.)

Our CMMI guy wants us to have one RTM for the entire system. He wants the requirements in the RTM to each have unique numbers. He doesn't like my method because there will be multiple instances of 6.1.5.3 (to use my example above). To explain it another way, I am tracking requirements for each change request, but he wants one for the entire system.

Since the existing requirements for it aren't documented anywhere, he suggested that we just go into the system like a user and document the functionality that we can see and use that as sort of a skeleton.

Has anybody here had to try to document requirements for an existing, undocumented system? How did you do it? Also, how did you draft and maintain an RTM for it?

(I should add that we're not required to document the requirements for the existing functionality. Just get a skeleton of the existing functionality for the RTM. His thought is that over time we'll eventually have the whole thing documented.)