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?”

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

Right Tool for the Job?

58% of Projects are at Risk due to Poor Requirements Management Tool Selection.

Requirements Management usage info graphic
Mandatory Info Graphic (Requirements Management Tools Usage)

Over half of projects are using spreadsheets and word processing documents to manage their requirements they are taking a large risk.

poll showing who uses what tool
Requirements Management Poll

OK, so the tool  poll was very small and not necessarily scientifically significant, but it does indicate that not everyone has seen the light. And it gives us some data to draw the nowadays ‘mandatory’ info graphic!

As a young student, I remember being introduced to ‘Office‘ applications on a special ‘visit’ to a college. We were shown a spreadsheet and a word-processor. During the hands on task we were all asked to write something. A fellow student completed their piece but couldn’t understand why their work preview looked different to everyone else’s. Whilst all the words were there they were spaced in an odd manner. They’d used the spreadsheet, and entered a word in each cell and changed the columns until the text fitted. Whilst this is laughable now, the fact is the tool still allowed the job to be completed, still allowed the brief to be met. However, the result, using the wrong tool, was not as useful. Imagine trying to cut and paste a sentence into the middle of an existing clause….

A requirements management tool is adapted to aid the flow of requirement through design to testing and end of life. Items are linked in the project’s chain, unlike a design attribute in one document, vaguely referring to some version of a requirement in another.

Would we suggest a Requirements Management tool is needed for all projects?

NO! We wouldn’t, which may sound surprising from a tool vendor. If you make cupcakes and you get an order for 24 cakes 12 blueberry and 12 chocolate we would suggest a spreadsheet with a sheet of costings and a sheet of orders is probably enough, even a diary with the order written in the day before collection day would suffice.  We really don’t want you to spend your money on an inappropriate tool. Spend it on some new icing nozzles and deliver us a batch of cakes. However, if you produce tens of thousands of cupcakes for a number of different vendors and have numerous suppliers, recipes and food standards to meet, well we could conceive of a Cupcake project as a set of Requirements and associated items that needed to be managed. Supplier X changes their ingredient, which products does this affect?

Away from food, before we all feel hungry, we can confidently say that YES the more complex your product, the more components, stakeholders, standards and tests you have to mange, the more important the right tool. The easier traceability becomes, the easier changes can be made and impact calculated. Don’t try laying bricks with a spade, just because you have one in the shed. Don’t try turning precision parts with a drill and a file just because it appears to work. Don’t try and write a novel in EMACS just because it is an extremely powerful text editor . DO use the right tools for the job,

Related Articles

Seeing the light, are you viewing your projects through rose coloured spectacles? Windows and Doors do they need RM (Requirements Management)?

Merging Items Together

Merging Items

One or more requirements or system notes can be merged into either a new item or an existing item. Merging items combines their frames, concatenating frames that appear in two or more of the source items. Cross references are created between the requirements being merged and the merged result.

You can control the effect on the item’s key, origin, reference and category codes. The merged item can be cross referenced to everything that the sources were, as well as to the sources themselves. The source requirements can be deleted after the merge (if you have read-write access to them) if required.

When multiple items are merged, conflicts arise when their components differ. Fields in the Item Merge dialog with a blue border show conflicts between the selected items. The Options section in this dialog helps define how such conflicts can be resolved.

Dialog produced when merging items
Item Merge dialog

Click here to see the steps on how to merge your requirements/system notes.

 

Requirements Management for Windows and Doors?

Requirements Management Isn’t Just For The Big Players.

Your boss says “Don’t be ridiculous you don’t need, requirements management for windows and doors!”…

Your client has asked that the new Town-Lodge is fitted with UPVC doors, windows and fascias throughout. All fire regulations for a medium occupancy building must be adhered to. Locks must have master key and single key access. Glass must meet the company’s privacy specification.  And so on….. Whether you are building a spacecraft with millions of parts with hundreds of engineers, or you’re a firm of three fitters running a building service, you have requirements to manage. The HID (Hierarchy Diagram below) shows that a large number of interdependencies, even for the supply of simple items, quickly builds. Consequently the complexity of managing those requirements becomes more of a task. The requirements for windows and doors to a 20 room Town-Lodge involves glass specifications and safety constraints. These may differ depending on the location and size of the window/door. Planning, using a tool can simplify the traceability of any job.

HID showing how complex even a requirement for a few windows and doors can be complex
Even Windows and Doors Can Benefit from Requirements Management

Managing Change

The quotation has been accepted by the Town-Lodge. However, you were careful enough to note that the price was ‘subject to regulatory change’. When Ref 125-ere-2008 comes up for review and an amendment is raised, it is easy to trace what this impacts. Running a query on the Safety Regulations and showing the linked items, furthermore,  it can be seen these refer to the Emergency Access Windows. The trace shows these are linked to Customer Requirement CR6 and CR8. Finally it is a simple case of writing the email to the Town-Lodge and explaining regulatory change requires thicker glass and this will change the price for these two windows. Then await their approval. Therefore, in answer to your boss, “I can see the future for a tool to give us requirements management for windows and doors – can we buy a copy of Cradle ?”

Running a query to find the impact of a change, requirements management for windows and doors is necessary
Finding the Impact of a Change

Validation and Acceptance

The Lodge has agreed that they will pay when the work has been completed satisfactorily. Prior to starting work you have agreed a set of acceptance criteria. There could be endless tweaks or subjective “I don’t think that’s finished” conversations unless clear acceptance criteria and associated validation techniques have been agreed. Imagine you have a noise reduction requirement, “The noise reduction between the window open and window closed shall be 6dB”. Record the pre-agreed acceptance method as a Cradle item, and link this to each of the requirements with noise acceptance criteria. (This requirement in turn is linked to the rooms that it affects)

  • Noise Reduction Measurement. A white noise generator shall be sited at 1m from the window. The position will be adjusted until a measurement of 80db or more is detected inside the room with the window open at a distance of 1m inside the room. A second reading shall be taken with the window shut and this shall be subtracted from the first reading.

Running a query against the noise test will find all the rooms that this applies to. Now you can make your measurements and record your findings. You now have full traceability for each aspect of the product being delivered to The Lodge. “Dear Boss, Submit the invoice, Cradle aided demonstration to The Lodge site manager that all our acceptance criteria had been met. I think we’ve proved a use for requirements management for windows and doors.”

UK Coffee Week 10-16 April 2017

Supporting Others by Drinking Coffee

The UKCoffeeWeek website supports Project Waterfall which aims to bring clean water to coffee growing communities. Much of the coffee consumed round the world originates from some of the poorest communities. By drinking your coffee during UK Coffee week at one of the participating coffee shops you’ll be putting something back into the communities that helped create your drink.

Do Your Engineers Run on Tea of Coffee?

3SL, producers of the Cradle engineering tool, is based in the UK, traditionally a tea loving nation. However, there has been a marked shift to coffee drinking in all variants. Here at 3SL towers, we have a mix of Tea and Coffee drinkers. Both sides are adamant that their drink is the best….. Take a minute to answer our snap Twitter poll.

 

Happy Pi Day 2017

Misunderstood Requirement Number 3.14159

“The system shall use Pie to calculate the….”

OK so it’s a homophone, caused by a typo. But misunderstood requirements can have a big impact.

Pi Day itself can throw up the question which part of the world do you live in? Today 14/03/2017 specifying in increasing component granularity dd/mm/yyyy is nothing like π. In reverse as UTC 2017-03-14T12:46:14Z again does not have any π significance. However, living elsewhere in the world, as long as it still used the Julian calendar, dates are written differently, if you swap the components to mm/dd/yyyy 3/14/2017 does have a meaning, although we have to skip back in time to 1592 to really tell the joke!

Writing unambiguous requirements is about being clear in your language, precise in your detail and knowing your audience. Otherwise you may end up with Pi on your face…..

photo of a pie
A Tasty Meat and Vegetable Pie

According to piday.org Pi Day is celebrated on March 14th (3/14) around the world. Pi (Greek letter “π”) is the symbol used in mathematics to represent a constant — the ratio of the circumference of a circle to its diameter — which is approximately 3.14159.

Highlight Important Values with Colour

Handling masses amount of data within a project can be very challenging. Especially when only wanting to see certain values. Adding colour to these values is not only simple but very effective.

It is usual for most types of information, particularly user stories, features, needs, requirements, test cases and test results to have attributes that characterise the items, such as:

– The priority or release cycle of a user story
– The result of a test
– The responsibility of a system requirement
– The severity of a risk

It is helpful to colour-code these values and to display the attributes with background or foreground colours set from the attributes’ values. To do this:

1. Define colours for the category code’s values in the schema
2. When the category is shown in a view cell, enable use of colour, either foreground or background

You can choose any colours for your values, but there are obvious advantages in using ‘traffic light’ based colours to convey items that are important, delinquent, serious or failures (typically red) and optional, low, OK, satisfactory or pass (typically green), with orange and yellow used for intermediate values. We typically use a bright blue for unset values, simply because they ‘stand out’.

Highlight Important Values with Colour
Highlight Important Values with Colour

Hopefully after this you can start to implment colour into projects making it easier for everyone locating key data. The cradle help offers in depth detail on topics relating to values in colour.

Article Updated 04/02/2019 – Added intro and conclusion

Clear Requirements

The Problem

The teacher, or your customer, envisages a house built on a hill, they see this as their requirements. In their mind they understand what they want, they have an inherent understanding of how a house should be oriented.

The pupil,  or supplier, may not have the same inherent understanding and this can disappoint the customer.

House 'on' in the loose sense, a hill
Requirement for a house ‘on’ a hill

The Managed Requirements Solution

Managing requirements, managing expectations, ensuring clear and unambiguous understanding creates a successful project and a happy customer.

Furthermore, following a defined process of elicitation, discussion, refinement and validation will ensure all parties are kept in the picture throughout the process. There should be no surprises.

The stages can be generalised as:

  • recording the Customer requirements (what the teacher said);
  • connecting these to System Requirements (what the pupil thinks is the right way to place a house on the hill);
  • reviewing and verifying with the customer that all is clear and understood (the teacher has a chance to see that the relative orientation has not been considered);
  • correction and update;
  • build and validate;
  • Happy customer!

Equally we live in the real world and thing need and do change. A process needs to cope with and manage those changes. These may be customer initiated, corrections as part of the refinement and understanding stage, or external influences.

Control and Managing Change

This could be through a set of documents, but this is not very scalable. The more complex and numerous the requirements, the more difficult it is to manage the inter dependencies between different parts of the document set.

Imagine the simple case in our example:

  • “The foundations shall comply with building regulation ABC”.

It is easy enough to imagine one chapter with some dimensions for the foundations and one building regulation document.

Remaining with the simplistic house:

  • “Kitchen wiring shall provide one outlet for each of the 12 appliances in accordance with regulation GHI(i)”,
  • “Lounge wiring shall provide a multiple in window bay and one outlet in each of the other corners in accordance with regulation GHI(i)”,
  • “Bedroom 1 shall provide one outlet in each corner of the room in accordance with regulation GHI(i)”,
  • “Bedroom2….”

It is still possible to get your head round the interconnects. It will be a bit more time consuming when GHI(i) is up-released to GHI(ii) and building work hasn’t started and you have to check all the items ordered for the socket outlets still comply in each room.

Conclusion

With a small scale step the complexity the above can soon become unmanageable. Our house may only have seven rooms, but what if these were tens of different compartments on a submarine, hundreds shops owned by a national retailer? GHI(ii)- sub section ‘Public accessible spaces’ is upgraded after a regulatory consultation. How many room specifications are affected?

In a managed solution, a simple report on elements dependent on GHI will give a quick way of calculating the cost impact of altering all the specified outlets. If the power outlets had been categorised when the requirements were written with say Public / Employee / Private access, the number affected, and thus the impact to your customer, could have been further refined.

Article Updated 30/01/2019 – Updated formatting

 

Shoulds and Shalls

Conformance Checker

Do you need to validate the quality of your Requirements?  Using Cradle’s Conformance Checker will help you sort the to sort the “shoulds” from the “shalls”. Validate your items’ text  with a set of regular expressions to ensure you have clear statements.

Picture of conformance checker output
Conformance check your “Shoulds” and “Shalls”

Language Analysis

There are numerous aspects you can search for in the Cradle Conformance Checker.

  1. Stipulations such as Shall and Must
  2. Expectations such as Should
  3. Desires such as Might
  4. Continuations such as  As Follows
  5. Exemplifications such as e.g.
  6. Detractions such as Around
  7. Incompletes such as TBD

These can all be altered to suit your language and product / engineering domain. They are written as Regular Expressions (Regexes) through the project setup.