“You’re a Cab”


Airport Taxi
“Ready for Taxi”

“This is Delta Bravo Twoah Oner Niner, ready for Taxi”
“He’s just on his way now. – Going to Paris Avenue or Road is it ‘guv?”[1]

“Call me a Taxi”[2]
“You’re a Taxi”

“The project output
should be limited  
to 15 rows”        

“I hope we don’t argue anywhere near that much!”

Whilst the examples above are intended to amuse they do highlight the need to be clear about your intention. Whilst they are a play on the English language, translations to and from customers and suppliers can cause equal ambiguity, especially if auto translated.  Using a well known search engine the phrase “The ship shall have a 50m bow” translated to Greek “Το πλοίο θα έχει τόξο 50 μέτρων” and back again “The ship will have an arc of 50 meters” which could easily be interpreted as its turning ability rather than the size of the prow. We just hope they see sense and don’t order yards of ribbon.  The addition of engineering drawings would, in this case have made the design request clear. It could also be achieved by having the requirements in a hierarchical order. If this sentence appeared as a sub requirement of dimensions rather then manoeuvrability.


What is smooth?

Welding Photo by based on Danial Abdullah from Pexels
Smooth Welding

We have previously noted the difference between “should” and “shall”, that which is a desire and that which is a must. However, it is still important to remember the context and understanding of your stakeholders and suppliers. Say you need a framework to support a conveyor belt in a factory, you may contact a steelwork supplier. The required dimensions and weight bearing characteristics could be specified with a clear tolerance and safety margin. You may also specify that ‘all surfaces are  smooth’ . The latter requirement being driven by the need to keep your employees and products from getting cuts or snagged from rough welds or sharp edges.

Your supplier is used to making conveyor systems for use in food and medical supply factories. To them ‘smooth’ implies a high quality stainless steel, with surface pitting limited to parts of a millimetre to allow for hygienic sterilisation. This sort of accuracy and finishing does not come cheap. A bit over the top given your conveyor is only moving some boxes of nails and screws to a palletising area. Whilst this would have given an over manufactured product that fulfilled the brief, it would have been far worse if the customer supplier situation had been reversed.  It is important to remember there are many different view points depending where you sit in the chain. Understanding these differences and making your requirements match can reduce costs and prevent mistakes.


Manufacturing can introduce errors

Even with clear unambiguous instructions, the implementation can still go awry. A requirement for a level concrete shed base that needed to be 13ft by 9ft, given to a local landscaper seemed pretty unambiguous. Dimensions and context were all clear. The site was cleared and the shuttering ordered. The 2″*4″(nominal) timber was cut and assembled. What could go wrong? Each piece of timber had been cut to a fairly precise tolerance. Oops! The width of the wood had not been taken into consideration. The internal width was therefore only 8’8″ and not 9ft…… Luckily this was caught by customer checking before the concrete was poured, otherwise it would have been very difficult to rectify. In many cases manufacture could be too far down the line to amend in the same way as the shuttering was extended. Prototypes and intermediate component validation can all help.


Take AIM

Plan and understand, to avoid requirement failure

  • Avoid Ambiguity use sensible breakdown and context,
  • Ensure all your suppliers and stakeholders make the same Interpretation
  • Check the Manufacture meets the design

Use the right tools to make your job easier and traceable

Don’t try and juggle the data in many different silos. You should ensure your requirements, design, risks, and measurements are held in one linked dataset. Select Cradle and AIM for quality and success.


[1] The term “guv” or guv’ner a contraction of governor a colloquial deference to a ‘boss’ or ‘chief’

[2] The terms “cab” and “taxi” are accepted as synonymous. They refer to a vehicle that can be hired for transportation. Customers are picked up from one location and driven to another, the vehicle is known as a taxicab. The terms “cab” or “taxi” are derived from the same root. Cab is more common in the USA and Taxi more frequently used in the UK.

National Swap Ideas Day 2020

Got an Idea?

Celebrating question mark
Got an Idea?

Swap Ideas Day 10th September 2020 is all about sharing your thoughts and ideas. This could be with colleagues, friends or working partners. However, it may even be that you have a great idea, that does not quite fit into your industry – so why not post it and share it with others?  It could be the spark of something beautiful.

If you have a great idea and want to share it you could tweet us @threesl or you could email us at social-customer@threesl.com. If we like it we may update this post and list it, so be sure to include your company contact details if you want them included.

What if I want to comment on a design, process or implementation detail?

Companies that are involved in design, production, through or end-life support should have a documented way to communicate ideas. Sometimes it is easy to miss the obvious, be blinkered by “that’s the way we have always done it” or get stuck without the vision of how to see ‘outside the box’.

White-boarding / Mind-mapping / Idea pooling / Video chat discussion

Whatever you want to call them these are intended to encourage imagination and creativity. To spark conversation, to record thoughts and to gather ideas. This is the most common point to share.


A formal or informally conducted critique or consideration of a piece of work. This may be with colleagues, customers and/or other stakeholders. It’s aim is to promote comments and question, and thereby to ensure involved are happy with the development at this point in time.  The depth of the review will depend on the stage in the lifecycle and the criticality of the decisions and potential negative impacts if the work is not correct.  It can range from a cursory glance at an email to ensure all the facts brought up in a discussion have been covered, to a minute atomic step through Fagan Inspection.

Change Control

As a product moves through the cycle there may be a need to react to new requirements or changes in project constraints. This could be the results of another review, a technology demonstration, test measurements or supplier issues, which can also lead to a need to change. To prevent a loss of control, this must be a considered and documented process.  This could range from a simple agreement by email, or a formal request and review board approval.

Comments / Feedback

There always needs to be a way to react to changes, new ideas, issues raised by the user or customer. These may be positive “what if” or “could we also” or negative “it doesn’t” or “it really should”. However these arrive, as emails, comments on a social media platform, user feedback sessions, or questionnaires, our process should allow the feedback loop to feed back into the design cycle for consideration.

Tools Support

You’ll no doubt have heard us mention the need to make sure you have the ‘right tools for the job‘ a number of times. So it will be no surprise that  we have made sure Cradle supports these idea stages.

Idea Gathering.

Create an item type that records any meetings you have. You can assign frames to hold images, documents or any other binary data you like. Add some categories with values such as “Status” with values “Candidate” “Dismissed” “Future“. Add a Group or additional category to collect similar topics.


User definable workflows allow reviews to be a simple recording mechanism with one approver, or to require  majority, unanimous etc. decisions. This gives full traceability of the decisions and when and who made them.

Change Control

Cradle supports formal Change Requests CHRs and Change Tasks CHTs.  Which, combined with the review mechanism and workflows, allow you to ensure alterations follow you process and procedures.


Discussions are an ideal way to add comments to any item in the Cradle database. They can be agreed / dismissed and follow a conversational thread  style.

Your Ideas:

If we receive any ideas they will be updated on our blog post here:




Terms and Conditions

Continue reading “National Swap Ideas Day 2020”

Cradle Supports Office – Not Office Apps in the Microsoft Store

Many of us use Microsoft Office to do our document-related work. There are now many versions of Office and many ways to get access to it. For example, you can buy, download and install it. Or, you can do this as part of a subscription service. You can also use simplified Office tools as pure web applications. Or you can use Office as a set of apps from the Microsoft Store. Cradle supports Office, but not the Office apps in the Microsoft Store.

Cradle’s Use of Office

Cradle uses Office tools in several ways:

  • Cradle’s Document Loader tool uses Word to split documents into items in the database
  • Cradle’s Document Publisher tool uses Word to assemble output documents from items in the database
  • Cradle has a plug-in for Excel. You can use this plug-in to load data from Excel into a Cradle database, either as new items or to merge into existing items
  • When you publish reports to HTML and CSV, you can view them in Excel
  • You can publish reports to RTF and view them in Word
  • Print your MBSE models’ diagrams directly to PowerPoint
  • You can link symbols in Visio diagrams to items in a Cradle database
  • Link a Work Breakdown Structure (WBS) in Cradle, bi-directionally, to the activities in a schedule in Project
  • Items in a Cradle database can contain rich text attributes that can be edited with Word
  • Items in a Cradle database can have attributes that can contain, or reference, any type of Office document

So your use of Cradle can be quite closely linked to Office. Hence it is a good idea to have a set of Office tools available when you use Cradle!

Supported Versions of Office

Cradle supports several versions of Office:

  • 2007 (SP3, 32-bit)
  • 2010 (SP2, 32-bit and 64-bit)
  • 2013 (SP1, 32-bit and 64-bit)
  • 2016 (32-bit and 64-bit)

You can install one of these versions of Office on your computer, either by buying it, or as part of an Office 365 subscription. Then, you install Cradle which will connect itself into Office to provide the facilities listed above.

Please do not install parts of different versions of Office. For example, do not install Project from Office 2016 with Office 2013 tools. If you do this, the Cradle installer will not install any of Cradle’s tools for Office.

Office 365

Office 365 is essentially a subscription service through which you can download the latest version of Office and install it onto one or more computers. So Office 365 produces the same result on your computer, you have an installation of Office. Hence Cradle supports Office 365.


The Universal Windows Platform (UWP) apps (previously called Windows Store apps and Metro-style apps) are apps that can be used across all compatible Microsoft Windows devices, including personal computers (PCs), tablets, smartphones, Xbox One, Microsoft HoloLens, and Internet of Things.

UWP apps are primarily purchased and downloaded via the Microsoft Store.

Microsoft Store

The Microsoft Store started as a means to distribute apps created for the Universal Windows Platform (UWP). Now, the Microsoft Store is the name for the consolidation of all of Microsoft’s previous distribution channels, including the Windows Marketplace, Windows Phone Store, Xbox Video, Xbox Music and the Xbox Games Store.


No supported Office version screenshot
No supported Office version

Please note that Cradle does NOT support Office products downloaded from the Microsoft Store.

External Articles

Here are a couple of articles on the differences between Microsoft’s Desktop apps and Microsoft Store apps:

What’s the Difference Between Microsoft Office’s Desktop, Web, and Mobile Apps?

Why ‘Office in the Windows Store’ isn’t really Microsoft Office

Office desktop apps now available for download from Windows Store in Windows 10 S

Is Nineteen a Magic Number?


A Number


It’s a number cardinally one more than 18, and one less than 20. It is a prime number, which some may class as mysterious . It can be prefixed with twenty, to start a long count down, or denote ‘this’ year (’20’-’19’).  Physics considers it one short of being magic in the sequence of nucleons in atomic shells (2, 8, 20, 50). In middle English nynetene derived from the concatenation of nigon + -tīene, but that does not make it magic. It was a political statement in a song by Paul Hardcastle, but it didn’t change the world.  It can be represented as XIX, 0x13, 10011 or |||| |||| |||| |||| but that does not make it magic. In the local shepherd counting dialect Cumbric, a Brittonic Celtic language,  it is Medder-a-Mimph (4 & 15),  which may sound magical, but casts no spell. It is a rather dark grey html color:rgb(19, 19, 19)▉ . Overall, there appears to be little significance to the number 19.

Too Few or Too Many?

However, in terms of Requirements, it could be a magic number. It does depend on your view point.

Dashboards showing ranges where 19 is good, insufficient or bad
19 A magic number?

Our example dashboard shows the same 19 Requirements could be considered Good, Insufficient or Over the top! If our example manufacturer is measuring the number of requirements for their  Information Display Unit, they could conceivably be happy with anything over 15 top level user requirements. Nineteen in this case would be considered in the happy zone and for this project a magic number. However, if these were the internal system requirements, experience tells them anything less than 200 is a bit short on detail 19 is certainly not magic. If these are specific regional variations to the product anything more than 10 may mean this is a different product, is suffering requirements creep and not just a variant, a little too much magic.


It is important to know what you are measuring and why. You can’t just say a number of requirements is good, bad or insufficient, until you know the context. Setting the parameter limits correctly, for the data you are trying to capture and analyse, is as important as capturing the data itself.

Sometimes these values have to be based on gut feeling. It’s better if they can be based on experience and foundationally more sound if they can be based on measured past experience.  So it’s important to remember, you could have a dashboard show you all green, and your project could still be in a rather brown mire.

We would like you to share your thoughts or experiences on choosing limits, or why nineteen is a magic number. We may include your comments in future updates, so please email social-customer@threesl.com


What is Engineering?

Engineering: (en-juhneer-ing)

The formal application of scientific and or mathematical principles to achieve a required goal.

This is quite a broad definition, there are many topics that are derived from the ‘pure sciences’ of  biology, chemistry, and physics and the mathematics behind them. Applying these sciences in different proportions gives us the terms we understand as engineering.  There are few ‘pure scientists’. Most professions require a mix with, say biology and chemistry to produce medicine or foodstuffs. Combine biology with physics to develop a space suit.  Physics and chemistry to produce batteries for your phone or car. Engineering is a mix of all these principles to solve problems and produce solutions.

Application of Science

As we, at 3SL, work (Software Engineers – application of logic and mathematical principles) there’s a construction site outside our windows. When you stop and think, there are a large number of principles being used in this civil engineering project. Definitely a lot of physics and mathematics, were used to calculate the safest ways to demolish the old building. A Police station, used to stand on this site. More science will have been used, by structural engineers, to calculate the forces and stresses in the new structure. A hotel and restaurant is to be built. Similarly the ‘Cast-In-Place’ 20m concrete piles that are being drilled into the ground will have chemical reactions occurring in the cement and ballast mix. These have been calculated and tested to produce the right strength pile to support the building.

You may not find much biology being applied on the site (save the organisms now living in the muddy puddles). However,  the chemicals used in the building from water pipes to paints will have had biological studies to ensure they are human safe, or how to use them safely.  Although,  when we have watched the seemingly graceful ballet of the excavators, diggers and trucks we can’t help feeling that the movements and joints were based on mother nature. The human and the control systems they operate, produce movements and operations which make it hard not to anthropomorphise the JCB!

Old Police station/ new Holiday Inn Express site Barrow-in-Furness
Civil Engineering Barrow-In-Furness

Discovery and Development

The principles used in engineering are or have been, observed empirically, calculated mathematically. They are then proven or developed by experimentation or modelling. The results are recorded and can be used in the next application. Therefore, that field of human endeavour moves forward. Whilst each engineering task will have a new goal, the principles that are applied will be based on the underlying sciences. The old building, that was removed, had different foundations from the new one. Development and testing move our engineering forward. We achieve more as knowledge and principles are built upon.


Engineers need to understand the principles they are applying. Whilst these may be at very different levels, they still require planning and thought. No one would expect the building  to be produced by pressing one button on an ‘app’, but neither would you expect the civil engineers and architects to start experimenting with concrete mixes for every building. That’s not to say that there isn’t a group of engineers experimenting with different carbon fibre additives to give the concrete more strength at a reduced weight; their results being fed upwards to the building design engineers of the future.


The formal application of these scientific principles, is how problem solving engineers meet the requirements. We know this as a design process. The whole being a ‘system’, this is systems engineering.  From the initial ideas and requirements management to the finished article, this engineering step is as crucial as the science principles upon which the solution relies. What ever engineering discipline you are in we hope you’ll agree, from concept to creation Cradle is the best tool you’ll see!

The Tail End

Whilst we agree that every job and every individual in our society plays an important role. There has been a bit of dilution of the ‘Engineering’ term in recent years. There’s a tendency for anything that is remotely technical to be labelled engineering. Anyone who understands which end of a screwdriver to hold gets called an engineer. Whilst I agree that there are chemical and physics principles afoot when I place the food in the pan for tea (dinner if you’re not from up North) and when I use the washing up liquid to clean the dishes, I don’t label myself a Domestic Engineer 😉

If you’d like to share your engineering thoughts for possible inclusion in a blog/Tweet/LinkedIn article, let us know your thoughts social-customer@threesl.com

Discussion Comments.

Continue reading “What is Engineering?”

Remote Workers and Cradle – Connecting with SSH Tunnels

Your company is using Cradle, but you’re a remote worker – how do you connect to the Cradle server?

If you have the Cradle client utilities installed locally without a local CDS then one method, if you have an externally accessible Linux/Unix system is SSH tunnels.

To use SSH tunnels you need to “lock down” the Cradle server to use specific ports, so they’re not randomly allocated from a wide pool.  You can do this in the $CRADLEHOME/admin/ports file.

Make a note of the internal IP address of the Cradle server – we’ll use CDS_IPADDR later in this post to reference this address. (In this test environment it is

Cradle Configuration Changes

As an example of a small Cradle system with 6 users we can configure the ports file as such. (We’re setting ports for each possible user and an extra)


WBENCH_TCP_PORT_NUMBER      = 16170-16176
CWS_TCP_PORT_NUMBER         = 21211-21217

This ports file needs to be copied to all the clients using this CDS.

Putty Configuration Changes

Now we can look at configuring the SSH tunnels. To do this we’ll be using PuTTY – probably the most popular Windows SSH client.

First off, click on the Category Session and enter the hostname or IP of the externally accessible box in the Host Name field.
Now expand the category SSH and click on Tunnels.
For each of the ports configured in Cradle we need to add an entry.
So, for the first one:
Source port  23960
Destination CDS_IPADDR:23960
You can leave the radio buttons alone (set to Local & Auto)
Now click the Add button.

In the Forwarded Ports box you should now have an entry similar to:

Repeat this for all the other ports and we end up with a Forwarded ports section which looks like (if you scroll up and down):

Cradle Putty Tunnel Settings


Click back on the category Session, then add a name to the Saved Sessions and click on Save – so we don’t have to do this again.

If you now click on Open and login to the Linux host.
You can now use your local Cradle client with it pointed to the CDS as being on your local IP.

While you have this SSH session active, you will be able to access the CDS over the SSH tunnels.

Related Articles

Remote Workers and Cradle – how do they communicate?

Count the Shalls

‘Shall’ Counting

“Count the shalls!” This was one of the strangest introductions to Requirements Management that I’ve heard. Firstly as a young engineer I didn’t know what a ‘shall‘ was, let alone why I should count it. For those of you reading this thinking “… no Idea what he’s on about..” let me explain. A crude method of working out the size of a project requirement was to count the number of paragraphs containing the word ‘shall‘. This gave the number of mandatory contractual statements that must be met for the project. Paragraphs containing ‘should‘ or ‘may‘ could be ignored as they were ‘nice to haves‘ rather than obligations.

counting the shalls as a method of determining contractual requirements


There is some logic to the approach, if the statements have been written atomically. However, as a provider one should never presume the customer has written the requirements to the right level for ‘shall counting‘.  For example these two customers’s requirement  sets are wildly different.

  1. The vehicle shall carry a load of 500Kg
  2. The vehicle shall pass legal requirements for use on UK roads.


  1. The pipe insulation shall be provided in 1m lengths
  2. Insulation shall be installable with standard DIY tools such as a craft knife and tie-wraps, and not require specialist equipment.
  3. The insulation shall achieve a thermal conductivity of  0.033W/mK or lower
  4. The insulation shall pass BS EN11925-2 BL
  5. No component material shall be classed as hazardous to health under COSHH regulations 2002
  6. The wholesale price point shall be 20p / m or lower

On a ‘shall‘ count the first project seems easiest just two requirements. But seriously!  would you accept a customer level requirement like this, and price up the work and expect a happy customer?
Have a Ford Transit, job done.
Then you find the customer wants to crane the load on.  Secondly you find they need a tailgate lift to unload it. Additionally you find the product needs weather protection during transit and so on.

The second project has SMART requirements
S pecific
M easurable
A ttainable
R ealisable
T raceable
Count the shalls here, and the measure may be a little more meaningful.

Shoulds and Mays

Can you afford to ignore ‘shoulds‘ and ‘mays‘ ? Contractually you could argue they don’t matter, but in forming a meaningful customer relationship, they are still important. “The insulation should be a mute colour” could contractually be met with vivid red foam, but you’re unlikely to get repeat business.

When the customer has an idea of the implementation (OK, requirements purists, don’t have a coronary) then they are guiding you as to the options they see as most appropriate.  “The vehicle shall have a mechanism to remove the load at a customer site” could be met with a separate fork lift truck being supplied. However “The vehicle may have a powered tailgate lift, or a body mounted mini crane” suggests the customer is seeing these as preferred solutions. In costing a bid these should certainly be considered. However, if your vehicles come with built in vehicle body to floor conveyors, this could still be a viable solution for the customer. After discussion your system requirement, linked to your customer requirement may become “The vehicle shall be fitted with a 800Kg NWL body/floor conveyor ” Of course this requirement would also have extra data within or linked to it minuting the discussion with the customer where they agreed this would meet their requirement.


example of the types of language that should be evaluated automatically
Conformance Checker Settings

There are definitely merits  for someone or something to ‘count the shalls’. If you have 1678 requirements in your project and 1698 ‘shalls‘ you obviously have some non atomic requirements.  Running a Conformance Checker can validate the semantics, across your whole requirement set. What automated tools can’t do is look at the logic and complexity of the requirement. In these cases breaking your customer requirement into a number of domain specific system requirements ensures the level of the requirements against which you bid, design and build are truly SMART. Whilst unsurprisingly we advocate the use of a tool to manage your requirements, to link the User Requirements to the derived or system requirements, we don’t claim a tool will solve the problem of poor specification;  For that you need good, competent engineers, whose job is made easier by using the correct tools.




Building One Brick at a Time

Building your Dream

In the words of Phineas T. Barnum starting with the smallest blocks you can build it “….one brick at a time…”[1] and then you should be able to achieve anything you can dream of.

LEGO bricks based on image from rick mason via unsplash
LEGO® bricks

Consider your ‘dream’ as the top level requirement, this is your ultimate goal. The problem is you’re not sure what constitutes a ‘brick’. Unless it’s a wall you’re building the smallest parts are unlikely to be equal. If only all world engineering problems could be solved with LEGO®! The aim, however is still the same, take the goal and break it down to atomic parts that we can quantify, specify and build. Together those elements will form the whole.

Breakdown Structure

Hierarchies are an important way to describe, link and visualise the ‘dream’ you’re building. The bottom of the hierarchy should be as close to the ‘brick’ as possible. A self contained, unit, the ‘atom’ within your project.


Most people are familiar with a company structure from the MD to the process workers via managers and team leaders workers. Imagine a company where every worker tried to talk to the main boss, as soon as there are more than a handful of employees, this would become unmanageable. Conversely consider too many layers of middle management, all pulling in slightly different directions, then the workers end up without clear direction. It’s a balancing act.

Requirement Breakdown

Your ‘dream’ may be to reach for the stars, or it may be to install the machinery to make spaghetti. In both cases you have an end goal, the main top level requirement. In each case these problems can be broken down into smaller problems, launch, travel and land, or ingredients, process and pack.

displaying hierarchies
A Collection of SBS Hierarchies

These in turn may break down into mechanical, electrical and software problems. The decision as to where to break will depend on the industry you are in, the number of issues that need to be tackled and the logical breakdown of the components. In this comparison, the launch may be considered completely different to the travel or landing requirements. However, in the factory system, it may be more prudent to devolve the level directly into the mechanical and electrical areas as there may be no significant difference between process and packing. Falling out the bottom the atomic ‘bricks’  may now be motors, control sensors, and pipes.

Realistically a more complex project can consider in parallel with the ‘dream’ or ‘User Requirements’, that there are the ‘System Requirements‘ which possibly lead to ‘Derived Requirements‘. These in turn  link to the ‘System Breakdown Structure‘ (SBS) and  ‘Product Breakdown Structure’ (PBS) .


Work Breakdown

Image showing the project plans process
Project plans process

When the problem has been broken down into the smallest conceptual parts the order that these must be assembled can also be broken into a hierarchy. The mechanical systems must be installed before they can be wired, the control systems may be developed in parallel, but they can’t be integration tested until the sensors are installed. A work breakdown structure (WBS) is a plan to ensure that the right bricks are in place at the right time to support the next layer of the structure.


the interrelationship between parts of the project's design and components
Complex Project Dependencies

There will be a complex relationship between each of the hierarchies in your project. If your team of electrical engineers are required to complete two different parts of the WBS they can’t be completed in parallel. This is where plan schedules are useful. Microsoft® Project is one way to achieve a schedule using Gantt Charts to illustrate the sequencing. The links between which System Requirement links to an item in the SBS or which Derived Requirement links to a PBS item must also be maintained.


Therefore, to manage a  big problem it needs to be broken down into smaller atomic ‘bricks’. But the interrelationship of those components is complex and needs to be managed.  Cradle allows all these components to be managed, linked, visualised and reported.  From whatever your original concept, to the final brilliant creation, you can build it one brick at a time.


1.  Lyrics ‘Barnum’ by Michael Stewart.

What is a System?


[sis-tuh m]noun:  an assemblage or combination of things, parts, sub systems, members, operations or principles forming a complex or unitary whole.


To answer the question ‘What is a System?’ you first need to understand your context. When you get down to the ‘atomic’ level for your component parts you’re unlikely to model them any further. A local authority may want to model their transport system. This may include vehicles, termini, and ticketing systems. Whilst their model may include the external specifications of a bus (in terms of weight and width) to plan a terminal, they are unlikely to care whether the bus electrical operates on 24v or 48v batteries.  Unless they have to supply charging points at the depots. The tram’s external specification would again include width, height and mass, but it is very likely that the authority would need to know the electrical operation characteristics in their model if they are responsible for the track.

illustration of systems and context
System Components

The bus manufacturer is not really interested in how the local authority terminal looks or operates. However, they may have design constraints for the width or length imposed by their customer. Being able to identify these parameters in their design will help them design any modifications needed to meet the requirements. Some times there is need for shared information. The ticketing system may be supplied by a third party, both the council and the bus vendor will be interested as part of that system will fall within their responsibility. Ticket sales at the terminal, ticket machines fitted on the bus. The bus manufacturer will undoubtedly model their vehicle, there will be detail plans of what connects to what and what operational parameters are needed for each. In this way if a new component is introduced, it is easier to see the impact. The new air conditioning unit needs 48v supply, the bus currently uses 24v how do we assess the impact and know what is dependent on the current voltage line?

Should I model X?

Whether a system, or sub-system is worth modelling heavily depends on your position in the project chain. Deciding whether this is ‘atomic’ level for you is very dependent on your industry. Assessment should be made as to  the likelihood that parameters of the component may affect higher level systems. The likelihood of whether a subsystem is going to be re-used in a number of different high level systems, and whether stakeholder or external constraints need to be considered.

modelled low level components
Circuit model

If you make capacitors, you’ll have specifications for the capacitor, it’s voltage, capacitance, temperature range and so on. However, there is not much you can model at this level. If you also make wire wound inductors, then it will have similar specifications. However, as soon as they are linked together forming an LC oscillator, you have a system. There are two components who’s characteristics interact. If the LC sub-system is being supplied then the voltage at which it is safe to operate will be dictated by the components within. In this case specifying the inductor and capacitor as blocks with characteristics that form the internals of the oscillator will have a benefit in future design or specifying the operation of the sub-assembly supplied to onward customers. As the vehicle parts designer wanting to make a turning indicator unit, whether the oscillator is LC, RC and Transistor or Op-Amp is of little concern as long as the voltage, current and timing are correct. The oscillator would therefore be the atomic level here. The bus designer is not worried about the indicator unit design as long as the brightness and timing meet regulations and the longevity and power consumption are within performance parameters. They would have no interest in modelling the oscillator.

Model Benefits

Query showing relationships
Linked Specification

The fact that your model contains detailed information of the interconnections, parameters and ranges of your atomic components makes querying your model to analyse change much easier. Being able to identify all components that are expecting the same power will aid a designer in assessing the impact or running a different voltage.

Can you model anything?

Pretty much any system can be modelled. Software was maybe the original stable from which many modelling techniques originated, there is a need to define at what point each module interacts with the other modules. The depth to which the functions are modelled will again depend on the context. There would be no point modelling the printer driver in the system beyond the interface, if that driver is purchased along with the printer hardware. Library functions may be modelled in their own right, but the higher level designer will reference them as white or black boxes.

No one model has to contain everything. The passenger movements, purchases modelled as use cases. The hardware components forming the bus. The sub components forming the indicators. The software controlling the ticket system are all separate systems working as a whole.


Baselines – The end of the road in Configuration Management?

End?, No Way! A Baseline is just the beginning……

Divide and conquer bound, line in the sand

When you have a complex problem, it is always good to ‘set some bounds’1, ‘divide and conquer’2 and ‘place a line in the sand’3. That’s 3 so far on the cliché count, but they are all true reflections of baselines and configuration management processes.

Baselines and Configuration Management. No real life project is static, it never has all the answers available up front and even the most basic of tasks is likely to have a change to its requirements. Changes can range from an alteration of delivery date or change of colour, to a whole change in direction caused by a change in circumstances, finance or regulation. If we’re not careful, project managing this changing landscape4 the ever changing goal posts5 puts project completion at risk.

We need to be clear that the proposed system requirements matched up to the user requirements at a particular point in time. Recording a baseline is that proverbial ‘line in the sand’. A baseline records the conditions at a point in time. The initial user requirements right at the beginning of the project would make an ideal baseline. It gives us a foundation to work from6. From there we can record, measure and control how the project develops. Far from being the ‘End’ of a project lifecycle, a baseline is a really good beginning.

Point of Decision

Now that we have our foundation, we can decide whether it is solid enough to build on. At present it may be more akin to a trench with some hardcore in the bottom, and nothing ready for a wall. However, we can now discuss these baselined requirements/or characteristics before moving on.

A Trench excavation at Winterbrook Oxfordshire - Bill Nicholls [CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons
“Is the wall definitely in the right direction?”,  “Is the wall to terminate at the end of the garden and no further?” (Setting the bounds) “Are you happy for us to quote for the full wall on this basis, or do we need to set a half-way house7 at the first course and then re-evaluate?” (Divided and hopefully conquered).

If all is well we can specify the system requirements and get the concrete poured. This firming up of the foundations8 would be another good baseline point.

Managing Change

“The neighbours have complained, the wall is too short to keep the dog in”.  Back to the drawing board? Not quite, we can go back to the baseline and check what the agreed characteristics of the foundations were. We can’t build the wall higher in solid blocks as the  foundations were not laid with sufficient margin for the extra weight. However, building the top part of the wall in decorative open block-work will meet the changed requirement and satisfy the user. Costs adjusted, new quantities calculated and time to take a new baseline.

Whilst ideally the project would have been planned from start to finish, before the first components were laid, this is not always possible or practical in real life. Recording when and why changes were made will help us make decisions based on firm ground9, rather than walking on sinking sand10.

bricks, wall garden
Garden Wall

Far from being end points, baselines should be seen as stepping stones to your goal11. However, they should not be seen as a linear path. There may be more than one path across the river12, and not all routes will lead successfully to the other side. Assume the neighbour decides to move and takes their dog with them. We can rewind to the baseline taken at the foundation stage and progress down the original planned height in solid bricks as we have the record that this was a possible solution at that point in time12.

Baselines and Configuration Management (CM)

CM is a process that aims to establish and maintain the quality and consistency of a system’s performance, functional, and physical attributes throughout its life. It is tightly linked to the Quality Management System (QMS) and Requirements Management System (RM/REQM) employed on a project. Deciding when and whether items should be baselined, would generally be subject to review (QMS). Providing traceability through the project’s lifecycle also a QMS function. Gathering, eliciting, and decomposing requirements is an RM function. Dealing with change, would need elements of all three. Whilst it may be fun playing cliché bingo, it really is time to place a stake in the ground13 and record milestones in your project14. Don’t delay baseline TODAY!

Related Topics

Custom Workflow for Configuration Management

Configuration Management in Web Access