pdfcoffee.com-systems…
)
Figure 5-9 Project characteristics radar chart for a prototypical agile project
5.6 Functional Requirements: The Key Determinant of BRUF
With the idea of radar charts in hand, we now dive deeper into each radar chart category (Functional Requirements, Non-functional Requirements, and Team Characteristics). We then explore the meaning and impact of the individual factors within each category. Some of these factors are straightforward. For example, as noted previously, it is easy to understand how a large number (Number) of complex (Complexity) features would push as toward a more hybrid approach, including substantial BRUF.
However, there are a few factors that are less obvious. In particular, these include Interdependence, Clarity, and Stability. These factors go to the heart of the agile versus hybrid debate. As such, you may mn into these arguments in your professional teams, in the trade press, or in blogs. Further, many of these arguments tend to be one-sided in favor of agile. In effect, they claim to establish that “agile is always the right answer.” To help ensure that you make the
right choice for the success of your team, we delve into these three items with particular care. As you read through this section, please refer to Tables 5-1 and 5-2 to maintain a high-level perspective on these factors.
Minicase 5.2: A Major Update to a Legacy Manufacturing App
Next, let’s look at a firm that has been running its heavy equipment manufacturing business on a legacy application. Written in the 1980s in COBOL, the application consists of millions of Imes of code that are poorly architected, designed, and documented. Put simply, when we try to modify the application in one functional area (like logistics), we risk inadvertently breaking functionality in another area (like assembly-line scheduling). This issue is compounded when the firm decides that, to stay competitive, it needs to create dozens of new major system features, including communicating with suppliers using web services, adding significant new types of data, revising major supply chain and scheduling algorithms, using artificial intelligence to optimize warehouse operations, and so on. In this case, the firm may very well decide that we need to drastically overhaul the underlying technology and, beyond that, add in and integrate several new technologies. This may be the only way to effectively add all this new functionality. The IT team might not be well positioned to make all this happen—for instance, the team could be too small and lack the needed skill set. Further, to bridge these gaps, we may need to hire IT contractors in multiple locations outside the main IT office. We may also need to involve several of our factory team members and outside consultants to enact the changes.
How do we plot this project on the radar chart? Figure 5-10 illustrates this situation. Here, every project factor is plotting near the outer edge of the chart, at a high or very high level. At a glance, we know we should use a hybrid approach with high levels of both BRUF for functional requirements and BDUF for architectural planning. Team factors pertaining to coordination, communication, and training also loom large.
