Before starting with the CATS+ TORFP Template, agencies should be engaged in the System Development Life Cycle (SDLC) process and have a dedicated project manager following Project Management Institute (PMI) or equivalent standards and methods. Agencies also should consider business process analysis, requirements workshops, benchmarking / demonstrations, and gap fit analysis before TORFP writing begins (see definitions below). These activities will help generate sufficient documentation for requirements and other key information for the TORFP. Questions about developing a TORFP may be referred to the DoIT Procurement Office at central.procurement@maryland.gov.

Below are recommended best practices to help ensure a quality TORFP and timely release. This information is advisory only, some elements may not apply to specific TORFPs.

Requirements Gathering:

• Start early! Allow plenty of time for requirements gathering.
• Consult key stakeholders for input on their needs for work processing and system functionality
• Use proven requirements gathering techniques, for example:
  • Business Process Analysis – Documenting work processes to identify how computer automation can yield improved process efficiency, accuracy, security, etc. This is best performed by a certified business analyst or industry subject matter expert, possibly under a separate procurement (see CATS+, FA 11 Business Process Consulting). The result of the process is requirements documentation.
  • Requirements Workshops – Meetings over several days where subject matter experts and IT specialists define and review requirements. Often referred to as Joint Application Development or "JAD" sessions.
  • Benchmarking / Demonstrations - Comparing a prospective business process or IT system to similar others already in production and considered successful.
  • Gap Fit Analysis – A comparison of COTS product functionality to business needs to identify shortfalls or "gaps." The result may be added software programming requirements or "COTS customization."
  • Stakeholder Interviews - The process of communicating with stakeholders to elicit, analyze, document, and validate requirements.

Requirements Identification:

• Ensure that all requirements are identified and defined completely and unambiguously.
• Create criteria for a "good requirement," e.g., clearly stated, testable, necessary, etc.
• Prioritize and identify minimum requirements.
• Identify functional / business requirements or what the system should accomplish (See Section 2.5.1 below).
• Identify technical requirements or how the system should operate and perform (See Section 2.5.2 below).
• Don't forget non-technical requirements, e.g., meetings, progress reports, user training, etc.
• Identify deliverables that result from requirements. e.g., software applications, reports, test results, etc.
• Avoid "gold plating" or adding extra unnecessary features to the requirements.

Documenting Requirements:

• Use an automated tool to document, track, and manage change to requirements.
• Number each individual requirement for traceability through development and testing. (See Example Requirements Matrix).
• Document the rationale for each requirement.
• As you document requirements, document "acceptance criteria" or what must be done to accept a requirement. Define what measures, tests, or observations will prove when the requirement is completed.
• Use precise wording for requirements, e.g., "three second response" instead of "fast response."
• Group deliverables under project milestones or system development phases.
• Create a glossary of TORFP or project terms and acronyms.

Resources:

• Assign a full time Project Manager (PM). The PM must be able to devote significant time to the project to ensure that all SDLC artifacts are developed in a timely fashion that the project is being managed according to those artifacts daily. The PM must also closely manage any and all contractors devoted to the effort. This cannot happen when the PM also has other significant responsibilities.
• Assign a business process analyst to document "before and after" business processes with an eye toward improving processes via computer automation. The analyst will document requirements.
• Define roles and responsibilities among staff, including staff from the agency responsible for the project, any agency staff participating from other agencies and contracted staff.
• Obtain buy-in from functional managers whose resources/staff will be necessary at any time to fulfill project requirements (e.g., requirements gathering, testing, pilot implementation).

The TORFP Process:

• Review and understand the TORFP process.
• Develop a procurement schedule (see Example Procurement Plan).
• Allow sufficient lead time to replace current contracts.
• Allow sufficient lead time for internal and external reviews of TORFPs. For planning purposes, assume at least two iterations once the TORFP is submitted to DoIT.
• Obtain input from key stakeholders on the TORFP scope of work.
• Inform DoIT of new IT initiatives well in advance of initiating the effort.
• Complete an ITPR before starting a TORFP.
  

​