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.

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

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!