Requirements Cross Components
In "Agile and Large Teams" (www.ddj.com/architect/208700162), 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 (www.ddj.com/development-tools/196603524), 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.
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.
