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.
The system developer will map System Requirements to each of the user requirements to define and constrain the system level functionality. Along with additional external references, constraints or standards, this will define the design parameters for the system.
The final deliverable is acceptable if the product can be show to provide each of the user requirements. It would be unreasonable for the customer to expect features outside the original URD scope.
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.
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?
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.
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
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: