Why This Metric Indicates Risk

TBDs, TBCs, and TBRs reflect ambiguities or unresolved issues in software requirements documentation. Often placeholders for incomplete information or outstanding decisions, these "placeholders" directly undermine the foundational purpose of the software requirements document (SRD), which is to define what the system must do and how it must behave in a clear and actionable way.

When their prevalence exceeds 1%, significant gaps in the understanding and agreement on software functionality, constraints, or interfaces emerge. These uncertainties propagate across the software development lifecycle, causing challenges in design implementation, traceability, testing, and lifecycle integration.

TBD (To Be Determined)

• Definition: A placeholder for information that has not yet been decided or defined.
• Example: "Input data format TBD" or "Encryption algorithm TBD."
• Risk: Design and development may proceed without critical information, leading to suboptimal or incorrect implementations once the missing details are added.

TBC (To Be Confirmed)

• Definition: An item that is partially defined but requires verification of accuracy or completeness.
• Example: "Expected data throughput TBC as design matures."
• Risk: Teams may wrongly assume the TBC value is fixed, creating misalignment in software functionality or performance expectations.

TBR (To Be Reviewed)

• Definition: An item that is defined but requires stakeholder review or approval before being finalized.
• Example: "System mode transition criteria TBR during stakeholder review."
• Risk: Designs or work based on unreviewed requirements can result in wasted resources if the requirements are later updated or rejected.

These placeholders can persist due to incomplete stakeholder input, poor coordination between teams, or tight project deadlines. However, their presence disrupts progress and creates avoidable risks.

Impacts of Excessive TBDs, TBCs, and TBRs in Software Requirements

1. Incomplete Requirements Decomposition:

   • TBDs and placeholders often block derivation of lower-level requirements. Without fully decomposed requirements, detailed designs, specifications, and test cases cannot be developed, delaying downstream activities.

2. Increased Ambiguity for Development Teams:

   • Developers may make assumptions or guess the intent of unresolved items, resulting in incorrect implementation that needs to be reworked later.

3. Design Instability:

   • Missing details compromise software architecture and design quality, as these elements rely on finalized requirements for decisions related to modules, interfaces, and internal logic.

4. Integration Failures:

   • If TBDs exist in areas such as interfaces, external dependencies, or data formats, integration between software components or with external systems may fail, requiring significant workarounds.

5. Testing Gaps:

   • Open or unresolved requirements prevent the generation of complete testing scenarios or acceptance criteria, leading to insufficient test coverage and, ultimately, delivered software that is misaligned with user needs.

6. Scope Creep and Cost Overruns:

   • Unresolved decisions (i.e., TBDs or TBCs) often lead to significant scope fluctuations once details are finalized, introducing unplanned work, longer schedules, and higher costs.

7. Misalignment with Stakeholders:

   • TBRs signal that stakeholders have yet to review and approve certain requirements. Prolonged TBRs indicate a lack of agreement among stakeholders, leading to delays and unclear expectations.

8. Compliance and Certification Challenges:

   • In regulated projects (e.g., those in defense, medical, or aerospace industries), unresolved requirements at high levels cast doubt on the software’s ability to meet certification or compliance benchmarks.

9. Erosion of Confidence:

   • An SRD with excessive placeholders creates mistrust among stakeholders, who may question whether the project team has control of the development process.

Root Causes of TBD/TBC/TBR Prevalence

1. Incomplete Stakeholder Input:

   • Requirements are ambiguous or missing because stakeholders have not provided complete information, perhaps due to organizational misalignment or delays.

2. Unclear Scope or Mission Goals:

   • The high-level system objectives might not yet be fully clarified, causing difficulty in defining actionable software requirements.

3. Premature Initiation of Software Development:

   • Software teams may have begun their work despite incomplete inputs, signaling a rushed or immature project kickoff.

4. Insufficient Collaboration Among Teams:

   • Poor communication between system engineers, software architects, and software developers can delay resolving system-level TBDs that cascade to lower-level software requirements.

5. Overloaded or Understaffed Teams:

   • Requirements engineering resources may not be sufficient to clarify or finalize TBDs and placeholders within the necessary timeline.

6. Late Changes or Iterative Inputs:

   • Rapid evolution of project goals introduces updates to requirements that are marked as TBD/TBC/TBR while awaiting customer or system engineering updates.

7. Lack of Formal Requirements Process:

   • Projects without structured practices for resolving TBDs, TBCs, and TBRs (e.g., deadlines for closure, placeholders tracking) have undefined or perpetually unresolved requirements.

Mitigation Strategies

1. Track and Manage TBD/TBC/TBR Items:

   • Introduce a formal mechanism (e.g., a requirements database or a traceability matrix) to track all TBD/TBC/TBR placeholders. Each should have an owner and a resolution date to ensure accountability and closure.

2. Set Threshold Limits:

   • Establish a policy that the percentage of unresolved placeholders in requirements must not exceed 1% at critical milestones (e.g., CDR, SIR, TRR). Flag projects exceeding this limit for additional review.

3. Collaborate Early with Stakeholders:

   • Engage stakeholders early in the project lifecycle to clarify ambiguous requirements and address TBD/TBC/TBR items before they propagate downstream. Use structured requirements workshops or reviews to accelerate decision-making.

4. Perform Incremental Resolution:

   • Focus on resolving high-priority TBDs, particularly for mission-critical, safety-critical, or integration-sensitive areas, to mitigate associated risks first.

5. Conduct Periodic Placeholder Reviews:

   • Hold regular requirements reviews to track progress in resolving TBD/TBC/TBRs. These meetings should include systems engineers, software engineers, and key stakeholders.

6. Complete High-Level System Requirements First:

   • Ensure system-level requirements are finalized before decomposing into software requirements. This prevents downstream artifacts from inheriting uncertainties.

7. Apply Iterative Requirements Development:

   • If requirements must evolve (e.g., in agile or iterative environments), implement feedback loops to close unresolved issues in earlier iterations.

8. Formalize Resolution Deadlines in Change Control Processes:

   • Tie TBD/TBC/TBR resolutions to project schedule milestones and require formal reviews of outstanding placeholders during key decision gates.

9. Allocate Dedicated Resources for Requirements Management:

   • Assign responsibility for resolving TBD/TBC/TBRs to specific team members or roles within the project, ensuring accountability and timely closure.

10. Leverage Tools for Traceability and Status Updates:

    • Use tools such as IBM DOORS, Jama Connect, or Polarion to manage requirements traceability and track the status of placeholders systematically. These tools make it easier to identify and prioritize unresolved items.

Conclusion

Exceeding 1% TBD/TBC/TBRs in the software requirements document introduces significant risks to project clarity, downstream activities, and overall schedule stability. Such placeholders erode confidence in the requirements document as a solid foundation for design and development. By using formal tracking, stakeholder collaboration, and proactive resolution management, projects can manage and reduce TBD/TBC/TBR items, ensuring greater clarity and alignment as the project progresses. Ultimately, resolving placeholders early minimizes downstream challenges and helps ensure successful project outcomes.

3. Resources

3.1 References