Good evening Systems Thinkers,
Big thank you to Gary Smith
Yesterday, we were extremely fortunate and privileged to have Gary Smith come to speak with us.
Gary is a seriously bright guy. I already knew that, but what I hadn’t quite appreciated is just how deep a systems thinker he actually is and in particular, his incredible appreciation of systemic human interconnectedness. Thank you Gary, I feel like I was missing something important that you’ve helped reconnect now.
The session has given me a jolt and left me asking some questions about the direction we’re taking. Perhaps we need to mix in more systems theory and philosophy and investigate the emotional and sensory apsects of being a good systems thinker, as well as plugging away with the practical tool kit we’ve been learning. You thoughts are welcome.
I’ll write up a full reflection on the session and get it posted. If you were there, and would like to add your own thoughts, please do note them down and let me have them.
Now, I know you’ve really missed having homework the past couple of weeks, so here is some for next week’s session. I propose we revert back to our plan of do a show and tell of the two purpose Tree Diagrams we built. To help us in our discussions about them, it would be good to improve our understanding of defining different types of Requirements.
I realised my understanding of how to define and classify requirements isn’t up to scratch and that left us floundering a little when trying to do it, so if we can all read the linked document below and learn together, that will be great. So, here’s the reading, the Harmonised Requirements Model:
The Harmonised Requirements Model is quite a technical approach and there’s quite a bit of detail to digest and understand in this paper, so please do try to read it a couple of times, and not at the last moment.
Hard or Soft
This is an approach from the “hard” side of systems approaches and more commonly used in Systems Engineering of physical systems, rather than the “soft” approaches we are focussing on for use in systems involving human interaction, or Human Activity Systems as they’re known.
I think that is OK though. It’s certainly OK to use this approach when you’re designing a stand alone service I think and the problem is relatively tame. That may or may not be the case with our allotment example. We can discuss that.
I also think this is a very helpful approach to help us gain a deeper understanding of requirements that relate to function, operation, performance etc. It will give us a better understanding of how to describe systems and their purposes, before we get into the more comprehensive “soft” approaches. This is should give us a good grounding.
So, enjoy your weekend and i look forward to seeing you next week.