Tag: user requirements

User Requirements usually originate from a User Requirements Document (URD) or User Requirements Specification (URS). This is the main interface document in the customer’s language that defines what the product should do.

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

Thesaurus Day 2018

Thesaurus Day Celebrate Variety

Happy #ThesaurusDay or Should that be “Convivial greetings to all celebrating alternative onomasticon listings day” ?

In pure terms a list of equivalent words or synonyms helps enrich our language. The thesaurus may list a number of alternatives that are subtly different.

Requirements ambiguity

When writing a requirement we have to be careful that we are unambiguous in both our language and meaning.

Language Construct

“The value displayed shall be the total time expended for each activity of a particular type divided by the count of all activities of each type”.  Could be interpreted as

A1 2mins, A2 1min, A3 4mins = 7 mins for type A
B1 3mins, B2 4mins, B3 8mins, B4 1min = 16 mins for type B

Value to display for A = (7 mins / 7 )  = 7
Value to display for B = (16 mins / 7) = 2.3

or as intended

Value to display for A = (7 mins / 3 )  = 2.3
Value to display for B = (16 mins / 4) = 4

In this case we could have removed the ambiguity by using an equation as a synonym for the language.

ValA = sum{typeA.duration} / count{type A}
ValB = sum{typeB.duration} / count{type B}

Meanings

Choices in language can mean different things to different people. This is especially true where suppliers and customers work in different fields. The Customer’s Requirement is their end goal, for the supplier it is the starting point. The Customer asks that the “After the office upgrade and IT installation users should have a clear desk”. Maybe unhindered or unobstructed would have served better?

ambiguity over a meaning
Clear Desk – What was envisaged & what was delivered

Stay SMART(U)

So to celebrate thesaurus day 2018 : Do your best to keep your requirements Specific, Measurable, Attainable, Relevant and Time-bound. Oh and of course Unambiguous, but rich with language.

Posted on

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
Posted on

Role and Representation of User Requirements in Systems Engineering

We are pleased to announce the second in our a new series of white papers that will discuss the role of different types of information in systems engineering processes, and how to deploy each of them in Cradle.

The second white paper in this series discusses user requirements. It is available here:

https://www.threesl.com/downloads/download.php?version=v7.1&section=whitepapers&filename=ra00701-User_Requirements_in_Systems_Engineering.pdf

And as a short link here:

http://ow.ly/4n6nHO

Visit the Resources section of our website: www.threesl.com for this and many other useful resources!

We hope that this white paper is interesting, the next one will appear quite soon!