Risk Management Toolkit

Support Assets

Taxonomies

Risk Areas:
Requirements

Risk Management home

Risk Areas' page

Process Assets
Standard Process
  • Definitions
  • Steps of Process
  • Tailoring Guidelines

    Compliance

  • Self Assessment
  • Compliance Process
  • CMMI Risk Management Goals
  • Risk Review

    Policy

  • AF Policy Directive 90-9: Operational Risk Management, 1 April 2000
  • AFI 90-901: Operational Risk Management, 1 April 2000
  • AFMC Instruction 90-902: Operational Risk Management, Dec 2007

    Support Assets
    Procedures

  • Affinity Diagrams
  • Brainstorming
  • Risk Plotting
  • Risk Statements

    Taxonomies

  • Individual
  • Consolidated
  • Risk Areas

    • Tools & Techniques

  • RiskNav
  • Risk Matrix
  • Risk Radar

    Training

  • Risk Process Orientation
  • Detailed Risk Process
  • Facilitator Training

    Examples

  • Sample Risk Management Plan
  • Process Lessons Learned

    		•   

    Description:
    How well a mission requirement can be supported or the validity of a mission-related capability against a threat.

    Risks:

    • Can the current requirements baseline be identified?

    • Are the operational requirements properly established and clearly stated?

    • Is the required operating environment described accurately and in sufficient detail?

    • Are sufficient subject matter experts available to review the requirements?

    • Have all requirements been captured from:
      • documents?
      • architectures, models, or use cases?
      • customer expectations?
      • operational usage?
      • all relevant stakeholders?
      • organizational policies or standards?
      • military policies or standards?
      • commercial standards?

    • Have the requirements been successfully implemented on any other system or product?

    • Are non-developmental items (NDI) being used on the program?

    • Is requirements analysis based on realistic design assumptions?

    • Are requirements for the current development or spiral:
      • complete (no TBDs)?
      • clear?
      • feasible?
      • testable?
      • measurable?
      • understood by all stakeholders?
      • time-sequenced?
      • prioritized?
      • design or solution independent?

    • Do the requirements meet the customer's intent for the system or product (i.e., will it do what its supposed to do)?

    • Are requirements stable?

    • Can the requirements change in response to:
      • new or changing threat?
      • funding shift or cut?
      • world event?
      • technology opportunity?
      • schedule?
      • resource reduction?

    • How quickly are requirements changing?

    • Are changes tracked?

    • Are requirements changes analyzed for:
      • impact on lower requirements?
      • impact on achieving program objectives?
      • conflict with program objectives or requirements?
      • interfaces with other programs or systems?

    • Are the requirements under configuration control?

    • Are dependent requirements identified?

    • Does each requirements have one or more funded "parent" requirement(s)?

    • Are requirements available to the program from a single repository?

    • Does the program have a Change Control Board (CCB):
      • established at the program level?
      • established at appropriate sub-program levels?
      • representative of all stakeholders?
      • that meets regularly?
      • that is effective?

    • Are requirements consistent with:
      • program funding and schedule?
      • stakeholder involvement?
      • technology available?
      • infrastructure architecture?

    • Are hardware, software and interface constraints identified?

    • Do the requirements address the entire life cycle (including logistics and suitability)?


    Back to top