Systems Engineering Requirements and Lifecycle Management Exercises

These exercises practise systems engineering as a quantitative and evidence-driven discipline. They cover requirement quality, traceability, interface acceptance, verification and validation coverage, configuration control, reliability allocation, lifecycle cost, requirements debt, handover readiness, and operational feedback.

The purpose is not to fill out a management template. The purpose is to decide whether a complex engineering system has enough controlled evidence to be designed, integrated, accepted, operated, changed, and improved without relying on hidden assumptions.

Assume simplified scoring and deterministic inputs unless an exercise states otherwise. Real systems engineering work should also check configuration version, interface ownership, stakeholder need, hazard severity, supply chain constraints, cybersecurity, human workload, maintainability, regulatory obligations, and the evidence needed for acceptance.

How to Use These Exercises

For each systems engineering calculation, define:

1. the system boundary and lifecycle phase;
2. the requirement, interface, risk, or decision being controlled;
3. the evidence needed to make an acceptance decision;
4. the owner of the requirement, interface, risk control, or change;
5. the consequence of accepting weak evidence.

The common mistake is counting documents as progress. Useful systems engineering metrics reveal whether requirements are testable, interfaces are ready, verification evidence matches configuration, changes are controlled, and operational feedback improves the next decision.

For each result, state whether it supports baseline release, interface hold, verification readiness, validation retest, change-board escalation, reliability allocation, handover acceptance, or lifecycle corrective action. Acceptance is credible only when the evidence matches the controlled configuration.

Exercise 1: Requirement Quality Screening

A preliminary requirements set contains 180 requirements. A review classifies them as:

Category	Count
Testable and traceable	124
Testable but missing upstream need	26
Ambiguous acceptance criterion	18
Duplicate or conflicting	7
Out of scope	5

Calculate the percentage of requirements that are immediately acceptable for baseline release. Also calculate the percentage that require rework.

Solution

Immediately acceptable requirements:

Requirements requiring rework:

Engineering Comment

A 68.9 percent acceptable rate is not enough for a baseline that drives procurement, design verification, or supplier commitments. The 31.1 percent rework fraction is requirements debt: unresolved ambiguity that will appear later as interface disputes, test failures, scope growth, or acceptance arguments.

The highest-value correction is not cosmetic wording. Each weak requirement should be connected to a stakeholder need or hazard, given a measurable acceptance criterion, assigned an owner, and mapped to verification or validation evidence.

Exercise 2: Traceability Closure

A subsystem has:

The traceability matrix shows:

Trace status	Count
Requirement linked to design element and verification evidence	72
Requirement linked to design element only	15
Requirement linked to verification evidence only	4
Requirement with no downstream trace	5

Calculate the full traceability closure rate. Then calculate the number of requirements that cannot yet support acceptance.

Solution

Full traceability closure:

Requirements not fully closed:

As a percentage:

Engineering Comment

Only 75 percent of the requirements connect need, design, and evidence. The other 25 percent cannot yet support acceptance because the team cannot reconstruct either what satisfies the requirement or how satisfaction is proven.

Requirements linked only to design may become unverified features. Requirements linked only to verification may indicate tests with no controlled design allocation. Requirements with no downstream trace are especially risky because they can disappear during integration.

Exercise 3: Interface Readiness Index

An integration review covers 32 interfaces. Each interface is scored against four readiness items:

1. owner assigned;
2. units, limits, timing, or tolerances defined;
3. acceptance method defined;
4. change-control rule defined.

The review finds:

Interface status	Count
All four items complete	19
Three items complete	7
Two items complete	4
One item complete	2

Compute an interface readiness index using:

Solution

Completed readiness items:

Total possible readiness items:

Interface readiness index:

Engineering Comment

An 83.6 percent readiness index is useful for management visibility, but integration risk is concentrated in the incomplete interfaces. The two interfaces with only one item complete should be treated as blockers if they carry load, power, data timing, safety state, clinical workflow, cybersecurity, thermal duty, or contractual acceptance.

Interface readiness is not an average-property problem. One uncontrolled interface can stop the whole integration campaign.

Exercise 4: Verification Coverage by Method

A verification plan covers 140 requirements:

Method	Requirements
Inspection	34
Analysis	28
Test	52
Demonstration	16
Audit or review	10

During readiness review, 11 test procedures and 5 analysis reports are not yet approved. Calculate the approved verification coverage.

Solution

Approved verification items:

Approved coverage:

Unapproved coverage:

Engineering Comment

The plan is close but not ready for full acceptance. Missing approved test procedures are more urgent than missing paperwork because they can affect test equipment, configuration, safety controls, data capture, and acceptance criteria.

Approved coverage should also be checked against risk. If the unapproved 11.4 percent includes safety controls, interfaces, cybersecurity, human tasks, or degraded modes, the program should not treat it as a minor residual item.

Exercise 5: Validation Scenario Coverage

A validation plan defines five operational scenarios and four user roles. A complete validation matrix would test each role in each scenario:

The executed validation campaign covers 16 cells. Of those, 14 pass without critical issue and 2 reveal critical workflow failures. Calculate matrix coverage and pass rate for executed cells.

Solution

Validation matrix coverage:

Pass rate among executed cells:

Pass rate against the full intended matrix:

Engineering Comment

The executed pass rate of 87.5 percent hides two problems: 20 percent of the intended validation matrix is missing, and 2 executed cells found critical workflow failures. For validation, a critical failure is not diluted by a high aggregate score.

The engineering action is to correct the workflow failure, update requirements or interfaces if needed, and rerun the affected role-scenario cells. Validation evidence must prove real use, not only nominal technical function.

Exercise 6: Change Impact Review

A supplier proposes a firmware timing change for a controller. The change affects the following items:

Impacted item	Count
Requirements requiring review	12
Interface documents requiring review	5
Verification tests requiring regression	9
Operating procedures requiring update	3
Training modules requiring update	2

The project rule states that a change is minor only if it affects fewer than 10 total controlled items and no user-facing procedure or training asset. Classify the change.

Solution

Total affected controlled items:

The change affects more than 10 controlled items:

It also affects user-facing procedures and training:

Engineering Comment

This is not a minor change. Calling it “firmware timing only” would hide lifecycle impact. The change touches requirements, interfaces, regression tests, procedures, and training, so it needs formal change control, configuration update, regression planning, and operational communication.

The key systems engineering discipline is impact analysis. A small code or supplier change can invalidate evidence across the system if timing affects alarms, data exchange, interlocks, operator response, or maintenance workflow.

Exercise 7: Reliability Allocation from System Target

A system must achieve reliability:

for a mission interval. It has four essential independent subsystems in series. If reliability is allocated equally, find the required reliability of each subsystem.

For a series system:

With equal allocation:

Solution

Subsystem reliability:

Each subsystem must therefore achieve approximately:

reliability over the mission interval.

Engineering Comment

The equal allocation is a starting point, not a design answer. Subsystems may differ in maturity, environment, repair access, load, duty cycle, supplier control, software complexity, and failure consequence.

If one subsystem can only credibly achieve 97 percent reliability, the other subsystems must compensate, the architecture must add redundancy, the mission target must be renegotiated, or the maintenance and recovery concept must change.

Exercise 8: Lifecycle Cost Trade-Off

A team compares two architectures for a monitoring system:

Cost element	Architecture A	Architecture B
Initial implementation	420,000 USD	560,000 USD
Annual maintenance	85,000 USD/year	54,000 USD/year
Expected annual downtime cost	72,000 USD/year	38,000 USD/year

Use a five-year undiscounted lifecycle cost screen. Which architecture has lower lifecycle cost?

Solution

Architecture A:

Architecture B:

Difference:

Engineering Comment

Architecture B has the lower five-year screen by 185,000 USD despite higher initial cost. The decision should still test uncertainty: downtime assumptions, spare strategy, cybersecurity maintenance, obsolescence, training, supplier lock-in, and validation burden.

Systems engineering should avoid selecting the cheapest initial architecture when lifecycle operation, reliability, and maintainability dominate the decision.

Exercise 9: Requirements Debt Burn-Down

A project starts integration with 64 open requirements issues. The team closes 9 issues per week, but integration testing creates 4 new issues per week. Estimate the net closure rate and the number of weeks required to reach fewer than 10 open issues.

Solution

Net closure rate:

Open issues must fall from 64 to fewer than 10. The required reduction is:

Weeks required:

Engineering Comment

The project needs about 11 weeks to reach fewer than 10 open issues if the arrival and closure rates remain stable. That assumption should be challenged. Integration often reveals coupled issues that take longer than early issue closures.

Requirements debt is not merely a count. A single unresolved safety requirement, interface requirement, cybersecurity condition, or validation scenario can be more important than many minor wording corrections.

Exercise 10: Handover Readiness Score

A system is ready for operational handover only if evidence is complete across six categories. The readiness review records:

Handover category	Required records	Complete records
Requirements status	42	42
Configuration baseline	18	17
Training records	60	54
Maintenance procedures	24	21
Spares and tools	16	14
Monitoring and escalation paths	20	16

Calculate the overall record completion rate. Identify the weakest category.

Solution

Total required records:

Total complete records:

Overall completion:

Category completion rates:

Handover category	Completion
Requirements status	100.0%
Configuration baseline	94.4%
Training records	90.0%
Maintenance procedures	87.5%
Spares and tools	87.5%
Monitoring and escalation paths	80.0%

The weakest category is monitoring and escalation paths at 80.0 percent.

Engineering Comment

The overall score looks strong, but the weakest category matters. Handover can fail after commissioning if operators do not know what to monitor, when to escalate, who owns unresolved risks, or which field data must feed reliability and change control.

Operational readiness is not complete until the receiving organization can sustain the system. A technically accepted configuration without monitoring and escalation evidence can drift quickly after release.

Exercise 11: Operational Feedback Closure

During the first quarter after release, the support team records:

Feedback type	Count
Field defects	18
Near misses	7
Repeated user questions	33
Maintenance rework events	12
Supplier nonconformances	5

The lifecycle board reviews 52 of the 75 total items and converts 21 into controlled actions. Calculate the review coverage and action conversion rate.

Solution

Total feedback items:

Review coverage:

Action conversion rate relative to reviewed items:

Action conversion rate relative to all feedback:

Engineering Comment

Only 69.3 percent of feedback was reviewed, and only 28.0 percent of all feedback became controlled action. The high number of repeated user questions should be treated as engineering evidence, not support noise. It may indicate weak requirements, unclear interface behavior, poor training, missing labels, inadequate workflow validation, or documentation mismatch.

Lifecycle feedback closes the loop only when it changes requirements, design, procedures, supplier controls, maintenance plans, validation scenarios, or training.

Review Checklist

When reviewing systems engineering evidence, ask:

• Does each requirement have a need, owner, acceptance criterion, and verification or validation method?
• Are interfaces accepted with explicit evidence for nominal, startup, shutdown, maintenance, and fault modes?
• Does verification evidence match the actual configuration being released?
• Does validation represent real users, environments, degraded modes, and operational workflows?
• Has each change been assessed for requirements, interfaces, tests, procedures, training, cost, and schedule?
• Are reliability and risk controls allocated to owners and testable evidence?
• Does handover include spares, procedures, training, monitoring, escalation, and open-risk ownership?
• Does operational feedback produce controlled engineering action?
• Are unresolved requirements, weak interfaces, unapproved tests, and missing handover records classified by consequence rather than only counted?
• Can each accepted claim be traced to requirement, design element, verification or validation evidence, configuration version, owner, and residual risk?

Good systems engineering makes hidden assumptions visible before they become integration failures, acceptance disputes, field defects, or unsafe workarounds.