pdfcoffee.com-systems…
• • Clarity: This is the second of three functional requirements factors where agile and hybrid approaches make different assumptions and therefore reach different conclusions regarding BRUF. Clarity refers to the degree to which we understand two things: (1) current state, or the current business processes and software, and (2) future state, or the envisioned business processes and software after the project is delivered. You might wonder how a team could fail to be clear about its own existing business processes and software. There are many reasons for this. For example, it may be that business policies and procedures are not written down. Similarly, different business users in different locations may do business and use the existing system in different ways. The IT team may not understand the application code itself. This is especially the case if the IT team has lost experienced members who were involved in creating the current version of the system. Lacking clarity regarding future state might seem a little more obvious: we clearly must work to understand the new features. This can be especially challenging if we have many users to interview or if those users lack the time or commitment to talk to us. However, the real issue for future state clarity is not whether we understand those future requirements. Rather, the real challenge is whether we can understand those future requirements before we build the software. For example, consider a start-up business that intends to implement a novel business model—for instance, the first-ever retail website or online ridesharing service. Today the functionality of the Amazon or Uber apps may seem obvious or intuitive, but it’s likely that before any such systems existed, it was hard for those start-up teams to imagine up front all the features and details the systems would need and how to build them. In other words, they could probably create some of the user stories, but figuring out the requirements in detail probably required an iterative “build a little, review a little, revise a little” approach. 0 • Agile assumption: Agile assumes that achieving a high degree of clarity is generally impossible. This is partly because agile assumes that software, as an intangible product, is fundamentally more difficult to envision than tangible items such as a house or car. Further, agile argues that implementing new software itself tends to shift requirements. Because of these arguments, agile assumes that the initial completeness and accuracy of BRUF will be low, lessening its value to the team. This is shown via the solid line at the bottom of the graph in Figure 5-14. o • Hybrid assumption: In contrast, hybrid assumes BRUF works because a well-defined set of requirements can be created with proper time and effort. If we are automating parts of an existing business process—for example, the drug-sharing process for the I2C2 pharmacy enhancements—this may well be the case. Hybrid would assume that in such circumstances we can create highly complete and accurate requirements via BRUF. This is shown via the dashed line at the top of the graph in Figure 5-14.
As with interdependence, sometimes we will be able to envision future requirements and other times we won’t. When we can, the value of hybrid BRUF increases. When we can’t, a more agile approach using emergent requirements will be more effective.
Clarity
The degree to which we understand (or can understand) the current and future state of the business and corresponding software requirements.
• Stability: This is the last of the three functional requirements factors where agile and hybrid approaches make different assumptions and therefore reach different conclusions regarding BRUF. Stability is the extent to which software requirements stay the same (or change only slowly) over time. 0 • Agile assumption: Numerous agile sources make broad claims that business requirements are changing more rapidly in a broad range of companies in recent years due to an increasingly dynamic market environment. This provides another explanation as to why agile argues against the value of BRUF: even if we can capture requirements completely and accurately at the beginning of a project, those BRUF specifications will become rapidly out of date during software construction. Thus agile argues for detailing requirements at the “last responsible moment”—right before a feature is constructed. This is shown via the solid line at the bottom of the graph in Figure 5-14. o -Hybrid nanumntinn• rnntract hvhrigi acelirnpe that rpniiilvmpnte