Slide background

Systems Engineering

In an effort to minimize cost and schedule risk, Braxton’s engineering processes ensure requirements are mapped out and confirmed with the customer using display mockups, white papers, prototypes, and formal requirements documents. The hybrid Agile process delivers reliably on a demanding ops tempo, demonstrating Braxton’s ability to manage challenging turnaround times and short-notice changes.

Due to the demanding nature of Braxton’s programs, risk reduction processes ensure requirements are mapped out and confirmed with the customer using display mockups, white papers, prototypes, and formal requirements documents. Braxton stays in close communication with the customer throughout each release cycle to ensure the deliveries will meet customer expectations. Braxton provides program status via weekly customer “tagups” to identify and resolve problems immediately, and Braxton participates in impromptu status meetings as needed.

Braxton manages requirements carefully on these programs, accepting requirements from the customer by various means, including verbally, presentations, screen shots, and requirements documents. Requirements are maintained on Braxton’s requirements and workflow management system, document management system, and collaboration wiki, as well as on the customer’s document management site. Each program maintains requirements traceability and verification matrix used to manage the work process and system verification prior to operational deployment.

Braxton regularly holds design reviews so the customer can gain confidence in the programs’ architectural direction and so Braxton can confirm the accuracy of requirements, solutions, and implementation.

Software Engineering

The hybrid Agile software development model is selected for programs when the customer requirements are defined at a high level at program start and then developed in a series of development sprints. The iterative aspect of this strategy acknowledges that some user needs and associated requirements may not be fully understood up front due to the scale and complexity of the system being developed, enabling some low-level refinement of requirements in each sprint as well as technology insertion as the system architecture is defined during the systems engineering effort in each sprint. This strategy is appropriate for a program that enables early and frequent deliveries of capabilities, reduces schedule risk through concurrent engineering, and enables some managed and controlled evolvement of requirements and capabilities.