October 2019 Newsletter

Spirits, Cauldrons, Witches and Jack-O-Lanterns

Hubble bubble a requirements cauldron
Cauldron

The masses were hungry, they needed a solution. The Requirements Master toiled over her cauldron. Into the mix she added a freshly cut bunch of requirements, a handful of ideas and a sackful of luck. The brew steamed for day and night, and as members of her family walked by they threw in their ha’p’orth of comments.

The requirements soon stewed and disintegrated, but all could see the ideas floating to the top.

The swirling liquor produced a heady vapour, caught by the nostrils of the management team. They liked what they smelled and believed the Requirements Master was doing just fine.

When the soup was dished up to the masses, the flavour was odd, and it didn’t satisfy their hunger. They felt weakened and sad, some even passed over to another project. “A curse has been placed upon this town”, they cried, “the Requirements Master is a Witch!”  The town’s folk lit lanterns to guide the lost souls home to the  land of abandoned engineering.

Well, that’s certainly one way to do design and engineering! But we don’t believe the most successful.  Whilst it is often the case that many ideas are ‘chucked in the melting pot’, it should be used as a tool elicit idea, and not to ‘hopefully solve’ the problem. A more complex mix isn’t necessarily successful. As the tale told, losing sight of the requirements is a dangerous thing. Managing the project by a whiff of success is unlikely to be accurate.

So, don’t fall under the spell of those that don’t know how to engineer, and let Cradle light your way!

Non-Model Items, in a Model

What do we mean by non-model  items? In our system engineering representations specific components of the ‘model’ appear as particular symbols on the diagram. Behind each symbol the specification details the values and characteristics associated with the process/function/store/environment etc. A data definition is used to detail the information in a flow/store/relationship and so on.

The diagram can be cross referenced to the other Cradle components, such as  requirements or user defined system design notes. In this way a requirement could be “modelled by” a particular diagram. A feature “defined by” a state transition diagram and so on. These items, present in the Requirements Management arena are linked but not directly depicted within the model. We therefore class them as ‘non-model’ items.

It is possible, within Cradle, to directly show these items on FAD (Function Analysis Design) modelling diagrams. They can be used to group sub components of the diagram by representing the context within which they reside, or directly showing the item and some of its details. ‘Opening’ the symbol will show the details of the item in a Cradle form.

Screenshot of non-model items on a modelling diagram
Non-modelling Items on a Diagram

For further information on classic modelling, see the Cradle help.

Social Media

Twitter

@ThalesGroup tweet regarding cyber attack prevention on transportation systems
@ThalesGroup Tweet

We postulated over travelling to work in a software controlled transport system, and the damage it could wreak following this tweet from @thalesgroup.

We asked you to get a colleague to quickly draw a hill on a piece of paper and then draw a house on it. How did they do?

That’s all for the October 2019 Newsletter, but if you would like to suggest a topic for next time, drop us a line social-customer@threesl.com.