Technical Specification Documents (38)

Description:

This building block details specification about exactly how the technical system will operate. The system design documents—which include the system requirement specifications, interface control document, and business rules (see System Design Documents building block)—should specify exactly how the system should work. Designing the technical system includes creating software specifications. It also may include developing hardware (i.e., circuit board) specifications. A technology vendor typically completes this building block. If separate RUC systems are needed for commercial and noncommercial vehicles, the specifications should be as consistent as possible between the two systems.

Details:

Based on the system design documents, use software and hardware engineering practices to develop detailed specifications documents that show exactly how the system works. Anything that is not described in the higher-level specification documents—which include system design specifications, interface control document, business rules, and user-experience guidelines, if any—is up for the engineer (vendor) to decide. If those requirements seem ambiguous, incomplete, or contradictory, then the vendor should ask the state for guidance, instead of simply deciding. State and vendor systems specifications will likely be different.

Primary Use:

Specify the exact system to be built, including software and hardware details.

Best Practices/Lessons Learned:

  • Specifications must work. They must fulfill all requirements in the system requirement specifications, interface control document, and business rules, and follow any user-experience guidelines.
  • If any requirements seem ambiguous, incomplete, or contradictory to the vendor, the state provides guidance.
  • If any requirements cannot be fulfilled, the vendor should discuss alternatives with the state.
  • If the consequence of fulfilling one or more requirements would result in something the vendor thinks the state is not expecting, the vendor should discuss the matter with the state.
  • The vendor should preview design decisions with the state, if possible.
  • Specify as many values or choices as possible as parameters. Avoid hardcoding values, so changes can be made easily in the system.

State Government Context and Assumptions:

After any contracts to develop the technical system are awarded, the developer of the technical system completes this task. In most cases, this will be a technology vendor, but in some cases, this could be the state itself.