pdfcoffee.com-systems… q
)
Figure 5-10 Project characteristics radar chart for prototypical plan-driven project
5.6.1 Functional Requirements: The Key Determinant of BRUF
For the BA, functional requirements will always be a primary concern. In contrast, while the BA needs to address non-functional requirements—particularly when the BA is playing a project leadership role—designing solutions for non-functional requirements tends to be a more technical task. As such, the BA may “outsource” some non-functional requirements issues to technical specialists, including architects, cybersecurity specialists, and senior developers.
Given the primary importance of functional requirements to the BA, we focus on these factors first and foremost. To understand this, we return to the radar chart, and specifically to the upper-right “BRUF” factors sector of the chart. These factors help us decide between utilizing an agile approach that avoids BRUF, in favor of emergent requirements, versus a hybrid approach that does utilize heavy BRUF.
Minicase 5.3: Major Feature Updates for an Insurance System
An insurer has a system it uses to process health care claims—for example, those sent in by a doctor’s office or hospital. Processing a claim involves a series of interrelated, sequential steps: determining if the member is eligible, then checking to see if the medical service is covered, then determining the amount to pay for each service, and so on. The system performs quickly and reliably for the current 150 claims clerks who use it. The functionality is also generally satisfactory, and the requirements haven’t changed much recently. However, the firm decides to buy another insurance company, which will add about 100 additional users. The acquired firm has had significant problems with its system, so the buying firm decides to retire that system and move the acquired business to the existing system. Performance testing shows that the existing system can easily expand to support the added load. However, analysis of the acquired firm’s health care benefit plans shows that the existing system will need major new features to support additional ways to process these claims: calculating benefits, determining how much to pay health care providers, and so on. The acquired firm also sells life insurance, which is a functionality that will need to be added to the current system. Making this happen will require the existing customer team to communicate thoroughly, with a significant number of new customer team members from the acquired firm. This will make requirements discussions much broader than in the past.
How do we plot this project on the radar chart? Figure 5-11 plots this situation. The architecture and technology of the system appear to be satisfactory, so we may not need much BDUF. But we dearly need to implement a significant number of new, complex features. Given the way claims process in a series of related steps, interdependence is also likely to be high. Finally, if we involve both existing and new customers, we should be able to reach significant clarity about these requirements. Finally, the pace of change in these health care claims processing requirements has been fairly slow. Given these points, we should pursue a hybrid approach emphasizing heavy BRUF.
