Overview |  | Roles |  | Work Items |  | Views |  | CMMI |  | Index |  | Glossary |

Project Portal
| Alternative Practices collapse all
About Alternative Practices |
Requirements Management Specific Practice 1.4 |
|  | Requirements Management Specific Practice 1.4 ## Standard Approach — Conformance to Plan and Specification The Requirements Management Specific Practice 1.4 is written with the mindset that planning and functional specification is done early and is comprehensive. This approach necessitates having bidirectional traceability to provide context, governance, and dependency tracking. For example, a developer is assigned a functional requirement. It is one of more than 2000 requirements on project that has lasted more than two years. The developer uses the traceability to the plan to understand the timing of when the functionality is expected, and the traceability to the specification to trace back from the functional requirement to the linked customer input requirements (sometimes through more than one level of requirements) to understand the context. The project manager uses the traceability from the plan to the requirements to track when a milestone is reached as the requirements are “done” – as soon as all the requirements for a milestone are marked as done, the milestone is reached. Product Management maintains control over the product definition through the bidirectional traceability – if a requirement at any point in the traceability hierarchy is altered the other linked requirements are flagged as suspect and need to be reviewed and changed, as necessary. This approach appears to be ideal; everything is covered, nothing is missed, and you know when you are done. The only problem is that there is a great chasm between what the customer needs and what is produced. The developer is so far removed from the customer that she needs to research what the functional requirement means. How well are the requirements written? Are they being interpreted correctly? The project manager is tracking when the project is “done” with tasks that are not focused on delivering what the customer wants. Product Management spends its time trying to keep the requirements up-to-date and consistent with each other instead of making sure the product is staying current or ahead of the market. The organization strains under the weight of the process. ## Alternative Approach — Conformance to Process MSF for CMMI® Process Improvement is based on the more agile mindset that you do some general planning and understand the customer and their needs at the beginning, and then make decisions on the details as the functionality is added in small iterations. Conformance to specification and plan are therefore replaced by conformance to process. Context and governance are provided and the need for dependency tracking is reduced by the more agile process. The context is provided by personas, scenarios, small iterations, and the postponement of decisions. Detailed persona and scenario definitions tie the development directly to who the customers are and how they will use the product in a much more palpable way than the abstract traditional customer requirement. The small iterations are planned to deliver defined scenarios, the small size helping to reduce the amount of change that will need to be absorbed during development. The postponement of decisions such as what is really important to the customer, how the architecture will change to accommodate the additional functionality and quality of service updates, and even the detailed product requirements themselves means that everything is absolutely fresh at the time the developers are ready to code. The product and customer requirements are used to create a backlog of tasks for the iteration, so tracking the project is done by using a variety of automated reports and queries in Visual Studio 2005 Team System – no need to track using traceability. Also, work items can be linked to other work items. With the ability to link and how the context and governance are handled as described above, the need for bidirectional traceability for dependency tracking and impact analysis is greatly reduced, if not eliminated. The postponement of decisions means that change requests are going to be logged primarily against actual working code, not abstract requirements waiting to be implemented. Impact to existing code is much easier to assess. The change request can be linked to requirements, tasks, bugs, etc. While this isn’t “bidirectional” traceability, it allows anyone involved to quickly find related work items and modify them as needed.
© 2005 Microsoft Corporation. All rights reserved. MSF for CMMI Process Improvement: 1.00.0000.00 |