Formal Requirements Are Only the Starting Point

The approved requirements baseline establishes the mission need, intended effect, high-level capabilities, and formal constraints. It cannot fully capture operational workflows, usability needs, fielding realities, and adaptation conditions, which software teams must discover continuously with warfighters, operators, and sustainment organizations.

POSSE applies product orientation to maintain this connection throughout development and sustainment. Continuous Requirements Discovery turns operational evidence into product decisions as missions, threats, users, and operating conditions change.

​

The Systems Engineering and Software Development Disconnect

Systems engineers define mission needs, system behavior, interfaces, constraints, and required performance. Software developers make the design and implementation decisions that determine whether the system can achieve those goals.

The connection between the 2 disciplines often breaks down. Developers may receive requirements without enough mission, system, or architectural context. Systems engineers often see the software as a black box within the larger system.

This disconnect creates consequences throughout acquisition:

• Integration problems emerge late.

• System requirements fail to shape the software architecture.

• Local software decisions undermine system-level quality attributes.

• Systems engineers cannot trace proposed changes into the implemented software.

• MBSE models lose their connection to the software architecture and code.

• MOSA defines interfaces without ensuring software modularity.

• Software becomes difficult to understand, sustain, and adapt.

• Technical debt slows future capability delivery.

​​​

Systems Thinking Must Reach the Code

POSSE teaches developers to begin at the system level and drive the design from the top down. System decisions shape the software architecture, which guides lower-level design and implementation.

Developers model the software around intuitive abstractions and make the implemented code mirror the architecture.

This preserves conceptual integrity as the software grows. Developers understand how their work fits into the complete system. Systems engineers can understand the software architecture, evaluate its relationship to system requirements, and participate in technical tradeoffs.

The architecture becomes the working connection between systems engineering and software development.

​

Faster Software Acquisition

Acquisition slows when programs discover architectural conflicts, integration problems, and missing quality requirements after implementation has begun.

POSSE brings these decisions forward. Developers consider system constraints, interfaces, quality attributes, and likely changes while shaping the architecture. Systems engineers gain earlier visibility into the software structures that will produce system behavior.

Earlier alignment reduces rework, integration surprises, and technical risk.

​

Sustainable Software Systems

Defense platforms can remain in service for decades. The developers maintaining their software in the future will often have no contact with its original authors.

POSSE treats architectural comprehensibility and code maintainability as essential engineering properties. Future developers must be able to understand, modify, and test the software without depending on undocumented knowledge held by the original team.

This preserves the government’s freedom to sustain the software, compete future work, change vendors, and continue delivering capability.

​

Rapid Wartime Adaptation

A new threat can require changes across sensors, data, interfaces, algorithms, operator workflows, and system behavior. Programs must understand how those changes reach the software.

A comprehensible architecture allows engineers to identify the affected parts of the system. Maintainable code allows developers to implement and test the changes safely.

The capacity for rapid wartime adaptation must be built before the emergency begins.

​

Enabling MBSE and MOSA

MBSE can describe a system while leaving its software architecture opaque. MOSA can define modularity and interface requirements while the implemented software remains tightly coupled.

POSSE carries systems thinking into software design and implementation. Systems engineers gain visibility into the software architecture, while developers understand how system requirements, constraints, interfaces, and quality attributes shape their work.

MBSE and MOSA need this connection to achieve their intended results.

​

Product Orientation for Defense Software

POSSE treats software as a long-lived mission product.

Developers build the domain knowledge needed to understand the mission, users, system, and operating environment. They remain connected to operational communities and take responsibility for the quality and adaptability of the complete software product.

Product orientation supplies mission and domain context. Systems engineering provides system-level direction. Software craftsmanship develops the skill to implement the design well.

​

What POSSE Covers

• Mission Value and Continuous Requirements Discovery: Software must produce the intended mission effect and support operators under realistic conditions. Continuous Requirements Discovery fills the gaps in the approved baseline and keeps the product aligned with operational needs.

• Systems Engineering for Software Developers: Developers learn how system purpose, constraints, interfaces, and required qualities shape software architecture and implementation.

• Quality Attribute Prioritization: Performance, reliability, interoperability, security, safety, adaptability, usability, and other qualities compete for technical resources. Engineering teams need a shared understanding of which qualities govern when design choices conflict.

• Architectural Health: The architecture must support the required quality attributes and remain comprehensible as the system changes.

• Code Maintainability: The code must remain understandable, changeable, and testable by developers who did not write it. Maintainability affects delivery speed, integration risk, sustainment cost, contractor transitions, and wartime adaptation.

• Software Craftsmanship: POSSE develops engineering judgment through design principles, domain knowledge, mentorship, critiqued practice, and experience with the long-term consequences of design decisions.

• Engineering Evidence: Programs need evidence that the software supports mission outcomes, required quality attributes, architectural health, and maintainability. Delivery metrics and vendor reputation cannot establish those conditions.

Who POSSE Is For

• Software Developers: POSSE develops the systems thinking, design judgment, domain knowledge, and craftsmanship needed to build large, long-lived software systems.

• Systems Engineers: POSSE provides visibility into software architecture and strengthens the connection between system requirements and implementation.

• Engineering Leaders: POSSE provides a model for developing talent, preserving conceptual integrity, and strengthening collaboration between systems and software engineering.

​

Built From Experience

Beginning in 2004, Andrew Park developed a training and mentorship approach that was applied to every engineer hired into his organization. Over approximately 5 years, each person developed from a software developer into a software engineer and ultimately a product engineer with strong system, domain, and product knowledge.

POSSE brings the practices behind that transformation together for defense software engineering.

​

Build Software That Preserves Mission Freedom

Defense organizations need software that reaches the field faster, remains sustainable, and adapts when operational conditions change.

POSSE develops the engineering capability required to produce it.