Requirements Management is the combination of the requirements capture and requirements engineering activities as repeated over time in the development, delivery, and through life support of a system.
The second RM training this year is – Requirements Management August 2022 course.
“A great opportunity for small teams, or a couple of new team members to get started with RM and Cradle”
Online Course
Businesses that are introducing Cradle and full Requirements Management processes into their operations, can book training for all aspects of the roll-out, from the basics through to specialist administration courses – See here. These courses are tailored and held at your premises / virtually depending on restrictions and requirements and are ideal for getting a team up and running.
Public Requirements Management August 15th to 18th 2022
If, however, you have one or two people new to a project or only have a very small team, this may not be a viable solution. With 3SL’s public online courses, you’ll benefit from all the normal learning, but will have the chance to network and share with other virtual attendees from other industries. This can be a cost effective solution to get you up to speed with Cradle and Requirements Management.
PC/Laptop – internet browser & Cradle installed **
Soft copy course materials, and printed certificate
If you would like to be kept in touch with the details for this Training Course – Requirements Management August 15th to 18th please send an email to salesdetails@threesl.com
“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?
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
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.
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!
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 😉
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.
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
Inspectionis 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
Demonstrationmeans 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 validationsand verifications, and not the more general term, confirmations. Therefore, we would refer to:
The validation methodof each user requirement
Writing validation items for user requirements
The verification methodof each system requirement
Writing verification items for system requirements
Although it is impossible to generalise:
The confirmation methods of user requirementsare predominately Inspection and Demonstration
The confirmation methods of system requirementsare predominately Test and Analysis
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)?
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.
Item Merge dialog
Click here to see the steps on how to merge your requirements/system notes.
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.
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 RequirementCR6 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 ?”
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.”
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.
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…..
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.
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
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
