Have you looked at modules in Rational Requirements Composer (RRC) or DOORS Next Generation (DNG) yet? If not, I would suggest you take a look to see if it can help you better organize and manage your requirements. We think they're kind of a big deal, but we'd love to hear what you think of them. We know we still have work to do, and we'd like to have your input to influence our design directions.
First, I'd like to briefly describe what a module is, and some of the reasons why we think they're a big deal. Then, I'll tell you about where we think we need to focus to make it more usable and ask for your comments on the design direction.
Modules were introduced to RRC and DNG in Version 4.0.1 as a way to organize, structure and provide context to requirement artifacts. (If you're a DOORS user, you already know about modules, although modules in DNG and RRC are different in some significant ways). Prior to V4.0.1, the primary way to organize and structure requirements was through "composite" documents or collections.
A composite document is a "master" document that embeds requirement artifacts, and provides the structure and context around those requirements. Composite documents can read like a requirement specification document, but are limited in management of those requirements; you can't edit the requirements directly from the master document, you can't create views or filters of those requirements, and you can't show requirement attributes on all the requirements (you can only hover on one embedded requirement at a time to see it's attributes).
Figure 1. Example of a composite document. Note that the numbers are manually added. (Click to see larger image.)
A collection also allows you to group requirements. With collections, you can show attributes of the requirements in the collection (in separate columns), and create views and filters on those requirements. However, they are unordered and unstructured, so they don't read like a specification document and are not as easy to consume.
Figure 2. Example of a collection. (Click to see larger image.)
Modules combine the best of composite documents and collections, and then takes it up a notch. Modules are a collection of other artifacts, and use the same "grid" display for artifacts that collections use, so you can show attributes and create filters and views. However, modules allow you to order requirements, create a hierarchy and add headings, so you can provide structure. Headings are also automatically numbered based on their position in the hierarchy. So a module looks like a requirements specification document and is easier to consume. Additionally, you can edit requirement content and attributes and create new requirements right from the module, so they are easier to manage as well.
Figure 3. Example of a module (Click to see larger image.)
I'd like to mention a few more things that make modules a big deal before talking about what we'd like to improve in the future.
Context-specific properties. As with composite documents and collections, artifacts can be reused in multiple modules; and changing them in one place will change them in all places they are used. However, modules do provide a few context-specific properties. When you add comments, tags and links to a requirement artifact in a given module, they are specific to that instance of the requirement in that module. You can also link to a specific instance of a requirement within a module.
Module templates. Module templates are a step up from standard artifact templates. You can create a module template which contains headings, process guidance text, and other things which you want to be common across multiple modules, as well as "placeholder" requirements for each section of the module. When a new module is created from the template, the common parts of the template will be reused in the new module (and later changes to those artifacts in the template will also be changed in the new module), but the placeholder requirements will be duplicated (e.g., new artifacts will be created just for that module).
Converting requirement specs to modules. If you already have a requirements specification in a single document (either in RRC/DNG or externally in a Word document), you can easily convert that to a module. There is an import wizard that will essentially look in the existing document, extract headings and requirements, create individual requirement artifacts for each of them, and put them into a new module. The resulting module will resemble the original document, but is now made up of individual requirement artifacts in RRC/DNG.
Future usability improvements
Hopefully I've convinced you that modules are a big deal. (Please, don't just take my word for it -- try them out yourself). That being said, we're just getting started. We know that we still have work to do to make modules read and edit like a requirements specification document, and make it easier to manage your requirements within a module. We've already received a lot of user feedback from beta programs, design partner programs, usability tests, Innovate conference, etc., so we know some of the things we need to improve. Below are some of the things that our module design team has identified as top priorities based on that feedback (as well as our internal usability reviews).
Future focus areas:
Simplify process of creating new artifacts within a module
- Avoid use of New Artifact dialog as much as possible; it breaks the user flow, it's confusing in the context of a module, etc.
- Make it easier to pick artifact type, be smarter about artifact type choices
- Be smarter about displaying artifacts as headings (e.g., specify "heading" artifact types that are always displayed as headings).
- Improve performance of creating and editing requirements in a module
- Drag and drop to rearrange artifacts within a module (in addition to the current cut and paste method)
- Improve module print (print what you see on the screen)
- Better review and commenting of artifacts within a module
- Easier to view and modify artifact properties within a module
- Easier to summarize and navigate within a module
Additionally, you can look at the following documents to see what our goals are, both from a product perspective and from a design perspective.
- From a product perspective, you can view the requirements specification for modules (presented as a requirements module of course ;-): 12640: URS-Core Module Support
- From a usability and design perspective, the following document summarizes and organizes some of the larger usability issues we are aware of with modules: 14840: Scenario: Using Modules
Finally, we welcome any feedback on our design focus. If you find additional usability problems or have input on our priorities, please let us know either through RTC work items or comments to this blog.
Kirk Grotjohn (UX Designer for Rational Requirements Management)