00:28:08 Amy Moy: Amy Moy, Enchantment Chapter President, Sandia Labs, Systems Engineer 00:28:43 Ann Hodges: Ann Hodges, Enchantment Chapter Secretary, INCOSE SE in Early-Stage R&D Working Group Chair, Sandia National Labs Systems Engineer (retired) 00:29:02 Phil B: Trevor Bennett, Co-Founder, Starfish Space (guest) 00:34:54 Melissa Whitcomb: Getting some echo, please mute your mikes 00:35:58 Ann Hodges: As host, I muted open mikes. 00:38:34 John O. Clark: The bottom of the V-Model on Slide 5 includes Software/Hardware Development. Should Humanware (i.e., operator/maintainer) Development be added? 00:42:17 John O. Clark: Should Slide 7 include Requirements Verification? 00:45:02 Ann Hodges: Unspoken mission need 00:45:02 Ron Carson: Customer ConOps is in conflict with contract requirements. 00:45:02 Brian Simonis: Program requirements not clear 00:45:03 Melissa Whitcomb: Vague and ill-defined requirements which must be drilled down/corrected by folks 3-5 yrs later. 00:45:03 Derrick Ike: Bad assumptions 00:45:03 David: varying interpretation of requirements 00:45:03 Tishanda Aley: differing opinions across teams on how the requirements should be written 00:45:03 Quinn: DoD writes needs not requirements. 00:45:03 Doug Jones: Derivation in an unfamiliar field. 00:45:04 Erin: poorly written that are hard to verify 00:45:05 Russ Fortner: Ambiguous requirements that are impossible to verify. Requirements with no verification planning. 00:45:06 David Orr: Requirement owners want to write their own requirements. 00:45:06 Judy Wilk: Not knowing customer needs 00:45:07 mmheise: Not all customers know their real requirements. Frequently they put tighter constraints than necessary. 00:45:10 Raymond Wolfgang: A large scale rescope of stakeholder-level requirements and operational needs. 00:45:12 Amy Moy: stakeholder need and not a requirement written as requirement 00:45:13 Marissa Christman: Sufficient direction on process quality requirements 00:45:14 lewis152: evolving 00:45:37 Judy Wilk: Reacted to "differing opinions..." with 👍 00:45:40 Maria D Coulter: There's a misunderstanding as to where requirements come from. It has to be from the customer, the one with the pain point. I've been in instances where the solution architects conceptualize what the system should be 00:46:03 Tishanda Aley: Reacted to "A large scale rescop..." with 👍 00:47:56 Raymond Wolfgang: Replying to "There's a misunderst..." Then write requirements to back up their architecture .... 00:48:05 Marissa Christman: Reacted to "Not all customers kn..." with 👍 00:56:58 Ron Carson: Sorry, Rick: Function w/o performance is unverifiable. 00:57:54 John O. Clark: Replying to "There's a misunderst..." The SE processes (e.g., requirements-architecture-design development processes) are iterative, recursive, and concurrent. 01:00:19 Ron Carson: "Capability" statements are a trap for customer, because Supplier may need additional non-system components to satisfy the requirement; but it's "capable". 01:01:16 John O. Clark: Side 15: Is the performance requirement in reverse or forward? 01:02:58 Vladimir: how would you break down functional hierarchy for 3D medical device software? 01:03:17 John O. Clark: Slide 16: Note that the functions are verb-noun pairs. 01:03:48 Vladimir: Reacted to "Slide 16: Note that ..." with 👍 01:06:36 Ron Carson: Observable function - measurable object/noun. 01:07:13 John O. Clark: Slide 17: Note that the Design Structure Matrix (DSM) is sometimes called an NxN (N-Square) diagram. 01:07:51 Russ Fortner: Reacted to ""Capability" state..." with 👍 01:10:39 John O. Clark: Slide 19: Verification = System Right? Validation= Right System? 01:19:06 Ron Carson: Slide 21: simulation!!! 01:19:37 Ann Hodges: Replying to "Slide 21: simulation..." I agree that simulation is a useful way to prototype 01:20:40 Ann Hodges: Replying to "Slide 21: simulation..." For research-oriented projects, experimentation is applicable as well 01:21:05 John O. Clark: Slide 20: To agree with the title of the slide, should the top box be labeled Validation and the bottom box be labeled Verification? 01:21:33 Melissa Whitcomb: Sorry all, must head out for my kid. Thanks for a great presentation! 01:23:14 John O. Clark: Slide 23: Note that the subparagraphs are verb-noun pairs (i.e., Functions). 01:24:18 Quinn: 'Shall not' is often difficult to prove unconditionally. 01:26:42 Ron Carson: C15: "complete", per SEH 5th edition. 01:26:48 John O. Clark: Slide 24: "Shall not" can be challenging to verify (e.g., the system shall not shoot down friendly aircraft). 01:28:22 Maria D Coulter: c-14 Able to be validated - do you consider this equivalent to A requirement is "testable" 01:30:41 Ron Carson: C15 is "Correct"; sorry for wrong label. 01:31:47 Ann Hodges: Slide 32: Another Performance verification method can be simulation 01:37:11 Maria D Coulter: thank you 01:37:11 Brian Simonis: Thank you! 01:37:13 Tishanda Aley: Thank you Rick 01:37:14 Raymond Wolfgang: A tour de force, thanks Rick! 01:37:14 Maria D Coulter: good stuff 01:37:19 Derrick Ike: Thank you! 01:37:20 Vladimir: thank you! 01:37:24 Anggasta Anindityo: thank you 01:37:32 Zhentao Lu: Thank you so much 01:37:35 John O. Clark: Excellent Rick!