Week 16: Déjà vu with the Holistic Requirements Model

Dear STA gang,

It’s a winding road (back from holiday)

By now, I’m sure you’ve realised I’m no slave to a plan and am inclined to make up our path as we travel along it.  This week was no exception.  We had intended to get back to our allotment example and use the Holistic Requirements Model (HRM) to categorise the requirements we’d previously defined and tried using to put together a tree diagram.   We are now going to do that next week, which means the “Is Anything Worth Maximising?” session has been pushed further into the future.  

As a number of people had been away on holiday last week, but had now returned, and some of those who had come last week couldn’t come this week, I thought it worth repeating the HRM session again.  So that is what we did.

There were 8 of us in the session yesterday, which I was really pleased with.  We’ve now been going for approaching 4 months, so to have so many people attend in the middle of holiday season and to still be enjoying themselves is simply fantastic.  I want to say thanks to the group for sticking with it and putting in the effort to keep up with the reading and turning up week in and week out.

All credit to the learners

In this time of cut, or non-existent training budgets, I think it’s credit to all of you that you’re taking your personal development into your own hands and putting in your own time in the form of lunch breaks and evenings to plug away at learning something new.  I’m sure you will enjoy the fruits of your labours.  I’m positive you, our organisations and ultimately, our patients will and that makes me very pleased.  That, and getting the word out about the goodness of systems approaches and how their use could benefit health care commissioning is the reason I began this journey with you, so I’m thrilled we’re sticking with it and making tangible progress.  Thank you, and keep up the good work.

There’s nothing more to say

I wrote such a comprehensive report on our HRM session last week, that I don’t think there’s much more to report from yesterday’s session.  We basically covered the same ground again.  I found it really useful to do so actually and felt it helped me get a firmer grasp on the various types of requirements and how they work together.  Now we’ll have to put that to the test with the allotment example.

Apart from checking our tree

To remind you, here is the Tree Diagram we’d put together. Click it t expand it. Well, it’s actually one of two we produced, but it’s the more developed one.   Thanks to Matt for putting it together in electronic format. There’s still more work to do on it, and it will be interesting to pick that back up again, once we’ve fully defined out requirements with the HRM.  We had a helpful comment on an older post pointing out we’d not defined functions as verb nouns, so we’ll take that on board and be careful to remodel the requirements correctly.  Thanks for the comment julian Johnson.  It’s appreciated.

Allotment System Tree Diagram

What are Requirements anyway?

One thing I’m not sure we have covered here in the blog, is an actual definition of what Requirements are.  So here is one from the Systems Engineering Book of Knowledge (SEBoK):

Statement that identifies a product* or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability.

*includes product, service, or enterprise.

It looks as though they have taken this definition from the ISO/IEC 42010:2007 Standard.  You may, or may not choose to look that up. 

The homework

The homework for next week is to individually think about how we might turn the definitions of categories of requirements into language that is more understandable and accessible to our colleagues.  Terms such as “Non-Functional Implementation Requirements” are going to leave people wondering what on earth we are talking about.  Whilst it might make us sound ever so clever, it would likely make people think we’re weird and talking unhelpful gibberish.  The challenge will be to find terminology that will be meaningful to people, but also manage to retain the specificity of the original.  Let’s see what we can come up with.

Enjoy your weekend,

Tim

1 thought on “Week 16: Déjà vu with the Holistic Requirements Model”

  1. Hi. Offline I’ve provided to Tim some suggested ‘verb-noun’ re-expressions of the tree list of potential functions you’ve previously produced.
    One point I make here is: the form you elaborate your potential requirements in probably depends on whether you are aiming to produce ‘a set of requirements’ as a convention set of natural language statements, or whether you are aiming to produce the clauses or fragments that actually evolve into a ‘model’ of your intended system.
    Taking a couple of examples, my short verb-noun forms of a couple of the ‘requirements’ are:
    manage tenants
    define rules
    Expressed like this, these ‘requirements’ are much closer to the name of a function you might see in a model of the ‘allotment system’. But if you wanted to express the corresponding requirement as a text requirement, it may be more appropriate to capture:
    The allotment system will manage the tenants
    The allotment system will define the rules for [managing tenants / all operations of the allotments].
    These are rather in the style that BurgeHughesWalsh illustrate, see page 8 of the note on STA at http://www.burgehugheswalsh.co.uk/Uploaded/1/Documents/Systemic-Textual-Analysis-Tool-v1.pdf
    Some industries (like aerospace) adopt strict rules for use of vocabulary in textual requirements, like use of the word ‘shall’:
    The allotment system shall manage the tenants
    So to summarise, how you evolve your ‘requirements’ essentially depends are where you are heading, and what you want achieve.
    Hope that helps.

Leave a Reply

Your email address will not be published. Required fields are marked *