Understanding CSV User

Requirements

Ivonne del C. Ramos

Senior Quality Engineering Manager,
Validation COE Leader

1 Understand CSV User Requirements| APR 2017|

Course Objective & Approach

Objectives:
• Understand …
o User requirement definition
o Good user requirements
o How to write user requirements
o How to test a user requirement
o How to trace a user requirement
o How to document a failure in a user requirement

Approach:
• Presentation
• Audience Interaction throughout presentation

2 Understand CSV User Requirements| APR 2017|

 Understanding CSV User Requirements

SECTION 1
Define user requirement

3 Understand CSV User Requirements| APR 2017|

Understanding CSV User Requirements
What is an USER REQUIREMENT ?
• An User Requirement describes the business needs. In other words,
what the users require from the system.
 Calculate…
 Consolidate data…
 Control equipment…
 Create reports…

• User Requirements documents are written early in the validation process,

typically before the CSV system is created.
• Intended use indicates how the CSV will be used taking into consideration
what decisions will be made with the output.
• The intended use helps to determine what type of validation activities are
required.

4 Understand CSV User Requirements| APR 2017|

Understanding CSV User Requirements
Typical software requirements specify the following:

• Inputs & Outputs

• Functions that the software system will perform;
• Performance requirements that the software will meet, (e.g., data throughput,
reliability, and timing);
• The definition of all external and user interfaces, as well as any internal software-
to-system interfaces;
• How users will interact with the system;
• What constitutes an error and how errors should be handled;
• Required response times;
• The intended operating environment for the software, if this is a design constraint
(e.g., hardware platform, operating system);
• All ranges, limits, defaults, and specific values that the software will accept; and
• All safety related requirements, specifications, features, or functions that will be
implemented in software.

Taken from General Principles of Software Validation; Final Guidance for Industry and FDA Staff 2002

5 Understand CSV User Requirements| APR 2017|

 Understanding CSV User Requirements

SECTION 2
Good User Requirements

6 Understand CSV User Requirements| APR 2017|

Good User Requirements are…
• Correct.
o Each requirement must accurately describe the functionality to be
delivered.

• Feasible.
o Each requirement needs to be implemented within the known
capabilities and limitations of the system and its environment.
• Necessary.
o Each requirement should document something the users really need
or something that is required for conformance to an external
requirement, an external interface, or a standard.
• Prioritized.
o Assign an implementation priority to each requirement, feature, or
use case to indicate how essential it is to include it in a particular
product release.

7 Understand CSV User Requirements| APR 2017|

Good User Requirements are…
• Unambiguous
o The reader of a requirement statement should be able to
draw only one interpretation of it.
o Multiple readers of a requirement should arrive at the
same interpretation.
o Avoid subjective words like user-friendly, easy, simple,
rapid, efficient, several, state-of-the-art, improved,
maximize, and minimize.

• Verifiable
o Check if you can test or use verification approaches, such
as inspection or demonstration, to determine whether
each requirement is properly implemented.
o Requirements that are not consistent, feasible, or
unambiguous also are not verifiable.

8 Understand CSV User Requirements| APR 2017|

Knowledge Check

• Example #1: "The computer system shall provide

status messages at regular intervals not less than
every 60 seconds.“
o Good requirement or Bad Requirement ?
o Why ?
o What is missing?

9 Understand CSV User Requirements| APR 2017|

Knowledge Check Evaluation

• What are the status messages and how are they supposed
to be displayed to the user?
• The requirement contains several ambiguities.
• What part of the computer system are we talking about?
o Is the interval between status messages really supposed to be at
least 60 seconds, so showing a new message every 10 years is
okay?
o Perhaps the intent is to have no more than 60 seconds elapse
between messages; would 1 millisecond be too short?
o The word "every" just confuses the issue.
o As a result of these problems, the requirement is not verifiable.

10 Understand CSV User Requirements| APR 2017|

Improving the requirement
Example 1 –
• "The computer • The Computer system shall display
status messages in a designated
system shall provide area of the user interface at
intervals of 60 plus or minus 10
status messages at seconds.
regular intervals not
o If background task processing is
less than every 60 progressing normally, the
percentage of the background task
seconds.“ processing that has been completed
shall be displayed.

o A message shall be displayed when

the background task is completed.

o An error message shall be displayed

if the background task has stalled."

11 Understand CSV User Requirements| APR 2017|

Knowledge Check

• Example #2:“ The computer system shall switch

between displaying and hiding non-printing
characters instantaneously.
Good requirement or Bad Requirement ?
o Why ?
o What is missing?

12 Understand CSV User Requirements| APR 2017|

Knowledge Check Evaluation
• It is incomplete because it does not state the conditions that trigger the
state switch.
• Is the software making the change on its own under some conditions, or
does the user take some action to stimulate the change?
• Also, what is the scope of the display change within the document:
selected text, the entire document, or something else?
• There is an ambiguity problem, too. Are "non-printing" characters the
same as hidden text, or are they attribute tags or control characters of
some kind?
• As a result of these problems this requirement cannot be verified.

13 Understand CSV User Requirements| APR 2017|

Improving the requirement

• The computer system Example 2 –

shall switch between "The user shall be able to
displaying and hiding toggle between displaying
non-printing and hiding all HTML
characters markup tags in the
instantaneously.“ document being edited
with the activation of a
specific triggering
condition."

14 Understand CSV User Requirements| APR 2017|

 Understanding CSV User Requirements

SECTION 3
How to write Good User Requirements

15 Understand CSV User Requirements| APR 2017|

How to write Good User Requirements

• The User Requirements Document should include:

• Introduction – including the scope of the system, intended use, key
objectives for the project, and the applicable regulatory concerns
• Program Requirements – the functions and workflow that the system must
be able to perform
• Data Requirements – the type of information that a system must be able
to process
• Life Cycle Requirements – including how the system will be maintain and
users trained

16 Understand CSV User Requirements| APR 2017|

How to write Good User Requirements
• Keep sentences and paragraphs short.
• Use the active voice.
• Use proper spelling, punctuation and grammar.
• Ask a peer to review your requirement. Ask what he understood and think
about if it is what you want to say.
• Avoid long paragraphs. Try to write them individually.
• Check for multiple requirements in the same sentence. The use of and/or
is not recommended (combination of requirements)
• Avoid stating requirements redundantly.

17 Understand CSV User Requirements| APR 2017|

 Understanding CSV User Requirements

SECTION 4
How to test User Requirements

18 Understand CSV User Requirements| APR 2017|

How to test CS User Requirements

• User requirements testing can be very challenging.

• It takes many testers to coordinate
• Require lots of pressure to get sign off from business users.
• Tests have to be properly documented for auditing.

19 Understand CSV User Requirements| APR 2017|

Documentation requirements

Each requirement needs to be traced to a particular test case.

o Check if the test case procedure is clear – someone besides you needs
to be able to follow it and execute.
o Define what will be the objective evidence for the test.
o Check if the test case developed really challenges the intended
requirement.
o One example that could be followed when creating protocols:

User Test Testing Expected Actual Pass/ Fail ? Signature Date

Req # Case # Procedure Results Conditions
observed

Can not de
documented If Fails – need to
Important to define the
using “as make a
traceability matrix reference to the
expected
deviation #

20 Understand CSV User Requirements| APR 2017|

 Understanding CSV User Requirements

SECTION 5
How to trace User Requirements

21 Understand CSV User Requirements| APR 2017|

Traceability requirements

Each requirement needs to be traced to a particular test case.

• Traceability Matrix details the requirement and the corresponding testing.

o Recommendation – If you are not going to test something - don’t include it as part of your
requirements.
o Agencies are giving observations related to inadequate validation when they see that a
requirement was not tested and there is no justification or explanation for it.

• A Traceability Matrix needs to be a quality record.

o Approved.
o Linked to a particular Validation Document or it could be part of one.
o Template – routed and approved.

• It is the most useful document when a Quality Review is performed.

o It helps to detect gaps (missing testing, incomplete testing, inadequate testing, etc.)

22 Understand CSV User Requirements| APR 2017|

 Understanding CSV User Requirements

SECTION 6
How to document a failure in a User
requirement test

23 Understand CSV User Requirements| APR 2017|

Failure documentation

A Validation Deviation is defined as a departure from an established

requirement or planned activity included as part of an approved validation
protocol.
 A validation deviation needs to be documented at the time when it occurred
or when it was discovered.
 Needs to be included as part of the corresponding validation report.
 Needs to be traced to the Test Case and the User requirement.
 Needs to be closed prior to the approval of the report.

24 Understand CSV User Requirements| APR 2017|

Things to be considered when creating a deviation

• Deviation Number
• Protocol #
• Deviation Date
• Deviation Initiator
• Test case and User requirement impacted due to the
failure
• Deviation Description
• Investigation Steps & Root Cause
• Action Plan
• Deviation Impact to the Validation
• Closure documentation

25 Understand CSV User Requirements| APR 2017|

Questions

26 Understand CSV User Requirements| APR 2017|

Thanks !

27 Understand CSV User Requirements| APR 2017|