Figure 5-8 Impacts on team characteristics as functional and non-functional requirements characteristics increase
For example, as the number and complexity of functional requirements increase, we will tend to need bigger IT teams (TT Team Size), and bigger IT teams often end up being located in multiple locations (TT Team Locations). Similarly, large non-functional requirements often require using many specialized TT skill sets (IT Team Skills), which, in turn, may also increase IT Team Size and IT Team Locations.
These relationships can help determine how to create project teams of appropriate size and complexity to match functional and non-functional requirements. But assessing team characteristics in an existing team can help make sense of these relationships in the opposite direction. For example, if you are newly assigned to an existing team, take a look at the IT and customer team characteristics: a large, highly specialized IT team suggests both high functional and high non-functional requirements (and, if not, then that team may need to be reorganized). Similarly, a large, diverse customer team will often result in diverse requirements. Needing to support many users also tends to increase non-functional requirements (e.g., Performance).
5.5.2 Making Sense of Project Characteristics at a Glance
As noted previously, systems projects are highly complex, requiring the measurement of many factors to describe them and thereby select the best project approach. Fortunately, once these values are plotted, we can use a project characteristics radar chart to quickly characterize the project and determine the right approach to use We illustrate this process using a series of minicase studies.
Minicase 5.1: Creating an Internal Analytics App to Analyze Prescription Drag Use
Consider a situation in which we want to create a data analytics application to analyze prescription drug use in our 12C2 pharmacies. This requires importing data from a single source: our own pharmacy administration module. Only a handful of pharmacy analysts will access the app, and they can do so within 12C2’s internal secure network, not via the public intemet. We will use a database management system and data analytics tool that we already license and understand. While the pharmacy analysts may do some complex analyses, the current project only needs to create the database and populate it with data. Thus the number of features we need to create is small.
How do we plot this project on the radar chart? Li 5- corresponds to this description. Here, we see the project plotting close to the center of the chart for nearly all factors. Only the non-functional factor “Criticality” reaches the medium level. This indicates the need to securely store sensitive health care data stored in the system. However, this doesn’t reach a high or very high level because we don’t need to expose the system for public access via the internet. The key takeaway here is that, at a glance, we can see this project is an excellent candidate fora highly agile project approach. In particular, we should minimize BRUF, and for BDUF, we should focus mostly on the Criticality factor.
10391
pdfcoffee.com-systems… q
)