How can you validate functional requirements in Systems Engineering?

-Understanding of big picture! -Always start from real world problem then gat back to the technology. - Clear understanding of technology readiness.

Need to consider multiple parameters: 1) What are the safety measurements or the standard to be considered? What is the impact in case system fails? What is the quality standard to be followed? 2) What are the requirements can validate using review and inspection method? 3) What are the requirements can validate using simulation and modeling method? 4) What are the requirements really need actual system testing and verification? The best approach would be combination of all 3 approaches. 5) How exactly the decided validation methods supports higher level assemblies and future maintenance. And finally any project activities need to consider: What is the actual scope of work, what is the allocated budget and delivery milestone :)

Usually, depend on the industry, review the deliverable and inspection can be beneficial. there are some complex systems that need a prototype to be tested along with the production. this is called AGILE which is a continuous improvement process on capital projects. in order to be sure the system functions as expected, you need to understand the goal and the expectations of the contract, stakeholders and the product. once this is understood, a TEST PLAN can be provided with all the pivotal points of the product or system. this ensures the prototype works as expected and during this demo the customer or stakeholders have a chance to observe their end product before the mass production starts. within this phase lies many different factors...

I find it useful to apply a business mentality to assessing functional requirements. Did the system add the needed value to the intended value stream? It's tempting to get too detailed in decomposing functions, which can result in brittle system solutions that are technically requirements compliant. Clear functional requirements can communicate the context for what a system must do in ways that other requirements drop between the cracks.

Don't overcomplicate or believe it is complex. The thing needs to prove that it does what it is intended to be capable of. Proof can be by: - inspection - testing - by design (but watch out for this one)

A model must be 1) descriptive of a system or process, 2) predictive of the outcomes of a system or a process, and (ideally), 3) prescriptive of solutions to problems associated with a system or process. Over the years, I've become a huge fan of model-based simulations not only for testing functional requirements, but evolving them during the development process to become "digital twins" of the final system or process. Discrete-event simulations are wonderful models of system functional requirements where Monte Carlo "what if" scenarios can be run to verify requirements.

- Iteration 1, simulate the functional behaviours with any programming language you are familiar with. - Iteration 2, use industry standard tools with proper physics and other functionality that your customer will trust in. - Make sure that the model you are using is covers the minimum inputs and outputs to run any scenarios that the final product should perform.

- Be agile in prototyping for both hardware and software modules, make them as separate logical blocks with proper inputs and outputs to be able to demonstrate/debug them separately. -Demonstrate not only the functionality , but the sense of the ownership.

- Test driven development is a key. - Start with basic functionality verification with software in the loop methodologies. - Hardware in the loop testing is mandatory for safety critical applications.

Setting up traceability matrices is common systems engineering practice. They are a crucial part of requirements validation as they provide a clear link between intended objectives and project requirements. Although functional requirements do not have parent requirements, like sub-requirements do, they can be linked directly to customer given requirements and/or project objectives determined and agreed upon by stakeholders at the beginning of the project. Traceability Matrices help ensure completeness, facilitate change management, aid in verification, and serve as valuable documentation for compliance and project approvals, ultimately contributing to the success of a project.

Tracing functions to mission vignettes or real system use cases is essential. ...not use cases in the abstract UML sense, but in the pure systems engineering sense: an actual thing that a user can and must try to do with the system, in mission relevant content.

- Use the same metrics during the entire product design lifecycle. - Define common data hierarchy for development and testing data including low level measurements starting from simulation and ending up with physical measurements. - Correlate the key KPI during the entire lifecycle.

In specific for commercial aviation, most of the design systems and related components for aircraft and powerplant are established in regulations such as FAR for FAA and JAR for EASA. These documents indicate the minimum requirements to comply with a safety and functional operation. There are technical criteria as Damage Tolerance for structural components, or Redundancy for electromechanical systems as flight controls.