CMMI Levels and RMM Level 5 – Integrated Requirements

Book 5 in a stack of 5 books

Background

In our introduction to mapping RMM levels to CMMI levels, we presented background info on CMMI, introduced the IBM article on RMM levels, and posted an initial mapping structure. In this article, we will look at the definition of RMM level 5. We also look at the mapping from RMM level 5 to various CMMI levels.

CMMI to RMM Mapping

(larger version)

In the previous article in the series, we looked at how RMM level 4 – traced requirements processes map to CMMI levels.

RMM Level 5 – Integrated Requirements

In RMM level 4 we discussed the benefits of establishing traceability within the scope of the requirements realm. This traceability helped us with tracking the impact of changes and validation of requirements, and it helped us with reporting and management functions that improved our insight and lessened our efforts.

RMM level 5 extends this traceability concept beyond the requirements realm. We can extend tracing into development, testing and documentation, as well as project management.

Delivery Scheduling

Each delivery of our software includes a set amount of functionality. We prefer using a timebox approach for planning those deliveries. We also suggest using use cases as the “pieces” of functionality that are delivered. We also have proposed an approach to managing changes to the delivery schedule. This overall process is a form of integration of requirements, and is dependent upon having organized, structured, traced requirements. It also requires us to create linkages between implementation elements/effort and the requirements that are supported.

Quality Assurance

There are two elements of integration between QA and requirements. The first is in defining test cases based on use cases. Each use case drives the creation of one or more test cases that are used to validate that the delivered software meets the requirements.

The second element is in tracking and management of bugs. We have a triage process for determining how to address bugs. Those bugs can come from anywhere – and sometimes they come from incorrect requirements. Establishing relationships between requirements and bugs allows us to manage the defect resolution process more effectively.

Documentation

When we write documentation, our goal is to have the reader know how to accomplish something that they want to do. When we develop software, we define the things that users will be able to do. It only makes sense to structure documentation around use cases.

Mapping CMMI Levels to RMM Level 5

In our diagram, we show the following mappings for RMM level 5:

  • CMMI level 0 – No Entry
  • CMMI level 1 – No Entry
  • CMMI level 2 – No Entry
  • CMMI level 3 – Requirements Should Be Integrated
  • CMMI level 4 – Requirements Should Be Integrated
  • CMMI level 5 – Requirements Should Be Integrated

For CMMI Level 0 through CMMI Level 2 – when our process is unmanaged, and unstructured, integration doesn’t matter. Requirements management software will not solve our problems.

For CMMI Level 3 through CMMI Level 5 – Being able to quantify the performance of our process, and improve our process based on that feedback both require an element of instrumentation and insight into our techniques and tools. Attempting to do that meaningfully without additional structure and traceability will provide limited benefit. If we’re investing this level of effort in our requirements process, we should extend it to include our overal software development process by integrating to other systems.

From a CMMI Level Perspective

The previous analysis basically looked at the “RMM level 5″ column in our grid, and inspected the relative decisions for each “CMMI level” row. Now we will look at it by reviewing the CMMI levels, and seeing how they map to the RMM level.

A quick review of the same chart (so you don’t have to scroll up and down):

CMMI to RMM Mapping
(larger version)

At CMMI level 1 through CMMI level 3, we don’t address integration with other systems. We want to focus on getting a cohesive and powerful requirements management process in place before we look at integrating it to our other processes.

At CMMI levels 4 and 5 we are measuring and improving on our process. We require traceability as a key component to our quantified analysis and instrumentation. We should be extending that traceability beyond the requirements realm to maximize the value of what we are doing.

Summary

  • RMM level 5 specifies that requirements documents are organized, structured, and traceable – both to each other and to other systems.
  • Once we reach a company-standard process (CMMI level 3) we should be at RMM level 5, but we must have reached RMM level 2.
  • RMM level 5 is never required to achieve any of the CMMI levels – but it is valuable and encouraged.

Don’t forget to take our One Minute Survey on CMMI and RMM Levels.

  • Scott Sehlhorst

    Scott Sehlhorst is a product management and strategy consultant with over 30 years of experience in engineering, software development, and business. Scott founded Tyner Blain in 2005 to focus on helping companies, teams, and product managers build better products. Follow him on LinkedIn, and connect to see how Scott can help your organization.

2 thoughts on “CMMI Levels and RMM Level 5 – Integrated Requirements

  1. Scott,
    I have looked at some technologies for managing products, like Accept 360 from Accept Software, and use case requirements management tools like OptimalTrace from Compuware. I’d like to know how you manage products and requirements? Do you use Word, Excel, and Visio like many of us or do you use a dedicated set of tools? We seem to always be behind the 8 ball trying to track, manage and plan our products, requirements, defects while still writing content for marketing collateral, training sales and others, and doing numerous sales assistance tasks (RFP responses, sales calls, etc.).

    Tim

  2. Hey Tim, thanks for reading and for asking a great question!

    Most of my decade has been spent in a consulting role, which means I end up using the products/techniques/processes mandated by my clients. Occasionally I get to help them improve or change their processes and tools.

    To date, I’ve not found “project management” and “requirements management” in the same application / solution. I’ve always had to either juggle two systems, or roll-my-own (usually when the client did not have anything in place and project timelines / politics prohibited introducing something).

    I can’t give you a “magic wand” solution, I don’t think it exists (yet). Here’s some of the different stuff I’ve used and my thoughts. Skip to the end if you just want my opinion on what to do. Read through the next section if you want to see stuff I’ve done, which puts my opinions in context.

    In the “using products that already exist” camp, I’ve used the following products. I’ve included my “skill level” info, so you can put each opinion in context:

    • MS Project : Standard, generic, overly complex for managing dependencies (imho). My skill level: marginally competent. I know enough to believe that there are good ways to use this product. I haven’t had the pleasure of working with / learning from anyone who can do that on a large project (> a few man-years of effort). I’m sure those people are out there.
    • Caliber RM : Great schema for managing requirements data. Expensive. Horrible for managing communication. Almost an “input only” tool. I had the most success when pulling a local copy of the database, and generating a static HTML “report” that was really a significant sized hyperlinked website. I was able to create the actionable reports / warnings that were not apparent from the application’s UI (like the impact of schedule delays propagating through traced requirements to affected use cases). My skill level – expert(ish)
    • Version Control “solutions” for requirements
      • MKS – expensive. Custom ant scripts made this much better. My skill level – power user on MKS, expertish on ant.
      • VSS – yes, I’m that old. Data corruption issues make this not worth talking about.
      • Sharepoint – ugh. Maybe Sharepoint 2007 will be better, but managing docs (and links) with previous versions was at best clunky. My skill level – competent.
      • Network Share – Versioning files by date, keeping an archive folder, regular backups (both in the network and to my hard drive). Batch files and cron jobs (scheduled tasks) combined with Beyond Compare (great shareware diff-tool) make this workable, but still reliant on people and process. My skill level – power user.
      • subversion – Free, open source, and my hands-down favorite. My skill level – beginner.
      • Lotus Notes – Great when customized. Closed format, only useful when you already have it ingrained in the corporate culture as the source of ‘everything’. Actually evolved some very powerful collaborative databases for in-house teams. Also allowed integration of project management activities (used a Notes DB for that too). Note – this is more than just a repository, it is a working “solution” – but it also served as a repository, so I’m listing it here. My skill level – expert.
    • MS Excel – When you know what you need to track, and what you want to report, you can make this work. You’re using a hammer to drive a screw, but you can get it done. I’ve had the most impact/satisfaction when using it to track a work breakdown structure against a set of requirements, including PERT estimates and reconcilliation of estimation quality over time. I’ve also used it effectively to create auto-populated scorecards for reporting project status. If it were less arcane, I would automate linkage of scorecards to powerpoint. Warning: I’ve also been on projects that ABUSED excel as a requirements repository. Change management is all but impossible to do effectively. If you’re managing multiple releases in parallel – forget it. My skill level – expert.
    • MS Access – I’ve rolled my own here before too. Once for tracking requirements, and once (more significantly) as a test-automation tool. The effort to benefit ratio is too high to encourage using this. My skill level – competent.
    • Visio – I love Visio. Been using it since before Microsoft bought it. I’ve never tried to generate stuff from diagrams, I would look to Lombardi or other vendors to pursue that. I have generated diagrams from source code before (to map dependencies, etc). If using a .NET language, there are solutions that do that for you (and probably for others as well, I was working as a developer in a proprietary language at the time). The ability to create custom shapes and templates makes it a lot easier to standardize diagramming across a project, and get some work-efficiencies for the team. When diagramming processes and building UML models, I go here first. So easy that I don’t try and use rational or other UML tools. The value is in the visual, and it’s easy with visio. Why learn something else? My skill level – power user.

    I’ve also rolled-my-own as a C# application, which dabbled in project tracking, but was truly focused on test automation. A bit off-topic, but I would say it is a quick and dirty approach to getting a small team to improve their process. A couple of months of development and we had payback within the first month (on a team with ~ a dozen developers).

    Looking forward
    I’ve just discovered what might be the ideal software project management solution – devshop. It is a hosted SaaS project management tool that is optimized for software projects. I haven’t used it yet, but I’ve watched all the demos. Here’s my takeaway – looks like it has all the project management stuff I need, and makes leveling/scheduling easy. Not sure exactly how multiple-concurrent-releases would work, but looks very promising. Addresses what I would consider to be the most important elements of risk management. Allows for tying of “SRS level requirements” and designs to specific deliverables. No requirements-specific support. I will absolutely use this for the next project that I can.

    For tactical requirements management, honestly, none of the solutions appear to be good enough for me to encourage their use. Someone needs to do for requirements management what devshop appears to have done for (software) project management.

    For strategic requirements management / product planning – FeaturePlan may be the way to go. I’m a big fan of Pragmatic Marketing’s approach, and the demo shows what appears to be a compelling approach to managing the process from market research to requirement identification.

    I would love to hear what others suggest – especially their opinions on other solutions, and stuff they’ve done to “make it work”. What do y’all think?

    Oh – and if you’ve used devshop or FeaturePlan – you must tell us your impression!

Leave a Reply to Scott Sehlhorst Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.