IT Box

The IT Box model in the JCIDS Manual facilitates more efficient and timely software development by reducing the requirements documents required to go through the JCIDS process. An Information Systems Initial Capabilities Document (IS-ICD), a variant of the regular ICD, which outlines the “IT Box” is approved via the JCIDS process. Subsequent requirements documents, alternatives to CDDs and CPDs, are streamlined and incrementally approved. Requirements oversight and approvals are delegated to a flag-level oversight board within a Service or Component. This provides IS programs greater flexibility to incorporate evolving technologies and achieve faster responses from requirement validation processes.

The IT Box model is appropriate for:

Procuring or modifying GOTS/COTS IT products or developing dual-use technologies
Additional production or modification of previously developed IS products
Customized software development
All hardware associated with an IS-ICD must be COTS/GOTS
Software with projected life cycle costs exceed $15M

IT Box is are NOT appropriate for:

Software embedded as a subset of a developed capability solution
Software requiring a host platform, such as a manned or unmanned vehicle
Increases in quantities of previously fielded IS without modification
Requirements for DBS capabilities

The following diagram is tailored from one in the JCIDS Manual as an example of using two document types. Actual names, content, and approval process are at the discretion of the delegated oversight authority.

The Requirements Definition Package (RDP) (or equivalent) is a first level refinement of one or more capability requirements identified in an IS-ICD or IS-CDD, and is co-developed by the operational user (or representative) and the program office. The RDP (or equivalent) identifies the KPPs (including updates to the NR KPP), KSAs, and APAs necessary to scope and cost a specific implementation of a capability solution. The RDP (or equivalent) may also identify non-materiel changes that need to be implemented to fully realize the IS capability solution. The RDP (or equivalent) is approved by the delegated oversight authority identified in the IS-ICD or IS-CDD.

The Capability Drop (CD) (or equivalent) could describe the performance characteristics of a relatively small increment of a capability solution included in a software build necessary for partial deployment of the overall capability solution, typically developed and fielded within a short period of time. It could be developed through a rapid prototyping effort with the user to ensure it meets their needs. A CD (or equivalent) could be developed directly from the definitions in the IS-ICD in the event of a more timely need for the capability solution. More commonly, multiple CDs (or equivalents) would be derived from an RDP (or equivalent) or IS-CDD to deliver the overall capability solution defined in the RDP (or equivalent) or IS-CDD.

The IS-ICD is the preferred method for implementing the IT Box model, but IS-CDDs may be used in cases where a validated ICD contains capability requirements which can be addressed by a combination of IS and non-IS capability solutions and the IT Box construct is applicable to the IS portion of the capability solution(s). IS-CDDs may be used for MDAP and MAIS programs to comply with statutory requirements for a CDD while allowing for other flexibilities of the IT Box model. IS-CDD are also appropriate for use in cases where a validated CDD was generated before the IT-Box construct was introduced, and the Sponsor wants to revalidate under the IT-Box construct. The IS-CDD outlines a similar IT Box and upon approval via JCIDS, requirements oversight and subsequent documentation approval is delegated to the identified flag-level requirements board.

See the JCIDS Manual for full details on IT Box applicability, documentation, and process details.

Aligning IT Box and Agile

IT Box provides programs great flexibility to iteratively define and document their requirements. Programs using an Agile methodology often manage requirements via user stories via product, release, and sprint backlogs (or equivalent). Programs may consider tailoring the notional RDPs and CDs as outlined in the JCIDS manual with release and sprint backlogs.

A core Agile tenet is to not spend too much time upfront with documentation.
In collaboration with the flag-level requirements board, a program could propose they approve the release backlog prior to the start of each release.
The board review and approval process should be conducted in a timely manner to support the rapid Agile timelines.
The product owner can walk through the user stories on the backlog a COTS Agile tool during a review with a backlog report shared as a read-ahead item.
As the scope of releases can change during development, product owners should be empowered to manage changes during the release execution with the agreement the board is kept informed of changes in a timely manner.
Sprint backlogs should be agreed upon by the product owner and development team and not require the requirements board approval prior to beginning each sprint.
Board members may be granted access to the backlogs and invited to demonstrations during the release development to gain insight into the progress.
The product owner can also review the product backlog with the requirements board to provide insight into the larger epics planned, priorities of items on the backlog, and insight into the notional items planned for the next few releases.