This stage represents one of the most labor-intensive phases of the procurement project, but also one of the most fundamental and interesting. The objective is to complete whatever formal, properly-written documents are required to support the procurement moving forward, including detailed documentation of the IIS business requirements. Such a requirements document should be clear and unambiguous.

If procuring a new IIS, the requirements documentation typically includes functional, technical and performance requirements. Because this part of the process can involve many staff from across the immunization program and central IT, it needs to begin well in advance of issuing a solicitation (unless you have good documentation already, which ideally you do). Additional guidance on requirements is provided in the solicitation section.

Among the questions your core team should discuss and document are:

1. Do we have our requirements defined and documented?
   1. Have we reviewed prior requirements documentation?
   2. Have we asked CDC, AIRA or other jurisdictions for guidance or for samples?
   3. Does our intended procurement process have a specific format or template we must use for documenting our requirements?
   4. Who on the core or extended teams would ideally be involved in requirements gathering?
   5. Who on the core or extended teams would ideally be involved in validating draft requirements?
   6. Are the requirements testable? Do we have test scripts?
2. Is hosting outside of the jurisdiction, either vendor-hosted or cloud-hosted, an option for our IIS?
   1. If so, what technical and policy (e.g., security, liability) requirements must we and/or the contractor meet?
   2. What role(s) does central IT play in reviewing/approving external hosting requirements and agreements? What information do they need to make their decision?
   3. Will the procurement, legal or any other office need to review and approve requirements and agreements?
   4. What have we learned from other jurisdictions hosting in the way we are considering? For example, should the IIS vendor and the hosting service be separate procurements?

Considerations

See also the solicitation section for more guidance on writing and validating requirements.

• Clearly define the requirements. Carefully and precisely defining your requirements, particularly those that are unique to your jurisdiction or that go beyond the IIS Functional Standards, is indispensable to achieving your programmatic goals. Consider whether specific requirements are mandatory (“must” or “shall” meet) or just desired (“may” meet) and note this designation in the document.
• Carefully consider the importance and consequences of unique jurisdictional requirements not required by law. Customization of a commercial software product (versus configuration that’s enabled by the product) adds not only up-front costs but potentially downstream costs. For example, if you’re working within a custom build of a software product, you may not be able to benefit from future software releases without further customization or special testing. This is a very important consideration in terms of sustainability. Consider carefully the total cost of product customizations over a five-year or longer period of time.
• Include a business analyst on the team for requirements analysis. A skilled business analyst can be indispensable in gathering and documenting requirements.
• Seek sample IIS requirements from other jurisdictions but carefully review before accepting. Be careful not to adopt another jurisdiction’s requirements without thorough review.
• If you are procuring IT services (versus products) to enhance your IIS, remember that formal requirements documents are a feature of a traditional (sometimes called “waterfall”) approach to application development. Some jurisdictions and vendors are now using what is called an agile approach that emphasizes incremental application development and more real-time development of requirements as application development proceeds. Using a performance work statement or statement of objectives approach to procurement can provide more flexibility for you and the bidders with your solicitation. Be sure your articulation of requirements matches the style of services you wish to acquire.
  • If using more of an agile approach, you should ensure you have thorough and formal requirements documentation. This is important, for instance, to ensure that people other than the current development staff have the knowledge needed to understand the application structure and be able to make sensible design choices when the original developers are no longer available.