Channels ▼


Complex Requirements On an Agile Project

Requirements Cross Components

In "Agile and Large Teams" (, I described how large agile teams are organized into small agile subteams, often around the architecture of the system being built, and how the product owners of each subteam need to coordinate their efforts with the other product owners. The reason for this is depicted in Figure 3, which shows how a given usage requirement is implemented as a collection of smaller requirements implemented by different subteams. In the example, the yellow work items form a single usage requirement, with the lines between the work items depicting the logic flow of the scenario. The product owners on each subteam need to understand these dependencies between requirements and act accordingly. This coordination will occur via regular working meetings of all product owners, a "scrum of scrums" focused on requirements, as well as through impromptu sessions between individual product owners to iron out specific problems.

This is not only an issue within a single large system, it is also an issue between systems. Very few people sit down at their computer and use a single application all day long; instead, they use several in different ways throughout the day. The implication is that for the individual systems to add true value to the stakeholder, the required functionality of each system must be implemented. For example, assume that a banker uses a customer information system, an account information system, and a printing system to open a bank account for a person. Even though the new versions of the customer and account systems have been deployed into production and have the requisite functionality, the printing system has run into problems and won't be deployed for another three months. As a result, the new functionality in the other two systems will go unused, through no fault of their own, potentially making them appear to be failures. For several years now, IBM has acted on this realization and actively identifies green threads (, which are common usage scenarios that cross several systems, enabling us to better understand the needs of our customers and thereby deliver better product to them.

Figure 3: On large-scale agile projects usage scenarios cross several components.

Keep It Simple

Requirements often prove to be very complex in practice. Although agile methods, in particular Scrum, have offered good advice for simplifying requirements management, there is a distinct risk that their advice is overly simplistic and will put your project teams at risk. The advice of the traditional community, however, is overly complicated and bureaucratic, also putting your teams at risk. A middle road does however exist, as I've shown in this column, and you can address the complexities of complex requirements management without taking on the risks inherent in traditional change prevention strategies.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.