AVGS Activity Models
Role-Based Perspectives
Systems Engineer

Systems Engineer Perspective

Authors lower-level requirements that decompose Product Support parents into precise, technically scoped Ground Systems statements.

  • Write requirement text and rationale
  • Maintain parent-child traceability
  • Resolve ambiguity with SMEs before JAMA entry

Primary responsibilities

  • Decompose each Product Support parent into lower-level requirements that add real engineering content beyond restating the parent.
  • Ensure every requirement is unambiguous, testable, and bounded to what Ground Systems provides, enables, or supports.
  • Capture definitions, assumptions, standards, and interface expectations in rationale.
  • Maintain bi-directional traceability to the parent and to downstream allocations.

Day-to-day work activities

  1. Pull the assigned parent requirement from JAMA; read parent text, rationale, and linked ARB notes.1
  2. Identify the major nouns (instrumentation, PSE, CJP, FDR, cradle) and confirm definitions with the right SME.2
  3. Draft single-purpose, testable lower-level requirements stating what Ground Systems provides, enables, or supports.3
  4. Write rationale covering definitions, applicable standards/AFIs, interfaces, and SME-confirmed assumptions.4
  5. Run the draft through the pre-submit checklist; log open SME questions in the tracker.5
  6. Walk the draft through SME review, then Architect allocation review, then Project Engineer readiness gate.6
  7. Submit to JAMA, link parent and children, and hand ownership to the Requirement Owner.7

Requirements work

ArtifactAuthorReviewerSystem of Record
Lower-level requirement textSystems EngineerSME + ArchitectJAMA
RationaleSystems EngineerSME + Reliability (if applicable)JAMA
Parent-child linksSystems EngineerConfiguration ManagerJAMA
Open-question logSystems EngineerProject EngineerDecomposition tracker

Architecture touchpoints

  • Use ARB-approved generalized naming for CBM+, Integrity Programs, Data Collection, and Instrumentation.
  • Cite the allocated Ground Systems element exactly as defined in the architecture description.
  • Reference interface contracts (e.g., CJP interface) in rationale rather than redefining them in the requirement.
  • Escalate to the Architect any decomposition that would change an interface, allocation, or element name.

Government approvals and reviews

Review / GateRoleEntry criteriaExit criteria
SME ReviewAuthorDraft + open questionsSME sign-off captured in rationale
ARBPresenter for naming/behavior impactsAllocation and naming alignedARB minutes referenced
JAMA Readiness GateAuthorChecklist complete, no open SME questionsProject Engineer marks ready
Customer / Program ReviewSupporting authorJAMA baseline + rationaleComments dispositioned

Deliverables

  • Draft lower-level requirements ready for SME review.
  • Rationale text explaining scope boundaries and SME confirmations.
  • List of open SME questions blocking JAMA submission.
  • Traceability map from parent to children with allocation noted.

Dependencies

Needs from others

  • SME confirmation of intent (Product Support / Reliability).
  • Architectural allocation guidance from the Architect.
  • Interface definitions from Integration Engineering.

Provides to others

  • Clean, testable requirement text for JAMA.
  • Rationale that downstream verification can use.
  • Issue list for the Project Engineer to track.

Decision rights

  • Final wording of the lower-level requirement (after SME and Architect sign-off).
  • Whether to split, merge, or defer a decomposition based on clarity and scope.

Checklist before JAMA submission

  • Requirement is scoped strictly to Ground Systems responsibility.
  • Text avoids implementation detail unless required for verification.
  • Rationale references applicable standards, interfaces, and SME confirmations.
  • Parent linkage is correct and complete.
  • All open SME questions are resolved or explicitly deferred.