What Software Tools Support Requirements Management?

Requirements Management (RM) is a very complex task that can only be accomplished with the support of suitable tools. Even small software projects need at least some manual tools like index cards or flip charts for supporting clarification and communication of requirements.

This blog article investigates what kinds of software tools can be used for supporting requirements management. Specialized RM tools are spreading across the industry since a few years. (Look up our list of RM tools for examples.) We will see that they are only one of many different kinds of tools (although an important one) that support requirements practices.

This list of tool categories has matured over a series of inspiring discussions with my colleague Gerald Heller. I highly appreciate his contributions and comments.

Specialized RM tools have evolved dramatically over the past years: Functionalities of the individual tools have grown and improved very much, and the number of viable tool solutions has grown significantly. These tools define each requirement as a record of attributes (i.e., record-based RM), can link requirements with each other, and provide analysis, reporting, and document generation functionality. Perhaps most important, specialized RM tools allow for concurrent editing and change tracking. Increasingly, RM tools also offer to edit requirements in a manner very similar to text processors (i.e., document-oriented RM).

It is important to emphasize that specialized RM tools are not plug-and-play solutions. Rather, they are platforms that must be customized to the specific information structures, processes, and context factors of the specific software development or requirements management organization.

Within the family of specialized RM tools, two different groups can be distinguished: Traditional record-based RM tools and agile RM tools. Agile RM tools provide the specific concepts and processes for efficient agile requirements. According to common agile practices, they link requirements (mostly in the form of agile user stories) with tasks. So they represent a combination of RM functionality, project management, and issue tracking.

Specialized requirements development tools (RD; also denoted requirements definition tools) address the early phases of eliciting, analyzing, and documenting requirements. They provide functionality like brainstorming support and structured group discussions. RD tools evolve as an important addition to RM tools. On the long run, both tool types might merge into combined RD and RM tools.

For a more detailed discussion of RM and RD tools, you can refer to Gerald’s blog article on RM/RD tool characteristics.

Office applications and suites are still the most widely used tools for developing requirements specifications and managing individual requirements. Their advantage is that they are ubiquitous and everybody knows how to use them. Their severe disadvantages are that they are lacking any specialized RM functionality like treating each requirement as a separate entity and requirements traceability, and that parallel editing of documents is not supported. So, I recommend to use office applications (albeit in a well-planned and structured manner) as an entry solution for systematic RM, but to move to specialized tool support when needs become more complex.

Word processors are the office application most commonly used for RM, particularly for developing RM specification documents. It is highly recommended to define the structure of the documents prior to starting actual specification work, for instance by using templates and example documents. A person should be assigned to ensuring that the document structure is always considered and evolved when needed.

Several years ago, I witnessed a project that very systematically approached requirements management with Microsoft Word. They defined a master document, which consisted of several sub-documents. Each sub-document was written and managed by a separate team, enabling efficient work distribution. However, nowadays specialized RM tools with their advanced report generation features are the most efficient solution for such situations.

Spreadsheet software allows managing each requirements as a separate compound object of attributes and attribute values. This comes at the expense that a requirements can only be presented as lists or tables. Document-like views are hardly possible.

Presentation software is also quite often used for defining specification documents in the form of slide presentations. However, such specifications tend to stay on high levels of abstraction. People usually don’t put much detail into these specifications. This can be acceptable for smaller work packages in stable environments. But it will definetely be insuffient for any larger development effort.

Visual modeling tools for developing and managing graphical models in notations like Unified Modeling Language (UML), Business Process Process Model and Notation (BPMN), or Systems Modeling Language (SysML) are an important pilar of many specificiations. However, in most situations they should not be the sole environment for defining requirements. Rather, visual modeling tools should be used together with and integrated well with specialized RM solutions.

Issue tracking software (also denoted request, problem, or defect tracking software), especially in its variant of work item tracking software, is also a frequently used solution for implementing and supporting RM. In particular for situations where individual requirements need to be managed instead of large compound specification documents, issue tracking software can be a very viable solution for RM.

The tool categories described above might be the most relevant ones, covering the vast majority of RM tool applications. However, there are also several other categories of software tools that can be used effectively to support RM:

In addition, there are some tool families that can add specific value to RM tools:

  • ALM suites integrate RM functionality with support for many other development activities and phases.
  • Testing and test management software enable or facilitate requirements-based testing.
  • Configuration management and revision control tools add specifically to office applications and partly compensate for a shortcoming of office applications when compared to specialized RM tools.
  • Software engineering platforms and integration middleware integrate RM tools with other tools along the development lifecycle.

Having now unfolded the wide spectrum of RM tool support, what do we learn? First, there is not one single best way to tool-based RM. Rather, every organization must consider its specific situation and constraints (e.g., tool solutions in place for other development and management areas) and develop its customized RM tool solution.

Second, specialized RM and RD tools provide a reliable basis for RM, and they will continue to becoming increasingly important. The wide variety of different RM tools creates new challenges: How can we systematically evaluate and select the tool most suitable for us? How can we consolidate a grown tool landscape that includes many different RM tools? How can we align the usage of a consolidated RM tool across several independent entities of a larger software organization?

So it is clear: Tool-based RM will progress further, and we are looking forward to a highly interesting (while challenging) future.

Pathways to Requirements Based Testing

Andreas Birk published the article “Pfade zum Requirements-basierten Testen” in issue 17 of the German SQ Magazin. He elaborated several paths how to achieve requirements-based testing. In summary: Test manager can benefit substantially from an established requirements process. Therefore it’s in their best interest to take action and drive the requirements practice in their organizations.
The SQ Magazin is available from the ASQF website.

Who Owns the Requirements

When it comes to the question of who owns the requirements the answer is sometimes surprising.

Depending on the titles used in an organization we may hear requirements analyst, business analyst or product manager. Others might name development manager, solution manager or system analyst. While all these people have to say a lot about requirements the product manager should have overall responsibility for the requirements.

Why that? Well, it is the product manager who is ultimately responsible for the business success of the product. He provides product direction and sets the goals for product releases. Through his direct connection to customers and the market he knows best what customer problems are and understands current offerings of competitors. Therefore he is optimally equipped to guide the business team.

Unfortunately, in most organizations the product manager is a poorly defined role. Often product managers get many things to work on, typically too many to be effective. A recent study clearly indicates that product managers work too often on tactical tasks, like customer escalations and supporting sales inquiries.

Successful organizations understand that product management must be balanced between tactical and strategic tasks. However due to the lack of a common understanding of all these tasks it is often a time consuming ineffective effort. Tools that provide an overview of all product management activities accelerate this work substantially.

In October 2010 I gave a presentation at the German “Requirements days” in Munich where I presented some of the fundamental activities in software product management.

Interestingly I got quite some feedback from people, who see a need for clarification specifically in organizations who move towards agile. The simple approach that a product manager equates to a product owner in Scrum doesn’t work out well. On the other extreme product managers might position agile product development to effect only the development organization. They continue to work as before not realizing the full potential of agile development.

Independent whether a software organization works agile or traditional a framework of software product management activities will enable them to improve its effectiveness. That’s why the International Software Product Management Association (ISPMA) pushes towards a certification of software product management.

If this topic is of interest to you, then get in contact with me and/or download the presentation.

Requirements Prioritization

Beyond the Limits of One-Dimensional Lists

Prioritizing requirements for a software release is an activity which frequently crosses the border between science and psychology. The goal is to determine the right set of things to do for a release. For many IT projects this turns out to be a moving target.

In software product development, requirement priorities are set by the product manager. Typically a product manager focuses exclusively on the market need of a requirement and its selling potential. Excellent software companies look at additional factors as well:

  • Cost
  • Risk
  • Fit to product strategy and architecture
  • Ability to deliver

Creating estimates for these factors cannot be done by a single person. Experts from different domains are needed.

There is a couple of techniques available to cope with this issue. Most of them are based on “cost-value” approaches. In my projects, I have applied a variety of them ranging from simple to complex ones. Often we started with something similar to Karl Wieger’s requirements prioritization approach (see www.processimpact.com).

Ultimately, these techniques yield a list of requirements ordered by their relative priority. Such a list is charming because you can always pick the most important requirement next. It is so charming, that this approach has made it into today’s most prominent development approach: Agile methodologies. In agile projects, the term “product backlog” describes a priority-ordered list of work items, which are addressed from top to bottom.

However, there are some shortcomings with these approaches, which need to be overcome in industrial practice. The key problem is the underlying assumption that requirements can be prioritized independently from each other.

Experience shows that this is seldom the case. Most requirements are interdependent from other requirements.

Across many industry domains including software and IT, the fundamental approach to building a system is always the same: A high-level plan is decomposed until the units of work are manageable. Elements of such units share some characteristics. They belong to the same domain and have similar complexity. Rating such elements in relative order works well. However, if the elements are from different domains, you may run into problems: They might have architectural dependencies which cannot be addressed in isolation. Many times, I saw projects getting stuck, because one team was waiting for something that another team had decided to lower in priority.

This problem of deadlock situations can be addressed by explicit dependency management. In requirements engineering, the concept of traceability is used to manage dependent work-items. Directional links express dependency relationships. These techniques exist and are available in most modern requirements management tools. However, in practice, these solutions can be very hard to accomplish, because they require more discipline than most projects are able to bring up.

So I recommend to deploy lightweight traceability using tagging mechanisms at requirements. Sometimes multiple backlogs are used. Each backlog holds items from the same domain. I have seen such approaches working pretty well in many project situations. So they might be the optimal solutions with the right mix of rigor and flexibility.

And don’t forget the importance of communication: Whatever approach one uses, it will be successful only if it is accompanied by good communication structures in the organization.

Two Essential Stages of Testing

Good test coverage is important and sometimes not easy to achieve. A simple principle can lay a solid foundation for test coverage: Distinguishing two essential stages of testing.

The initial low-level stage tests basic development artifacts immediately or soon after they have become available. This is usually called component, module or unit testing.

The later high-level stage tests the entire system or its higher-level aggregates as early as possible and lasting until very close before product delivery. This is usually called acceptance test.

The concepts of low-level and high-level tests are not new. Important is to relate them to different phases of the development cycle (or to activities within agile iterations, likewise; levels become stages) and to systematically plan associated activities. This way, good test coverage  can be achieved very efficiently.

Low-level testing stage High-level testing stage
Tests cover implementation of each basic development artifact from an implementation point of view (white or grey box testing) Tests cover design of the entire system or major system part from a business or usage point of view (black box testing)
Test cases defined by developers; derived from requirements and design Test cases defined by testers, domain experts from the software team, and/or customers; derived from explicit requirements or tacit domain knowledge
Tests conducted by developers Tests conducted by testers and/or customers or users
Defects usually fixed immediately or otherwise entered into defect database Defects usually entered into defect database, fixed, and being re-tested

I have seen many projects in trouble, because they did not properly address these test stages. Sometimes, low-level testing was replaced by pure faith (“My programs always run well”). Sometimes, high-level testing was shallow and ineffective (“We don’t have any time for more tests”). Often, the relation between both stages was not managed well, lowering product quality and limiting the efficiency of testing.

Taking care that both stages of testing are being addressed is a first and important step towards improved testing. Both stages are complementing each other well, so that higher test coverage can be achieved without very little planning and qualification efforts. This is also a good basis for subsequent improvement activities.

Additional details on the concepts of low-level and high-level testing are described in the testing literature, although the relation between the levels and phases of the development lifecycle is often not explored very much. A very instructive book is TMap® Next by Koomen et al. (2006). Another elaboration on the two testing levels are Brian Marick’s agile testing quadrants. Lisa Crispin’s presentation on  agile test planning provides a detailed explanation of those quadrants. Finally, an inspiring reflection on testing is Robert L. Glass’s text on The Many Flavors of Testing.