Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Why CMMi? Initial Situation The SCRUM Process Agile Concerns Requirements Management New Areas

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.

[Click image to view at full size]

Figure 6: Dealing with requirements.

Previous Page | 1 Why CMMi? | 2 Initial Situation | 3 The SCRUM Process | 4 Agile Concerns | 5 Requirements Management | 6 New Areas Next Page

RELATED ARTICLES Danube Releases ScrumWorks Pro 4.1 Why We Need a Theory for Software Engineering Nokia Takes Task Management For A Spin Programmer Productivity Integrating ALM: Lessons Learned Deploying Tasktop at Nokia		TOP 5 ARTICLES No Top Articles.