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.

UWP

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?

Nineteen

A Number

19

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.

Conclusion

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.

Application

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.

Process

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 192.168.11.168)

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)

CDS_UDP_PORT_NUMBER = 23960
TOOL_UDP_PORT_NUMBER = 23961
PRJMAN_UDP_PORT_NUMBER = 23962

CDS_TCP_TOOL_PORT_NUMBER   = 16161
CDS_TCP_PRJMAN_PORT_NUMBER = 16162
UTILITIES_TCP_PORT_NUMBER   = 16163-16169
WBENCH_TCP_PORT_NUMBER      = 16170-16176
CWS_TCP_PORT_NUMBER         = 21211-21217
PRJMAN_TCP_PORT_NUMBER      = 16177

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:
L23960     192.168.11.168:23960

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

L23960 192.168.11.168:23960
L23961 192.168.11.168:23961
L23962 192.168.11.168:23962
L16161 192.168.11.168:16161
L16162 192.168.11.168:16162
L16163 192.168.11.168:16163
L16164 192.168.11.168:16164
L16165 192.168.11.168:16165
L16166 192.168.11.168:16166
L16167 192.168.11.168:16167
L16168 192.168.11.168:16168
L16169 192.168.11.168:16169
L16170 192.168.11.168:16170
L16171 192.168.11.168:16171
L16172 192.168.11.168:16172
L16173 192.168.11.168:16173
L16174 192.168.11.168:16174
L16175 192.168.11.168:16175
L16176 192.168.11.168:16176
L16177 192.168.11.168:16177

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
Shalls

Limitations

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.

and

  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.

Solutions

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.

People

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.

Dependencies

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.

Tools

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?

System

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

Context

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
Clichés

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
Foundations
“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

A Holistic View – The Context Diagram

Context Diagram – the world around our project

A context diagram aids visualisation of where a project sits in relation to its external interactions. We don’t want to model those external systems, but we do want to know how they interact with our system.

Automatic wipers for a car don’t need to know how the weather works, but they do need to sense the presence of water on the windscreen. The context would, therefore, include the weather as an external influence with ‘rain’ or ‘rain present’ being signalled to our system. If our company only produces the wiper element the actual car is outside our scope. However, this is where we get our power from and it’s where we will install them so the car is part of our context. The interactions with the car such as ’12v supply’ and ‘user control signal’ are likely to show a part of the holistic context.

Data Flow Diagram (DFD)

In terms of functional analysis and design the DFD shows the external elements with which our main system interacts on the context diagram. This usually has only one process on it, and that is our system of interest.

an example context diagram
Context Diagram – DFD

Taken from the Cradle demonstration project this diagram shows our system of interest is operating the aircraft. The externals that we interact with form the context within which the project operates. This includes the booking system, the fuel suppliers, the control tower and so on.

When the design and analysis are broken down at lower levels, the passenger details or navigation information will have to be handled by parts of the target system. If there is anything that does not balance at the lower levels, then a function must be missing. It implies that we have an input stimulus or an expected output and have nothing to handle or provide it.

Block Definition Diagram (bdd)

Context diagram notations are not restricted to Yourdon, a SysML bdd is also used to describe the context. Information gathered from the use cases and operational scenarios can be used to build a holistic view.

Context diagram shown on a bdd
Context Diagram – bdd

Visual

Whilst not necessary, adding images to your context can aid communication to your stakeholders and customers. They don’t really have to understand the notation to visualise the ‘Passenger’ as a person interacting with the flight. In Cradle, images can be added to the diagram as standalone images, or can actually replace the symbol on the diagram. (The image in the latter will follow all the rules and have the underlying specification of the real diagram element).

The 4 Types of Requirement Confirmation

Every user requirement must be a clearly stated expressions of a stakeholder need for an externally-observable characteristic of the system being developed. Therefore, it must be possible to check that the system we have built satisfies all of its user requirements. Since there are different ways to check things, it is helpful to identify the 4 types of requirement confirmation and to tag all requirements with one or more of these types as early as possible in their development.

the 4 types of requirement confirmation
Verification and Validation in the Systems Lifecycle

Verification and Validation

But first, we need to define some terminology. The terms verification, validation and the acronym V&V are often used for checking compliance with requirements. Sometimes they are used differently, which can be confusing. So, we will define them first:

  • Verification is the activity of checking that the implementation, build or construction of a component, and the system itself, has been done properly. It is the idea of checking that a power outlet has been wired correctly and that it is properly earthed. Verification means to answer the question “have we built it correctly?”.
  • This is a good question to ask, but it does not answer the question “have we built the correct thing?”. That is validation. So, validation means to check that the system conforms to what its stakeholders asked for.
  • V&V is the combination of these two. Depending on your preference, it could mean either Verification and Validation, or Validation and Verification. Most of us in 3SL prefer the second, as it is a little easier to say. The two are equivalent. As a result, V&V simply means to check everything, from the quality of the raw materials, and the fabrication or assembly of components, to the final inspection, configuration, alignment or calibration of the finished product.

The 4 Types of Requirement Confirmation

The 4 types of requirement confirmation are:

  • Inspection, or I
  • Analysis, or A
  • Demonstration, or D
  • Test, or T

We usually abbreviate these types to IADT. They are often called validation methods.

Most requirements will have one of these validation methods, but sometimes a requirement will have more than one.

The Requirements Confirmation Methods

We can describe the 4 types of requirement confirmation as follows.

Inspection

Inspection is the examination of the product or system using basic senses. This means to do one or more of look at it, touch it, smell it (rarely applicable), taste it (even more rarely applicable!). So, we would physically examine a product and check that all its physical characteristics are as required and that it has all of the controls that it is supposed to have. Similarly, for a software system, we would check that its UI is as required, that it has all of the data entry fields and buttons that it is supposed to have. For a web application, we would check its appearance on different screen sizes.

Analysis

Analysis is the validation of a product or system using calculations and models. We will use analysis to make predictions of the product or system’s performance based on some representative, actual, test results. We can use analysis to calculate failure points based on actual test results, without resorting to destructive testing (expensive as we can only do it once!).

Demonstration

Demonstration means that we use the product or system as it is intended to be used. So we can follow the functional user requirements and check that the product or system does what the user requirements say that it should do. We will press every button and use every control in a product to confirm that the product does what it is supposed to do. For software, we enter data as users will do and ensure that the software performs the actions that it is supposed to do and check that its reports are correct.

Test

Test is a more precise and controlled form of demonstration. We test a product to confirm that it behaves precisely as specified under a set of carefully specified test conditions. We repeat these operations using different sets of test conditions, following precisely-specified steps to complete the test. Therefore, this is often to verify performance requirements.

Use in the Process

It is good practice to specify the confirmation criteria for each requirement as it is written. This is because it helps reviewers to confirm that the requirement has been written clearly, by answering questions such as “could I inspect the product and confirm this requirement?”, or “could I demonstrate that this requirement has been met with the finished product?”, and so on.

Once the requirement and its confirmation method(s) are agreed, we can create its confirmation item(s). If a requirement is simple, then it will have one confirmation. If complex, we will create more than one confirmation.

Similarly, if the requirement has multiple confirmation methods, then we will need a confirmation item for each of them.

Therefore, the goal would be a single validation for each requirement, because an atomic requirement (one that says only one thing) should only need one validation.

Of course, both user requirements and system requirements will have a confirmation method. So we would normally talk about validations and verifications, and not the more general term, confirmations. Therefore, we would refer to:

  • The validation method of each user requirement
  • Writing validation items for user requirements
  • The verification method of each system requirement
  • Writing verification items for system requirements

Although it is impossible to generalise:

  • The confirmation methods of user requirements are predominately Inspection and Demonstration
  • The confirmation methods of system requirements are predominately Test and Analysis