7  Stakeholder Analysis

7.1 Stakeholder Identification

Per [1, Sec. 2.3.5.2], the stakeholder needs and requirements definition process identifies stakeholders and their needs throughout the system lifecycle.

Stakeholder	Category	Interest	Influence	Success Criteria
GitLab	Sponsor	Market positioning in SE/defense space	High	Visible GitLab integration, open source contribution
Academic Advisor	Authority	SE process rigor, academic standards	High	Complete SE artifacts, proper methodology
Capstone Collaborator	Team	Course completion, DoD relevance	High	Shared workload, defensible deliverables
Open Source Community	User	Usable tool, extensibility	Medium	Working software, good documentation
Defense/Aerospace Users	User	Practical utility, compliance	Medium	Solves real workflow problems
INCOSE/SE Community	Influencer	Advancing AI4SE	Low	Novel contribution, reproducible results
SysML v2 Implementers	Supplier	Adoption of standard	Low	Correct API usage, spec compliance

7.1.1 Stakeholder Analysis Matrix

Stakeholder	Power	Interest	Strategy
GitLab	High	High	Manage Closely
Academic Advisor	High	High	Manage Closely
Capstone Collaborator	High	High	Manage Closely
Open Source Community	Low	High	Keep Informed
Defense/Aerospace Users	Low	High	Keep Informed
INCOSE/SE Community	Low	Medium	Monitor
SysML v2 Implementers	Low	Low	Monitor

7.2 Team Roles

Role	Person	Affiliation	Primary Responsibilities
Technical Lead	Andrew Dunn	GitLab Public Sector	Software implementation, CI/CD, architecture
SE Lead	Greg Pappas	DoD, Army, AFC-DEVCOM	Requirements, V&V Plan, SEP, review facilitation
Advisor	Dr. Stephen Rapp	Wayne State University, ISE	Technical reviews, capstone evaluation

7.2.1 Responsibility Matrix (RACI)

WBS Element	Andrew	Greg	Dr. Rapp
1.1.1 Planning	R	C	I
1.1.2 Technical Reviews	R	R	A
1.2.1 SEP	C	R	A
1.2.2 Stakeholder Analysis	C	R	I
1.2.3 SyRS	C	R	A
1.2.4 ADD	R	C	A
1.2.5 VVP	C	R	A
1.2.6 RTM	C	R	I
1.3.x Software Dev	R	I	I
1.4.x Infrastructure	R	I	I
1.5.1-3 Quarto Book	C	R	I
1.5.4 Software Docs	R	C	I
1.6.x Papers	R	R	C

Legend: R=Responsible, A=Accountable, C=Consulted, I=Informed

7.3 Operational Concept

Per [1, Sec. 2.3.5.2], the operational concept describes how users will interact with the system in its intended environment.

7.3.1 System Context

The SysML v2 MCP Server operates as middleware between AI assistants (LLM clients) and MBSE infrastructure (GitLab repositories, SysML v2 API servers).

┌───────────────────────────────────────────────────────────────┐
│                      User Environment                         │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐        │
│  │   Claude    │    │   VS Code   │    │  Custom AI  │        │
│  │   Desktop   │    │ + Continue  │    │ Application │        │
│  └──────┬──────┘    └──────┬──────┘    └──────┬──────┘        │
│         │                  │                  │               │
│         └──────────────────┼──────────────────┘               │
│                            │ MCP Protocol                     │
│                            ▼                                  │
│                  ┌───────────────────┐                        │
│                  │   SysML v2 MCP    │                        │
│                  │      Server       │                        │
│                  │  (stdio or HTTP)  │                        │
│                  └─────────┬─────────┘                        │
│                            │                                  │
└────────────────────────────┼──────────────────────────────────┘
                             │
          ┌──────────────────┼──────────────────┐
          │                  │                  │
          ▼                  ▼                  ▼
   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
   │   GitLab    │    │ SysML v2    │    │ Local Files │
   │ (gitlab.com │    │ API Server  │    │  (.sysml)   │
   │  or self)   │    │ (optional)  │    │             │
   └─────────────┘    └─────────────┘    └─────────────┘

7.3.2 Use Cases

UC-1: AI-Assisted Model Review

1. Systems engineer opens Claude Desktop with MCP server configured
2. Engineer asks: “List all requirement definitions in the vehicle model”
3. MCP server calls gitlab_read_file to fetch model from GitLab
4. MCP server calls sysml_parse to extract elements
5. Claude presents findings and suggests improvements
6. Engineer requests changes; Claude uses gitlab_commit to save

UC-2: Model Validation in CI/CD

1. Developer commits SysML v2 model changes to GitLab
2. CI pipeline starts MCP server in HTTP mode
3. Pipeline calls sysml_validate via HTTP
4. Validation results reported in merge request
5. Reviewer sees AI-generated model summary

UC-3: Exploratory Model Query

1. New team member needs to understand existing model
2. Opens AI assistant with MCP server connected
3. Asks natural language questions about model structure
4. MCP server uses sysml_query to search elements
5. AI explains model architecture, relationships

7.3.3 Operational Modes

Mode	Transport	Use Case	Authentication
Local Development	stdio	Individual engineer with Claude/VS Code	GitLab PAT in environment
Team Server	HTTP	Shared server for team access	GitLab PAT per request
CI/CD Pipeline	HTTP	Automated validation in GitLab CI	GitLab CI_JOB_TOKEN

7.4 Stakeholder Needs

Per [1, Sec. 2.3.5.2], stakeholder needs are statements of what stakeholders require from the system.

7.4.1 Need Statement Format

[SN-XXX] As a [stakeholder], I need [capability] so that [benefit].

7.4.2 GitLab (Sponsor)

[SN-001] As GitLab, I need the MCP server to integrate with GitLab APIs so that GitLab is positioned as the platform for AI-augmented MBSE.

[SN-002] As GitLab, I need the project to be open source so that it contributes to the GitLab ecosystem and community.

[SN-003] As GitLab, I need CI/CD integration showcased so that the DevSecOps value proposition extends to systems engineering.

7.4.3 Academic/Capstone (Authority)

[SN-004] As the academic advisor, I need the project to follow INCOSE SE processes so that students demonstrate proper methodology.

[SN-005] As the academic advisor, I need formal technical reviews (SRR, PDR, CDR) so that the capstone meets academic rigor requirements.

[SN-006] As the capstone collaborator, I need shared workload distribution so that both team members contribute equitably.

7.4.4 Technical Users

[SN-007] As a systems engineer, I need easy installation (single binary) so that I can start using the tool without complex setup.

[SN-008] As a systems engineer, I need clear documentation with examples so that I understand how to use the MCP tools.

[SN-009] As a DevOps engineer, I need container deployment support so that I can integrate the server into existing infrastructure.

[SN-010] As a systems engineer, I need to query SysML v2 models through natural language so that I can explore models without learning query syntax.

7.4.5 Defense/Aerospace Users

[SN-011] As a defense contractor, I need support for self-hosted GitLab so that I can use the tool in air-gapped environments.

[SN-012] As a defense systems engineer, I need model validation against SysML v2 spec so that I ensure model compliance.

7.4.6 Needs to Requirements Traceability

Stakeholder Need	Stakeholder Requirement(s)	Rationale
SN-001	SR-001	Direct derivation
SN-002	SR-002	Direct derivation
SN-003	SR-003	Direct derivation
SN-004	SR-004	Direct derivation
SN-005	SR-005	Direct derivation
SN-006	-	Process constraint, not system requirement
SN-007	SR-006	Direct derivation
SN-008	SR-007, SR-008	Direct derivation
SN-009	SR-009	Direct derivation
SN-010	SR-012	Direct derivation
SN-011	SR-010	Direct derivation
SN-012	SR-011	Direct derivation

Complete traceability matrix in Section 15.1.

7.5 Stakeholder Requirements

Per [1, Sec. 2.3.5.2], stakeholder requirements are derived from stakeholder needs and expressed in technical terms.

7.5.1 Requirement Format

[SR-XXX] The system shall [capability] [condition] [constraint].

Trace: Derived from [SN-XXX]

7.5.2 Platform Requirements

[SR-001] The system shall integrate with GitLab REST API for repository operations.
Trace: SN-001

[SR-002] The system shall be licensed under the MIT open source license.
Trace: SN-002

[SR-003] The system shall provide GitLab CI/CD integration examples.
Trace: SN-003

7.5.3 Process Requirements

[SR-004] The project shall produce SE artifacts per INCOSE Handbook guidance (SEP, SyRS, ADD, VVP, RTM).
Trace: SN-004

[SR-005] The project shall conduct SRR, PDR, and CDR technical reviews with documented entry/exit criteria.
Trace: SN-005

7.5.4 Usability Requirements

[SR-006] The system shall be distributable as a single static binary requiring no external dependencies.
Trace: SN-007

[SR-007] The system shall include README with installation and configuration instructions.
Trace: SN-008

[SR-008] The system shall provide example SysML v2 models demonstrating tool capabilities.
Trace: SN-008

[SR-009] The system shall be distributable as an OCI-compliant container image.
Trace: SN-009

7.5.5 Functional Requirements

[SR-010] The system shall support self-hosted GitLab instances via configurable base URL.
Trace: SN-011

[SR-011] The system shall validate SysML v2 model syntax via API integration.
Trace: SN-012

[SR-012] The system shall parse SysML v2 textual notation and extract element information.
Trace: SN-010

[1]

INCOSE, INCOSE systems engineering handbook, 5th ed. Wiley, 2023.