Understanding CSV User Requirements

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

Understanding CSV User Requirements
SECTION 1
Define user requirement

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.

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

SECTION 2
Good User Requirements

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.

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.

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?

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.

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."

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?

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.

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."

SECTION 3
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

• 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.

SECTION 4
How to test User Requirements

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.

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 #

SECTION 5
How to trace User Requirements

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.)

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

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.

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

Questions

Thanks !

Understanding CSV User Requirements

Uploaded by

Copyright:

Available Formats

Understanding CSV User Requirements

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Understanding CSV User Requirements

Uploaded by

Copyright:

Available Formats

What are the objectives of understanding user requirements?

What are the objectives of understanding user requirements?

What are characteristics of good user requirements?

What are characteristics of good user requirements?

Understanding CSV User

Ivonne del C. Ramos

1 Understand CSV User Requirements| APR 2017|

2 Understand CSV User Requirements| APR 2017|

3 Understand CSV User Requirements| APR 2017|

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

4 Understand CSV User Requirements| APR 2017|

• Inputs & Outputs

5 Understand CSV User Requirements| APR 2017|

6 Understand CSV User Requirements| APR 2017|

7 Understand CSV User Requirements| APR 2017|

8 Understand CSV User Requirements| APR 2017|

• Example #1: "The computer system shall provide

9 Understand CSV User Requirements| APR 2017|

10 Understand CSV User Requirements| APR 2017|

o A message shall be displayed when

o An error message shall be displayed

11 Understand CSV User Requirements| APR 2017|

• Example #2:“ The computer system shall switch

12 Understand CSV User Requirements| APR 2017|

13 Understand CSV User Requirements| APR 2017|

• The computer system Example 2 –

14 Understand CSV User Requirements| APR 2017|

15 Understand CSV User Requirements| APR 2017|

• The User Requirements Document should include:

16 Understand CSV User Requirements| APR 2017|

17 Understand CSV User Requirements| APR 2017|

18 Understand CSV User Requirements| APR 2017|

• User requirements testing can be very challenging.

19 Understand CSV User Requirements| APR 2017|

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

User Test Testing Expected Actual Pass/ Fail ? Signature Date

20 Understand CSV User Requirements| APR 2017|

21 Understand CSV User Requirements| APR 2017|

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

• Traceability Matrix details the requirement and the corresponding testing.

• A Traceability Matrix needs to be a quality record.

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

22 Understand CSV User Requirements| APR 2017|

23 Understand CSV User Requirements| APR 2017|

A Validation Deviation is defined as a departure from an established

24 Understand CSV User Requirements| APR 2017|

25 Understand CSV User Requirements| APR 2017|

26 Understand CSV User Requirements| APR 2017|

27 Understand CSV User Requirements| APR 2017|

You might also like