Once the inception phase of your project has been completed, a project will enter the requirements analysis phase. What role do configuration management (CM) and quality assurance/control (QA/QC) play during this phase of a project’s lifecycle? One might say that these methods have little to do with this phase, but I think both CM and QA/QC play big roles that have long lasting implications for the project’s future.
On a website discussing his book, E.R. Williams says CM’s role “is to document the system from requirements and include design and code and then managing any configuration changes to the product/system.” This would include any documentation and specifications during the requirements analysis phase of the project. While I agree with his sentiments, I think it goes much deeper than this. CM’s role is to make sure requirements can be traced back from the code to each level of requirements, i.e. business—functional to technical.
I am not the only person who agrees with this assessment. I found a good presentation on CM and requirements traceability that looks at CM’s role in this area. Some students from Kansas State University take a deep dive into the different ways you can have this traceability of requirements. Additionally, MKS.com has a short article that really drives home this point. While the article states that reuse is the main reason for requirements traceability, there are other reasons why it’s important as well.
The importance of CM and requirements also comes into play with how you “manage” your requirements. We have to face it: Requirements change—sometimes frequently—and you should have a plan to manage this change. I found an excellent resource on why requirements changes must be versioned, with the most compelling reason being that “71% of software projects that fail do so because of poor requirements management.” The article further breaks this down into poor CM for your requirements, mainly when it comes to versioning.
Let’s now turn to QA/QC and the role they play in the analysis and requirements phase of projects. You might be thinking, “With nothing to test what role can QA/QC really play?” This brings up the topic of requirements defects. Obviously, the earlier you find defects the better, but can you really find them this early? For the answer to this question I found a great article on requirement-driven testing. The neatest part of this methodology is it can be used in both waterfall and agile methodologies.
So I leave you with this question: Is CM and QA/QC involved in your requirements analysis phase?
Joe Townsend has been in the configuration management field for twelve years. He has worked for CNA Life Insurance, RCA, Boeing, UPS, and in state government. Joe has primarily worked with Serena tools, including PVCS Version Manager, Tracker, TeamTrack (Mashups), and Dimensions. He is an administrator for WebFocus and supports Eclipse users.