Read this if you have a responsibility for acquiring and implementing victim notifications for your jurisdiction.
In the first article of this three-part series we explored the challenges and risks associated with utilizing multiple victim notification systems across your state, while the second focused on exploring what the choices are to address these challenges. In this final installment, we demystify the process of developing requirements for a victim notification system. Here are some things to address when developing requirements:
- Considering all of your victim notification stakeholders and their specific needs
- “Mining” requirements from your current victim notification system to ensure that your current needs are met in the future system
- Determining what the market can support (and what it can’t)
- Utilizing standards to increase the likelihood that market solutions, designed based on these standards, will meet the needs of your jurisdiction
Understanding the needs (and wants) of your stakeholder group is critical to defining a successful set of requirements that meets your specific needs. Representative stakeholders may include:
- Victim advocacy groups (both government run and private sector)
- Police and sheriff departments
- Department of Corrections
- The courts
- Probation department
- Prosecutor offices
- The victims themselves
Of course the stakeholder group in your jurisdiction may differ, and the needs of these groups will also differ. For example, victims and advocacy groups are concerned about ease of use, accuracy, and timeliness of notifications. Police and sheriff departments may be concerned about ensuring they are meeting their statutory and moral obligations to notify the victims when offenders are released from custody.
Since these groups have varied needs, it’s important to engage them early and throughout the requirements development process. Talk to them, observe their practices, and review their current systems. It’s possible, for example, that it’s important that sheriff departments can integrate their jail management system to the replacement victim notification system and the integration creates a seamless and timeline notification process when an offender is processed out of jail and into the community. Because the Department of Corrections is designed to hold offenders for a longer period of time, the department may require that their offender management system triggers an alert to victims when pre-release planning activities begin.
Scaling victim notification systems
Utilization of victim notification systems can also include a broad spectrum; from a single jail engaging with a victim notification system vendor to provide specific notification services, to a statewide victim notification system that provides these services for the larger stakeholder group. Because of this, your requirements must reflect that “scale.” Consider the utilization of the system before developing your requirements so that you don’t over (or under) engineer the system for your jurisdiction.
As mentioned in the second article in this series, there are many victim notification system options to consider, from home-grown applications to turnkey software as a service (SaaS) services. Regardless of the path you choose, consider leveraging the victim notification system standards as defined by the Department of Justice (DOJ) Bureau of Justice Assistance (BJA SAVIN Guidelines). These guidelines and standards are terrific sources for victim notification system requirements, and can be thought-provoking as you engage your stakeholder groups.
Though these standards are extremely useful, be sure to identify and include any jurisdiction-specific needs in your set of requirements. They may be driven by state statutes or by local policy or process. In defining your unique requirements, just ask, “Why are they important? Were they defined based on processes put in place because you don’t have a strong victim notification system, or are they critical to satisfying statute or policy?”
Stakeholder communication and engagement
Once you develop a preliminary set of requirements, it’s important to meet with the stakeholder groups to refine and prioritize the requirements. This exercise will result in a clear and concise set of requirements that are understandable by victim notification system vendors that may be responding to the resulting solicitation. When defining the requirements themselves, we find it useful to follow the guidelines from the Institute of Electrical and Electronics Engineers, Inc. (IEEE) called “IEEE Recommended Practice for Software Requirements Specifications.” According to the IEEE standard, good software and hardware requirements should be:
- Correct
- Unambiguous
- Complete
- Consistent
- Ranked for importance
- Verifiable
- Modifiable
- Traceable
Prioritization of the requirements also helps responding vendors understand which requirements are most important to your jurisdiction. This prioritization model can also be used when scoring the vendors’ responses to the requirements once proposals have been received.
Conclusion
In summary, it is important your victim notification system requirements reflect the needs of your stakeholders, are realistic, and clear. Vendors will be asked to respond to how they can accommodate the requirements, so using the IEEE method described above can be useful.
Though this article doesn’t dive deeply into the development of the request for proposals (RFP) for the victim notification system, below are some actions to take to improve your chances for a successful system selection project:
- Define a meaningful project scope to scale the vendor market
- Assign a balanced evaluation committee with impartial scoring criteria
- Craft a structured procurement package that attracts multiple vendors
- Design a reasonable and achievable RFP schedule of events
- Reduce ambiguity and increasing clarity of RFP terms
If you have questions about your specific situation, please contact our Justice & Public Safety consulting team. We’re here to help. The BerryDunn team has developed a mature methodology for determining victim notification system requirements, and has a rich repository of requirements to start with so that you don’t need to start from scratch.