Requirements Management
One of the tough points we found was the requirements management area where we were informal:
- SCM requirements are well-known. Making a new SCM system is not like developing new business software. You don't have to understand what customers want because you can be your own customer. You do understand what you are talking about, which is essentially good for software development. Then there is a whole set of bibliography on the subject. If you need to understand what a "repository," "revision," or "item" is, you can find a book, article, or a website where it is described.
- The entire team works together identifying and deciding about functionalities in a hierarchically flat structure. Clearly defining what had to be done, one of the main targets when dealing with requirements, was not as important for us because we all shared the knowledge.
- We weren't using user stories or other Agile requirement-management alternatives. We used a full-feature list decorated with descriptions only to explain our product's innovative capabilities.
It was clear we had to improve how we were dealing with requirements. The first step was introducing them as first-level players in Defect Control; see Figure 6. This way we were able to link tasks with requirements, tests, analysis, design activities, and the like. A traceability matrix (not a shaped matrix, but all the required information) was made available and we were able to grasp the impact of a change in a certain requirement. This was neither easy nor quick. Understanding and making the best use of registering each requirement took time and we are still adapting to it. Beyond CMMi, the internal motivation was creating an entire maintained catalog—not just functionalities, but also decisions that would help reviewing why a certain capability was (or wasn't) there. Basically, this was the benefit of requirements management we knew in advance, but it took time to spread throughout the team.
