An Introduction to Requirements | Systems Engineering, Part 4

See all the videos in this playlist: • Systems Engineering
Get an introduction to an important tool in systems engineering: requirements. You'll learn about the three things every requirement must have and what makes a requirement valid. You'll also see how requirements and requirement hierarchies contribute to the system design process.
Systems Engineering Featured Products:
System Composer: bit.ly/3kAMErX
Simulink Requirements: bit.ly/3ko9BOq
--------------------------------------------------------------------------------------------------------
Get a free product trial: goo.gl/ZHFb5u
Learn more about MATLAB: goo.gl/8QV7ZZ
Learn more about Simulink: goo.gl/nqnbLe
See what's new in MATLAB and Simulink: goo.gl/pgGtod
© 2020 The MathWorks, Inc. MATLAB and Simulink are registered trademarks of The MathWorks, Inc.
See www.mathworks.com/trademarks for a list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders.

[@Jair_inacio_Neto_Teixeira]

You have a great way to teach complex topics Brian! You should make a course about controls from paper to hardware... I'd buy it

[@makzmakz]

@3:50 you say that the toaster must the requirements. Why do you then use as the dependency relation from the functions to the requirement? "Implementation" is very different than high level functional architecture. It is the E/E assembly that the function! EDIT: This is exactly what you do @9:34!

[@adithyaramachandran7427]

Good Morning Brian, I wanted to know how you would specify technical safety requirements without forcing an implementation ? If a requirement is ASIL rated, there are specific ISO-26262 guidelines to be followed when the programmer is developing the code (Like Variable definition, ASIL component partitions, No recursions, no hidden dataflows, no unconditional jumps, only 1 entry and exit point per function, etc.). That gives the developer a lot less freedom on how to implement and forces a particular strategy.

[@makzmakz]

@13:06 you say that a spring has been chosen as a design and you go on to say that you can state a requirement for that spring. Fair enough. However you do this while showing a relation from the function "Store ME" to the requirement and the requirement contains the word "spring" you therefore have a requirement that is specifying an implementation, but the dependency comes from the function. Very confusing!

[@Tetek91]

The original quote comes from A. Lincoln - about sharpening an ax

[@neil9325]

amazing

[@tassioleno808]

A more complet set of characteristics of a good requirement: * necessary * singular * correct * unambiguos * feasible * appropriate to level * complete * conforming * verifiable

[@marcoarcifa4901]

The example chose was an unhappy one, all the time I thought how easy was a George Foreman Grill instead the toaster.

[@briancelidonia8258]

Unfortunately, I don't think this is a great example. Saying that 10 slices are un-acceptable, but there are no requirements for the any number of pieces of toast....so a 1 slice toaster? Why are there not requirements for "time to toast" , "even-ness of toasting/browning"...this went straight to a wattage requirement , but not a requirement to work on 120V outlet. Also, the "mechanical energy storage" requirement assumes a solution of a person pressing down and the toast popping out....this could instead be motorized to pull the toast through to ensure more evenness of toasting, etc. Finally, requirements should not assume solutions. If the solution is the requirement, then just state that...don't pretend that it is a "better requirement" because it doesn't explicitly state that "it shall use a spring loading / unloading system that tensions the spring when loading, then uses that tension to eject the toast when complete"