Using Inflectra SpiraTeam for Managing the Software Engineer

by Dr. Sriram Rajagopalan on Monday, February 2, 2026

Overview

Aerospace and defense programs producing deliverable software must demonstrate disciplined planning, traceability, configuration control, verification evidence, and durable records suitable for customer and prime audits. AS9115A is intended as a software-focused supplement to the 9100 quality management system, adding software-specific clarification for processes used to design, develop, and deploy deliverable software.

This paper explains why SpiraTeam is a strong fit for AS9115A-aligned execution and provides a concrete configuration blueprint—workflows, roles, baselines, signatures, traceability, and reporting—that can be adopted as a repeatable operating model.

1. Context: What AS9115A is asking you to prove

AS9115/9115A is positioned as a supplement to 9100 that adds specificity for deliverable software. “Deliverable software” is typically defined as software that is developed or modified for airborne/spaceborne/ground/shipborne contexts, delivered either as a standalone line item or embedded in a product; unmodified COTS components are excluded.

Practically, AS9115A-aligned programs must be able to demonstrate (with objective evidence) that they have:

Planning artifacts (e.g., Software Development Plan and supporting plans) and governance records.

Requirements definition and change control, including impact analysis.

Verification planning and results, with bidirectional traceability.

Configuration management, including baselines, version control, status accounting, and audits.

Problem reporting/corrective action, including closure evidence and record retention.

This expectation is visible in prime/supplier flowdowns: for example, Collins Aerospace supplier requirements enumerate SDP contents and call out problem reporting, risk management, tool control, metrics, security/safety requirements, and configuration management planning elements.
cybersecurity themes (e.g., protected environments, tools/utilities, code analysis capability).

2. Why SpiraTeam is a strong fit for AS9115A execution

SpiraTeam is an integrated software lifecycle management platform that manages requirements, tests, plans/tasks, and issues/defects in one environment with end-to-end traceability. For AS9115A, that integrated data model matters because audits typically fail at the seams—where requirements live in one place, test evidence in another, and configuration status somewhere else.

2.1 Key capabilities that map cleanly to AS9115A needs

A. Traceability you can audit

SpiraTeam supports requirements-to-test coverage mapping and traceability reporting (impact analysis, coverage gaps, and “what failed and what it affects”).

B. Baselining for configuration control

SpiraTeam includes baseline management to snapshot requirements, test cases, incidents, and other artifacts at a point in time—supporting robust configuration management and audits.

C. Workflow governance + electronic approvals

Inflectra’s platform supports configurable workflows and electronic signatures integrated into transitions (commonly used for regulated environments). This allows you to enforce gated approvals (e.g., requirement approval, test completion, release authorization) with attributable accountability.

D. Evidence packaging for customer/prime audits

Because requirements, tests, defects, approvals, and baselines live in one system, generating an “audit packet” is primarily a reporting/configuration task—not a multi-tool reconciliation effort.

3. AS9115A-to-SpiraTeam crosswalk (implementation-focused)

Note: This crosswalk is written as an operational mapping (what you need to demonstrate) rather than reproducing AS9115A clause text.

What AS9115A programs must demonstrate	SpiraTeam mechanism	Configuration you should implement
Controlled planning (SDP + supporting plans; roles; milestones; reviews; records)	Releases, Documents, Tasks, Milestones, baselines	“Plans & Reviews” artifact set; review workflow; baseline at major gates
Requirements definition + change control + impact analysis	Requirements module + traceability links + baselines	Requirement types, mandatory fields, approval workflow, baseline strategy
Verification planning & results (unit/module/CSCI/CSU testing; environment control; results retention)	Test cases, test runs, releases, incident linkage	Test plan structure per release; required environment fields; results retention rules
Problem reporting, tracking, and corrective action	Incidents/defects with workflow + root cause fields	PR/FRB workflow with required RCA + verification + closure approval
Configuration management planning (identification, control, status accounting, audits, access control)	Baselining, permissions, reporting, release management	Baseline gates; CM roles; status accounting dashboards; periodic baseline diffs
Cyber-aware controlled tools & environments	Roles/permissions, auditability, controlled workflow, deployment options	Least-privilege roles; restricted admin actions; controlled integrations & service accounts

4. Reference configuration: “AS9115A-ready” SpiraTeam operating model

4.1 Project template and information architecture

Create a Project Template that every deliverable-software program inherits:

A. Requirement taxonomy (systems engineering-friendly)

Requirement Types:

Stakeholder / Mission Needs

System Requirements

Software Requirements

Interface Requirements (ICD items)

Safety / Security Requirements

Verification Requirements (optional, if you separate “what” from “how to verify”)

Requirement hierarchy:

Use parent/child decomposition to represent allocation (System → Software → Subsystem → Component).

B. Release structure (align to program increments & baselines)

Releases = contractual deliveries or major increments.

Iterations/Sprints (if using Agile) under Releases, but keep baseline gates at the Release level.

C. Standard artifact sets

Requirements

Test Cases + Test Sets aligned to verification plan

Incidents (defects, anomalies, change requests)

Tasks (implementation + reviews)

Documents (SDP, SQAP, SCMP, SVP, STR, SVD, etc.)

Supplier flowdowns commonly expect SDP + SCMP + verification/test plan content and explicit records lists.

4.2 Roles, permissions, and segregation of duties

Implement least-privilege roles (examples):

Systems Engineer (SE): create/edit requirements, propose changes, run traceability reports.

Software Lead (SWL): manage tasks/releases, approve implementation readiness.

SQA: independent review authority; can sign/approve transitions; cannot edit code tasks post-baseline without formal CR.

CM (Configuration Manager): baseline creation authority; release authorization workflow control.

Test/Verification Lead: manage test sets/runs and verification evidence.

External Reviewer (Customer/Prime): read-only access to agreed artifacts + reports.

This supports AS9115A’s emphasis on defined responsibilities, independence of QA, and controlled access to records.

4.3 Workflows: gated control with attributable approvals

A. Requirements workflow (example)

Draft

Under Review

Approved

Implemented

Verified

Baselined

Released

Obsolete

Recommended gate controls:

Under Review → Approved: requires SQA + SE approval (signature if enabled).

Verified → Baselined: requires CM approval.

Baselined → Released: requires program authorization.

Spira supports workflow-driven approvals and electronic signature approaches for regulated governance.

B. Incident / problem report workflow (PR/DR)

Triaged

Dispositioned (use categories: defect, change request, inquiry)

In Work

Fixed

Verified

Closed

Mandatory fields by transition:

Triaged: severity/priority, affected baseline/release, reproducibility, safety/security impact.

Dispositioned: decision authority + rationale.

Fixed: root cause category + link to change set/task + regression scope.

Closed: verification evidence + SQA closure approval.

This directly addresses “problem reporting, tracking and corrective action system” expectations seen in aerospace flowdowns.

C. Test workflow (test case and test run governance)

Test Case: Draft → Reviewed → Approved → Active → Retired

Test Run: Planned → Executed → Reviewed → Accepted (signature at acceptance gate if your process requires it)

4.4 Data model: mandatory fields that make audits painless

Configure custom properties to ensure every artifact carries audit-relevant metadata without manual narrative reconstruction.

Requirements (minimum recommended fields)

Unique ID (native)

Source (contract, ICD, hazard analysis, stakeholder)

Criticality (safety/security/mission)

Verification Method (Test / Analysis / Inspection / Demonstration)

Verification Level (unit / subsystem / system)

Acceptance Criteria

Owner + Approver(s)

Allocated Component / Subsystem

Link to hazards/threats (if applicable)

Test Cases / Runs

Verification method + level

Environment configuration ID (test bench, simulator version, dataset)

Pass/fail criteria

Evidence attachment/link + baseline tag

Incidents

Affected baseline(s)

Root cause category (requirements, design, code, integration, environment)

Corrective action summary + preventive action (if applicable)

4.5 Configuration management with baselines (core to AS9115A)

Baselines are your “configuration snapshots” for audits, release readiness, and change impact. SpiraTeam baselining is explicitly designed to support robust configuration management over requirements, test cases, and other artifacts.

Recommended baseline strategy

BL-0 (SRR): requirements set approved for architecture/design

BL-1 (PDR): allocated requirements + initial verification plan

BL-2 (CDR): detailed requirements + approved test cases

BL-3 (TRR): test-ready configuration

BL-4 (Release): delivered configuration + final STR/SVD record set

Baseline rules

Only CM can create baselines.

After baseline creation, changes require a formal change request incident and new baseline increment.

Use baseline diff reporting as configuration status accounting evidence.

4.6 Planning artifacts and record retention (SDP/SQAP/SCMP/SVP)

Instead of treating plans as disconnected Word/PDF files, manage them as controlled records with:

Document versioning and controlled approval workflow

Links from plan sections to the governing artifacts (requirements sets, test sets, baseline IDs)

Baseline association at major gates

This aligns to typical SDP expectations such as formal reviews, metrics, risk management, tool control, subcontractor management, and security/safety requirements.

Operational tip: create a “Plan Compliance Matrix” artifact (document or report) that links:

SDP section → Spira artifact(s) → evidence report(s) → baseline(s)

4.7 Tool/environment control and cybersecurity themes

AS9115A revision materials highlight the need to consider threat profiles and protect software environments (tools/utilities, cyber-protected environments, analysis capabilities).

Dedicated admin roles (few users) and change-controlled configuration updates

Service accounts for integrations (CI, source control) with scoped permissions

Periodic access reviews (export user/role listings for audit evidence)

Environment identifiers recorded on test runs and baselines

Secure deployment posture (on-prem/controlled hosting as required by program constraints)

5. Implementation plan (what you do in the first 30–60 days)

Phase 1 — Process definition (Week 1–2)

Deliverables:

Lifecycle SOPs (requirements, V&V, CM, PR/DR handling)

Baseline strategy + review gates

Audit packet definition (what gets produced at each gate)

Phase 2 — SpiraTeam configuration (Week 2–4)

Build the project template (types, fields, workflows)

Configure roles/permissions and segregation of duties

Configure baselines and release structure

Configure signature/approval gates consistent with your governance approach

Phase 3 — Reporting and audit packet automation (Week 4–6)

Create standard reports:

Requirements Traceability Matrix (Req ↔ Test ↔ Incident)

Baseline content report (what’s in BL-x)

Open anomalies by baseline/release

Verification status by requirement criticality

Change impact summary (baseline diffs + linked CRs)

SpiraTeam’s native traceability and baselining are the keystone here.

Phase 4 — Pilot and institutionalize (Week 6–8)

Run one increment end-to-end in SpiraTeam

Conduct a mock audit using your defined audit packet

Adjust fields/workflows to eliminate “offline evidence”

6. What auditors and primes will like about this approach

Objective evidence is inherent: traceability, baselines, approvals, and defect closure live together.

Change impact is fast and defensible: you can show exactly what changed between baselines and why.

Verification evidence is organized around requirements, which is where audits usually start.

Governance is enforceable: workflows and (optionally) signatures prevent “informal approvals.”

7. How Does It Relate to DO-178C?

In summary, AS9115A governs how aerospace organizations manage software quality, while DO-178C governs whether a specific airborne software product is safe enough to fly.

AS9115A creates a repeatable, controlled environment

DO-178C consumes that environment to produce certifiable evidence for a specific product that was developed in that environment

You can think of AS9115A as ensuring “does this organization consistently manage software delivery in a controlled, auditable, and compliant way?” whereas DO-178C asks specifically “is this specific software safe enough to fly?”.

8. Appendix: Example “AS9115A-ready” checklists

A. Minimum required fields checklist

Requirements: source, criticality, verification method, acceptance criteria, approver, baseline tag

Tests: environment ID, evidence, linked requirements, approval

Incidents: affected baseline, root cause, corrective action, verification, closure approval

B. Baseline readiness checklist

100% requirements in scope are Approved

Planned verification coverage defined for all requirements

No open “must-fix” anomalies for the target baseline

All required plan documents approved and linked to baseline

Baseline diff report generated and stored as record

C. Audit packet contents (per release)

RTM (Req↔Test↔Defect)

Baseline definition + diff from prior baseline

Verification summary + failed test disposition

Open/closed PR log with RCA & closure evidence

Approved SDP/SQAP/SCMP/SVP and review minutes (or equivalent records)

Dr. Sriram Rajagopalan serves as the Global Head of Agile Strategy and Training Services at Inflectra, where he leads the design and execution of the company’s training and learning programs for the diverse clients Inflectra serves. He creates hands-on workshops to help development teams improve ALM with SpiraTeam, streamline test management with SpiraTest, and automate testing with Rapise.