2: How do we know what we're aiming at?

"Requirements"!

So far I have not mentioned "requirements" once in this blog; how on earth have I got this far without doing so?!??

In all honesty, I have no idea.  And it was probably a mistake.  Without "requirements" it's really easy to "do things right" - i.e. ensure the design confirms to some architecture, whether it be that of the enterprise or the vendor, but to "do the right things"?  Humph, maybe that's it - my focus on design v architecture diverted me too much...

So... if I have a "system design model" that needs to do the right things, do I have a "requirements model" defining what those things are?  Some would say "yes" - based very much on the notion that a model supports a particular viewpoint (see last entry!).

I say no - we need the model necessary to integrate all the viewpoints we need as system designers, and since requirements are just as important as the system design that satisfies them, the model must enable views from the requirements' viewpoint to be envisioned and drawn alongside the eight design viewpoints.

This then means my box must still contain one joined-up model, but now not only "looked at" from my eight design viewpoints, but also from a (or some!) requirements viewpoint(s).

So where do I put these requirements' viewpoints' "holes" in my box?

On top.

The box's vertical dimension is "application above technical" - so it seems equally natural for "requirements to be above application" - i.e. in the same way as "technical" stuff "satisfies the requirements placed on it from above by "application stuff", so the application satisfies the requirements placed on it from above. It's just that until now there's not been that explicit level above application - now there is, the "requirements level" - and all still inside the box.  (This of course means the "top four" application level design viewpoints need to "look slightly downwards" from their cut outs into the application level.)  And rather than a 2 * 2 * 2 arrangement of boxlettes, it's now 3 * 2 * 2...

What do I see when I look at my model from the requirements' viewpoint?  Indeed, is there just one requirements' viewpoint - it would seem rather stingy given there are eight design viewpoints!  A quick check of the top of the now taller box tells us there are four requirements "boxlettes", each focused on one of the other two dimensions of functional and operational issues from a logical and physical perspective.

Some would say "yes, there's just one requirements viewpoint (from the middle of the top) with four sets of views", others would say "the four sets of requirements views are sufficiently far apart to be modelled as separate requirements viewpoints".  For once, I don't actually have a point of view on this (there's that awful pun again), what I do care about are the views...

...because this has been our Achilles Heel for decades.   Whenever a solution designer, or business analyst, or expert user considers "what should this system do?", they automajically focus on the functional stuff - what the application has to do, and the data it has to do things to.  When asked something related to the operational aspect, such as "how well does it have to do all this?" (*), the answer comes back "I have no idea, but I'll know when I haven't got what I need!"

And all of this pre-supposes the requirements are being described in business terms (i.e. logically), and not physically by someone leaping to the conclusion that "the answer is Package X!"

In other words, only by recognizing the power of the box's dimensions can we hope to create a system that works functionally and operationally, assuming of course we can understand the relationships between the boxlettes...

(*) "how well" - ensuring the system achieves the right levels of things like performance, availability and security