Category: Articles

Discussion articles about Requirements Management (RM), Model Based Systems Engineering (MBSE). Software tools including Cradle.

Contents of 3SL marketing documents.

Posted on

The Right Mix

A Measure of Quality

“This porridge is too hot, this porridge is too cold, this porridge is just right”

Goldilocks knew exactly what she wanted. Even if she’d not shared her requirements with the bears beforehand.   However the measures made were fairly subjective.

Sand castle right mix
Sandcastle – Right Mix

In other situations it is much more important to get the mix right. Try building a sand castle with sand that is too wet, or too dry and the product fails, and that’s not just an opinion. If that was part of a concrete mix for a new building, you’d want to be sure it was “just right”.

What Is Quality?

Magna Carter image from national archive used under open licence http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/ http://www.nationalarchives.gov.uk/wp-content/uploads/2015/07/37.-Magna-Carta-1297-DL10-197.jpeg
Magna Carter

What constitutes ‘quality’ will vary by product and stakeholder. Some may consider a luxury leather bound volume a ‘quality’ product. It would be wasteful and excessive to use such an expensive resource to write shopping lists. It would be more appropriate to use it to record pledges of office for city officials that will be kept in a permanent archive.

Quality may be best judged by the longevity of writing preserved in the volume’s pages. It will be of little use if its writings fade to invisibility in a few years. Copies of the Magna Carta written on parchment have lasted for over 800 years. This would be unlikely had it been written on cellulose based paper with a disposable ball point pen.

How Do You Measure It?

As part of our validation activity, we will need a way to measure the characteristics that we have decided will be used to describe quality. In our example, we could subject our ledger to an accelerated weathering simulation with cycles of varying intensities of UV light, humidity and temperature. We could then check the integrity of the volume’s bindings, its pages and the contrast of the ink and the page.

With defined quality metrics and measurable values for each metric, the quality of each product can be judged against the metrics and accepted or rejected.

What If I Can’t Measure It?

Ruler Segment - illustrating "Measure"
Measure

There are some things that are much more difficult to quantify. However that should not stop us trying. A customer requirement to have a soft-touch finish on their product could be met by covering it in foam padding, or a velvet cover. These might be acceptable for a chair, but not much use on the handle of a cold chisel. For this quality metric, the customer wanted something to absorb vibrations and so make the tool more comfortable to use. There may be measures of ‘softness’ in terms of compressibility and stiffness, but these may be difficult to use as quantities; You could argue velvet feels ‘softer’ than a rubberised plastic handle, but the latter will compress more than the former.

Be SMART

In some cases to make the requirement SMART (Specific, Measurable, Attainable, Realisable, Traceable) the specific and measurable aspects may be done by comparison, or actually specifying part of the ‘solution’ in the requirement. Whist well written requirements should not mandate the solution. They should be a detailed expression of the needs, allowing the design and production to choose the most appropriate solution. However, this is not always possible. “The chair must be covered in velvet“, is really a constraint, it is unambiguous and would allow the end product to be undeniably validated. However, we could still debate the “plushness” and whether it is made from artificial or natural fibre.

Be Clear

In the case of the chisel, the main product finish may be specified by meeting a design constraint; such as British Standard BS 3066. This will ensure hardness of the cutting edge impact resistance will be suitable. However, the optional handle would not be covered.

We could write, “The handle should be soft to the touch providing good grip and absorbing at least 50% of the impact force when compared to an uncovered chisel. Properties comparable to the material used on the Club hammer CLBHM002 in the same range should be considered.” This time the requirement is not mandating the same material, it is allowing practical consideration as to what is possible in the manufacturing environment. It does invoke a measurable aspect whist not needing to meet specific values. It also highlights the reasons for the specification, to provide grip. If this came to a point of discussion and the supplier covered the handle in PTFE encased foam, it may be soft but would not be considered an aid to grip. However, a rubber, or texturized plastic would both pass muster.

Strive Towards Acceptance

A cold chisel
Cold Chisel

The book on requirements management might tell you about being precise. Even in the trivial examples given we could all spot flaws. How long does the handle need to last? Does the product have to be water repellent? It would be terrible using a chisel with a lovely shock absorbing handle, if it became cold and soggy at the first sign of rain, or when rinsing it clean.

As either a customer or supplier we can mitigate against these problems, by taking a more agile approach to the whole design. Before final design and definitely before production, a round of review of design and validation criteria should be undertaken. Samples of the handle material can be shared with the customer. The baselined requirement can be updated with a new version, to explicitly state “The handle shall be manufactured from a suitably damage tolerant material, providing a good non-slip grip such as EVA – an ethylene polymer“. We have then full traceability that the requirement was updated as a result of design review. We also have a constraint that can be validated.

A Word of Caution

Whilst communicating with  potential suppliers, you also need to ensure a building of trust. Ensure each side has all the correct confidentiality agreements signed. Make sure it is clear who owns the IP on any design. Whilst researching this article, the need to keep your discussions under wraps was highlighted, by Footprint Tools. If details are handed out too freely, you may find a supplier you end up not using plus a competitor buyer,  beats you to market. Unfortunately you may also find if your chosen supplier is less than trustworthy they  could  use your design to create product for another buyer.  Quality in this case applies to the contract and the trust of everyone in the engineering lifecycle chain.

Reference:
Posted on

Will your product be around in 2039?

Where is your product’s future?

Future Vision Harsch Shivam via PEXELS
Future Vision

If this year in 2021 you’re designing flashing wrist bands for the FIFA World Cup in 2022, then it’s unlikely you’ll be worried about your product’s next ‘development stage’ in 2023. Should you be building a house you’d expect greater longevity. You’d hope the architect had designed it to still be standing in 2039, but you would not have expected them to design elements of your house to provide facilities for you to easily add an extension. If you’re designing a router, it’s unlikely that the product will still be in use in 2027, but it is likely that an iteration of your current design will be shipping to your customers.  If you are creating a factory, its likely that decisions you make now will affect how flexible your production line is and how able it is to cope with future developments.

Longevity or Variant Flexibility

There is a difference between designing for a product or product line that needs to last into the future and one that needs to provide a base for a number of variants. They are not mutually exclusive but both have an impact on the effort and cost. Without being mindful of the intended product route, it is not possible to plan for this flexibility. Longevity can also be divided into product longevity and design longevity, both of which can affect your product’s end date.

Flexibility

LEDs on development board Marc Mueller on PEXELS.com
LEDs

Considering the examples above, if you are creating the flashing  wristband and know that you need red, and yellow variants. That’s what the organisers have asked for,  a different colour for the opposing teams. It is also possible, but not yet confirmed, that you’ll need green, orange, and blue variants for the semi and finals, but this is only being ‘talked about’. It would be short-sighted  ordering your integrated chip-on-board circuit with a ‘built in drive resistor’ to provide the 1.8v needed for the LEDs; only to find the green and blue models can not be made.

It would be much better to add a requirement to allow this flexibility by designing the current regulating resistor as a separate component allowing the 3.2v needed for the other colours. This is a flexible design variant, it is known about and has a high probability of being needed. The impact of this on the design is minimal. The cost saving; allowing many different bands to be produced with the same chip-on-board IC; far outweighs the cost of the extra pick and place operation to add the separate resistor.

It would, however, be very unlikely that producing a variant that could be connected to a sounder to ‘beep’,  as well as flash would be produced. Just imagine how annoying the stadium would be filled with beeping noises. The extra cost of designing the chip to have that facility would not produce pay back. That said, if your company  produces other novelties; which include a kids toy that needs flashing and beeping; then you may be able to justify using the same chip design across two product ranges.

In house building,  the variants are likely to be 2, 3 and 4 bedrooms or left and right hand versions of semi-detached, properties. The commonalities providing cost benefits, when ordering anything from windows to staircases.

Design Longevity

Factory Internals on PEXELS.com
Factory

Whilst we expect the house to be still standing, and the factory to still be producing; we’d not be overly surprised if the router had stopped working.

The house design is essentially static. It does not change, unless the architect is commissioned to oversee new builds. In that case they may need to be altered to meet changing building regulations.

The concepts of the router should still be good; there should be aspects of our original design in any current products.

The factory product may well alter, if it’s set up to assemble routers that are around 200mm long by 150mm wide; it would be very short-sighted to design all the conveyors and packing systems to only handle that one size. As soon as the new router design of 150mm by 100mm is required, the whole line would need to be changed. So designing for longevity; making as many of the elements of the system configurable or generic as possible; will allow you to accommodate future variants, even if their details are not yet known. Again a balance needs to be struck; designing  the conveyors and packing systems that ‘might need’ to handle 3000mm wide packages, would plainly be overkill.

Product Longevity

Our house design could be thrown away after the estate is complete. It may not be possible to keep building the same type of house for twenty years. The product, does however need to be designed to last that long. The system requirements must specify materials which will last, no one would seriously want a house built of straw. Just ask the three little pigs… The products we make on the factory line will have their own longevity, this should have been specified at concept. Some elements of the factory may still be the same. It’s the overall design and operation that we needed to last, not necessarily the products being made. If we’d been assembling the wristbands, by now they will hopefully have been recycled, else they clutter in the attic of our house with not a flash left to give.

A Balance

Router by rawpixels on PEXELS
Router

We should not consider longevity and flexibility separately. Take the router itself; designing the board to allow the flexibility of adding  support for a USB device to future variants is good planning. Adding a spare memory socket to allow more caching, to assist with the expected line speed increase with a switch to FTTP is prudent. Designing software and board layouts to cope with an experimental processor and protocols; that only exist in a university study; are likely to be a waste of effort given the expected lifecycle. Designing the software that could still be in use[*] or the basis of the router you will release in 2030, to cope with dates beyond 2038[**] is likely to be worthwhile!

Tool Support

Ensure your design tool allows you to collate, process, link and trace your variants and plan for longevity. Whether this is via an inbuilt mechanism, such as Cradle variants, or by linking longevity requirements as separate items to your main system requirements.

 

*Extremetech.com:Microsoft Windows XP Is Finally Dead, Nearly 18 Years Post-Launch Last official variant (Windows Embedded POSReady 2009) support dropped.

**Wikipedia:Year 2038 problem Seconds since 1970 32 bit integer seconds overflow

 

Posted on

Test, Execution and Recording

“It will work…” (Probably)

Based on Photo by Ksenia Chernaya from Pexels
Passed?

No product manager wants to be confirming their solution’s viability without the backup of evidence. It is imperative to test and assure your process or product. Tests should demonstrate conformance with, all the vital parameters that comprise your design; regulatory compliance; ongoing quality.

This whole quality cycle should include test, execution and recording functions.

Appropriate Testing

Cradle TER module - Test Case
Test Case

We should accept that these tests, and the effort used, should be commensurate with the importance of the design element. There’s every reason to test whether a product can place components with sub-millimetre accuracy if we’re designing a circuit board pick and place machine, but within a few mm is probably good enough for a machine placing variable size apples in a packing crate. When testing the same product used in different situations the complexity and accuracy of the test will change. Measuring the slump and hardness of concrete for a garden path, is probably judged by eye, three level compaction in a cone testing for a road, but you’d expect samples to be taken and lab tested it is being poured to form the main tower of a suspension bridge.

Scope

It is also important to test not only for the expected criteria, but the off-norms (off from normal) too. “The program shall accept user input of their weight in kilogrammes and their height in metres. Their BMI shall be displayed as a ratio of their (weight / height) to two decimal places” The previous requirements can be thoroughly tested for a full range of human weights and heights, but then fall over at the first hurdle when a user enters 0 for their height.

Executing

Cradle TER module - Test Run
Test Run

Once developed, the set of tests may need to be run multiple times on the same product as development tweaks are made, or once on each batch of product to ensure ongoing conformity. Services, procedures and physical products can all be tested. Whether that’s timing the office evacuation during a fire drill or the alcohol content of a batch of whiskey. It is also important to recognise that each execution set may need to be full or a partial set of the tests.   Every safety harness may be subject to visual inspection and, checks on fastener operation. Every tenth to a set of detailed measurements and every two hundredth to a full destruction test. The ability to execute a set of tests from our full suite is therefore important.

 

Recording

Cradle TER module - Test Result
Test Result

Finally the test execution will produce a set of results which should be recorded. Not only does the recording provide the traceability your QA (Quality assurance) plan should aim for, but it will allow you to investigate trends. How many failures were there last month? Were there more or fewer than the previous month. Is investigation required?

 

Cradle

Cradle’s TEST module  (Test, Execution & Recording (TER)) allows you to directly link Test Cases to your requirements, needs, or design elements. You can then define Test Plans and Test Executions to group and run these tests. And as you’d expect the tool will record the Test Results against each Test Step.

For more information download an evaluation copy of Cradle or book a webinar now.

TER video

Posted on

How Risky?

Risk Management

Every project has risks associated with it. They range from the risks to the programme, supply chain, staff, technology; through financial backing and cash flow; to safety and performance of the product. But just how risky is it?

Recording, quantifying, mitigating and reviewing these risks helps reduce their likelihood and severity. The more complex the project the more risks you will need to manage and the greater the range and type that needs to be managed.

Risk Register example
Risk Register

Tools

Tools to manage risk don’t make the risks go away in themselves, a shiny RAG chart does not make a project safe. However, management is all about controlling these parameters. Visualisation and quantifying risks is a management aid to ensure effort is spent in the most appropriate place to give maximum benefit, and also to ensure the smaller issues don’t get completely lost at the periphery.

Parameters That Define Risk

ParameterDescription
Likelihood
The probability of the risk occurring. This could be simply High, Medium and Low, or 9:10, 5:10, 1:10, or Daily, Monthly, Yearly.
Consequence
What impact does the risk occurring pose to the project. Again this could simply be a generic High, Medium and Low or a more ultimate Death, Hospitalisation, Injury or Catastrophic, Severe, Dangerous, Limited.
Magnitude
The importance or priority we assign to the risk given our assessment. These quantities are often associated with colours  e.g. High=Red, Medium=Orange, Low=Green. These would be the colour displayed on your RAG chart.
Dates
Some risks will only be present during certain parts of the project. Funding may only be an issue up to the point that the project is started. Manufacturing defects can be thought about but can’t start occurring until the production run starts, so don’t form part of the overall current profile until that point. Adding start and finish dates to your risks bounds them and allows you to show a chronological profile.

Finally every risk should be reviewed on a regular basis to make sure the parameters have not changed and the mitigations are still valid.

Value
Used to quantify the size of the risk should the risk’s event occur.
Owner
The person or organisation who is responsible for determining the mitigation of the risk and for monitoring how this mitigation is avoiding (negative risks) or promoting (positive risks) the risk’s associated event(s).
Mitigation
There is not much point identifying a risk if we make no effort to reduce it. Unless that is of course because it is below our threshold. The impact is low, and the probability is small and if it did occur the cost is small. In all other cases we should record what it is we intend to do to reduce the risk. We can then re evaluate the risk with the applied mitigation. We dig a hole in the street, likelihood is someone will fall down it, the impact is severe and the value would be expensive. This would generally be flagged as a High priority risk. The mitigation might be to assemble barriers before hole is dug. This does not reduce the severity of a fall or the cost to business, however the probability that someone will fall is drastically reduced, and thus the mitigation leads to a reassessment as a Medium priority risk.

Analysis

By selecting categories for each risk, grouping the likelihoods and consequences we can draw a matrix. A RAM (Risk Assessment Matrix) this provides a uniform method of quantifying the risks.

LikelihoodConsequence
1 – TBD2 – Low3 – Medium4 – High
1 – HighHighMediumHighCritical
2 – MediumMediumMediumMediumHigh
3 – LowLowLowMediumMedium
4 – TBDTBDLowMediumHigh

For each risk we decide the likelihood it will occur (its probability), the consequence of it occurring (its impact) and then look up the magnitude given to the risk (its risk priority). When we then look at the project as a whole, we can see how many of these risks are classed as high or critical. These are areas that need resource and attention first. As noted above if the risks present themselves at different times during the project it is also possible to produce a chronological risk profile.

Visualisation and Profiling

How Risky – Counting

Risk graph example
Risk Count

Risks can simply be counted, and visualised as a graph over time. This gives a good indication of the number of each type of risk we are dealing with at any point throughout the project. However we should concentrate efforts on those most critical risks.

How Risky – Costs

Total risk profile example
Total Risk Count – Profile

Once we have an idea of the number of risks we have for each period of our project we can produce a risk profile.

Unfortunately this does not give us a picture of the overall cost to the project if these risks occur.

Maximum Risk Profile example
Maximum Risk – Profile

By assigning a value to each risk we can work out the overall ‘cost’ whether that be in time delays, money or some nominal value. For any point in time we have a maximum risk exposure.

How Risky – Weighting

Weighted Risk Profile example
Weighted Risk – Profile

However, we also must take a pragmatic view to the consequence of a risk and the effort that is reasonable to expend trying to mitigate it. If we have ten risks that have a fair chance of occurring, and will have an impact on our business, it is likely that we should spend effort mitigating these. Whilst we will want to mitigate against a  catastrophic risk, if its likelihood is “once in a blue moon” the amount of effort expended must be tempered. By assigning a weighting to our risks we can ensure the overall profile is adjusted to be more meaningful. There is no exact science to this but it is a tool to help focus the projects needs.

Mitigation and Review

It is important to record all the decisions and parameters used when assessing risks and designing mitigations. Whether this be reserving funds for an unexpected cost, or adding safety barriers round the hole. We’re sorry to say that adding a high-viz isn’t the correct mitigation for every risk!

Re-evaluate

Once each risk has been calculated and a mitigation has been assigned, its value should be recalculated in light of the mitigation. For example if we had identified a risk that members of the public may fall down holes we are digging to install fibre, our mitigation may include adding plastic barriers round the hole. The probability that a person will fall down a marked and barriers surrounded hole may reduce from a likelihood of  “Highly likely” to “Not very likely“. Whilst the overall count of risks will not have been reduced, the weighted profile will have lowered as although the cost of someone falling down the hole has reduced, the likelihood has been reduced.

Risks and the appropriate mitigations will change over time. This may be because a particular likelihood has increased, an element of the project has been delivered or delayed. So it is important to add review dates into your plan to ensure they are re-evaluated correctly. After all there is no point ordering all those plastic barriers to put round the hole if a project decision to sub contract hole digging was made a month earlier. Therefore you should always be asking “How risky is my project?”

Cradle

Cradle 7.6 introduces a new Risk Management module to help in planning for and managing project  risks. All the aspects above are held in Cradle attributes and each Risk item can be linked to any other Cradle item, e.g requirement, design note, diagram. This will help you manage the risks associated with each element of your project’s needs, and solutions. You can find more in the Risk section of the Cradle manual.

Related Articles

Cradle Risks video

Posted on

Exchanging data/responses with your customers/suppliers

Data Exchange Mechanisms

The data to be exchanged, and the mechanism to be used to exchange it, will depend on the scenario between you and your customer. In this post we will outline the approach that can be used in two main scenarios when one of the parties isn’t using Cradle:

    • One to One – single need to single response
    • One to Many – single need may link to one or more responses

Each of these scenarios can be further varied by being a ‘one off’ or an iterative repeated exchange.

Scenario 1 -One to One

This scenario is where the customer has a list of needs and each need will only have one response, you then have the option of capturing the data only once or capturing the needs and responses multiple times.

Once-only Data Exchange (one to one)

The simplest approach where your customer/supplier has a list of needs, you can then respond to each need with values for the new attributes. One file is exchanged between you and the customer which they incorporate with their needs.

List of needs
List of needs from customer, each with an ID (n#)

Within Cradle you have a single item type for these needs, the item type would  be made up of the following attributes:

Need #Need ID (n#)
NeedText frame to store the need statement
ComplianceCategory to record the compliance of the response
ResponseText frame to store a statement of how it is compliant
List of needs shown in WorkBench
List of needs shown in WorkBench

Responses would then be added to each need, with values for the new attributes, such as the degree of compliance and a statement of how it is compliant.

Response to needs
Response to needs

 

Respones shown in WorkBench
Responses shown in WorkBench

There are a number of ways the response could be sent to the customer / supplier, as a report, a document or using an interchange such as CSV (Comma Separated Values).

Once all your responses are updated the next step is to create an export file to send to your customer.

Use CSV which includes only plain UTF-8 and avoid codepage issues. Only one file needs to be sent which includes:

    • Need #
    • Compliance
    • Response

To make this process easier you can set up export formats with the settings you want so that each time you want to run the process you don’t need to remember what the correct setting is. You can choose to load the export format which will instantly load the settings you have saved.

The customer then merges your response into their needs by importing the file with overwrite set to merge. The customer could also use import formats so each time you supply an update they have the correct import settings.

Repeated Data Exchange (one to one)

Your customer/customer has a list of needs where there are multiple copies for each need, you would then respond with datestamps so that when the customer imports the file the correct needs are updated. One file is exchanged between you and the customer which they incorporate with their needs.

List of need with datestamp
List of needs from customer, each with an ID (n#) and a date

Within Cradle you have a single item type for these needs, the item type would be made up of the following attributes:

Need #Need ID (n#)
NeedText frame to store the need statement
ComplianceCategory to record the compliance of the response
ResponseText frame to store a statement of how it is compliant
Need-DatestampCategory to record need date (ndate)
Response-DatestampCategory to record response date (rdate)
Needs with Datestamp in WorkBench
Needs with datestamp in WorkBench

Responses should then be added to each need, with values for the new attributes, such as the degree of compliance and a statement of how it is compliant. Responses have a datestamp and will overwrite their predecessor when loaded.

Response to need with datestamp
Response to need with datestamp
Responses in WorkBench with datestamps
Responses in WorkBench with datestamps

Once all your responses are updated the next step is to create an export file to send to your customer. There are a number of ways the response could be sent to the customer / supplier, as a report, a document or using an interchange such as CSV (Comma Separated Values).

Use CSV which includes only plain UTF-8 and avoid codepage issues. Only one file needs to be sent which includes:

    • Need #
    • Need-Datestamp
    • Compliance
    • Response
    • Response-Datestamp

To make this process easier you can set up export formats. (See above regarding export formats)

The customer then merges your response into their needs by importing the file with overwrite set to merge. Responses have a datestamp and will overwrite their predecessor when loaded. The customer could also use import formats so each time you supply an update they have the correct import settings.

Scenario 2 -One to Many

This scenario is where the customer has a list of needs and each need may have many responses and/or a single response may be valid for multiple needs. The advantage of this scenario is that duplication of data is kept to a minimum, you also have the option of capturing the data only once or capturing the needs and responses multiple times.

Once-only Data Exchange (one to many)

Where your customer has a list of needs, you then respond with the new item (response) which you can link to a need. The major advantage of this is that a response can apply to more than one need removing the possibility of duplicate data/information.

List of needs
List of needs from customer, each with an ID (n#)
Needs in WorkBench
Needs shown in WorkBench

Within Cradle you have two item types one for needs and one for the responses.

The need item type would be made up of the following attributes:

Need #Need ID (n#)
NeedText frame to store the need statement
ComplianceCategory to record the compliance of the response

The response item type would be made up of the following attributes:

Response #Response ID (r#)
ResponseText frame to store the response statement
ComplianceCategory to record the compliance of the response

Response items would be created for each need with values for the new attributes, such as the degree of compliance and a statement of how it is compliant and linked to the corresponding need.

Response to needs
New items as response to needs

 

Responses in WorkBench
Response 1 linked to multiple needs

Once all responses are updated the next step is to create files to send to your customer. You can send one file which includes the Response #, Compliance, Response and a list of related need #’s. This single file would be loaded from a Word table with the above columns. Or load two CSV plain UTF-8 files, one with responses and the other with links.

Sends 1 file:Response #, Compliance, Response, list of related need #s
Or 2 files:Response #, Compliance, Response
Need #, Response #

To make this process easier you can set up export formats. (See above regarding export formats)

The customer then incorporates your responses with their needs by importing the file with overwrite set to merge. The customer could also use import formats so each time you supply an update they have the correct import settings.

Repeated Data Exchange (one to many)

Where there are multiple copies for each need, you then respond with new items (responses) with a datestamp which you can link to a need. The major advantage of this is that a response can apply to more than one need removing the possibility of duplicate data/information as well as dealing with multiple copies of a need.

List of need with datestamp
List of needs from customer, each with an ID (n#) and a date

 

Needs with Datestamp in WorkBench
Needs with Datestamp shown in WorkBench

Within Cradle you have two item types, one for needs and one for the responses.

The need item type would be made up of the following attributes:

Need #Need ID (n#)
NeedText frame to store the need statement
ComplianceCategory to record the compliance of the response
Need-DatestampCategory to record need date (ndate)

The response item type would be made up of the following attributes:

Response #Response ID (r#)
ResponseText frame to store the response statement
ComplianceCategory to record the compliance of the response
Response-DatestampCategory to record response date (rdate)

Response items would be created for each need with values for the new attributes, such as the degree of compliance and a statement of how it is compliant and linked to the corresponding need.

Response to needs with datestamps
Response to needs with datestamps

Responses are created for each need, each with an ID (r#). Responses
have a datestamp and overwrite their predecessor when loaded. All links to needs are replaced in each load.

Responses with datestamps and multiple versions in WorkBench
Response 1 linked to multiple needs with multiple copies of need 5/8

Once all responses are updated the next step is to create files to send to your customer. You can send one file which includes the Response #, Compliance, Response and a list of related need #’s. This single file would be loaded from a Word table with the above columns. Or load two CSV plain UTF-8 files, one with responses and the other with links.

Sends 1 file:Response #, Need-Datestamp, Response-Datestamp, Compliance, Response, list of related need #s
Or 2 files:Response #, Need-Datestamp, Response-Datestamp, Compliance, Response
Need #, Response #

To make this process easier you can set up export formats with the settings you need so that each time you want to run the process you don’t need to remember what the correct settings are.

Customer loads responses and links each response to the associated needs. If the customer has multiple copies of each need, the need datestamps identify which needs to update. There are a number of options you can use to capture the data:

    • Load a Word table from Microsoft Word®
    • Using two CSV plain UTF-8 files one with responses and another with links
    • An industry-standard like ReqIF
Posted on

“You’re a Cab”

Ambiguity

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.

Interpretation

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.

Manufacture

Manufacturing can introduce errors
Oops!

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.

Posted on

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.

Review

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.

Review

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.

Comments

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”

Posted on

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

Posted on

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

 

Posted on

What is Engineering?

Engineering: (en-juh–neer-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?”