I used your version of the V-Model on your version of the V-Model... pretty cool. Thanks for the information and showing it applied.

You're a legend. I'm doing a masters degree in engineering management, and you just clarified the whole unit! Thanks!

@theboard

4 жыл бұрын

Hi PedalPromise! I'm glad that this helped you understand some of the aspects (the more basic ones) of Systems Engineering :)

This video is helping me out create a presentation for a Systems Engineering job interview. Well done!

@theboard

5 жыл бұрын

Good Luck! I'm glad that it helped ^_^

Both of these Systems Engineering videos were brilliant! I can see how I can apply this to graphic design or any kind of design conception altogether :) Thank you so much! I'll be watching these over and over haha

@theboard

7 жыл бұрын

Certainly, as I would imagine that the requirements would be clearly detailed first, and then each sub-requirement element of the design can be broken down to the component level, down to say distinct and discrete elements of what the customer wants, how it looks, colour, and then the integration back up to make sure that the look of the design does not clash with other elements in style, colour, appearance, size, etc. By taking this kind of approach, you would definitely avoid ending up on /r/crappydesign haha.

@seconduk

7 жыл бұрын

I definitely want to avoid /r/crappydesign hahaha. I often have to ask clients what the graphics are going to be applied on, which can change a lot of things (regular t-shirt prints or embroidery = avoid using gradients because of machinery-related posterization. Dye-sub print = need to use darker colours on light grey/white keycaps + high-contrast colours for vital elements like text and important object outlines)

@theboard

7 жыл бұрын

A lot of this can be covered with say a standard data collection at the start of a 'project'. All these aspects can be distilled into field data that you would give to the client at the start, as their requirements list. Any questions/fields that they don't know should be clarified at that point before going further simply because it will save them, and you, potential pain and issues later on. If they have no idea at all, then you should step back and say, I would love to help you find the answer, however if you do not have a clear vision, this will take more time, and cost until the vision is strong enough for us to move forward (i.e. the field can be filled in). This also provides you with some defence should they change their mind later because you now have evidence document that the requirements they initially agreed on were changed without you being involved.

@seconduk

7 жыл бұрын

That...is very useful. Thank you. I will have to make a fill-out sheet with questions. I tend to satisfy clients better when I've managed to put their visions on paper, so to speak. Their requirements are my limitations, which is mostly good as I can concentrated on completing their objectives by applying what I know about graphics. It's rare that I can 100% satisfy a client the first time round if they give me a clean slate to work with

@theboard

7 жыл бұрын

Its very rate that anyone (graphics, software, hardware, etc) will ever be satisfied in the first round of any design process. In actual systems engineering, there is the initial requirements, then there is the preliminary design review, then system design review, before you would go into 'production'. These check 'gates' essentially brings everyone up to speed to where everything is, and allows for adjustments and changes so everyone has reached compromises where they are happy (time, cost, things not initially considered are compromised until satisfactory decisions are made). Its just a suggestion, you might want to try it with one client, and see how it works out, and refine your own processes to make your work easier, smoother, and with a greater satisfaction rating.

In a new management position and this is going to really help me lead my systems engineering and integration team

@theboard

3 жыл бұрын

Hi Krystal, hopefully you'll pick up a bit more depth over time quickly to give them more guidance than my two videos :) Best of luck in your new role :D

Trying to land a dream job. Thank-you so much for the explanations

@theboard

2 жыл бұрын

Good Luck with the job applications, hope it brings you much joy and excitement!

Brilliant! Thank you! you helped me a lot

@theboard

4 жыл бұрын

Hi Juliana, thank you for the kind words, I'm glad that these two were of help to you :)

nicely done...thanks.

@theboard

4 жыл бұрын

Thank you :) Its pretty high level simplistic overview, but I hope it continues to help people looking to understand the concepts.

Thank you, this helped expand my systems thinking.

@theboard

5 жыл бұрын

Thank you for your kind comment! I'm glad I could be of help for you : )

This second video did not come up after I watched the first. Maybe add a link to it? Nice mini series, now I don't have to pay 5000 dollars for the MIT course just to find out what Systems Engineering actually is!

@theboard

2 жыл бұрын

Hi Carlo, thank you for the recommendation, I should go and see the best way to link it :)

thanks for these videos, can I use them to help teach my design fundamentals course?

@theboard

4 жыл бұрын

Hi Josh, Its public visible content on YT, so I guess if all you're doing is sharing a link as a reference material for your students, it should be fine, but anything more commercial than that, I would probably say there is going to be some kind of limitations on YTs side more than anything else. Please note of course anything I say in the videos is at a very basic/high level conceptually, but if it helps, then great :)

Thanks for the videos. Would you complete these decomposition prior to starting design or is this completed adjacent to the design work? And the same question for integration - would you write out the sets of integration for the whole system before staring design or any testing?

@theboard

Жыл бұрын

Hi Daniel, It depends on the complexity of the system design. It is not unusual that if it is highly complex with lots of systems, sub-systems, sub-sub systems and so forth, to break it down adjacent/concurrently as you design as it makes it much easier to detail for your test and trials planning, and your verification of requirements cross-matrix. The greater depth of detail, the sooner you should start it to prevent things being missed, and it also makes the immense scale much easier to digest.

@SeracS354

Жыл бұрын

@@theboard thanks for the reply! 1. When designing, you often start with several concepts of the whole product/system before selecting one. The different design solutions can radically change the whole system architecture. How does this factor into systems engineering? Would you need to agree on a whole concept of the system before conducting a detailed systems engineering approach? 2. I’m I right in thinking verification is assessing if a particular part/component meets it’s specifications, for example meeting its tolerance on the drawing by inspection, whereas, validation is checking the system meets the customer requirements, for example, by testing of the final product? 3. Are there methods within system engineering to restrict customers (or whoever has the requirement) from creating requirements that are unachievable?

@theboard

Жыл бұрын

One way to approach this is with your appropriate stage gates. Going from a Needs Analysis/Requirements Analysis to determine what the problem needs and requirements are, and utilising the results of that to have a system requirements review. This stage gate is a critical go/no-go point that should be held with the customer before you progress to any preliminary or detail design work. The customers feedback and input can also be sought during the needs/requirements analysis portion, but should not heavily influence your solutioneering from a product safety or innovation perspective. the SRR portion however should be approved by the customer as it sets the baseline minimum requirements the solution addresses against their end product. For V&V, the verification process checks that your design particulars tick offs everything that is listed under the system requirements (which the requirements ticks off everything the system needs are), while the validation is the act of conducting testing in some meaningful manner that demonstrates the design meets it. So you might say that the design has a need to have load bearing of 100kg, so your verification portion might be the bolt selected must have greater than 100kg load bearing, and you show in the design the size of the M12 bolt has a theoretical weight load of 4.8Ton, so that is ticked. Your validation portion would be during your test and trials work, we would load test to 150% of requirement, and conduct a 150kg load trial, which once completed if the bolt assembly does not fail, then it is validated that the design will meet 100kg load. As for restricting customers from requesting unachievable, thats part of stakeholder management and demonstrating value for money/safety. What I mean by that is, its not impossible to design the unachievable if you have unlimited time and money. You just need to show them either the technology doesn't exist currently and therefore requires development (time and money), or, the design could be achieved but its out of your budget/schedule. This is typical possible to be communicated under your needs/requirements portion where you create a solution to the unachievable with the requirements to design/fabricate/install it. Once they are given that which detail the mammoth effort, thats the conversation to say, hey, lets wind this back.