Summary

A gap exists between the values expressed in informal specifications in terms of parameters familiar to many engineering disciplines. As a systems engineer, I bridge this gap by ensuring that the customer’s needs are always kept in mind throughout the development of a product. Using an array of tools to:

• Understand the customer’s needs.
• Discover, validate and verify the requirements, both at a structural and functional level.
• Evaluate a variety of solutions available by using models and matrices
• Model the system based on these requirements and evaluations
• Integrate the various subsystems which are identified, as most of the issues occur when connecting subsystems at their interface.
• Assess the performance of the product against a set of metrics which hold the customer’s requirements in focus.

An important point to note is that this is an iterative process with various tools feeding into each other. It is also necessary to keep updating these tools to ensure their maximum benefits.

I would say that the primary difference between traditional software product management roles and traditional hardware ones is the increased need to ship a 100% working product (or a 99.9999% product) on the first revision.

Tools

• Microsoft Office tools.
• NASA Systems Engineering Protocols
  • Use case diagrams
  • Originating and Derived Requirements
  • Functional Flow Block Diagrams
  • Goal Question Matrix
  • Quality Functional Deployment
  • Operational Description Template
  • Interface Matrix
  • Verification Cross Reference Matrix
  • Failure Modes and Effect Analysis
  • Event and Fault Trees
  • Project Timelines