This is part of the Knowledge Curation set of ideas.
‘General to Specific’ is just the process which I’m sure you would do if you had to explain a complicated bit of a model, and if you could get your audience gathered around a white board. You’d just draw them an example.
Suppose your model looked like this:
Well-read readers will recognize this instantly as an example of the ‘Gang of Four’ composite pattern (this is what made me into a modelling geek – just this diagram, presented by Kent Beck at IBM team meeting in the early 1990s – happy days).
Students of UML will understand what this means, but it’s beauty and utility as a solution to an organisation hierarchy problem are not immediately obvious. So I’ll read it back to you:
- There’s an abstract idea of ‘Organisational Unit’ (abstract because it’s in italics – my least favorite bit of UML notation)
- There are two ‘real’ types of things which are kinds of Organisational Unit: Person, and Team. These are shown by the lines with the arrow.
- Teams are slightly different from People: they can contain other Organisational Units (the line with diamond). But People can’t.
- And because Organisational Units are either People or Teams, then Teams can contain Teams, which contain other Teams etc, until finally they contain People.
Simple, elegant, brilliant, re-usable in lots of ways, but really not obvious to anyone but a competent UML reader.
So how to curate a model like this? You know already, I’m sure: you create an example:
Even knowing nothing about the notation, this seems fairly obvious. Teams contain Teams, Teams contain People, but People don’t contain Teams. Just like the model said.
And this is the example I’m sure you’d sketch onto a whiteboard, of you had all your model readers gathered around it. And they’d understand it. Maybe not the deep elegance of the model, but at least it’s effect.
And this is why this technique is called General to Specific, and not the otrher way around.
You have already done the really clever bit: taking all their specific requirements and making a generic model from them. That’s the ‘Specific to General’ thing which analysts and modellers do.
Now you’re going back the other way.
The example above uses a Domain Model: a model of the ‘ideas’ in someones’ world. But we might equally apply it to other kinds of model:
- In a Use Case (or User story), replace the generic with the specific. So
“The use case starts when the user wants to find a widget configuration
1- The User tells the system the widget details
2 – the System finds matching Widgets, and shows then in order of configuration date”
” Fred needs to find the configuration of a type 45, blue widget
1- Fred types ‘type=45, color=blue” into the system
2 – system shows him:
Widget Type colour configuration date
#123 42 blue 1/1/2019
#456 42 light blue 31/12/2018
- For a requirement, make a concrete example of the consequences of it:
“The solution shall allow only pre-configured widgets to be listed”
“…so, for example, un-configured – but pending – widgets will not appear”
Is the second bit part of the formal specification? No. because we put “..for example…”
The key to using this technique is not just to scribble it on a whiteboard. It’s to include these example in the model, so that when anyone reads a document, or looks at a website which is based on your model, they will see your explanation.
- It’s going to take some time to do this, so use the technique only where there are complicated bits. After a while, your readers will need fewer and fewer examples, as they start to understand what you’re saying
- Some pedants may confuse the specific with the generic, so make sure examples are clearly labelled as examples, and so are not thought of as part of the specification.