The Why, What, How, and Who of requirements writing...

... it's interesting when I talk to many engineers how they struggle with the concept of raising their thinking to a systems, rather than implementation level. Of course, this is a well known struggle within the world of good requirements writing. The ability to define hierarchies and separate customer/stakeholder need, for the how the implementation will full-it, gives the solution architect the freedom to choose and explore alternatives. Of course, the same thing happens with model-based systems engineering...

Here's one way to think about it.

In Scott and Long's MBSE Primer I quite like the way that they talk about 3 systems:
1. The system as it's perceived by the user (the Context System)
2. The design of components that realise the emergent behaviour (the system under design)
3. The designing system (i.e. the system being used to do the MBSE).

We often talk about 1 as being the Black-box system, 2 = the white box, and 3 = the process/method/people.

Of course, the way we model the context system is at a level of abstraction above that of white box modelling. This abstraction enables us to manage complexity. If we don't know how the user will use the system, then the chances of us being able to define the internal communication in the system is slim (at least if the system is new this is the case).

Another way of thinking of this abstraction is the why, what, how and who.

Take unlocking a vehicle use case, for example.

The first level to consider is the Why?

We can state the why, i.e. the goal, regardless of the what, how and who: The Driver needs to be able to secure their vehicle from theft. There may be many ways of doing this, of course. Conventionally, one uses a lock, but that doesn't mean that a water cannon that automatically fires when anybody else gets need, would not meet the same objective.

At the user interaction level we might define what a system does. For example, when I unlock the car, I expect the lights to flash.  This behaviour is emergent behaviour realised by multiple components, hence we can consider this to be a functional requirements of a system. The system includes a vehicle and a key. This is essentially a statement of what the system does. System level behaviours are black box requirements. They are realised by multiple components that are not realised by any individual component.

Below this level, is the white box. Perhaps we can think of this as the how (and maybe the who). Which components do what, and how do they communicate to achieve the black-box system level requirements. At the how level we can start to model the internal interactions of the system and allocate behaviour and logical interfaces to individual components.

Another way we could use the Who, of course, is to think of the 3rd system that Scott and Long consider which is the system used to create the system. Perhaps the Who is really the identification of the requirements and behaviours in the components of the system as these components are ultimately defined around people, i.e. as system engineers we write requirements at component level so that we can allocate work to people with some confidence that the work they complete will be valuable in realising the system requirements.

Each of these layers, is a lesson in abstraction. Without abstraction we cannot manage complexity. Abstraction is our friend.