Rethinking Requirements (5)
- Defining for Beyond Today
As our discussion on rethinking the process defining our requirements develops, we find that much of our thinking continues to be framed within the world as it exists today. This can limit how we look at future requirements.
If we look at our current systems, we can see how they support operations that were not part of what was originally planned when that system was implemented. Some of these functions may even go well beyond anything considered at that time. Yet, somehow, the system supports these requirements; sometimes well but often with compromises.
Opening our eyes to how our systems of today handle the un-planned for helps us understand that we must consider the fact that new requirements and functionalities are likely to develop during the life span of the systems we are currently defining. Just how should we consider these requirements; or better yet, how do we prepare for these undefined, or even ‘undefinable’ requirement.
Some call this process “future-proofing”, and while the history of future-proofing has far more failures than successes, it is still a worthy exercise. Conducted thoughtfully it can provide value throughout the life of the system by allowing for the ‘open hooks’ needed so that future functions and technologies can be given appropriate consideration. Conducted without the proper care it can cause significant costs without providing matching value. The challenge is addressing the likely future, without incurring costs for unlikely needs.
Just how do we find these “future requirements”? It is not always easy, but with some thoughtful analysis we can find good information sources. One of the best processes is to start with your current requirements and evaluate that factors that drive them.
Given the range of requirements we deal with, the information we need will come from significantly different sources depending on the specific requirement we are considering. To simplify our discussion, we will use the requirements for radio coverage area as an example.
We know where we absolutely need coverage today based on our existing service area. We also know where coverage is lacking today based on a review of calls for service and reported coverage gaps. Going beyond these two factors., future coverage requirements are all too often defined simply as “more” and “better”, but we need to improve that definition.
In looking at our future requirements, we need to consider; “what drives our coverage requirements?” A significant driver may be commercial and residential development within your jurisdiction. A second driver may be the annexation of and area or district that is currently outside your jurisdiction, and a third may be interagency agreements that expand you operating or service area beyond your existing jurisdiction.
While knowing how these will change in the future with a high level of certainty is difficult, it is very practical to review your jurisdiction long term planning process and documents, and even open discussions with the jurisdictional leaders who oversee these decisions. Using those discussions and some research, it becomes possible to develop scenarios for growth, and evaluate how your planned system could adapt to those changes.
As an example. you might have multiple options for tower selection that each provide near equal coverage of todays requirements, however one option, when compared to the others, may provide an easier migration path towards a likely growth scenario. Working through this process may cost nothing but a little time and effort yet could deliver significant cost savings if and when the system needs to be expanded.
A similar process can be applied to system sizing parameters, such as number of radio channels for the system or number of seats for dispatch. In both cases, the factors that drive the decision can be analyzed, and data driven scenarios can be developed for inclusion in system design criteria. Utilizing this process will yield a much more accurate design than the typical method of simply including a fixed percentage for system growth. Especially when that percentage has little or no underlying support.
An issue that needs to be considered is that as we move into a world where more of our systems are delivered “as-a-service”, these factors may become more easily addressed. Often adding capacity to a ‘service’ becomes less of a technical process and more of a contractual issue. However, this should not be an excuse not to do our homework when developing our requirements, since a well-developed requirements definition process not only helps address changes in your operation over time, but helps prepare for changes in the technologies used to address those needs.
Whether you are looking at services or systems, a thoughtfully evaluation of not just your current requirements, but also how they may change over the anticipated life of the solution being procured, can only help in making sure your agency’s needs are met on day one and into the future.
